What is VPC Peering?
Think of two office buildings that want to share a private phone line. VPC Peering is exactly that — a direct, private connection between two VPCs that lets them communicate using private IP addresses, as if they were on the same local network. No traffic touches the public internet.
VPC Peering is a networking connection between two VPCs that enables routing traffic between them using private IPv4 or IPv6 addresses. Peering can connect VPCs in the same AWS account, across different accounts, or even across different AWS regions (inter-region peering). Once established, you add routes to each VPC's route table pointing to the other VPC's CIDR block via the peering connection.
# Example route table entry in VPC A after peering with VPC B
Destination: 10.1.0.0/16 Target: pcx-0abc123def456789 (peering connection ID)
The Major Limitation: No Transitive Peering
The biggest problem with VPC peering at scale is that it is non-transitive. This is not a bug — it is a deliberate design decision. AWS does not allow traffic to flow through a VPC to reach another VPC.
- If VPC A is peered with VPC B...
- And VPC B is peered with VPC C...
- VPC A cannot talk to VPC C through VPC B.
To connect A and C, you must create a separate direct peering connection between them. VPC B cannot act as a relay.
The "Full Mesh" Nightmare
Imagine you have 10 VPCs that all need to talk to each other. Because of the non-transitive rule, you need a direct peering connection between every pair. The formula for the number of connections needed is n(n-1)/2. For 10 VPCs, that is 45 separate peering connections. For 20 VPCs, it is 190. You must also update route tables in every VPC whenever a new VPC is added or a CIDR block changes.
This is operationally unsustainable. VPC Peering is the right tool for simple 1:1 or 1:few connections, but it fails at scale.
Interviewers frequently ask: "Can traffic flow transitively through a peered VPC?" The answer is a hard no — AWS explicitly blocks this. Follow up by explaining why this matters: it forces you to choose between a full-mesh (operationally expensive) or a hub-and-spoke architecture using Transit Gateway (the correct answer at scale). Knowing the formula n(n-1)/2 for mesh connections demonstrates you understand the operational cost, not just the technical limitation.