AWS Transit Gateway: What It Is and When to Use It

Definition

AWS Transit Gateway (TGW) is a regional network hub that interconnects VPCs, Site-to-Site VPN connections, Direct Connect gateways, and other Transit Gateways (via peering). It replaces complex full-mesh VPC peering with a single hub-and-spoke fabric that supports transitive routing — traffic from VPC A can reach VPC C through the TGW without an explicit A-to-C connection. TGW scales to thousands of attachments per hub, making it the de facto backbone for multi-VPC and hybrid architectures on AWS.

Transit Gateway is a paid service (per-attachment-hour + per-GB processed) and is the recommended evolution from traditional VPC peering once you have more than a handful of VPCs to connect.

How It Works

You create a Transit Gateway in a specific Region, then create attachments for each thing you want to connect:

• VPC attachment — links a VPC to the TGW via ENIs in one or more subnets (one per AZ for HA).
• VPN attachment — IPsec tunnels to an on-premises router; supports static or BGP routing.
• Direct Connect Gateway attachment — associates a DX gateway with the TGW for high-bandwidth hybrid connectivity.
• Peering attachment — connects two TGWs, either in the same Region or across Regions (cross-Region TGW peering).
• Connect attachment — GRE tunnels over VPC / DX, used primarily with SD-WAN appliances.

Each attachment is associated with one TGW route table. A route table holds routes like 10.1.0.0/16 → vpc-a-attachment. By mixing associations and propagations, you can build sophisticated routing topologies:

• One route table, full mesh — simplest: every attachment in one table, everyone can reach everyone.
• Segmented route tables — prod, non-prod, shared-services tables; restrict which spokes can reach which others.
• Central inspection — route spoke-to-spoke traffic through an inspection VPC (Network Firewall, GWLB + appliance), then out to destination.
• Centralized egress — spoke VPCs route 0.0.0.0/0 through TGW to a shared NAT Gateway in an egress VPC.

Transitive routing is what sets TGW apart from VPC peering: once VPCs A, B, and C are attached to the same TGW, traffic flows any-to-any subject to route tables. With pairwise peering you would need 3 peerings for 3 VPCs, 10 for 5, 45 for 10, and so on.

Key Features and Limits

• Attachments: up to 5,000 attachments per Transit Gateway (soft cap).
• Throughput per VPC attachment: up to 100 Gbps (aggregate across flows, typically ~50 Gbps per flow).
• Route tables: 20 per TGW (default; raisable). Routes can be propagated from attachments or static.
• ECMP: supported on VPN and Connect attachments — TGW load-balances across equal-cost paths.
• Multicast: supported (the only AWS service that natively supports multicast across VPCs).
• Cross-Region peering: TGWs in different Regions can peer with each other over the AWS backbone (inter-Region TGW peering).
• Appliance Mode: keeps bidirectional flows pinned to the same AZ — essential for stateful firewalls attached to TGW.
• Resource Access Manager (RAM) sharing: share a TGW across AWS accounts (and Organizations) so multiple accounts attach to one central hub.
• Network Manager: global view of TGW topology, events, and metrics.
• Attachment-level security: no SGs on TGW itself; enforce at VPC subnet and ENI level.
• IPv4 + IPv6: both supported.

Common Use Cases

1. Multi-VPC landing zone — each business unit or environment has its own VPC, all attached to a central TGW; saves from an N*(N-1)/2 peering explosion.
2. Hybrid cloud — VPN and Direct Connect attachments let on-premises networks reach every VPC through one hub.
3. Centralized egress — spoke VPCs have no NAT Gateway; they route internet traffic via TGW to a shared egress VPC that hosts a single NAT Gateway (or a third-party NGFW).
4. Centralized inspection — TGW routes all inter-VPC traffic through an inspection VPC that runs AWS Network Firewall or GWLB-attached appliances.
5. Multi-Region DR — cross-Region TGW peering stretches the hub, allowing a DR Region to reach production VPCs for failover or replication.
6. Multicast workloads — financial market data, media streaming, legacy enterprise apps that rely on multicast (TGW is the only AWS service that supports it).
7. Merger / acquisition integration — stitch two companies' AWS accounts and on-prem networks together quickly with RAM-shared TGW.
8. SD-WAN integration — Connect attachments terminate GRE tunnels from Cisco / Aruba / Palo Alto appliances running in a VPC.

Pricing Model

Transit Gateway has three pricing components:

• Attachment-hour: per-hour charge per attached VPC / VPN / DX Gateway / TGW-peering. Typically ~$0.05/hour per attachment per Region.
• Data processing: per-GB charge for all data processed by the TGW (both directions). Typically ~$0.02/GB.
• Cross-Region TGW peering: standard inter-Region data-transfer charges apply on top.

