Transit Gateway

Hub-and-spoke topology for VPCs, centralized routing tables, TGW peering across regions, and comparison with VPC peering.

Overview

Overview AWS Transit Gateway (TGW) is a regional network transit hub that enables customers to connect VPCs, VPNs, and Direct Connect connections through a single gateway, implementing a hub-and-spoke network topology at scale. Launched in 2018, it solved the fundamental scalability problem of VPC peering's non-transitive, full-mesh requirement.

Every VPC, VPN, or Direct Connect attachment connects to the Transit Gateway, and the TGW routes traffic between all connected networks according to its route tables. A single TGW supports up to 5,000 VPC attachments, making it suitable for large enterprise multi-account AWS environments managed via AWS Organizations.

TGW uses a routing table model distinct from VPC route tables. Each TGW has one or more route tables. Each attachment is associated with a route table (for inbound route lookup) and can propagate its CIDR to one or more route tables. This enables sophisticated network segmentation: for example, a production route table that allows VPC-to-VPC communication, a development route table that only allows access to shared services, and a shared services route table accessible from all environments.

Transit Gateway peering extends this capability across AWS regions: two TGWs in different regions can be peered, creating a global network fabric. Cross-region TGW peering uses static routes (no dynamic propagation) and traverses the AWS backbone.

For connectivity with on-premises networks, TGW integrates with Site-to-Site VPN (each VPN tunnel terminates on TGW rather than individual VGWs) and Direct Connect Gateway (DXGW attaches to TGW via Transit VIF). This centralization means all VPCs share a single Direct Connect connection, dramatically reducing costs compared to per-VPC VGW configuration.

Key concepts

TGW Attachment
The connection between a resource and the Transit Gateway. Attachment types include VPC attachments (one per VPC, choosing subnets in each AZ), VPN attachments (Site-to-Site VPN tunnels), Direct Connect Gateway attachments (via Transit VIF), TGW Peering attachments (cross-region), and Appliance Mode attachments (for stateful inspection).
TGW Route Tables
TGW has its own route tables separate from VPC route tables. Each attachment is associated with a TGW route table for route lookups. Routes can be static (manually added) or dynamic (propagated from attachments). VPC CIDRs are auto-propagated when propagation is enabled. Multiple route tables enable network segmentation.
Route Propagation
When propagation is enabled for an attachment to a route table, the attachment automatically advertises its CIDR blocks to that route table. VPC attachments propagate their VPC CIDR. VPN attachments propagate BGP-learned routes from on-premises. Disabling propagation requires manual static routes and is used for isolation policies.
TGW Peering
Two TGWs in different AWS regions (or different accounts) can be peered. Unlike VPC peering, TGW peering does not use dynamic route propagation — all routes across the peering must be configured as static routes in the respective TGW route tables. This is a key operational difference from intra-region behavior.
Appliance Mode
For stateful firewall appliances in a centralized inspection VPC, all traffic flows from a specific source VPC must use the same Availability Zone path through the firewall (to maintain flow state). Appliance mode overrides TGW's default per-flow ECMP load balancing to ensure symmetric routing through the firewall.

When to use it

  • Connecting more than 10 VPCs with any-to-any or selective connectivity requirements
  • Centralizing VPN and Direct Connect connectivity shared across multiple VPCs
  • Implementing network segmentation between environments (prod/dev/shared services) at scale
  • Building a global network spanning multiple AWS regions with TGW peering
  • Centralized traffic inspection via a firewall VPC in a security hub-and-spoke architecture

Interview questions

  • Design a Transit Gateway architecture for a company with 50 VPCs across 3 environments (production, staging, development) where prod cannot communicate with dev, but all environments can reach a shared services VPC.

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio