VPC Subnet Planner
Give it a VPC CIDR, a number of availability zones and the tiers you want. Get every subnet range laid out, with the AWS usable-host count, room left for growth, and an optional Terraform locals block. Checked for overlaps by our own calculator.
subnet plan
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Forgetting the five addresses AWS reserves
Every subnet loses the network address, the VPC router, DNS, one reserved for future use, and broadcast. A /28 gives eleven usable, not sixteen.
Instead:Subtract five when sizing, and avoid subnets smaller than /28.
Allocating overlapping ranges across environments
Peering and transit gateways refuse overlapping CIDRs, and the discovery happens when two teams first need to connect.
Instead:Allocate from one plan up front, including environments that seem unrelated today.
Sizing subnets for today's pod count
The subnet CIDR cannot be changed after creation. On EKS every pod takes an address from it, so a subnet sized for nodes runs out at the pod level.
Instead:Size generously. Address space inside a private VPC is free.
What it does for you
Subnet arithmetic is not hard, it is just tedious and unforgiving, and the mistakes are permanent in a way most infrastructure mistakes are not.
Every block, allocated and checked
Give it a VPC and the number of availability zones, and it lays out one subnet per tier per zone with exact ranges. Then it feeds the whole set back through our CIDR calculator, so the claim that nothing overlaps is checked rather than asserted.
Headroom on purpose
Auto sizing splits the VPC into the next power of two above the subnet count, which usually leaves a chunk unallocated. That is the point: it is where a fourth availability zone or a new tier goes later without renumbering anything that already exists.
Tier-major allocation
All the public subnets, then all the private ones, then the databases. Each tier stays in one contiguous run, so a tier can be widened later without stepping on another. It also makes route table associations readable at a glance.
The AWS host count
Usable addresses are reported the way AWS counts them, which is five fewer per subnet than standard networking: the network address, the VPC router, DNS, one reserved for future use, and broadcast. On a /28 that is the difference between 16 and 11.
Terraform, optionally
Tick the box and the plan comes with a locals block in the shape terraform-aws-modules/vpc expects: vpc_cidr, azs, and one list per tier. Paste it in and the module does the rest.
It refuses impossible plans
Twelve subnets do not fit in a /24, and AWS will not accept a subnet smaller than /28. Rather than emitting something that fails at apply time, the planner says what is wrong and what to change.
Plan for the VPC you will have
The instinct when allocating addresses is to be tidy, filling the VPC neatly with exactly the subnets you need today. It is the wrong instinct, because subnet ranges are one of the few things in cloud infrastructure that cannot be changed once anything is running in them.
Everything else is a config change. A subnet is not: you create a new one, move every workload, update every route table and security group reference, and delete the old one. Teams postpone that for years, which is why so many VPCs have a fourth availability zone bolted on somewhere numerically absurd.
Address space in RFC 1918 is free and enormous. Take a /16, use a quarter of it, and leave the rest alone. The plan this page produces tells you exactly how much you have left and where it starts.
How do you lay out subnets in a VPC?
Subnetting arithmetic is the easy part, and the CIDR calculator on this site explains it. The harder question is the layout: how many subnets, how big, in what order, and how much space to leave alone. Those choices are close to permanent, because renumbering a VPC that has running workloads in it means rebuilding it.
One subnet per tier per availability zone
The standard shape is three tiers: public, private and database: across two or three availability zones, giving six or nine subnets. Public subnets hold load balancers and NAT gateways, never workloads. Private subnets hold the workloads and route outbound through NAT. The database tier gets no route to the internet at all, and RDS needs at least two of them in different zones before it will accept a subnet group.
eu-west-1a eu-west-1b eu-west-1c
public 10.42.0.0/20 10.42.16.0/20 10.42.32.0/20
private 10.42.48.0/20 10.42.64.0/20 10.42.80.0/20
database 10.42.96.0/20 10.42.112.0/20 10.42.128.0/20Allocate tier by tier, not zone by zone
Keeping each tier in one contiguous run means a tier can be widened later without stepping on another, and a single route table entry or security group rule can cover a whole tier. Interleaving by zone instead scatters each tier across the block, so any later change needs a separate rule per subnet. Both layouts are arithmetically identical and only one of them is still workable in two years.
Leave space on purpose
A plan that fits the VPC exactly has nowhere to put a fourth availability zone, an EKS cluster that wants its own subnets, or a tier nobody has thought of yet. Deliberate headroom costs nothing: private address space is free and a VPC is not billed by size, and it is the difference between adding a subnet and rebuilding a network. The planner above leaves the tail unallocated for exactly this and shows you how much.
Size for pods, not for instances
The usual instinct is to count instances and pick a subnet with room to spare. On EKS with the VPC CNI that is wrong: every pod gets a real VPC address, so a node running fifty pods consumes fifty addresses. A /28 has eleven usable addresses in AWS and one busy node can exhaust it alone. If EKS is in the picture, size the private subnets by peak pod count and add a wide margin.
/24 subnet 251 usable in AWS
~5 nodes at 50 pods each, and it is full
/20 subnet 4,091 usable
room to grow the cluster without renumbering