TGW itself is regional, so there is no per-hour TGW fee beyond attachments. At scale, the data-processing charge can become the dominant cost — cost audits typically compare TGW-centralized egress against per-VPC NAT Gateway placement. VPN attachments have the same $0.05/hour cost; VPC attachments are the most common.

Pros and Cons

Pros

• Massive scale: up to 5,000 attachments, thousands of routes.
• Transitive routing: any-to-any with route-table segmentation.
• Unified hybrid hub: VPC + VPN + DX + other TGWs in one place.
• Multicast support — unique among AWS networking services.
• Cross-account and cross-Organization via RAM sharing.
• Network Manager gives global topology visualization.

Cons

• Cost: attachment-hours + per-GB data processing can exceed simple VPC peering at small scale.
• Complexity: route-table design, associations, propagations, and appliance-mode are a learning curve.
• Bandwidth per flow: individual flows cap at ~50 Gbps, which can matter for extreme workloads.
• No TGW-level SG: security enforcement remains at VPC/ENI level.
• Regional: each Region has its own TGW; multi-Region requires TGW peering.

Comparison with Alternatives

| Feature | Transit Gateway | VPC Peering | AWS Cloud WAN | PrivateLink | | --- | --- | --- | --- | --- | | Topology | Hub-and-spoke | Point-to-point | Global fabric, policy-driven | Service-level | | Transitive | Yes | No | Yes | N/A | | Scale | 5,000 attachments | Pairwise only | Global segments, many attachments | Per service | | Scope | Regional (+peering) | VPC-to-VPC in same/other Region | Global | Regional | | Cost | Per-attachment + per-GB | Free (intra-AZ data transfer only) | Per-segment + per-GB | Per-hour + per-GB | | Best for | >5 VPCs, hybrid hub | 2–3 VPCs in same Region | Enterprise global WAN | Exposing one service |

VPC Peering remains free and simple for 2–3 VPCs; choose it when you don't need transitive routing. AWS Cloud WAN is the next step beyond TGW — a global policy-driven WAN that automates TGW-like constructs across Regions. PrivateLink solves a different problem: exposing a single service (behind an NLB) across accounts without full VPC connectivity.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — frequent topic: when to use TGW vs VPC Peering (answer: many VPCs and/or transitive routing), TGW with VPN for hybrid, RAM sharing across accounts.
• Solutions Architect Professional (SAP-C02) — deep: multi-account landing zones, segmented route tables, centralized egress/inspection patterns, DX Gateway + TGW, appliance mode.
• Advanced Networking Specialty (ANS-C01) — exhaustive: ECMP on VPN, multicast, Connect attachments, cross-Region TGW peering, Network Manager, BGP over VPN, asymmetric routing mitigation with appliance mode.
• Security Specialty (SCS-C02) — using TGW with centralized Network Firewall / GWLB inspection VPCs.

Classic exam traps: TGW supports transitive routing, VPC Peering does not. TGW is regional — use inter-Region TGW peering for multi-Region. Appliance mode prevents asymmetric routing for stateful appliances. Direct Connect gateway integrates with TGW for enterprise hybrid networking. TGW charges per attachment hour plus per GB processed.

Frequently Asked Questions

Q: When should I choose Transit Gateway over VPC Peering?

A: Use TGW when you have more than a handful of VPCs (the pairwise peering math becomes unmanageable — 10 VPCs require 45 peerings), when you need transitive routing (A ↔ B ↔ C through the hub), when you need to integrate on-premises via VPN or Direct Connect into the same fabric, or when you need centralized egress or inspection. Use VPC Peering when you have 2–3 VPCs, don't need transitivity, and want to avoid TGW's per-attachment fees.

Q: How does Transit Gateway transitive routing differ from VPC Peering?

A: VPC Peering is non-transitive by design: if A peers with B and B peers with C, traffic from A cannot reach C through B — you need an explicit A-to-C peering. Transit Gateway is transitive: every attachment's routes can be propagated into a shared route table, so A, B, and C all talk through the hub automatically. You control what goes where via route tables and associations/propagations, which lets you implement environment segmentation without losing the one-hop simplicity.

Q: What is "appliance mode" on a Transit Gateway attachment?

A: When a stateful appliance (firewall, IDS) sits in a VPC attached to TGW, asymmetric routing can cause return traffic to land in a different AZ — and therefore a different appliance — than the outbound traffic, breaking stateful inspection. Appliance mode (enabled on the appliance's VPC attachment) tells TGW to pin bidirectional flows to the same AZ, ensuring the same appliance sees both directions. Enable it whenever you use TGW with stateful network appliances for inter-VPC inspection.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Transit Gateway documentation before making production decisions.