Subnet

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

Public vs. Private Subnets

The most common subnet design pattern splits a VPC into public subnets (which have a route to an internet gateway, allowing resources within them to be directly reachable from and reach out to the internet) and private subnets (which have no direct internet route, typically reaching the internet only indirectly through a NAT gateway for outbound-only access). This separation is a foundational security pattern: application servers, databases, and other resources that don’t need to be directly internet-accessible are placed in private subnets, while only load balancers and other resources that genuinely need to receive inbound internet traffic live in public subnets, minimizing the overall attack surface exposed to the public internet.