Overlapping CIDR Blocks - How to Find Them Before VPC Peering or Transit Gateway Refuses the Connection, What AWS, Azure and Google Cloud Each Reject, and the Four Ways Out (Renumber, Secondary CIDR, Private NAT, PrivateLink)

TL;DR

• Overlap means one of three things: the ranges are identical (10.0.0.0/16 and 10.0.0.0/16), one contains the other (10.0.0.0/16 contains 10.0.128.0/17), or they are both inside a bigger block you treat as one (10.1.0.0/16 and 10.2.0.0/16 do not overlap; 10.0.0.0/15 contains both 10.0.0.0/16 and 10.1.0.0/16).
• What each cloud rejects: AWS refuses a peering connection if any CIDR block of either VPC overlaps, even one you never intend to route, and Transit Gateway cannot route two attachments with the same destination; Azure requires non-overlapping address spaces to peer; Google Cloud fails the peering if any subnet range matches, contains or fits inside a peer's, and keeps enforcing it on every new subnet afterwards.
• Check in seconds: ip_network(a).overlaps(ip_network(b)) in Python, or paste your inventory into the VPC Subnet Planner and it flags the hit and lists free blocks of the same size, 10.2.0.0/16 to 10.5.0.0/16 in the example below.
• When it is already in production, in order of cost: renumber the newer, smaller network; add a secondary CIDR to carry only the traffic that must cross; put a private NAT gateway between the overlapping ranges; or use PrivateLink or Private Service Connect so the service is reachable without any route to the other network.
• The real fix is an inventory. One line per network with its CIDR, owner and purpose, checked before every new VPC, VNet or project. The planner reads exactly that format.
• Not your exact case? If you are sizing the new network rather than checking it, start with what is CIDR; if the overlap is between a cluster's service range and a VPC, see EKS running out of IP addresses.

Table of Content

1. What overlap means, exactly
2. What AWS, Azure and Google Cloud reject
3. Check an inventory in seconds
4. The planner's overlap check and free alternatives
5. Four ways out when the overlap is already live
6. Keeping it from happening again
7. What broke when I ran this
8. Conclusion

1. What overlap means, exactly

Two CIDR blocks overlap when at least one address belongs to both. Because CIDR blocks are aligned powers of two, that can only happen in one of two shapes: the blocks are identical, or one contains the other. Two blocks of the same size either match exactly or do not touch at all; a bigger block either swallows a smaller one whole or misses it entirely. There is no partial overlap between valid CIDR blocks.

The fourth row is the one that catches people: "we used 10.0.0.0/8 for the office" means every 10.x.x.x VPC anyone ever creates overlaps the office, and the only clean fix is to stop writing /8 in inventories and record what the office actually uses.

2. What AWS, Azure and Google Cloud reject

Two details worth reading twice. On AWS the test is on every CIDR block of both VPCs, so the 100.64.0.0/16 you attached for EKS pods counts. On Google Cloud the test is on subnet ranges including secondary ranges, and it is enforced for the life of the peering, so a GKE Pod range created a year later can be the thing that fails.

3. Check an inventory in seconds

You do not need a tool for a single pair. Python's ipaddress module answers it, and tells you the shape (run on 2026-10-19 with Python 3.12.10):

1import ipaddress as ip
2pairs = [('10.0.0.0/16','10.0.0.0/16'), ('10.0.0.0/16','10.0.128.0/17'), ('10.0.0.0/15','10.1.0.0/16'),
3         ('10.1.0.0/16','10.2.0.0/16'), ('172.16.0.0/12','172.20.0.0/16'), ('100.64.0.0/16','10.0.0.0/8')]
4for a, b in pairs:
5    A, B = ip.ip_network(a), ip.ip_network(b)
6    rel = 'identical' if A == B else ('contains' if B.subnet_of(A) else ('inside' if A.subnet_of(B) else '-'))
7    print(f'{a:>16} vs {b:<16} overlap={str(A.overlaps(B)):<5} {rel}')

1     10.0.0.0/16 vs 10.0.0.0/16      overlap=True  identical
2     10.0.0.0/16 vs 10.0.128.0/17    overlap=True  contains
3     10.0.0.0/15 vs 10.1.0.0/16      overlap=True  contains
4     10.1.0.0/16 vs 10.2.0.0/16      overlap=False -
5   172.16.0.0/12 vs 172.20.0.0/16    overlap=True  contains
6   100.64.0.0/16 vs 10.0.0.0/8       overlap=False -

