How to Design IP Addressing for Amazon VPC and Subnets

Getting your VPC IP addressing wrong is painful to fix later — you can’t resize a subnet after creating it. This guide explains how to design IP addressing for Amazon VPC and subnets so you don’t run out of IPs, overlap with other networks, or waste address space.

How CIDR Notation Works

CIDR (Classless Inter-Domain Routing) defines an IP range using a base address and a prefix length. The prefix length (the number after the /) tells you how many IPs are in the block.

CIDR	Total IPs	Usable in AWS	Typical Use
/16	65,536	65,531	VPC (large)
/20	4,096	4,091	VPC (small) or large subnet
/24	256	251	Standard subnet
/26	64	59	Small subnet (spare AZ, firewall)
/28	16	11	Minimum AWS subnet size

The smaller the prefix number, the larger the block. A /16 is the maximum VPC size AWS allows. A /28 is the minimum subnet size.

AWS Reserved IP Addresses

AWS reserves 5 IP addresses in every subnet. You can’t assign these to instances or resources. For example, in a 10.0.1.0/24 subnet:

IP Address	Reserved For
10.0.1.0	Network address
10.0.1.1	VPC router
10.0.1.2	DNS server
10.0.1.3	Reserved for future use
10.0.1.255	Broadcast (not supported in VPC, but still reserved)

This means a /24 subnet gives you 251 usable IPs, not 256. A /28 gives you 11, not 16. Always account for these 5 reserved addresses when sizing your subnets.

Public vs Private Subnets

A public subnet has a route to an Internet Gateway. Resources in it can get public IPs and be reached from the internet. Use public subnets for load balancers, bastion hosts, and NAT gateways.

A private subnet has no direct internet route. Resources in it reach the internet through a NAT Gateway in a public subnet. Use private subnets for application servers, databases, and ECS Fargate tasks.

The subnet itself isn’t technically “public” or “private” — it’s the route table attached to it that determines this.

Design Example: Multi-AZ VPC

Here’s a practical VPC design using 10.0.0.0/16 spread across two Availability Zones with public and private subnets. This is a common pattern for production workloads.

VPC CIDR

Resource	CIDR	Total IPs
VPC	10.0.0.0/16	65,536

Subnet layout

Subnet Name	Type	AZ	CIDR	Usable IPs
public-az1	Public	us-east-1a	10.0.1.0/24	251
public-az2	Public	us-east-1b	10.0.2.0/24	251
private-az1	Private	us-east-1a	10.0.10.0/24	251
private-az2	Private	us-east-1b	10.0.11.0/24	251
data-az1	Private	us-east-1a	10.0.20.0/24	251
data-az2	Private	us-east-1b	10.0.21.0/24	251

The pattern here is intentional:

• 10.0.1-2.x — public subnets (load balancers, NAT gateways)
• 10.0.10-11.x — private app subnets (ECS, EC2, Lambda)
• 10.0.20-21.x — private data subnets (RDS, ElastiCache)

Leaving gaps between ranges (1-2, then 10-11, then 20-21) gives you room to add a third AZ or additional subnets later without restructuring.

Sizing Tips

• Start with /16 for production VPCs. It’s the maximum AWS allows and costs nothing extra. You’ll thank yourself later when you need more subnets.
• Use /24 for most subnets. 251 usable IPs is enough for most workloads and keeps the math simple.
• Use /20 or larger for EKS/Kubernetes subnets. Pods consume IPs quickly — a busy EKS cluster can exhaust a /24 in minutes.
• Avoid overlapping CIDRs across VPCs. If you ever need VPC peering, Transit Gateway, or VPN connections, overlapping ranges will block traffic. Plan unique ranges per VPC from the start. See Handling IP Address Overlapping in Network Connections for solutions when ranges already overlap.
• Use private RFC 1918 ranges. Stick to 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. AWS supports all three.

Helpful Tools

Use the LinuxBeast AWS VPC Subnet Planner to visualize and plan your subnet layout before creating anything in AWS.

For quick CIDR math, these calculators are useful:

• ipcalc — available via sudo apt install ipcalc on Ubuntu, gives you network range, broadcast, and host count from the command line
• Online subnet calculators like calculator.net or cidr.xyz for visual breakdowns

Conclusion

Good VPC IP addressing comes down to three things: pick a large enough VPC CIDR, leave room between subnet ranges for growth, and never overlap with other VPCs you might connect to.

Once your VPC is set up, you can deploy an EC2 instance into one of your subnets or use Terraform to provision the entire VPC as code.