VPC CIDR Best Practices for Multi-Region AWS Deployments
Choosing VPC CIDR blocks is easy to get wrong — and hard to fix later. Multi-region deployments need non-overlapping address spaces that support VPC peering, Transit Gateway, and on-premises connectivity.
VPC CIDR selection is one of those decisions that seems trivial until it is not. A VPC CIDR cannot be changed after creation — you can add secondary CIDRs, but the primary block is permanent. In a multi-region deployment with peering and on-premises connectivity, overlapping CIDRs break routing silently and are painful to untangle. Getting this right from the start saves significant operational pain.
The Core Constraint: No Overlapping CIDRs
AWS VPC peering and Transit Gateway only work between VPCs with non-overlapping CIDR blocks. If us-east-1 and eu-west-1 both use 10.0.0.0/16, you cannot peer them — the routing would be ambiguous. Every VPC in your organisation needs a unique, non-overlapping CIDR. This includes VPCs in accounts you control and any partner or acquired company networks you might eventually connect.
Systematic Allocation from 10.0.0.0/8
Start with the 10.0.0.0/8 supernet and allocate a /16 per VPC. This gives you 256 possible /16 blocks, each with 65,534 usable addresses before AWS reservations. A common allocation pattern:
10.0.0.0/16— Production, us-east-110.1.0.0/16— Production, eu-west-110.2.0.0/16— Production, ap-southeast-110.10.0.0/16— Staging, us-east-110.20.0.0/16— Development, us-east-110.100.0.0/16— Shared services
Reserve a block for on-premises (e.g. 10.200.0.0/14) so your corporate network never conflicts with cloud VPCs.
On-Premises and VPN Conflicts
The most common CIDR mistake is using 192.168.0.0/16 or 10.0.0.0/24 for a VPC without checking what the corporate network uses. Many companies already use 10.x.x.x for their internal network. If your VPC overlaps with the corporate range, VPN and Direct Connect connectivity will fail. Always map your existing address space before allocating VPC CIDRs. Our VPC CIDR selection guide has a pre-flight checklist.
Subnet Allocation Within a VPC
Within a /16 VPC, allocate subnets by tier and Availability Zone. A simple three-tier, three-AZ layout within 10.0.0.0/16:
- Public subnets:
10.0.0.0/24,10.0.1.0/24,10.0.2.0/24(one per AZ) - Private app subnets:
10.0.10.0/24,10.0.11.0/24,10.0.12.0/24 - Private data subnets:
10.0.20.0/24,10.0.21.0/24,10.0.22.0/24
Leave large gaps between tiers so you can expand without renumbering. The AWS VPC subnetting guide covers the full tier design. Browse live AWS IP ranges to understand how AWS itself allocates address space across regions.
Secondary CIDR Blocks
If you exhaust your primary VPC CIDR, AWS lets you add up to four secondary CIDRs. This provides some flexibility, but secondary CIDRs complicate routing, security group rules, and on-premises connectivity. Treat them as a last resort and plan primary CIDRs generously from the start.