AWS VPC Subnet Calculator

When you create a VPC in AWS you have to decide upfront how to divide your IP block into subnets. Getting this wrong means running out of IPs in a busy subnet while other subnets sit mostly empty. This calculator uses VLSM to allocate exactly the right block size for each subnet — the same logic AWS architects use when planning production environments.

Enter the IP address block that AWS will assign to your VPC. This is the total pool all subnets will be carved from.

1. 1Enter a VPC Base IP — typically a private RFC 1918 address like 10.0.0.0, 172.16.0.0, or 192.168.0.0.
2. 2Drag the CIDR slider or type a Subnet Mask. AWS VPCs support /16 to /28. A /16 gives 65,536 addresses — the most common choice for production VPCs.

Type how many subnets your VPC needs into the No. of Subnets box and click Generate Rows. One blank row appears for each subnet — fill in the four fields for each one:

1. →Subnet Name — a label you will recognise in the AWS console, for example web-public-1a or db-isolated-1b. Use a consistent naming scheme across your team.
2. →Availability Zone — type the AZ exactly as AWS names it, for example us-east-1a or eu-west-1b. This field is free-text so you can use any region and any AZ naming convention.
3. →Type — type public, private, or isolated. Public subnets face the internet via an Internet Gateway. Private subnets reach the internet only through a NAT Gateway. Isolated subnets have no internet route at all — for databases and internal services.
4. →Hosts Needed — the number of resources you expect to place in this subnet. Size generously — you cannot expand a subnet after it is created in AWS. The calculator rounds up to the nearest power-of-2 block and deducts the 5 AWS-reserved addresses automatically.

Click Generate Plan. The calculator allocates subnets from largest to smallest (VLSM order) to minimise gaps, then shows you the complete IP layout. Here is what each column means:

1. →Subnet Name / Type — your label and a colour-coded badge (green = Public, amber = Private, red = Isolated).
2. →AZ — the Availability Zone you selected.
3. →Network (CIDR) — the exact CIDR block to enter in the AWS console when creating this subnet.
4. →Total IPs — the full size of the block including AWS-reserved addresses.
5. →AWS Reserved — always 5. Shown separately so you can see exactly what AWS takes.
6. →Usable IPs — what you can actually assign to resources. This is Total IPs minus 5.
7. →Netmask — the subnet mask in dotted-decimal format.

A few rules that AWS and AWS Well-Architected Framework recommend when sizing subnets:

1. 1Size up, not down. You cannot resize a subnet after creation. It is better to allocate a /24 (251 usable) when you only need 50 hosts today — you can always leave addresses unused.
2. 2Keep subnets within one AZ. AWS subnets span exactly one AZ. Create one subnet per tier per AZ — not one shared subnet across AZs.
3. 3Public subnets can be smaller. Public subnets typically hold load balancers and NAT Gateways — not application instances. A /27 or /28 is often enough.
4. 4Private subnets need the most space. Application servers and containers scale horizontally. Give Private subnets the largest blocks (/22 or /23) so auto-scaling groups have room to grow.
5. 5Reserve space for the future. Leave at least 25–30% of your VPC CIDR unallocated. AWS lets you add a secondary CIDR later but the primary range is fixed.

AWS reserves the first four and the last IP address in every subnet. In order: the network address, the VPC router address (.1), the AWS DNS server (.2), an address reserved for future use (.3), and the broadcast address (last IP). These five are unavailable to your instances regardless of subnet size — a /28 with 16 total addresses only gives you 11 to use.

Use a private RFC 1918 range — 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. For most production environments, a /16 from the 10.x range is the standard starting point. It gives 65,536 addresses and enough room to add secondary CIDRs later. Avoid ranges that already exist in your data centre or other VPCs you might peer with in future.

A Public subnet has a route to an Internet Gateway — resources inside get a public IP and can communicate directly with the internet. A Private subnet routes outbound traffic through a NAT Gateway in a public subnet, so instances can download updates and call external APIs but are not reachable from the internet. An Isolated subnet has no internet route at all — it is used for databases and internal services where any internet connectivity is a security risk.

No. Once a subnet is created in AWS its CIDR block is permanent. The only way to change it is to delete the subnet and create a new one — which also means terminating any resources inside it first. This is why careful upfront planning with a tool like this one matters. It is far easier to adjust numbers here than to rebuild a live environment.

AWS recommends at least two AZs for high availability. Most well-architected production workloads use three — if one AZ has an outage, two-thirds of capacity remains. Each AZ gets its own set of subnets (public, private, isolated), so three AZs means nine subnets for a standard three-tier application. The calculator supports all three major AZs for the most common AWS regions.

The minimum subnet size in AWS is a /28, which has 16 total IP addresses. After the 5 AWS-reserved addresses, you have 11 usable IPs. This is acceptable for small infrastructure subnets — a NAT Gateway only needs one IP, and a VPN endpoint rarely needs more than a handful. Do not use /28 for application or container subnets that might need to scale.