The Hub-and-Spoke Problem
The Hub-and-Spoke Problem
VPC peering does not transit: with N VPCs you need a full mesh of pairwise peers, each with its own route table entries, and every new account adds another N connections. Transit Gateway replaces the mesh with a regional hub: VPC, VPN, Direct Connect gateway, and peering attachments all plug into one router you reason about centrally.
Inside TGW, route tables do the isolation work — attachments associate with a table, and propagated (from BGP/peers) or static routes decide what each attachment can reach. Associate-and-propagate defaults make on-prem prefixes appear automatically; static routes pin specific destinations. TGWs in different regions connect through TGW peering, and RAM shares one hub across accounts.
Building the Hub
Building the Hub
aws ec2 create-transit-gateway --description hub \
--amazon-side-asn 64512
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-123 --vpc-id vpc-abc \
--subnet-ids subnet-1 subnet-2
Two route-table entries are required per spoke: the VPC route table's route to the TGW CIDR pointing at the TGW attachment target, and the TGW route table's route back to the VPC CIDR. For on-prem, a VPN attachment brings two tunnels; BGP over them advertises corporate prefixes.
Give each environment (prod/dev) its own TGW route table so attachments cannot see each other unless you explicitly allow it.
Pitfalls and Interview Focus
Pitfalls and Interview Focus
The classic outage: VPC route updated, TGW route forgotten (or vice versa) — traffic dies in one direction. Enable appliance mode when an attachment targets a middlebox/inspection VPC: it pins the source AZ so stateful flows are not asymmetric across AZs. Without it, return traffic can land on a different appliance that has no session state.
Other traps: the default TGW route table auto-associates new attachments, silently connecting things you meant to isolate; forgetting RAM sharing leaves other accounts unable to attach; and assuming TGW transit works across regions without TGW peering.
Interview: draw hub, attachments, and both route tables, then name appliance mode as the fix for asymmetric flows.
Quiz
1. What problem does Transit Gateway solve versus VPC peering?
2. When is Transit Gateway appliance mode required?
3. How do multiple accounts use one Transit Gateway?
Flashcards
Question
TGW attachment types
Click to reveal answer
Answer
VPC, VPN, Direct Connect gateway, peering — all routed through TGW route tables.
Question
Association vs propagation
Click to reveal answer
Answer
Association: which table an attachment belongs to. Propagation: routes learned into it.
Question
Appliance mode
Click to reveal answer
Answer
Pins an attachment to one AZ so stateful middleboxes avoid asymmetric flows.
Question
Transit vs peering
Click to reveal answer
Answer
Peering is pairwise and non-transitive; TGW is a transitive regional hub.
Question
Cross-account TGW
Click to reveal answer
Answer
Share via RAM, then each account creates its own attachments.
Revision Notes
Key Takeaways
- 1. TGW turns an N² peering mesh into one hub governed by route tables
- 2. Both route directions (VPC and TGW) must exist or traffic dies one-way
- 3. Appliance mode and explicit route-table isolation prevent the two famous failures
Interview Tips
- • Explain TGW routing as two decisions: VPC route table → attachment, TGW route table → destination
- • Name appliance mode when a design includes an inspection/egress VPC
Cheat Sheet
TGW = hub for VPC/VPN/DX/peering attachments. Per spoke: VPC route → TGW + TGW route → CIDR. Separate TGW route tables per env; RAM-share across accounts; appliance mode for middlebox AZs.