Subnet
A slice of a VPC bound to one availability zone — the unit where routing, exposure, and blast radius are actually decided.
What is a subnet?
A subnet is a contiguous CIDR block carved from a VPC, and in AWS it lives in exactly one availability zone. That AZ binding is the underappreciated half of the definition: subnets are how architectures become multi-AZ. “Deploy across three AZs” concretely means “create three subnets per tier and spread instances across them.”
Public versus private is a routing fact, not a checkbox
Nothing on a subnet says “public.” A subnet is public purely because its route table sends 0.0.0.0/0 to an internet gateway; it’s private because it doesn’t. The standard three-tier pattern follows: public subnets hold only load balancers and NAT; private app subnets reach the internet outbound via NAT gateway; isolated data subnets route nowhere external at all. Databases with public IPs — still a leading breach cause — are almost always a subnet-placement mistake, not a firewall mistake.
Sizing and layout in practice
Plan per-AZ symmetric blocks (e.g., a /20 VPC region cut into /24s per tier per AZ) and leave headroom: EKS and ENI-hungry services blow through small subnets. Route tables associate per subnet, so your tiers are only as real as the table associations backing them — one misassociated subnet quietly makes a “private” tier public.
What people get wrong
- One giant subnet — no isolation tiers, no per-tier routing, and a single AZ’s failure domain.
- Asymmetric AZ coverage: a load balancer in three AZs pointing at app subnets in two produces cross-AZ latency and uneven load.
- Ignoring the five reserved IPs in every AWS subnet when capacity-planning small ranges.
Primary source: AWS VPC documentation — subnets
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.