IP address overlapping happens when two or more networks use the same CIDR range. When you try to connect them — through VPC peering, VPN, or Direct Connect — routing breaks because the network can’t tell which destination you mean. This is a common problem in AWS when connecting VPCs across accounts, regions, or to on-premises networks.
This post covers why overlapping happens, why some AWS services won’t work around it, and 5 practical solutions.
What Does Overlapping Look Like?
Say you have two VPCs that need to communicate:
| Network | CIDR | IP Range |
|---|---|---|
| VPC-A (Account A) | 10.0.0.0/16 |
10.0.0.0 – 10.0.255.255 |
| VPC-B (Account B) | 10.0.0.0/16 |
10.0.0.0 – 10.0.255.255 |
Both VPCs use 10.0.0.0/16. If an EC2 instance in VPC-A sends a packet to 10.0.1.50, the router has no way to know whether that address is in VPC-A or VPC-B. The packet stays local.
This also applies to partial overlaps. If VPC-A uses 10.0.0.0/16 and VPC-B uses 10.0.0.0/24, VPC-B’s range falls entirely inside VPC-A’s range — the connection still won’t work.
Why VPC Peering Won’t Help
AWS VPC Peering explicitly blocks connections between VPCs with overlapping CIDRs. You’ll get an error if you try to create a peering connection between them. This is by design — the route tables can’t distinguish between local and remote traffic when the ranges overlap.
The same restriction applies to Transit Gateway route tables. You can attach both VPCs to a Transit Gateway, but you can’t route traffic between them if their CIDRs overlap.
Solution 1: Re-address One Network
The cleanest fix is to change the CIDR of one of the overlapping networks. This eliminates the problem at the source.
When this works: The conflicting VPC is small, new, or has few resources. If you’re early in a project, re-addressing is worth the short-term effort to avoid long-term workarounds.
When it doesn’t: The VPC hosts production workloads with hardcoded IPs, security group references, or DNS records. Changing the CIDR means rebuilding subnets and migrating resources — which can mean downtime.
AWS lets you add a secondary CIDR to an existing VPC without rebuilding it. You can create new subnets in the secondary range, migrate resources over time, and eventually stop using the conflicting range. To plan new, non-overlapping ranges, try the AWS VPC Subnet Planner.
Solution 2: NAT at the Boundary
Place a NAT gateway or NAT instance between the two networks that translates source and destination IPs into a non-overlapping range before forwarding traffic.
For example, traffic from VPC-A (10.0.0.0/16) heading to VPC-B gets NAT’d to appear as coming from 100.64.0.0/16 (a non-routable range). VPC-B sees the translated address and responds to it. The NAT device translates the response back.
When to use: You need bidirectional communication between the networks and can’t re-address either one. This approach requires managing the NAT device and its translation rules.
Solution 3: AWS PrivateLink
PrivateLink is the modern AWS approach to cross-VPC connectivity when CIDRs overlap. It works because it creates a private endpoint in your VPC that gets its own IP from your subnet — it doesn’t need to route to the remote VPC’s CIDR at all.
How it works:
- VPC-B exposes a service behind a Network Load Balancer
- VPC-B creates a VPC Endpoint Service pointing to that NLB
- VPC-A creates an Interface VPC Endpoint that connects to VPC-B’s endpoint service
- VPC-A gets an ENI with a local IP in its own subnet — no CIDR overlap issues
When to use: You need service-to-service connectivity (e.g., API calls) rather than full network-level access. PrivateLink works across accounts and regions, ignores CIDR conflicts entirely, and doesn’t require managing NAT rules.
Limitation: Traffic is one-directional — the consumer (VPC-A) initiates connections to the provider (VPC-B). If both sides need to initiate, you’d set up endpoint services in both VPCs.
Solution 4: Bridge VPC with NAT
Create a third VPC with a non-overlapping CIDR that acts as a bridge between the two conflicting networks. The bridge VPC runs NAT instances that translate traffic in both directions.
| Network | CIDR | Connects To |
|---|---|---|
| VPC-A | 10.0.0.0/16 |
Bridge VPC (via peering or TGW) |
| Bridge VPC | 100.64.0.0/16 |
VPC-A and VPC-B |
| VPC-B | 10.0.0.0/16 |
Bridge VPC (via peering or TGW) |
VPC-A peers with the Bridge VPC (which works because their CIDRs don’t overlap). VPC-B peers with the Bridge VPC the same way. NAT instances in the Bridge VPC translate traffic between them.
When to use: You need full network-level connectivity, can’t re-address, and the traffic patterns are complex enough that PrivateLink doesn’t cover it.
Solution 5: Plan Ahead with IPAM
The best solution is preventing overlaps in the first place. AWS VPC IPAM (IP Address Manager) lets you allocate and track CIDR ranges centrally across your entire AWS organization.
With IPAM, you define IP pools and assign ranges from those pools when creating VPCs. This prevents two teams from accidentally picking the same CIDR. IPAM is especially useful in multi-account setups managed with AWS Organizations.
For a guide on planning VPC CIDRs from scratch, see How to Design IP Addressing for Amazon VPC and Subnets.
Which Solution Should You Use?
| Solution | Best For | Complexity |
|---|---|---|
| Re-address | Small or new VPCs with few resources | Low (if early), High (if production) |
| NAT at boundary | Full bidirectional network access needed | Medium |
| PrivateLink | Service-to-service API calls | Low |
| Bridge VPC | Complex traffic patterns, full network access | High |
| IPAM (prevention) | Multi-account organizations | Low (upfront planning) |
Conclusion
IP address overlapping is a design problem — not a bug. The earlier you catch it, the simpler the fix. If you’re dealing with it now, PrivateLink is usually the fastest path for service-to-service traffic, while a Bridge VPC with NAT handles cases where full network access is required.
For cross-account work beyond networking, see How to Set Up Cross-Account Access in AWS with AssumeRole.
