AWS Transit Gateway Cheat Sheet

🚀 Level 1: Core TGW Mechanics & Subnet Design

• The Hub & Spoke Engine: A regional Layer 3 cloud router that connects thousands of VPCs, completely replacing complex, non-transitive VPC Peering meshes.
• Subnet Multi-AZ Rule: Connects to a VPC by placing exactly one elastic network interface (ENI) inside a chosen subnet per Availability Zone (AZ).
• Dedicated /28 Design Pattern: Best practice dictates creating tiny, dedicated /28 subnets strictly for the TGW ENIs. This completely isolates core routing logic and custom NACLs from application workloads.
• VPC Fabric Routing: Subnets without a direct TGW ENI utilize the local VPC implicit router to forward traffic across the internal fabric to the TGW interface located within their same AZ.
• The Regional Boundary: TGW is strictly a regional resource; it cannot cross geographical borders natively without an explicit peering link.

[ Application Subnet (10.0.1.0/24) ] ──(Local Router)──► [ Tiny /28 TGW Subnet (10.0.2.0/28) ]
                                                                      │
                                                                 (TGW ENI)
                                                                      │
                                                                      ▼
                                                             [ Central TGW Hub ]

🎛️ Level 2: The Routing Engine (Association vs. Propagation)

• Association (Ingress Map): Directs the TGW on which specific route table to read when a packet leaves a spoke VPC and enters the TGW hub.
• The 1:1 Limit: An attachment can be associated with exactly one TGW route table at a time.
• Propagation (Egress Map): Directs the TGW on which route tables should dynamically learn and record this VPC’s network CIDR range.
• The 1:Many Scale: An attachment can propagate its routes to multiple TGW route tables simultaneously.
• Unidirectional Traffic Block: TGW routing is entirely stateless and cannot enforce one-way traffic (e.g., allow A -> B but block B -> A). Bidirectional paths are mandatory for TCP; stateful isolation must be handled via EC2 Security Groups.

🔒 Level 2 (Advanced): Centralized Traffic Inspection

• The Routing Loop Threat: Sending traffic to a firewall cluster and returning it to the spokes using a single TGW route table causes an infinite loop. You must separate this logic into two distinct route tables.
• Spoke TGW Route Table Configuration:
• Associations: Handled for all application workload spoke attachments.
• Static Steering Rule: Do not use dynamic propagation. Instead, create a manual static route (0.0.0.0/0 or 10.0.0.0/8) pointing directly to the Inspection VPC Attachment.
• Inspection TGW Route Table Configuration:
• Associations: Handled only for the Inspection VPC attachment itself.
• Propagations: Enabled for all spoke attachments. Once the firewall scrubs the packet and passes it back to the TGW, this map knows the exact, direct route to the target spoke.

[ Spoke VPC A ] ──► (Spoke-TGW-RT) ──[ Static 0.0.0.0/0 ]──► [ Inspection VPC (Firewall) ]
                                                                          │
[ Spoke VPC B ] ◄── (Inspection-TGW-RT) ◄──[ Dynamic Propagated Route ]───┘

🏢 Level 3: Enterprise Multi-Account Architecture & AWS RAM

• The Multi-Account Strategy: Isolates blast radiuses by separating central core networking, development workspaces, and production workloads into distinct AWS accounts.
• AWS Resource Access Manager (RAM): The secure bridge used to share a single central TGW engine out to external or organizational accounts.
• The Shared Engine Concept: RAM sharing does not provision a new router in the target account. There is only one physical TGW asset, located in the central Network Account. Spoke accounts merely plug their local VPCs into it.
• The Payer vs. Participant Billing Split: Highly tested target constraint.
• Hourly Attachment Fee: Billed completely to The Owner (Central Network Account).
• Data Processing Fee ($/GB): Billed completely to The Participant (The Spoke Account that generated the traffic).
• AWS Organizations Integration: Safely automates resource visibility at scale.
• The Automated Handshake: Sharing to an Organization ID or Organizational Unit (OU) ID completely bypasses the manual RAM invite confirmation step.
• Auto-Accept Attachments: Enabling this toggle on the TGW allows new spoke VPC attachments to spin up and activate instantly without network administrator approval.
• The External Account Handshake: Accounts outside the AWS Organization boundary require a two-step manual confirmation:

