Transit Gateway Architecture: Hub-and-Spoke Networking

AWS Transit Gateway revolutionized how organizations connect VPCs. Instead of mesh peering, Transit Gateway provides a central hub for routing at scale. This guide covers architecture patterns, routing, and integration with VPN and Direct Connect.

The Problem Transit Gateway Solves

Before Transit Gateway: VPC Peering Mesh

5 VPCs = 10 peering connections
10 VPCs = 45 peering connections
20 VPCs = 190 peering connections

Each VPC needs route to every other VPC
Changes require updating all VPCs
VPN/Direct Connect attached per VPC

With Transit Gateway: Hub-and-Spoke

               ┌──────────────────────┐
               │   Transit Gateway     │
               │   (Central Hub)       │
               └──────────┬───────────┘
        ┌─────────────────┼─────────────────┐
        │         │       │       │         │
        ▼         ▼       ▼       ▼         ▼
     [VPC 1]  [VPC 2] [VPC 3] [VPN] [Direct Connect]

Any-to-any communication through central hub
Single point of control for routing
One VPN/DX attachment serves all VPCs

Transit Gateway Concepts

Attachments

Connections to Transit Gateway:

• VPC attachment: Connect VPC to TGW (specify subnets)
• VPN attachment: Site-to-Site VPN terminates on TGW
• Direct Connect Gateway: Connect TGW to Direct Connect
• Transit Gateway Connect: SD-WAN integration via GRE
• Peering attachment: Connect to TGW in another region/account

Route Tables

Control traffic flow between attachments:

• Default route table: All attachments associated and routes propagated by default
• Custom route tables: Granular control over routing
• Association: Which route table an attachment uses
• Propagation: Which route tables receive the attachment's routes

Architecture Patterns

Pattern 1: Flat Network (All-to-All)

Single route table, all attachments associated and propagated

Use case: 
- Simple connectivity between all VPCs
- Every VPC can reach every other VPC
- VPN/Direct Connect reaches all VPCs

Pattern 2: Isolated VPCs with Shared Services

Route Tables:
- Shared Services RT: Routes to all VPCs
- Prod RT: Routes to shared services only
- Dev RT: Routes to shared services only

┌────────────────────────────────────────────────────┐
│                 Transit Gateway                     │
├──────────────────┬────────────────┬────────────────┤
│ Shared Svc RT    │ Production RT  │ Development RT │
│ → All VPCs       │ → Shared only  │ → Shared only  │
└──────────────────┴────────────────┴────────────────┘
        │                  │                │
   [Shared VPC]       [Prod VPCs]      [Dev VPCs]

Prod and Dev cannot communicate with each other
Both can reach shared services (DNS, logging, etc.)

Pattern 3: Inspection VPC

All traffic routes through security appliances

┌─────────────────────────────────────┐
│           Transit Gateway            │
│                                     │
│  Spoke Route Table:                 │
│  0.0.0.0/0 → Inspection VPC         │
│                                     │
│  Inspection Route Table:            │
│  10.0.0.0/8 → specific VPCs         │
└───────────────────┬─────────────────┘
                    │
            [Inspection VPC]
            [Firewall/IDS]

Multi-Account Architecture

RAM Sharing

Share Transit Gateway across AWS accounts using Resource Access Manager:

# Share TGW with organization or specific accounts
aws ram create-resource-share \
  --name "Transit-Gateway-Share" \
  --resource-arns "arn:aws:ec2:region:account:transit-gateway/tgw-xxx" \
  --principals "arn:aws:organizations::account:organization/o-xxx"

Centralized Networking Account

Networking Account (owns TGW)
├── Transit Gateway
├── Direct Connect Gateway
├── VPN connections
└── Shared services VPC

Workload Accounts (use shared TGW)
├── Production Account → VPC attached to TGW
├── Development Account → VPC attached to TGW
└── Security Account → Inspection VPC attached to TGW

VPN Integration

Site-to-Site VPN on Transit Gateway

• ECMP support: Multiple tunnels for higher throughput
• Accelerated VPN: Uses AWS Global Accelerator for improved performance
• BGP routing: Dynamic route exchange with on-premise

Scaling VPN Bandwidth

# Single VPN: 1.25 Gbps per tunnel
# With ECMP: Multiple VPNs for aggregate bandwidth

Customer Gateway 1 ─── VPN 1 (2 tunnels) ───┐
                                            ├── TGW (ECMP)
Customer Gateway 2 ─── VPN 2 (2 tunnels) ───┘

Total bandwidth: 4 tunnels × 1.25 Gbps = 5 Gbps

Direct Connect Integration

Transit VIF

On-Premise → Direct Connect → Transit VIF → DX Gateway → Transit Gateway

Benefits:
- Single DX connection serves all VPCs via TGW
- No per-VPC virtual interfaces needed
- Supports 5000+ VPCs (vs 10 with Private VIFs)

Multi-Region with Direct Connect

On-Premise
    │
Direct Connect Location
    │
Direct Connect Gateway (global)
    ├── TGW (us-east-1)
    └── TGW (eu-west-1)
    
Single DX reaches all regions via TGW

Inter-Region Peering

Connect Transit Gateways across regions:

us-east-1 TGW ◄────── Peering ──────► eu-west-1 TGW
     │                                     │
  [US VPCs]                            [EU VPCs]

Traffic between regions flows over AWS backbone
Add static routes for cross-region traffic

Routing Best Practices

Route Prioritization

1. Most specific route wins (longest prefix match)
2. Static routes take precedence over propagated
3. For equal prefix: VPC > Direct Connect > VPN

Blackhole Routes

# Create blackhole to drop traffic to specific CIDR
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-xxx \
  --destination-cidr-block 10.99.0.0/16 \
  --blackhole

Limits and Quotas

• Attachments: 5,000 per TGW
• Routes per route table: 10,000
• Bandwidth: 50 Gbps per VPC attachment
• Peering connections: 50 per TGW

Key Takeaways

• Transit Gateway replaces VPC peering mesh with hub-and-spoke
• Route tables control connectivity between attachments
• Use isolation patterns for security segmentation
• Share TGW across accounts with Resource Access Manager
• VPN ECMP enables higher throughput than single connection