VPC Peering Connection Failed: Overlapping CIDR Blocks — 3 Real Fixes

VPC peering requires that the two VPCs have completely non-overlapping IP address ranges. If both VPCs use 10.0.0.0/16 — which is what AWS creates by default — the peering request will be rejected with an overlapping CIDR error the moment you try to accept it.

Why Peering Can't Work with Overlapping CIDRs

VPC peering works by installing routes in each VPC's route tables pointing to the other VPC. If both VPCs use 10.0.0.0/16, AWS has no way to route traffic — it can't tell whether 10.0.1.5 belongs to VPC A or VPC B. The routing is fundamentally ambiguous, so AWS rejects it at the peering request stage.

This situation is extremely common. AWS defaults new VPCs to 10.0.0.0/16, so in any account with more than one VPC created without forethought, you will hit this eventually.

Diagnosing the Overlap

First, confirm which CIDRs are overlapping:

aws ec2 describe-vpcs \
  --query 'Vpcs[*].[VpcId,CidrBlock,Tags[?Key==`Name`].Value|[0]]' \
  --output table

If you see two VPCs with the same or overlapping ranges, peering won't work between them.

Your 3 Options

Option	Works When	Disruption
Add secondary CIDR	You only need to route some new subnets	Low — no existing infra moves
AWS PrivateLink	You only need to expose a specific service	None — no routing required
Recreate one VPC	You need full routing between VPCs	High — migrate all resources

Option 1: Add a Secondary CIDR (Least Disruptive)

You can add up to 4 secondary CIDR blocks to a VPC. If you add a non-overlapping secondary CIDR to one VPC, create subnets in that range, and peer on those subnets, you can make peering work — without touching existing infrastructure.

# Add a secondary CIDR to VPC B
aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 10.1.0.0/16

# Create subnets in the new range
aws ec2 create-subnet \
  --vpc-id vpc-0abc123 \
  --cidr-block 10.1.1.0/24

# Now peering between VPC A (10.0.0.0/16) and
# VPC B (10.1.0.0/16 secondary) will work

Limitation: you still can't route the original 10.0.0.0/16 range of VPC B — only the secondary CIDR. Existing instances in the original range are not reachable through peering.

Option 2: AWS PrivateLink (No Routing Needed)

If your goal is to expose a specific service (an internal API, a database, a load balancer) from VPC B to VPC A, PrivateLink is often the cleaner solution. It creates a private endpoint in VPC A that connects directly to a service in VPC B, without routing between the VPCs at all.

# In VPC B: create an endpoint service backed by an NLB
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:...

# In VPC A: create an interface endpoint to consume it
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0xyz789 \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-xxx \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-xxx

Option 3: Recreate the VPC with a Different CIDR

If you need full routing between both VPCs and secondary CIDRs won't cover your use case, the only way is to rebuild one VPC with a non-overlapping CIDR. This is disruptive — every resource needs to be migrated — but it's the only path to full peering.

When doing this, adopt a CIDR planning strategy upfront to avoid the same problem with future VPCs:

# Example: allocate per-environment ranges
Prod:    10.0.0.0/16   (10.0.x.x)
Staging: 10.1.0.0/16   (10.1.x.x)
Dev:     10.2.0.0/16   (10.2.x.x)
EU-Prod: 10.10.0.0/16  (10.10.x.x)

CIDR Overlap as a Topology Problem

CIDR conflicts are one of the most common findings Netway surfaces when scanning multi-VPC environments. They're often invisible until someone tries to peer two VPCs and hits the error. At that point, the overlap has usually existed for months.

Netway detects overlapping CIDRs across all your VPCs — including across accounts and regions — before you hit the peering limit.