Stop Treating AWS Subnets Like Simple IP Buckets

#network #subnet #cloud #aws

If you open up any standard cloud networking textbook, it will tell you that a subnet is simply a logical partition of your VPC's overall CIDR block.

Technically? Yes, that’s true.

But practically? If you view subnets just as buckets of IP addresses to dump your servers into, you are setting yourself up for a massive headache down the line. As an architect, you have to look at subnets entirely differently. They are not just address pools—they are your foundational boundary lines for security posture, traffic flow, and blast radius control.

Let’s break down how you should actually be thinking about your AWS VPC design.

The "Route Table" Mental Model
One of the biggest misconceptions I see when engineers first start building in AWS is the idea that "Public" and "Private" are just settings you toggle when you hit the "Create Subnet" button.

That is not how it works.

The distinction between a public and private subnet is 100% dictated by the Route Table attached to it. A subnet is entirely ignorant of its public/private status until you tell it how to route traffic.

Here is the 3-tier framework you should be using.

1. Public Subnets (The Front Door)
A subnet becomes "public" only when its associated route table has a direct route pointing to an Internet Gateway (IGW).

If a resource inside this subnet has a public IP address assigned to it, it can talk directly to the outside world, and the outside world can talk back. Because this is the wild west of the internet, you want to keep as little in here as possible.

What belongs here: Your Application Load Balancers (ALBs), NAT Gateways, and maybe Bastion hosts (though you should really be using AWS Systems Manager instead).

2. Private Subnets (The Engine Room)
A subnet is "private" when its route table strictly lacks a direct route to an IGW.

Even if you accidentally assign a public IP to an EC2 instance in this subnet, the internet cannot reach it. The routing simply does not exist. However, these resources usually still need to download patches or talk to external APIs. To allow this, you route their outbound-only traffic through a NAT Gateway (which sits in your public subnet).

What belongs here: Your core application servers, internal microservices, and background workers.

3. Isolated Subnets (The Vault)
This is a subnet with no route to an IGW and no route to a NAT Gateway.

This is the strictest network boundary you can create. Nothing gets in from the internet, and nothing gets out to the internet. If you are building scalable Data and AI platforms, this boundary is absolutely non-negotiable.

What belongs here: This is exactly where your backend databases, data warehouses, and core data processing platforms—like your Databricks clusters running on AWS—must reside.

The Dangerous Anti-Pattern: The Flat Network
The most common (and terrifying) mistake I see in cloud networking is the flat network design. This happens when a team places all their workloads into public subnets and relies exclusively on Security Groups (firewalls) to block unwanted external traffic.

Security Groups are incredibly important, but you have to understand a core architectural principle: Security Groups fail open under human error. If a tired engineer accidentally adds an inbound rule allowing 0.0.0.0/0 on port 3306 to troubleshoot a database issue and forgets to remove it, your data is now exposed to the internet.

Subnet routing, however, fails closed. If there is no physical route to the internet defined in the route table, it does not matter how badly you misconfigure your Security Groups. There is zero chance of external exposure. Period. The traffic simply has nowhere to go.

The Takeaway
Subnets define your blast radius. When you sit down to architect a new environment, don't just ask, "How many IPs do we need?" Instead, ask: "What is the sensitivity of the data here, and what is the strictest routing boundary we can enforce?"