Every AWS networking interview and Solutions Architect exam eventually asks the same question: should we peer VPCs directly, or route everything through a Transit Gateway?
The wrong answer is not "always use TGW." The wrong answer is also not "peering is free so use that." The right answer depends on topology, scale, and who owns the routing table at 2 a.m. when something breaks.
What VPC Peering actually gives you
VPC peering creates a private, non-transitive connection between two VPCs. Traffic stays on the AWS backbone. There is no NAT, no internet gateway, and no hourly charge for the peering connection itself — you pay for data transferred across it.
Best for:
- Two (maybe three) VPCs that need full private connectivity
- Same Region, low-latency requirements
- Simple hub-and-spoke where the hub is small and stable
- Teams that want minimal moving parts
Hard limits to remember:
- Peering is non-transitive — if VPC A peers with B and B peers with C, A cannot reach C through B
- CIDR blocks must not overlap between peered VPCs
- Cross-Region peering works but adds latency and separate peering connections per pair
- At scale, you get a mesh: N VPCs need up to N(N-1)/2 peering connections
What Transit Gateway (TGW) adds
AWS Transit Gateway is a regional hub that connects VPCs, VPN connections, Direct Connect gateways, and peering attachments to other TGWs. You attach spokes once; routing is centralized in route tables attached to the TGW.
Best for:
- Many VPCs (typically more than four) or a growing estate
- Hybrid cloud: on-prem via Site-to-Site VPN or Direct Connect through one hub
- Segmentation with multiple TGW route tables (prod vs dev, shared services isolation)
- Cross-account networking with Resource Access Manager (RAM)
Trade-offs:
- Hourly charge per attachment plus data processing per GB
- More concepts to operate: TGW route tables, propagation, static vs dynamic routes
- Still regional — multi-Region designs need TGW peering or separate hubs per Region
Side-by-side comparison
| Factor | VPC Peering | Transit Gateway |
|---|---|---|
| Transitive routing | No | Yes (within the hub) |
| Typical scale | 2–4 VPCs | Dozens to hundreds of VPCs |
| On-prem connectivity | Per-VPC VPN/DX (messy at scale) | Centralized via TGW |
| Cost model | Data transfer only | Attachment hours + data processing |
| Operational complexity | Low | Medium–high |
| Cross-account | Supported (accept peering) | Supported (RAM + attachments) |
Decision framework (use this in real designs)
- Count your VPCs today and in 18 months. If the answer is two and will stay two, peering is often enough.
- Draw the traffic paths. If spokes need to talk to each other and to on-prem, a mesh of peerings becomes unmaintainable fast.
- Check CIDR planning. Overlapping ranges block peering entirely. TGW does not fix overlapping VPC CIDRs inside attachments — plan IP space early.
- Model cost. For small static topologies, TGW attachment hours can exceed peering data transfer. For large dynamic estates, TGW usually wins on engineering time saved.
- Exam shortcut: "Hub-and-spoke with many VPCs and hybrid connectivity" → Transit Gateway. "Two VPCs, same Region, private connectivity" → VPC Peering.
Common mistakes
- Using peering as a "poor man's TGW" with five VPCs and a full mesh — route tables become a nightmare
- Deploying TGW for a dev + prod pair that never talks to anything else — you are paying for a hub you do not need
- Forgetting that security groups and NACLs still apply; networking connectivity is not authorization
- Assuming TGW replaces PrivateLink — it does not; use interface endpoints for service-to-service isolation
Practice it hands-on
The difference between reading this and understanding it is building both patterns once. Create two VPCs, peer them, ping across private subnets, then tear it down and rebuild with Transit Gateway attachments and separate route tables. You will feel why scale changes the answer.
Cloud Arena labs walk you through VPC peering and Transit Gateway in real AWS accounts — so you are not guessing on exam day or in a production design review.