MeshWorld India Logo MeshWorld.
aws vpc networking transit-gateway privatelink 4 min read

AWS Transit Gateway & VPC Routing Cheatsheet: The Complete Reference

Jena
By Jena
AWS Transit Gateway & VPC Routing Cheatsheet: The Complete Reference

Connecting multiple Virtual Private Clouds (VPCs) across a large AWS organization can quickly lead to a complex mess of individual peering connections. AWS Transit Gateway acts as a highly scalable cloud router, allowing you to connect thousands of VPCs and on-premises networks together using centralized route tables and propagation rules.

This reference sheet covers Peering vs Transit Gateway, Transit Gateway route tables, VPC Endpoints, and centralized internet egress routing topologies.


- **VPC Peering**: Best for low-latency, point-to-point connections between a small number of VPCs. - **Transit Gateway**: Simplifies multi-VPC networks by acting as a hub, reducing route table complexity. - **VPC Endpoints**: Access AWS services (like S3 or DynamoDB) privately, bypassing the public internet using Gateway or Interface endpoints. - **Centralized Egress**: Route all outbound internet traffic from multiple spoke VPCs through a single egress VPC containing NAT Gateways.

Before diving into this cheatsheet, check out my previous deep-dive on AWS EKS Production Tuning Cheatsheet: The Complete Reference to see how we structured these patterns in practice.

VPC Peering vs AWS Transit Gateway

Choose the right connection model based on your architecture size and routing requirements.

FeatureVPC PeeringAWS Transit Gateway
TopologyMesh (point-to-point)Hub-and-Spoke (centralized)
Transitive RoutingNot SupportedSupported
Scale LimitUp to 125 peers per VPCUp to 5,000 attachments per Gateway
Data CostOnly standard data transfer feesHourly attachment cost + per-GB data processing fees
ComplexityHigh at scale ($O(N^2)$ connections)Low ($O(N)$ connections attached to hub)

Setting Up Transit Gateway Route Tables

A Transit Gateway (TGW) uses attachments to connect to VPCs. You can control traffic flow by setting up isolated TGW Route Tables.

# Terraform configuration example for isolated TGW routing

# 1. Create the Transit Gateway
resource "aws_ec2_transit_gateway" "main" {
  description = "Central Cloud Router"
  dns_support = "enable"
}

# 2. Attach a Spoke VPC to the Transit Gateway
resource "aws_ec2_transit_gateway_vpc_attachment" "spoke_a" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = var.spoke_a_vpc_id
  subnet_ids         = var.spoke_a_private_subnets
}

# 3. Define a custom Transit Gateway Route Table for security isolation
resource "aws_ec2_transit_gateway_route_table" "isolated" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
}

Private Service Access with VPC Endpoints

Keep traffic inside the AWS network backbone instead of routing requests to AWS public endpoints over the open internet.

1. Gateway Endpoints (Free)

Gateway endpoints route traffic to Amazon S3 and DynamoDB by modifying your subnet route tables, requiring zero code changes.

# Add a Gateway Endpoint for S3 to your private route tables
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0111222233334444

Interface endpoints assign private IPs from your local subnets to represent AWS services, utilizing elastic network interfaces (ENIs).

# Create an Interface Endpoint for Amazon EC2 API access
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.ec2 \
  --subnet-ids subnet-aaaa1111 subnet-bbbb2222 \
  --security-group-ids sg-99998888

Centralized Internet Egress Architecture

A cost-saving design is to centralize internet egress. Instead of placing NAT Gateways in every VPC, route all outbound internet traffic from multiple spoke VPCs through a Transit Gateway to a centralized “Egress VPC.”

graph TD
    subgraph Spoke_VPC_A["Spoke VPC A (Private Subnets)"]
        AppA["App A"] -->|0.0.0.0/0| RT_A["VPC Route Table"]
    end
    
    subgraph Spoke_VPC_B["Spoke VPC B (Private Subnets)"]
        AppB["App B"] -->|0.0.0.0/0| RT_B["VPC Route Table"]
    end
    
    subgraph Transit_Gateway["AWS Transit Gateway"]
        TGW_RT["TGW Route Table"]
    end
    
    subgraph Egress_VPC["Egress VPC (Public Subnets)"]
        TGW_Attachment["TGW Attachment Subnet"] -->|0.0.0.0/0| NAT["NAT Gateway"]
        NAT -->|Internet| IGW["Internet Gateway"]
    end

    RT_A -->|TGW Attachment| TGW_RT
    RT_B -->|TGW Attachment| TGW_RT
    TGW_RT -->|0.0.0.0/0| TGW_Attachment

Route Table Configurations for Centralized Egress

  1. Spoke VPC Route Tables:

    • Route 10.0.0.0/8 (internal) to the local VPC.
    • Route 0.0.0.0/0 (internet) to the Transit Gateway attachment.
  2. Transit Gateway Route Table:

    • Associate spoke attachments to propagate internal routes.
    • Add a static route for 0.0.0.0/0 pointing directly to the Egress VPC attachment.
  3. Egress VPC Route Tables:

    • TGW Attachment Subnet: Route 0.0.0.0/0 to the local NAT Gateway.
    • Public Subnet (NAT GW): Route 0.0.0.0/0 to the local Internet Gateway (IGW).
    • NAT GW Route back to Spoke: Route spoke IPs (10.0.0.0/8 range) back to the Transit Gateway.