How to Make AWS Infrastructure Invisible to Attackers

Right now, someone is scanning your AWS infrastructure. Shodan indexes new endpoints within hours. Censys maps the internet continuously. Automated scanners run 24/7 looking for publicly accessible ALBs, API Gateways, EC2 instances, and EKS API servers.

When they find yours, they'll fingerprint the software version, probe for known CVEs, test default credentials, and add it to a target list. All of this happens before you get a single alert.

Security groups and NACLs filter traffic, but they don't hide your infrastructure. A scanner can still see that your ALB exists at a specific IP, that it's running a specific software stack, and that it's accepting connections on specific ports.

What if they found nothing?

The Problem with Visible AWS Infrastructure#

Every AWS resource with a public endpoint has attack surface:

Application Load Balancers (ALB): Public DNS name, open ports (80, 443), SSL certificate revealing domain names. Scanners identify ALBs instantly.

API Gateway: Public endpoints with discoverable paths. Even with API keys, the endpoints are visible and can be enumerated.

EKS API Server: The Kubernetes API endpoint is reachable from the internet by default. Even with RBAC, the endpoint itself is a target.

EC2 Instances: Any instance with a public IP or Elastic IP is scannable. Even with security groups, port responses reveal the instance exists.

RDS Instances: If publicly accessible (even "accidentally"), the database endpoint is discoverable and targetable.

AWS-native security (Security Groups, NACLs, WAF) operates on visible infrastructure. It filters traffic after your resources are already discovered. This is defense — not prevention.

Making AWS Resources Invisible#

Network hiding removes AWS resources from the internet entirely. Protected resources have zero network presence — Shodan returns nothing, Nmap returns nothing, DNS queries return nothing.

Here's what this looks like for common AWS resources:

Protecting an ALB#

1. Point your domain's DNS at LayerV's proxy instead of the ALB
2. The ALB becomes unreachable from the internet
3. Authorized users authenticate via Okta, receive a QURL, and access the ALB through LayerV's tunnel
4. The ALB is invisible to everyone else

No AWS configuration changes. No agents. No sidecars. One DNS change.

Protecting an API Gateway#

1. Configure a custom domain pointing through LayerV
2. API endpoints become invisible to unauthorized traffic
3. Authorized consumers (users, services, AI agents) access APIs through QURLs
4. Scanners and bots find nothing

For machine-to-machine access, QURLs can be created programmatically via the QURL API with configurable expiration and access policies.

Protecting an EKS API Server#

1. Route the EKS API endpoint through LayerV
2. The Kubernetes API becomes invisible to the internet
3. Authorized operators access it through time-limited QURLs after SSO authentication
4. kubectl and other tools work normally through the QURL tunnel

This eliminates one of the most dangerous attack vectors in cloud infrastructure: a publicly accessible Kubernetes API server.

What This Looks Like to an Attacker#

Before LayerV:

$ nmap -sV your-alb.example.com
PORT    STATE SERVICE VERSION
443/tcp open  https   Amazon ALB
80/tcp  open  http    Amazon ALB (redirect)

After LayerV:

$ nmap -sV your-alb.example.com
All 1000 scanned ports on your-alb.example.com are filtered
Nmap done: 1 IP address (0 hosts up)

Not "connection refused." Not "filtered by firewall." Zero response. The host appears non-existent.

Beyond Security Groups#

Security Groups and NACLs are essential — they're your baseline. But they operate after discovery:

| Control | Prevents Discovery? | Prevents Probing? | Prevents Targeting? | |---------|---------------------|-------------------|---------------------| | Security Groups | No | Partially | No | | NACLs | No | Partially | No | | WAF | No | No | Partially | | VPC Private Subnets | Yes (requires VPN) | Yes | Yes | | Network Hiding | Yes | Yes | Yes |

VPC private subnets are the closest AWS-native equivalent, but they require VPN or Direct Connect for access — which reintroduces the VPN attack surface. Network hiding provides the same isolation with per-resource, time-limited access through QURLs.

Getting Started#

The fastest way to see this working:

1. Try the QURL Playground — 30 seconds, no signup
2. Sign up free — 500 QURLs/month
3. Point one domain at LayerV — your first resource becomes invisible in minutes

Your AWS infrastructure is being scanned right now. Make it disappear.