1. The Problem: VPC Mesh

With VPC Peering, connecting N VPCs requires N(N-1)/2 connections. At scale, this becomes unmanageable. Transit Gateway solves this with a hub-and-spoke model.

VPC Peering (mesh):          Transit Gateway (hub-and-spoke):

  A───B                     A
  |\ /|                      \
  | X |       vs.         B───TGW───D
  |/ \|                      /
  C───D                     C

  4 VPCs = 6 connections    4 VPCs = 4 connections
 10 VPCs = 45 connections  10 VPCs = 10 connections


2. What is Transit Gateway?

AWS Transit Gateway is a network transit hub that connects VPCs, VPN connections, Direct Connect gateways, and on-premises networks through a single central gateway. It uses a hub-and-spoke model.

Core Concept
Transit Gateway is a Regional router that acts as a central hub. Attach VPCs, VPN, and Direct Connect to the TGW. All attached networks can communicate with each other through the TGW (if route tables allow). It replaces complex VPC Peering meshes and simplifies multi-VPC, hybrid architectures.

3. Key Characteristics

  1. Regional service (operates within one Region, but supports inter-Region peering)
  2. Hub-and-spoke model: all traffic flows through the TGW
  3. Supports: VPC attachments, VPN attachments, Direct Connect Gateway attachments, peering with other TGWs
  4. Transitive routing: VPC-A → TGW → VPC-B works without direct peering
  5. Route tables: TGW has its own route tables for controlling traffic between attachments
  6. Supports IP Multicast (the only AWS service that does)
  7. Bandwidth: up to 50 Gbps per VPC attachment
  8. Works across AWS accounts (via AWS RAM sharing)
  9. Supports ECMP (Equal-Cost Multi-Path) for VPN to aggregate bandwidth

4. TGW Architecture

Transit Gateway Hub-and-Spoke:

     ┌────────┐    ┌────────┐
     │ VPC-A  │    │ VPC-B  │
     └────┬───┘    └───┬────┘
          \            /
    ┌────────────────────┐
    │   Transit Gateway    │
    │   (Regional Hub)     │
    └───┬──────┬──────┬───┘
        |        |        |
     VPC-C   Site-to-  Direct
             Site VPN  Connect
                |        |
           On-premises Data Center


5. TGW Route Tables

  1. TGW has its own route tables (separate from VPC route tables)
  2. Control which attachments can communicate with which other attachments
  3. Default: one route table, all attachments can talk to each other
  4. Use multiple route tables for network segmentation (e.g., isolate prod from dev)


Route Table Segmentation Example

TGW Route Table: "Production"
  Associations: VPC-Prod-A, VPC-Prod-B, VPN-Corp
  Propagations: VPC-Prod-A, VPC-Prod-B, VPN-Corp
  Result: Prod VPCs + Corp VPN can talk to each other

TGW Route Table: "Development"
  Associations: VPC-Dev-A, VPC-Dev-B
  Propagations: VPC-Dev-A, VPC-Dev-B
  Result: Dev VPCs can talk to each other but NOT to Prod

Network segmentation without NACLs or SGs!


6. TGW Inter-Region Peering

  1. Connect Transit Gateways in different Regions
  2. Enables cross-Region VPC communication through TGW
  3. Traffic stays on the AWS global backbone (encrypted in transit)
  4. Static routing only (no dynamic route propagation across peering)

7. TGW + ECMP for VPN

  1. ECMP (Equal-Cost Multi-Path) aggregates bandwidth across multiple VPN tunnels
  2. Each Site-to-Site VPN connection provides 2 tunnels × 1.25 Gbps each
  3. With ECMP enabled on TGW, traffic is distributed across all tunnels
  4. Example: 4 VPN connections = 8 tunnels = 10 Gbps aggregate bandwidth
  5. Not possible with Virtual Private Gateway (VGW) — only TGW supports ECMP

8. VPC Peering vs Transit Gateway

Exam Tip
Transit Gateway: "Connect 10+ VPCs" = TGW. "Hub-and-spoke" = TGW. "Transitive routing needed" = TGW. "VPN + multiple VPCs" = TGW. "IP Multicast" = TGW (only service). "Network segmentation across VPCs" = TGW route tables. "ECMP for VPN bandwidth" = TGW. "2–3 VPCs, cheapest" = VPC Peering (free). Share TGW cross-account via AWS RAM.