For a whole inventory, pull the live ranges rather than the spreadsheet, because the spreadsheet is what was wrong in the first place:

1# AWS: every CIDR block of every VPC in the region, including secondary blocks
2aws ec2 describe-vpcs --query 'Vpcs[].[VpcId,CidrBlockAssociationSet[].CidrBlock]' --output text
3# Azure: address spaces of every VNet in the subscription
4az network vnet list --query '[].{name:name, space:addressSpace.addressPrefixes}' -o table
5# Google Cloud: every subnet range in the project, primary and secondary
6gcloud compute networks subnets list --format='table(name,region,ipCidrRange,secondaryIpRanges[].ipCidrRange)'

4. The planner's overlap check and free alternatives

The VPC Subnet Planner has a box for exactly this inventory, one CIDR per line with an optional label. I pasted four networks: the production VPC, a shared-services VPC, the office VPN range and the on-prem block, and asked for a new 10.0.0.0/16:

The design review drops to 75 of 100 and names the collision, and the overlap check below it lists each network as a hit or clear and then the free alternatives of the same size. This is the engine's output for that run from the planner's test harness on 2026-10-19, reformatted from its JSON into one line per network:

1score 75
2bad | Overlaps 1 existing network: 10.0.0.0/16 | VPC peering and Transit Gateway cannot route overlapping ranges. Pick a different block - the table below suggests free ones.
3existing: 10.0.0.0/16 prod-vpc hit=true | 10.1.0.0/16 shared-services hit=false | 192.168.0.0/16 office VPN hit=false | 172.16.0.0/12 on-prem hit=false
4free alternatives of the same size: 10.2.0.0/16, 10.3.0.0/16, 10.4.0.0/16, 10.5.0.0/16

The alternatives are the next aligned blocks of the requested size that touch nothing in the inventory, so the fix is one click: change the network address to 10.2.0.0, the score goes to 100, and the share link now carries the inventory with the design so the reviewer sees what it was checked against. The same check runs on the Azure and Google Cloud cards with their reserved-address rules, and the Kubernetes IP Calculator applies the EKS variant of it to the service CIDR, which must also avoid the VPC.

5. Four ways out when the overlap is already live

In the order I would try them, cheapest first:

The thing none of them fixes is a 10.0.0.0/8 written against the office in the inventory. Until the real office ranges are recorded, every 10.x VPC is an overlap on paper, and someone will approve one that overlaps for real.

6. Keeping it from happening again

1. One inventory, in a file, in a repository. CIDR, owner, purpose, cloud, account. The planner's "existing networks" box takes that format directly, so the inventory is the input to every new design.
2. Allocate from the top of a plan, not from habit. 10.0.0.0/16 is the first VPC on every account because it is the default in every tutorial, including mine. Give each account or team a /12 and let them carve /16s from it; the planner's "free alternatives" are that plan computed live.
3. Check every secondary range, not just the main one. EKS pod CIDRs and GKE Pod ranges are the overlaps nobody lists.
4. Reserve space for the next zone and the next environment before anyone needs it. Both planner switches are free today and expensive after the first peering.

7. What broke when I ran this

1. Python refused my "partial overlap" example. I wrote 10.1.0.0/15 to show a block straddling two /16s. ipaddress.ip_network('10.1.0.0/15') raises ValueError: 10.1.0.0/15 has host bits set, because a /15 starting at 10.1.0.0 is not aligned: the valid block is 10.0.0.0/15. That error is the section 1 lesson in one line, and the planner snaps an unaligned address to its network address for the same reason.

2. The planner's AWS card rejected my /15 before it checked overlap. Asking for 10.0.0.0/15 on AWS returned "AWS VPCs must be /16 to /28" alongside the overlap item. Correct, and it is why the free-alternatives list only ever proposes blocks the cloud would accept.

3. "10.0.0.0/8 corporate" moved every suggestion to 172.16. With a single /8 in the inventory the planner flagged my 10.20.0.0/16 as overlapping and proposed 172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16 and 172.19.0.0/16, which is correct and also useless if the whole company lives in 10.x. The tool was doing what the inventory told it. I added the line about recording real office ranges to section 5 because of this run, and the planner now shows an information item when an inventory entry is a /8 or larger, saying exactly that.

