Choosing the wrong CIDR block for your AWS VPC is one of those decisions that haunts you months later. Unlike most cloud configuration mistakes, you can't simply delete and recreate a VPC CIDR — it affects every subnet, security group, route table, and peering connection in your architecture.
This guide covers everything you need to plan VPC CIDR blocks correctly the first time — including sizing, subnet tiers, reserved IPs, multi-AZ design, and the most common mistakes that trip up even experienced engineers.
What is a VPC CIDR Block?
A VPC (Virtual Private Cloud) CIDR block defines the range of private IP addresses available to your AWS network. CIDR stands for Classless Inter-Domain Routing — it uses a slash notation to specify how many bits represent the network portion of an address.
For example:
10.0.0.0/16— 65,536 total IP addresses (the most common VPC size)10.0.0.0/24— 256 total IP addresses10.0.0.0/28— 16 total IP addresses (minimum allowed VPC size)
When you create an AWS VPC, you must choose a CIDR block. AWS allows VPC sizes between /16 (65,536 addresses) and /28 (16 addresses). Once created, you cannot shrink or replace the primary CIDR — you can only add secondary CIDR blocks later.
AWS Reserved IP Addresses Per Subnet
This is the fact that surprises most engineers during their first AWS deployment: AWS reserves 5 IP addresses in every subnet, not just the network and broadcast addresses you'd expect in traditional networking.
For a subnet with CIDR block 10.0.0.0/24:
| IP Address | Reserved For |
|---|---|
| 10.0.0.0 | Network address |
| 10.0.0.1 | AWS VPC router |
| 10.0.0.2 | AWS DNS server |
| 10.0.0.3 | Reserved for future AWS use |
| 10.0.0.255 | Broadcast address (not supported in VPC) |
This means a /24 subnet gives you 251 usable IP addresses, not 254. A /28 subnet (16 total) gives you only 11 usable addresses.
Always factor AWS's 5 reserved addresses into your subnet sizing calculations.
Choosing the Right VPC CIDR Size
The RFC 1918 Private Ranges
AWS strongly recommends using the RFC 1918 private address ranges:
10.0.0.0/8 — 10.x.x.x addresses (largest range)
172.16.0.0/12 — 172.16.x.x to 172.31.x.x
192.168.0.0/16 — 192.168.x.x (smallest, avoid for AWS)
For AWS VPCs, 10.0.0.0/8 is the most flexible. You can carve it into multiple /16 VPCs across regions and accounts without running out of space.
VPC Size Recommendations
| Use Case | Recommended VPC CIDR | Usable IPs |
|---|---|---|
| Production workloads | /16 | ~65,000 |
| Staging environment | /20 | ~4,000 |
| Development environment | /22 | ~1,000 |
| Small isolated service | /24 | ~250 |
| Testing only | /26 | ~60 |
The golden rule: Always go one size larger than you think you need. IP address space in a VPC is free — running out of addresses after deployment is an expensive migration problem.
Subnet Tiers — The Three-Layer Architecture
Almost every production AWS VPC follows a three-tier subnet pattern:
Public Subnets
Connected to an Internet Gateway. Hosts load balancers, NAT Gateways, and bastion hosts. Resources here have public IP addresses.
Typical size: /24 per Availability Zone (251 usable IPs)
Private Subnets
No direct internet access. Hosts application servers, ECS tasks, EKS nodes, and Lambda functions. Outbound internet via NAT Gateway.
Typical size: /22 per Availability Zone (1,019 usable IPs)
Data Subnets (Isolated)
No internet access at all — not even outbound. Hosts RDS databases, ElastiCache clusters, and other data stores. Locked down with strict security groups and NACLs.
Typical size: /24 per Availability Zone (251 usable IPs)
Full Example — Production VPC
Starting CIDR: 10.0.0.0/16
Public Subnets:
us-east-1a — 10.0.0.0/24 (public)
us-east-1b — 10.0.1.0/24 (public)
us-east-1c — 10.0.2.0/24 (public)
Private Subnets:
us-east-1a — 10.0.10.0/22 (private app)
us-east-1b — 10.0.14.0/22 (private app)
us-east-1c — 10.0.18.0/22 (private app)
Data Subnets:
us-east-1a — 10.0.50.0/24 (database)
us-east-1b — 10.0.51.0/24 (database)
us-east-1c — 10.0.52.0/24 (database)
This leaves plenty of 10.0.x.x space for future subnet tiers — EKS node groups, Lambda, PrivateLink endpoints, and more.