Bridging Isolated Networks
You have two VPCs — perhaps one for production and one for a shared services environment running your internal tooling. You need resources in both VPCs to communicate using private IP addresses, without traffic ever traversing the public internet.
VPC Peering creates a direct, private networking connection between two VPCs. Once established, resources in each VPC can route to each other's private IPs as if they were on the same network. The connection is encrypted and uses the cloud provider's backbone network — not the public internet.
The Crucial Limitation: No Transitive Routing
VPC Peering is strictly point-to-point. It does not support transitive routing.
Consider this scenario:
- VPC A is peered with VPC B.
- VPC B is peered with VPC C.
VPC A cannot reach VPC C through VPC B. Even though B is connected to both, it does not relay traffic between them. If A needs to talk to C, you must create a separate, direct peering connection between A and C.
This becomes a serious management problem at scale. With 10 VPCs, a full mesh requires $\frac{10 \times 9}{2} = 45$ peering connections. With 20 VPCs, that's 190 connections. Each connection has its own route table entries to manage.
When Peering Breaks Down: Transit Gateway
For architectures with many VPCs, Transit Gateway (AWS) or equivalent hub-and-spoke services solve the transitive routing problem. Instead of peering every VPC to every other VPC, each VPC connects to a central Transit Gateway. The gateway handles routing between all attached VPCs. This reduces N VPCs from $\frac{N(N-1)}{2}$ connections to just $N$ connections.
VPC Peering remains the right choice for simple, stable, two-VPC connections. Transit Gateway is the right choice when you have three or more VPCs that need to communicate, or when your network topology is expected to grow.
Interviewers often ask: "You have 5 VPCs that all need to communicate with each other. How do you design this?" The trap answer is "VPC Peering mesh" — technically correct but operationally painful (10 connections, 10 sets of route table entries, no central policy control). The strong answer is Transit Gateway: each VPC attaches to a central TGW, you manage routing in one place, and adding a 6th VPC requires one new attachment instead of five new peering connections.