Definition
- VPC Peering – A networking connection between two VPCs that lets resources communicate using private IPs, with traffic staying on the AWS network.
- Non-Transitive – If VPC A peers with B and B peers with C, A cannot reach C through B; each pair needs its own direct peering connection.
- Non-Overlapping CIDRs – Both VPCs must have different IP address ranges, or routing becomes ambiguous and peering fails.
- Two-Way Routes – Both VPCs must add route table entries pointing the other's CIDR to the peering connection.
- Transit Gateway – A hub-and-spoke service for connecting many VPCs, solving the scalability problem of full-mesh peering.
VPC peering is a private bridge built directly between two of National Bank of India's buildings so staff can walk between them without going out to the street. Non-transitive means the bridge only connects those two specific buildings – if building A has a bridge to B and B has a bridge to C, A's staff still cannot reach C. The bridge is useless unless both buildings put up signs pointing to it (routes), the guards let people cross (firewalls), and the two buildings do not share the same room numbers (non-overlapping CIDRs).
Understanding the Concepts
What is VPC peering?
VPC peering connects exactly two VPCs. Once the connection is accepted, resources address each other by private IP; traffic never touches the public internet. This is ideal for a bank sending sensitive data between a production VPC and an analytics VPC.
# Create a peering connection
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-production \
--peer-vpc-id vpc-analytics
# Output: pcx-0peer123
# Accept it from the other side
aws ec2 accept-vpc-peering-connection \
--vpc-peering-connection-id pcx-0peer123
Why is peering non-transitive?
The peering connection only routes traffic between its two endpoints. AWS does not forward packets through an intermediate VPC. So if VPC A peers with B and B peers with C, A cannot reach C through B. You would need a direct A-C peering or a Transit Gateway for hub-and-spoke connectivity.
# Non-transitive peering VPC A ←──peer──→ VPC B ←──peer──→ VPC C A can reach B: YES (direct peering) B can reach C: YES (direct peering) A can reach C through B: NO (non-transitive) A must peer directly with C: YES (or use Transit Gateway)
What four requirements must hold for peering to work?
For peering to work, four things must all be true:
- Non-overlapping CIDRs – If both VPCs use 10.0.0.0/16, addresses are ambiguous and routing fails.
- Route tables on both sides – Both VPCs need a route pointing the other's CIDR to the peering connection.
- Security Groups – The target instance's Security Group must allow traffic from the source VPC's CIDR.
- NACLs – The NACLs on both subnets must allow traffic in both directions.
# VPC A (10.0.0.0/16) route table 10.1.0.0/16 → pcx-0peer123 (to VPC B) # VPC B (10.1.0.0/16) route table 10.0.0.0/16 → pcx-0peer123 (back to VPC A) # BOTH sides required
What happens with overlapping CIDRs?
Overlapping CIDRs are a design error that cannot be fixed with routing tricks. If both VPCs use 10.0.0.0/16, an address like 10.0.5.9 is ambiguous – the route table cannot decide which VPC owns it. This cannot be fixed by adding routes; it requires re-addressing a VPC, which means recreating subnets and migrating workloads.
public class OverlappingCIDRProblem {
// VPC A: 10.0.0.0/16
// VPC B: 10.0.0.0/16 ← OVERLAP!
// Packet to 10.0.5.9 → which VPC? Ambiguous!
// Cannot be fixed with routes – must re-address one VPC
// Re-addressing a production bank network is massively disruptive
}
How do you troubleshoot a failed peering scenario?
When two peered VPCs cannot talk, troubleshoot in a fixed order:
- Overlapping CIDRs – Check first; this is a design error that cannot be patched.
- Route tables – Check both sides. The missing return route is the most common fix.
- Security Groups – Does the target allow the source VPC's CIDR range?
- NACLs – Check both subnets in both directions (stateless, so both inbound and outbound).
# Step 1: Check for overlapping CIDRs
aws ec2 describe-vpcs --vpc-ids vpc-prod vpc-analytics \
--query 'Vpcs[*].[VpcId,CidrBlock]'
# Step 2: Check route tables on BOTH sides
aws ec2 describe-route-tables \
--filters "Name=vpc-id,Values=vpc-prod" \
--query 'RouteTables[*].Routes[?VpcPeeringConnectionId!=`null`]'
# Repeat for vpc-analytics
# Step 3: Check Security Group on target instance
aws ec2 describe-security-groups --group-ids sg-target \
--query 'SecurityGroups[*].IpPermissions'
# Step 4: Check NACLs on both subnets
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-target"
What is the difference between peering and Transit Gateway?
| Aspect | VPC Peering | Transit Gateway |
|---|---|---|
| Topology | Point-to-point (two VPCs) | Hub-and-spoke (many VPCs) |
| Transitivity | Non-transitive | Transitive by default |
| Scalability | Full mesh needed for many VPCs | One attachment per VPC |
| Cost | No data-processing charge (same Region) | Per-attachment and per-GB charge |
| Use case | Few VPCs, simple connectivity | Many VPCs, environments, accounts |
| Isolation | Not possible with peering alone | Route tables per attachment for isolation |
public class PeeringVsTransitGateway {
// 2-3 VPCs: peering is simpler and cheaper
// 5+ VPCs: Transit Gateway avoids full-mesh complexity
// Environment isolation: only Transit Gateway route tables can do this
}
What are common mistakes?
The most common mistake is adding the route on only one side. Traffic flows from A to B, but B has no route back, so replies are silently dropped and the connection appears dead. Always check both sides.
The second mistake is trying to peer VPCs with overlapping CIDRs, which fails at creation time.
The third mistake is forgetting to update Security Groups to allow the peer VPC's CIDR range.
public class PeeringMistakes {
// WRONG: route on production side only
// Production → route to analytics ✓
// Analytics → no route to production ✗ → replies dropped
// FIX: add route on analytics side too
// Production → route to analytics ✓
// Analytics → route to production ✓ → connectivity works
}
What should a senior engineer know?
A senior engineer knows that peering is ideal for a small number of VPCs with simple connectivity needs. Beyond five or six VPCs, the full mesh becomes unmanageable (n*(n-1)/2 connections), and Transit Gateway is the right solution. They also know that cross-Region peering is supported but incurs data-transfer charges, and that peering does not support transitive routing even with route propagation.
For the troubleshooting scenario, they always check in order: CIDRs, routes on both sides, Security Groups, NACLs. This systematic approach avoids wasting time on the wrong layer.
# Full mesh vs Transit Gateway 5 VPCs peered: 10 peering connections (5*4/2) 10 VPCs peered: 45 peering connections 20 VPCs peered: 190 peering connections ← unmanageable 20 VPCs via Transit Gateway: 20 attachments ← manageable
Visual Overview
┌──────── VPC Peering Connectivity ────────┐ │ │ │ Non-Transitive: │ │ A ←──peer──→ B ←──peer──→ C │ │ A cannot reach C through B │ │ │ │ Four Requirements: │ │ 1. Non-overlapping CIDRs │ │ A: 10.0.0.0/16 │ │ B: 10.1.0.0/16 ✓ no overlap │ │ │ │ 2. Routes on BOTH sides │ │ A route table: 10.1.0.0/16 → pcx │ │ B route table: 10.0.0.0/16 → pcx │ │ │ │ 3. Security Groups allow source range │ │ B's SG: allow from 10.0.0.0/16 │ │ │ │ 4. NACLs allow both directions │ │ Both subnets: inbound + outbound │ │ │ │ Troubleshoot Order: │ │ CIDRs → Routes → SG → NACL │ │ (design) (most common fix) │ └───────────────────────────────────────────┘
Key Takeaway
VPC peering is a direct networking connection between two VPCs that lets their resources talk to each other over private IP addresses, with traffic never touching the public internet. The key property is that peering is non-transitive: a peering connection only carries traffic between its two endpoints, so if A is peered with B and B is peered with C, A still cannot reach C through B. For many VPCs, Transit Gateway solves the scalability problem.
For peering to actually work, four requirements must all hold. The CIDR blocks must not overlap, because identical ranges make addresses ambiguous. Both route tables need entries pointing the other VPC's CIDR to the peering connection, since routing is two-way and a route on only one side gives requests with no return path. The Security Groups on the target must allow the source range. And the NACLs must allow traffic in both directions.
For the troubleshooting scenario where two peered VPCs still cannot talk, I check in a fixed order. First overlapping CIDRs, because that is a design error I cannot patch. Then both route tables – the missing return route is the most common fix. Then Security Groups on the target. Then NACLs on both subnets in both directions.
At National Bank of India this exact situation happened between our production and analytics VPCs. The analytics instance could not reach production, and the cause was that we had added the route on the production side but forgotten the return route on analytics. Adding it fixed connectivity instantly. The lesson is that peering connectivity is a two-way conversation, so checking only one side is the classic mistake.
Remember one sentence: VPC peering is a non-transitive, private link between two VPCs that requires non-overlapping CIDRs, routes on both sides, and firewall rules allowing the traffic.
---