Overlap rules on AWS, Azure and Google Cloud
Each cloud checks a different set of ranges, so put the right ones on each line:
- AWS VPC peering fails when any IPv4 or IPv6 CIDR block of one VPC matches or overlaps a block of the other, even if you only plan to route the blocks that don't overlap. List every block of the VPC, primary and secondary.
- AWS Transit Gateway lets you attach the VPC, but when its CIDR is identical to, or overlaps with, the CIDR of a VPC already attached, the new VPC's routes are not propagated to the transit gateway route table.
- Azure virtual network (VNet) peering requires the peered virtual networks to have nonoverlapping address spaces. List each VNet's address spaces.
- Google Cloud (GCP) VPC Network Peering fails when a subnet range, primary or secondary, exactly matches, contains or fits within a subnet range in the peered network. List the subnet ranges.
Worked example: a shared secondary block
In the example loaded above, prod and dev have primary blocks that sit side by side: 10.0.0.0/16 ends at 10.0.255.255 and 10.1.0.0/16 starts at 10.1.0.0, so they don't overlap. Both later got 10.8.0.0/16 as a secondary block. Those two blocks are identical, all 65,536 addresses are shared, and AWS refuses the peering connection even though the primary blocks are fine.
The third line shows the other kind of overlap: the shared VPC's 10.0.128.0/20 sits inside prod's 10.0.0.0/16, so the two networks share 4,096 addresses. To fix an overlap, re-address one side before you peer. On AWS you can remove a secondary block such as 10.8.0.0/16 from one VPC, but you can't resize a CIDR block or remove the primary one, so pick a primary range no other network uses when you create a VPC; the AWS VPC subnet planner then lays out its subnets.
Why two blocks never partly overlap
A CIDR block always starts on a multiple of its own size: a /24 starts where the last octet is 0, a /16 where the last two are. So two blocks either share no address, or the smaller one sits wholly inside the larger one. That leaves three results, the same three cases Google Cloud's rule names: identical (exactly match), contains, and inside (fit within). The shared range is always the smaller block.
A block with host bits set, such as 100.68.0.18/18, is checked as its network address, 100.68.0.0/18. AWS does the same when you create a VPC with that value from the CLI or the API.
Pitfall: spokes that overlap each other
Peering is not transitive, so it is tempting to check each spoke against the hub only. AWS does let a hub VPC peer with two VPCs whose CIDR blocks match, but the hub then needs routes to specific subnets or addresses. AWS also warns that reply traffic can reach the wrong VPC, because peering connections don't send replies back by source address. Google Cloud applies its overlap checks to networks peered through a common network too. On AWS, VPCs associated with one Direct Connect gateway must not overlap either. Put every network that shares a hub on its own line: the checker compares every pair, spokes included.
FAQ
Can I peer two VPCs if only their secondary CIDR blocks overlap?
No. AWS refuses a VPC peering connection if any IPv4 CIDR block of one VPC overlaps a block of the other, even if you intend to use only the non-overlapping blocks or only IPv6. Check every block of each VPC, primary and secondary.
Do 10.0.0.0/16 and 10.1.0.0/16 overlap?
No. 10.0.0.0/16 covers 10.0.0.0 to 10.0.255.255, and 10.1.0.0/16 starts at the next address, 10.1.0.0. Blocks overlap only when they share at least one address, so adjacent blocks are fine for peering.
What happens when VPCs with overlapping CIDRs attach to a transit gateway?
You can attach them, but a transit gateway does not route between VPCs with identical or overlapping CIDRs: the routes of the VPC attached later are not propagated. AWS documents a workaround: give each VPC an extra CIDR block that overlaps nothing, attach the VPCs to the transit gateway through those blocks with static routes instead of route propagation, and send traffic through a private NAT gateway in one VPC to a load balancer in the other.
Do Azure and Google Cloud allow overlapping ranges when peering?
Not with regular peering. Azure virtual network peering requires nonoverlapping address spaces. Azure subnet peering, which links selected subnets, can connect virtual networks that share an address space, but only through subnets in address spaces the two do not share. Microsoft has to register your subscription for subnet peering first, and you set it up with the CLI, PowerShell, Terraform, an ARM template or the API, not in the portal. Google Cloud refuses overlapping subnet ranges, and two auto mode VPC networks cannot be peered with each other at all, because their subnets use the same predefined ranges.
Can I add a CIDR block to a VPC that is already peered?
Yes, if it does not overlap the peer. With an active peering connection, AWS lets you add CIDR blocks that do not overlap a CIDR block of the peer VPC. While the request is still pending acceptance, the requester VPC cannot add any block, and an overlapping block added to the accepter VPC makes the request fail.
Does the overlap rule apply to IPv6 CIDR blocks?
On AWS, yes: a VPC peering connection is refused when IPv4 or IPv6 CIDR blocks match or overlap. This checker reads IPv4 blocks only and flags IPv6 input, so compare IPv6 blocks by hand.