Introduction: Why VPC CIDR Planning is a Day-Zero Constraint
In AWS architecture, few decisions are as difficult to roll back as VPC IP addressing. Once a Virtual Private Cloud (VPC) is deployed and populated with EC2 instances, RDS databases, and Elastic Load Balancers, the primary Classless Inter-Domain Routing (CIDR) block is locked. If that block proves too small or overlaps with a newly acquired office or partner network, the rework often involves significant infrastructure migration.
Technical leaders frequently fall into the trap of sizing for 'what we need today' rather than 'what we need in five years.' In enterprise cloud environments, IP Management (IPAM) is not just about counting addresses; it is about ensuring that routing, peering, and hybrid connectivity remain possible as the environment scales. Refresh your knowledge on CIDR math before starting your VPC design.
The Core Mechanics: AWS VPC CIDR Blocks
AWS VPCs support primary and secondary CIDR blocks from the private IPv4 ranges defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), as well as publicly routable IP ranges. The constraints are straightforward: the block must be between /16 and /28 in size. However, the sizing strategy is more nuanced.
Teams that start with a /24 VPC (256 addresses) often regret the decision within months. Between container orchestration (EKS), multi-AZ redundancy, and serverless interfaces (Lambda VPC interfaces), IP addresses are consumed much faster than many teams expect. Standard enterprise practice is to default to a /16 for major VPCs or a /20 for smaller, isolated environments.
The 'AWS Tax': Reserved Addresses in Every Subnet
When calculating capacity, developers must subtract the AWS reserved addresses. Unlike traditional on-premises networking, where you lose only the network and broadcast addresses, AWS reserves five IPs per subnet:
- x.x.x.0: Network address.
- x.x.x.1: VPC Router.
- x.x.x.2: AWS DNS Server (AmazonProvidedDNS).
- x.x.x.3: Reserved by AWS for future use.
- the last IP in the subnet range: reserved by AWS (acts as a network broadcast address substitute).
In a /28 subnet (16 total IPs), you have only 11 usable addresses. In a /24 (256 total IPs), you have 251 usable. This overhead makes very small subnets less efficient for dynamic environments.
CIDR Sizing and Capacity Table
| CIDR BLOCK | TOTAL IPs | USABLE IPs IN AWS | TYPICAL USE CASE |
|---|---|---|---|
| /24 | 256 | 251 | Small microservice subnet |
| /22 | 1,024 | 1,019 | Standard application tier |
| /20 | 4,096 | 4,091 | Large data processing VPC |
| /16 | 65,536 | 65,531 | Standard Enterprise VPC |
Multi-AZ Subnet Strategy: Design for Failure
Subnets in AWS do not span Availability Zones (AZs). If you have three AZs in a region (e.g., us-east-1a, 1b, 1c), you must create at least one subnet in each AZ for high availability. A common mistake is creating one massive public subnet in a single AZ, which creates a critical point of failure.
A common VPC design pattern uses the following structure per Availability Zone:
- Public Subnet: Hosts NAT Gateways and Application Load Balancers (ALBs).
- Private Subnet (App): Hosts EC2 instances, EKS worker nodes, and internal services.
- Private Subnet (Data): Hosts RDS instance endpoints or Elasticache nodes, often with stricter NACLs.
By mimicking this horizontally across AZs, you ensure that if one data center fails, the application remains reachable via the others. Read about NAT Gateway resilience patterns here.
The Overlap Problem: Peering and Transit Gateways
VPC Peering allows two VPCs to talk to each other as if they were on the same network. However, peering will not establish if the CIDR blocks overlap. If both VPCs use 10.0.0.0/16, the route tables will have no way to distinguish which traffic belongs to which VPC.
This problem becomes even more significant in AWS Transit Gateway environments. If you are connecting 50 VPCs to a central hub, and three of them have overlapping IPs, those three will be isolated. This is why enterprise networking teams maintain a global 'IP Registry' to ensure that every VPC has a unique, non-overlapping range across the entire corporate estate, including on-premises data centers connected via Direct Connect or VPN.
Expanding Space: Secondary CIDR Blocks
If you genuinely run out of IP addresses, AWS allows for Secondary CIDR Blocks. You can associate up to four additional blocks with a VPC. While this sounds like a solution to poor planning, it has limitations:
- Peering route updates are non-trivial.
- Existing security groups and NACLs must be audited to include the new ranges.
- Certain AWS services (like Managed Microsoft AD) can only use the primary CIDR block.
Secondary blocks can help growing environments expand without immediate redesign.
Future-Proofing with IPv6
AWS has made massive strides in Dual-Stack and IPv6-Only VPCs. In an IPv6 world, the overlap problem becomes much less likely. AWS assigns a /56 block to the VPC, and every subnet is a /64. This provides 18 quintillion addresses per subnet—making IPv6 address exhaustion effectively irrelevant for most environments.
With IPv6, the use of Egress-Only Internet Gateways allows private subnets to initiate outgoing traffic to the internet without allowing incoming connections, similar to a NAT gateway but without the data processing costs. For many teams, migrating to IPv6 is the most cost-effective way to manage massive EKS clusters. Learn how IPv6 subnetting differs from IPv4 here.
Common AWS Networking Mistakes
- Choosing a /24 VPC: Exhausting the 251 usable IPs within months.
- Ignoring Reserved IPs: Deploying an RDS cluster in a /28 subnet and finding no room for the standby instance.
- Shared NAT Gateways: Forcing all traffic through a single NAT Gateway in AZ-1, creating a cross-AZ data charge and a single point of failure.
- Overlap with VPNs: Choosing a VPC range that overlaps with the corporate Wi-Fi or local VPN, making it impossible for developers to access the cloud resources without a proxy.
Conclusion: Design for the Next Thousand Assets
AWS VPC IP management is a balance between conservatism (not wasting IPs in the global corporate space) and pragmatism (leaving enough room for the app to grow). The most resilient designs are those that silo resources by function (Public vs App vs Data), distribute them across Availability Zones, and avoid the 'Default VPC' traps.
By ensuring that every CIDR block is unique and that subnets are sized to handle the 5-address technical overhead, you create a networking foundation that supports Transit Gateway hubs and PrivateLink integrations with zero rework. For even more advanced routing patterns, explore BGP routing on Direct Connect here.