Overlapping CIDR blocks are the network-architecture mistake that comes back to bite you years after you make it. Two VPCs both default to 10.0.0.0/16. A company you acquire uses the same subnet as your DMZ. A consultant's lab range collides with your production. The discovery usually happens at the worst possible time — when business needs require the two networks to talk.

This article is a playbook for handling CIDR overlap: how to detect it before deployment, what to do when it surfaces after, and the migration patterns that minimize downtime.

Why overlap is a problem

Overlap matters because the routing table is a flat namespace: each destination IP maps to one next-hop. If two networks both contain 10.0.5.42, a router sitting between them cannot send a packet to "the right one" — there is no way to disambiguate.

Concrete manifestations:

  • VPC peering fails with InvalidVpcPeeringConnectionId.Conflict or similar.
  • Transit Gateway attachments fail with similar errors.
  • VPN tunnels won't establish if both endpoints claim the same subnet.
  • Direct Connect / ExpressRoute rejects route advertisements that overlap with existing.
  • Subtle routing failures when overlap is partial — some traffic works, some doesn't, and the pattern is hard to diagnose.

Detection: catching overlap before deployment

The cheapest fix is the one you make before infrastructure is provisioned. Validation should happen at:

  1. Design time — when someone proposes a new VPC, check the CIDR against the allocation chart.
  2. Code-review time — Terraform PR opens, CI runs CIDR validation.
  3. Apply time — the cloud platform itself rejects overlapping creates.

Detection tools:

  • Our Validate tool accepts a list of CIDRs and identifies overlaps.
  • The IPAM-Lite tracker warns when you add an entry that overlaps existing ones.
  • NetBox detects overlaps server-side when allocating new prefixes.
  • AWS VPC IPAM rejects overlapping allocations within a pool.

The overlap discovery checklist

When you suspect overlap (or know it but need to scope the damage), gather:

  1. List of all known CIDR allocations across the affected networks. Spreadsheet, IPAM, manual inventory — whatever you have.
  2. Active workloads in the overlapping ranges. What instances, what services, what owners?
  3. Routes that reference the overlapping ranges. Route tables, BGP, OSPF, VPN.
  4. Dependencies that traverse the overlap. Anything that connects to or through the conflict zone.

You cannot fix what you cannot see. Inventory first, intervene second.

Resolution options ranked by disruption

Option 1: avoid the connection (zero disruption)

The simplest fix is to not connect. If two VPCs overlap but the business only needs them to reach the same set of external services, you can route both through a shared egress without peering them to each other. They each see only their own /16; the conflict is invisible.

Limitations: only works when the connection is genuinely not needed. Cannot solve "we need our app in VPC-A to call services in VPC-B."

Option 2: NAT at the boundary (moderate complexity)

Translate one side's addresses at the boundary, so the conflicting range is presented to the other side under different addresses.

Patterns:

  • Private NAT Gateway on AWS — performs NAT at the VPC edge so the "other side" sees translated addresses.
  • F5 BIG-IP / Palo Alto / Fortinet appliances — vendor NAT/SNAT in inspection VPCs.
  • Application-layer proxies — when the application is HTTP-based, an ALB / ingress controller can act as the translation point.

Downsides:

  • End-to-end IP visibility is lost. Source IP for audit/logging becomes the NAT IP, not the original client.
  • Connections become asymmetric in interesting ways. Some protocols (FTP, SIP, IPsec) break under NAT.
  • Throughput limited by the NAT device.
  • Operational burden of maintaining the NAT mapping rules.

Useful for emergency interconnect when re-IPing isn't possible, less ideal as a permanent solution.

Option 3: re-IP one side (high disruption, clean result)

The painful but correct option. Pick the network with smaller blast radius and move it to a non-overlapping CIDR. Steps:

  1. Plan the new CIDR from a coordinated allocation chart. See our multi-cloud planning article.
  2. Build the new VPC alongside the old one, with new subnets, security groups, and route tables in the correct CIDR.
  3. Migrate workloads: standard patterns are blue-green (run both in parallel, cut over via DNS) or instance-by-instance (snapshot and relaunch in the new VPC).
  4. Update DNS and external integrations to point at the new addresses.
  5. Decommission the old VPC.

Typical timeline: 2-6 weeks for a moderate-sized VPC, longer for heavily-connected ones. Plan for a maintenance window for the DNS cutover even though most preparation happens in parallel.

Option 4: introduce a new range alongside (partial fix)

If you can't move existing workloads, you can sometimes add a secondary VPC CIDR in non-overlapping space. New workloads go in the secondary range; old ones stay where they are. AWS allows up to 4 secondary CIDRs per VPC, including from CGNAT (100.64.0.0/10).

This buys time but doesn't fully resolve the conflict — the original overlap still prevents the affected workloads from being reachable across the peering. Useful when most workloads can migrate gradually.

Acquisition scenarios

The classic case: your company acquires another that uses overlapping IP space. Common patterns:

  • Plan re-IP into the acquisition's project plan. If you control the timeline, do it right.
  • Use private NAT on the boundary as an interim while the acquisition's environment is re-IPed.
  • If the acquired network is too critical to touch, re-IP your side instead. Painful but sometimes the right call.
  • Set aside a /12 in your allocation chart for future acquisitions — common defensive practice in large organizations.

Migration patterns that minimize downtime

Blue-green re-IP

Build the entire new VPC, populate it with the migrated workloads (replicated from the source), test thoroughly, then cut over DNS in one operation. Old VPC is decommissioned after a verification period.

Pros: short cutover window. Cons: requires double infrastructure cost during migration.

Rolling re-IP (per-instance)

Move workloads one at a time from old VPC to new. Each instance is replaced with a snapshot in the new VPC. Inter-instance traffic during the migration goes via Transit Gateway (which can route between non-overlapping VPCs).

Pros: minimal extra infrastructure cost. Cons: longer overall timeline; complex temporary routing.

Application-level re-IP

For applications behind load balancers or service mesh, swap traffic by updating service registration rather than instance addresses. Old and new addresses are both registered; weight shifts gradually from old to new.

Pros: lowest user-visible disruption. Cons: requires the application to have a service mesh or load-balancer abstraction.

Prevention: lessons for going forward

The best fix for CIDR overlap is to never get it in the first place. The discipline that prevents it:

  1. One authoritative allocation chart for the entire organization.
  2. No VPC gets created without an allocated CIDR from the chart.
  3. The chart includes reserved ranges for acquisitions and growth.
  4. Use CGNAT (100.64.0.0/10) for high-density workloads like Kubernetes pods.
  5. Validate every new allocation against existing ones (use our Validate tool or NetBox or similar).

Key takeaways

  • Detect overlap at design, code review, and apply time — three layers of defense.
  • Avoidance (don't connect) is the cheapest fix when the connection is not actually needed.
  • NAT at the boundary is a workable interim measure but is operationally complex.
  • Re-IP one side is the correct long-term fix; takes 2-6 weeks for a typical VPC.
  • Blue-green or rolling migration patterns minimize downtime during re-IP.
  • Prevent future overlap with an authoritative allocation chart and validation tooling.