Multi-VPC Peering: Non-Overlapping CIDRs

Planning CIDRs for Multi-VPC Architectures

When connecting multiple VPCs via peering, Transit Gateway, or VPN, every VPC must have a unique, non-overlapping CIDR block. Planning this upfront prevents painful re-addressing later.

The Problem

VPC-A: 10.0.0.0/16   (Production)
VPC-B: 10.0.0.0/16   (Staging)    <- CONFLICT!

AWS, GCP, and Azure all reject peering between VPCs with overlapping CIDRs. Even with Transit Gateway, overlapping CIDRs cause ambiguous routing.

Recommended Allocation Strategy

Assign a /16 per VPC from the 10.0.0.0/8 space:

10.0.0.0/16   -> Production VPC
10.1.0.0/16   -> Staging VPC
10.2.0.0/16   -> Development VPC
10.3.0.0/16   -> Shared Services VPC
10.4.0.0/16   -> Data Analytics VPC
10.10.0.0/16  -> DR Region Production
10.11.0.0/16  -> DR Region Staging

This gives each VPC 65,536 addresses and guarantees zero overlap.

Multi-Account Strategy

For AWS Organizations with many accounts:

Account 100 (Prod):    10.0.0.0/16, 10.1.0.0/16
Account 200 (Stage):   10.2.0.0/16, 10.3.0.0/16
Account 300 (Dev):     10.4.0.0/16, 10.5.0.0/16
Account 400 (Shared):  10.10.0.0/16

Using This Calculator

Enter all your VPC CIDRs in the calculator to verify:

1. No two VPCs have overlapping ranges
2. VPC subnets are properly contained within their parent VPC CIDR
3. There is room for growth (unused address space between allocations)

Secondary CIDRs

AWS allows adding secondary CIDR blocks to existing VPCs. When planning, leave gaps between primary allocations to accommodate future secondary CIDRs without overlap.