Transit Gateway Patterns

Hub-and-spoke.

What Transit Gateway solves

VPC peering is many-to-many: every new VPC adds another mesh edge, and the count grows quadratically. Transit Gateway replaces that mesh with a single hub each VPC attaches to once. The connectivity math goes from N-squared back to N.

• Hub-and-spoke for many VPCs. Single TGW attachment per VPC replaces the N-by-N peering grid; routing centralises in one place.
• Cross-region connectivity. TGW peering between regions handles multi-region architectures without duplicating the mesh problem.
• On-prem connectivity. Direct Connect or VPN attaches once to the TGW; all spokes reach on-prem through the hub.
• RAM sharing across accounts. AWS Resource Access Manager shares the TGW across the organisation so each account does not need its own.

When to adopt

TGW pays back at scale. Below five VPCs the peering mesh is still tractable; above, it is not. Multi-account orgs cross the threshold sooner because per-account VPCs add up.

• Five or more VPCs. The N-by-N peering grid becomes unmanageable; TGW's fixed per-attachment cost is cheaper than the operational burden.
• Multi-account organisation. RAM-shared TGW lets spoke accounts attach without each owning a hub; the standard pattern for AWS Organizations.
• Complex routing requirements. Per-route-table policy supports transitive routing patterns that VPC peering cannot express.
• Centralised egress per spoke. Spokes route egress through a central NAT VPC attached to the TGW; one NAT gateway serves many spokes.

Cost model

TGW pricing has two dials: per-attachment per-hour and per-GB processed. At scale the data charge dominates; at low volume the per-attachment fixed cost dominates.

• Per-attachment per-hour. Roughly $36/month per attachment; multiplies with attachment count and the spoke architecture.
• Per-GB processed. $0.02/GB through the TGW; at meaningful cross-VPC traffic volume, this is the dominant line item.
• Compare to NAT and peering. TGW is often cheaper than per-VPC NAT at high cross-VPC volume; VPC peering is cheaper at low volume.
• Chargeback per account. Attachment-level cost supports per-team FinOps chargeback; orphaned attachments stand out.

Design patterns

Design patterns decide blast radius and inspection points. Per-environment route tables, an inspection VPC, and spoke isolation are the standard controls.

• Per-environment route tables. Separate prod, non-prod, and shared route tables; limits blast radius of routing mistakes to one environment.
• Inspection VPC pattern. Traffic between VPCs flows through a firewall VPC for inspection; required for many compliance regimes.
• Spoke isolation. Each spoke reaches only the hub; lateral connectivity between spokes happens only through inspection.
• Explicit propagation per route table. Document which attachments propagate to which tables; default-on propagation is how accidental connectivity ships.

Operating Transit Gateway

Operating TGW is a discipline. Named owners per attachment, quarterly review, and per-attachment monitoring keep the hub clean as the org grows.

• Named owner per attachment. Documented team responsible; orphaned attachments accumulate cost and blur the routing picture.
• Quarterly review. No-traffic attachments and stale route entries audited each quarter; drift surfaces faster on a fixed cadence.
• Per-attachment monitoring. Bytes processed, packet drops, attachment health all alarmed; anomalies flag for investigation before they become incidents.
• IaC source per attachment. Terraform definition for every attachment; click-ops creates the orphaned attachments nobody can explain six months later.