One VPC never stays alone. Teams get their own, environments get their own (prod/staging), acquisitions bring theirs, and eventually someone asks: "can service A in VPC-A call service B in VPC-B?" By default, absolutely not — VPCs are islands. This lesson is about the bridges.
VPC peering: a private cable between two VPCs
A peering connection joins exactly two VPCs so they can talk over private IPs — no internet, no gateways, no bandwidth bottleneck. But accepting the peering request is only step one. Nothing flows until both sides add routes. Feel that:
Peering routes: both sides or nothing
VPC-A and VPC-B are peered (pcx-11aa). Toggle the routes and send a request from A to B. A request needs a path there — and its reply needs a path back.
And the classic gotcha — peering CIDR overlap. Peering works by routing, and routing needs unambiguous destinations. If both VPCs are 10.0.0.0/16, a route "10.0.0.0/16 → peer" would fight the VPC's own local route. AWS simply refuses:
Try to peer twins
This is why organizations keep a CIDR allocation plan from day one — every new VPC gets a unique block (10.0/16, 10.1/16, 10.2/16…). Retro-fixing overlaps means re-IPing entire environments.
The transitivity wall — and the Transit Gateway
Peering has a hard rule: it is not transitive. If A peers with B, and B peers with C, then A still cannot reach C. Traffic will not hop through B, ever — the peering connection only forwards traffic between its own two members. With many VPCs, full connectivity via peering needs a mesh: 10 VPCs → 45 connections, each with routes on both sides. That's the n² problem, and the Transit Gateway (TGW) is the answer: a managed regional router every VPC attaches to once. Hub and spoke instead of mesh.
Watch transitivity fail, then fix it with a hub
A–B are peered; B–C are peered. Send A → C. Then flip to Transit Gateway mode and try again.
When to use which: two or three VPCs with stable needs → peering (simple, free per-GB within an AZ, lowest latency). A growing organization, shared services VPC, on-prem links, or anything past ~4 VPCs → Transit Gateway (one attachment each, central route tables you can segment — e.g. "prod spokes can't see dev spokes"). TGW costs per attachment-hour and per GB, so it's a convenience you pay for.
Reaching outside AWS: VPN and Direct Connect
Site-to-Site VPN
Encrypted IPsec tunnels over the public internet
Terminates on a Virtual Private Gateway or TGW
Up and running in hours; cheap
Latency and jitter are the internet's — no guarantees
~1.25 Gbps per tunnel ceiling
Direct Connect
A physical fiber from your data center/colo into AWS
Consistent latency, 1–100 Gbps
Weeks to provision; real money
Not encrypted by itself — often paired with VPN on top
The choice when hybrid is a permanent architecture, not a bridge
Both typically land on the Transit Gateway in mature setups, making on-prem effectively "one more spoke" in the hub.
Check yourself
1. A peering connection between VPC-A and VPC-B shows "active," but instances can't communicate. What's the first thing to check?
"Active" only means the handshake was accepted. Routes must be added in both VPCs' route tables (and SGs must allow the traffic — Lesson 2 never stops applying). Cross-region peering is supported, and no IGW is involved in peering at all.
2. Your shared-services VPC peers with 8 team VPCs. Team VPC-1 needs to call an API in team VPC-2. What's true?
This exact topology is how most teams discover non-transitivity. No route table trickery makes a peering connection forward third-party traffic. Either peer 1↔2 directly (hello, n² mesh) or move to a TGW.
3. Why do overlapping CIDRs block peering?
If both sides are 10.0.0.0/16, the address 10.0.1.10 exists in both worlds and no route table can distinguish them. There's no automatic NAT. Unique CIDR planning up front is the only clean answer.