How to Make AWS Infrastructure Invisible to Unauthenticated Reconnaissance

An internal dashboard should not need a public login page just because someone outside your VPC needs to use it. With LayerV, keep the HTTP origin private, publish it as a resource, and send access for the task.

The resource gets a Cryptographic Resource ID (CRID). A qURL™ carries a separate, signed access grant. Your code can create a fresh link for a customer preview, an operator task, or an AI agent without turning the origin into a permanent public destination.

That change has two parts: AWS controls keep the origin private; LayerV controls access to the published resource. Changing DNS alone does not close an existing public endpoint.

Start with the Origin#

AWS already provides ways to restrict network access. Security groups control allowed traffic; internal load balancers and private endpoints can keep services off public routes. LayerV works with those controls.

| Resource | What to check before publishing | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | HTTP app on EC2 | Bind it to loopback for the CLI walkthrough below. Check instance security groups and any load balancer that also reaches it. | | Application Load Balancer | Use an internal deployment where appropriate and restrict its security group. A different DNS record does not disable an internet-facing ALB. | | API Gateway | AWS supports private REST APIs through VPC endpoints. A private backend integration alone does not make the API's front door private. | | EKS Kubernetes API | Configure the cluster's endpoint access explicitly. A browser access link is not a documented drop-in replacement for kubectl connectivity. |

Use the AWS guides for ALB security groups, private REST APIs, and EKS endpoint access. Check routing, TLS, application authentication, and client compatibility before migrating a managed service. The walkthrough here demonstrates an HTTP app on an EC2 host; it does not configure ALB, API Gateway, EKS, or database access.

Publish an HTTP App from an EC2 Host#

Use a host where you can run the CLI and your app. Keep your existing administrative access while you test.

1. Follow the CLI quickstart on the EC2 host. Sign up or sign in to create an account API key with qurl:agent and qurl:resolve, then run qurl login. If the CLI reports missing connection settings, get a deployment file from LayerV and set QURL_DEPLOYMENT to its path before login.
2. Start your HTTP app on 127.0.0.1:3000. Use your app's actual port. Confirm it works locally, then keep it running.
3. In a second terminal, run qurl publish http://127.0.0.1:3000. Save the full CRID printed when the route is ready.
4. Run qurl share <CRID>, replacing the placeholder and brackets with that CRID. Send the returned link privately.
5. Open the link in a browser from the recipient's machine. The recipient needs no LayerV account or CLI; your application's own sign-in still applies.

Keep the app, host, and background publishing process running. The CRID identifies the resource and grants no access by itself. The access link is a bearer credential: anyone who obtains a usable link can attempt to redeem it. Link expiry and the resulting session's duration are separate controls.

Verify the Boundary#

Test both sides of the result: an authorized recipient can use the app, and the app cannot be reached through an old public path. Check the instance address, load balancer, default service endpoint, and any other route that reaches the same origin. Close unintended public routes through the relevant AWS configuration, then test again.

Check configuration and actual application reachability together. Scan results depend on routing and filtering, and public LayerV services remain reachable. Historical DNS and certificate records can also remain after an origin becomes private. What matters is that those records no longer give an unauthenticated caller a direct path to your application.

Make Access Part of the Work#

An outbound connection is useful, but it is not the whole product. Tunnels and other private-access systems can also keep origins private. LayerV combines a cryptographic resource identity with a signed grant that your application can issue for a particular task.

Publish the resource once, then use the SDK or API to create links with expiry and use limits. Revoke links when the work changes. Retain application authentication where you must verify the person's identity. This makes private resource access something builders can create and withdraw from code.

Start with one internal HTTP application, verify its private origin, and give the next collaborator access to that resource.