1. The external account must explicitly Accept the RAM Resource Share.

2. The network owner account must explicitly Accept the TGW VPC Attachment Request.

🌐 Levels 2 & 3: Cross-Region Architecture Patterns

• The Propagation Hard Limit: Dynamic route propagation does not cross inter-region TGW Peering connections.
• Static Bridge Rule: You must manually inject Static Routes into the TGW route tables of both regions, pointing target destination CIDRs to the tgw-peering-attachment-id.
• Subnet Target Logic: A local VPC subnet route table never targets a remote regional TGW. It always targets its local regional TGW ID, which passes the packet to the peering link.
• Decentralized Local Inspection Best Practice: Deploy a dedicated Inspection VPC per region. Routing inter-region traffic back to a single centralized region for firewall processing doubles data transfer costs and introduces extreme network latency.

[ Region A: us-east-1 ]                                     [ Region B: us-west-1 ]
[ VPC-A ] ──► [ TGW-A ] ──► (TGW-RT-A: Static Route) ──► [ TGW Peering ] ──► [ TGW-B ] ──► [ VPC-B ]

🔌 Level 4: Hybrid Connectivity & Global Scale (DX & VPN)

• The Transit VIF Mandate: The Transit Virtual Interface (Transit VIF) is the only Direct Connect connection layer capable of terminating on a TGW environment.
• The Direct Connect Gateway (DXGW) Hub: A non-regional, global routing component that sits directly between your physical fiber line and your cloud network.
• The Scale Limit: A single Transit VIF terminates on a DXGW, which can associate with up to 3 separate regional Transit Gateways globally.
• BGP Autonomous System Numbers (ASNs): For dynamic routing paths to initialize, the ASN assigned to your on-premises router must be completely different from the ASN configured on the AWS TGW/DXGW hub. Same ASNs cause an immediate loop-prevention drop.
• Breaking the 1.25 Gbps VPN Cap: A single IPsec VPN tunnel is limited to 1.25 Gbps due to hardware encryption limits. To scale throughput, you must enable TGW ECMP (Equal-Cost Multi-Pathing) and stripe traffic dynamically across multiple active BGP tunnels simultaneously.
• Path Failover Logic (DX vs. VPN): Managed natively by AWS using BGP priority evaluation:
• Outbound (AWS -> On-Prem): Longest Prefix Match wins first -> Shortest AS-Path wins second -> Direct Connect paths are natively preferred over VPN paths.
• Inbound (On-Prem -> AWS): Managed by your on-premises router using AS-Path Prepending (repeating your ASN to make a backup line look long and unattractive to AWS).
• Outbound Twin Links (AWS -> On-Prem Multi-DX): Managed by passing a lower BGP Multi-Exit Discriminator (MED) value to AWS on your primary line.

⚠️ Level 4 (Advanced): Deep Edge Cases

• Asymmetric Routing & TGW Appliance Mode: When combining centralized traffic inspection with multi-AZ hybrid connections, return paths can land on different stateful firewall nodes, breaking the connection.
• The Fix: You must explicitly enable Appliance Mode on the TGW VPC Attachment for the Inspection VPC to force both traffic directions to stick to the same AZ.
• The Inter-Region MTU Drop: Within a single region, TGW fully supports Jumbo Frames (9001 MTU). The exact moment traffic crosses an inter-region TGW Peering Connection, the performance ceiling drops strictly to 8500 MTU.
• Overlapping Network Ranges: If two spoke accounts share identical IP address allocations, they cannot propagate paths to the same TGW route table. You must implement Private NAT Gateways to translate the overlapping ranges into unique blocks before hitting the TGW attachment.
• Native Multicast Support: TGW bypasses standard cloud unicast limitations by offering TGW Multicast Domains, allowing legacy video feeds or high-frequency financial market tickers to stream to registered EC2 instances simultaneously.