4. The re:Post article I wanted to cite for the AWS peering failure message is gone, so the rules in section 2 are quoted from the current user guides instead, each of which I curled on 2026-10-19.

8. Conclusion

To summarise:

1. Overlap is identical or contained; there is no partial overlap between valid CIDR blocks, and a /8 in the inventory overlaps everything.
2. AWS tests every CIDR block of both VPCs for peering, Transit Gateway cannot route duplicate destinations, Azure requires non-overlapping address spaces, and Google Cloud tests every subnet range for the life of the peering.
3. Three lines of Python answer a pair; the planner answers an inventory and proposes free blocks.
4. Already live: renumber the small side, add a secondary CIDR, put a private NAT gateway between the ranges, or share the service with PrivateLink instead of the network.
5. Keep the inventory in a repository and check secondary ranges too.

AWS step by step series -

1. Part-1 : AWS IAM user - create a user, group, policy, access keys and MFA
2. Part-2 : AWS Organizations - multi-account setup, OUs and SCPs
3. Part-3 : AWS assume IAM role - trust policy, switch role in console and CLI
4. Part-4 : How to launch an EC2 instance - key pair, security group, SSH
5. Part-5 : AWS VPC - public and private subnets, Internet Gateway, NAT Gateway, route tables
6. Part-8 : EC2 launch template - versions, default version, source template, SSM parameter AMI
7. Part-10 : EC2 Auto Scaling - launch template, Auto Scaling group, target tracking, ALB
8. Part-11 : AWS WAF - web ACL, managed rules, rate limiting, geo blocking
9. Part-12 : AWS VPC Peering - connect two VPCs, routes, security groups, DNS
10. Part-13 : AWS Transit Gateway - hub-and-spoke for many VPCs and on-premises
11. Part-14 : AWS NAT Gateway deep dive - public vs private, limits, cost, troubleshooting
12. Part-15 : Amazon Route 53 - hosted zones, records, alias, routing policies, health checks
13. Part-16 : AWS security groups - inbound and outbound rules, stateful, referencing, quotas
14. Part-16 : AWS Certificate Manager - free TLS certificates for ALB, CloudFront and API Gateway
15. Part-17 : AWS Lambda - function URLs, environment variables and layers
16. Part-18 : Network Load Balancer - setup, and ALB vs NLB
17. Part-19 : VPC endpoints - gateway and interface endpoints (PrivateLink) instead of NAT
18. Part-20 : AWS PrivateLink - publish your own service with an endpoint service and NLB
19. Part-20 : Amazon EBS volumes - types, attach, mount, resize, snapshots, encryption
20. Part-21 : VPC Flow Logs - CloudWatch Logs, S3, record format, Logs Insights, Athena
21. Part-21 : EC2 Spot Instances - pricing, interruptions, mixed instances groups
22. Part-23 : AWS Global Accelerator - static anycast IPs in front of ALBs in two regions, traffic dials, weights
23. Part-24 : AWS Control Tower - landing zone, controls, Account Factory, Identity Center
24. Part-25 : AWS Cloud WAN - global network, core network policy, dev/prod/shared segments, tag-based attachments across three regions

Networking fundamentals -

1. What is a VPC and a subnet? AWS networking in five minutes
2. What is CIDR? Calculate IP ranges for VPCs and subnets
3. VPC Subnet Planner - the free tool I use to size the VPC and subnet CIDRs in every part of this series (AWS, Azure, GCP rules built in)
4. What is NAT? Static NAT, dynamic NAT and PAT explained

More AWS guides -

1. What is AWS CloudFormation? Templates, stacks, change sets, drift, StackSets
2. Learn AWS S3 - the complete course
3. AWS API Gateway - REST API with Lambda, authorizers, Terraform
4. AWS Advanced Networking Specialty (ANS-C01) - course companion
5. AWS ECS and Fargate - how to deploy a Docker container
6. AWS S3 - how to host a static website
7. Terraform create EC2 instance on AWS
8. Terraform AWS IAM - users, roles and policies
9. Terraform and AWS multi-account setup
10. Terraform - setting up an ALB and SSL