Transit Gateway

Connecting 10 VPCs with peering alone would require 45 individual peering connections (and n(n-1)/2 route table entries to manage). A Transit Gateway solves this by acting as a central, regional network hub: every VPC (or VPN, or Direct Connect connection) attaches to it once, and the Transit Gateway routes traffic between all attachments — turning a full mesh into a simple hub-and-spoke.

• A Transit Gateway is a regional resource, but Transit Gateway peering lets you connect Transit Gateways across regions.
• Each VPC attaches via a Transit Gateway attachment, placed in one or more subnets (one per AZ you want reachable).
• Unlike VPC Peering, traffic is transitive through a Transit Gateway — if A and B are both attached, they can reach each other without a direct connection between them.

graph TD
TGW["Transit Gateway"] --- A["VPC A"]
TGW --- B["VPC B"]
TGW --- C["VPC C"]
TGW --- VPN["Site-to-Site VPN"]
TGW --- DX["Direct Connect"]
classDef vpc fill:transparent,stroke:#8b3de0,stroke-width:2px
class A,B,C vpc

Transit Gateway bills an hourly charge per attachment plus a per-GB data processing charge for traffic that flows through it — conceptually similar to a NAT Gateway’s pricing model, but per attachment rather than per gateway.

• Transitivity is the headline difference vs. VPC Peering — this is the #1 reason the exam picks Transit Gateway over “just peer everything” once 3+ VPCs are involved.
• Route tables on the Transit Gateway itself (separate from VPC route tables) let you segment which attachments can talk to which others — e.g. isolating a “quarantine” VPC.
• Transit Gateway supports attaching VPCs, VPNs, and Direct Connect (via a Direct Connect Gateway) all into one unified hub — a common exam scenario for hybrid, multi-VPC architectures.
• It also supports multicast and inter-region peering, both niche but occasionally tested facts.