AWS Transit Gateway: Multi-VPC and Multi-Account Networking

Full mesh VPC peering stops scaling around four VPCs. By the time you have a production VPC, a shared services VPC, a security inspection VPC, and three environment VPCs across two accounts, the peering diagram looks like a conspiracy board and your route tables are a liability. Transit Gateway (TGW) is AWS's answer: one regional hub, attachments instead of pairwise peering, and route tables that let you express hub-and-spoke (or mesh-with-policy) without N² complexity.

This is core AWS Advanced Networking Specialty (ANS) territory and daily driver material for anyone running multi-account AWS.

Mental Model

[ VPC A ]──┐
[ VPC B ]──┼──► Transit Gateway ◄──► [ VPN / DX ]
[ VPC C ]──┘         │
                     ├── TGW route table: prod
                     ├── TGW route table: shared-services
                     └── TGW route table: inspection

• Attachment — a VPC, VPN, Direct Connect Gateway, or peering connection registered to the TGW.
• TGW route table — separate from VPC route tables; decides which attachment receives traffic for a given CIDR.
• Association — binds an attachment to exactly one TGW route table for inbound routing decisions.
• Propagation — optionally injects an attachment's CIDRs into a TGW route table automatically (great for spokes, dangerous for inspection VPCs if you're not careful).

The packet path: instance → VPC route table → TGW attachment ENI → TGW route lookup → egress attachment ENI → destination VPC route table → target.

When TGW Wins Over Peering

Scenario	Peering	Transit Gateway
2 VPCs, low traffic	Simple, cheap	Overkill
5+ VPCs, shared services	N(N-1)/2 peerings	One hub
Centralized egress / inspection	Route gymnastics	Dedicated inspection RT
Multi-account via RAM	Cross-account peering pain	Share TGW with Organizations
On-prem + many VPCs	DX/VPN per VPC or VGW	Single VPN/DX attachment to TGW

Cost note: TGW charges per attachment-hour plus per-GB processed. For two VPCs it's cheaper to peer. For eight VPCs and a VPN, TGW is usually cheaper and operable.

Building a Hub-and-Spoke

1. Create the TGW

resource "aws_ec2_transit_gateway" "hub" {
  description                     = "org-hub-us-west-2"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  auto_accept_shared_attachments  = "enable"

  tags = { Name = "tgw-hub-prod" }
}

Disabling default association/propagation is deliberate — you want explicit route tables for prod vs. dev vs. shared services. The ANS exam loves trick questions where default propagation leaks dev CIDRs into prod.

2. VPC Attachment

Each spoke VPC needs:

• Subnets in different AZs (TGW creates ENIs per AZ you select)
• dns_support and ipv6_support enabled on the attachment if needed
• VPC route table entries: 10.0.0.0/8 → tgw-xxxxx (or more specific prefixes)

resource "aws_ec2_transit_gateway_vpc_attachment" "app" {
  subnet_ids         = [aws_subnet.tgw_a.id, aws_subnet.tgw_b.id]
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  vpc_id             = aws_vpc.app.id

  dns_support  = "enable"
  ipv6_support = "disable"

  tags = { Name = "tgw-attach-app-prod" }
}

3. TGW Route Tables (the part people mess up)

Example three-table design:

Route table	Associated attachments	Typical routes
rt-spokes	App, Data, Dev VPCs	10.0.0.0/8 → local, 0.0.0.0/0 → inspection-vpc
rt-shared	Shared Services (AD, DNS)	Propagated spoke CIDRs
rt-inspection	Firewall VPC	0.0.0.0/0 → firewall attachment, spokes propagated

Blackhole routes appear when a CIDR is propagated but the attachment is down — TGW shows blackhole in the console. If your exam question mentions intermittent reachability after an AZ failure, check whether TGW subnets lost an ENI.

4. Multi-Account with RAM

In the network account:

1. Create TGW.
2. Share via AWS Resource Access Manager (RAM) to workload accounts.
3. Workload accounts create VPC attachments to the shared TGW.
4. Network account owns TGW route tables and approves attachments.

This is the landing zone pattern — network team controls the hub, app teams attach spokes. IAM and SCPs prevent teams from creating rogue peerings.

Inspection VPC Pattern

Egress from spokes through a centralized firewall (Palo Alto VM-Series, FortiGate, etc.):

1. Spoke VPC route: 0.0.0.0/0 → TGW
2. TGW rt-spokes: 0.0.0.0/0 → inspection-attachment
3. Inspection VPC: firewall subnets, no Internet Gateway on spoke-facing subnets — IGW only on firewall public subnets if needed
4. Return traffic must hairpin symmetrically or the firewall drops it

Asymmetric routing is the #1 production failure. Use same AZ for TGW ENI and firewall ENI where possible, and verify security groups/NACLs on the TGW ENI subnets.

VPN and Direct Connect to TGW

• Site-to-Site VPN attaches to TGW (not VGW) for multi-VPC reachability in one tunnel set.
• Direct Connect Gateway associates with TGW — on-prem learns VPC CIDRs via BGP; TGW route tables control which VPCs see which on-prem prefixes.

BGP over DX is where ANS gets spicy: local preference, AS path prepending, and advertising only specific prefixes to avoid becoming a transit AS for your entire corporate WAN.

Operations Checklist

# Attachment state
aws ec2 describe-transit-gateway-vpc-attachments \
  --filters Name=transit-gateway-id,Values=tgw-0abc123

# Routes in a TGW route table
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0def456 \
  --filters Name=state,Values=active

# Flow logs — enable on TGW (not just VPC FL)
aws ec2 create-flow-logs \
  --resource-type TransitGateway \
  --resource-ids tgw-0abc123 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /tgw/hub/flowlogs

Pair TGW flow logs with VPC Reachability Analyzer when a path "should work" — it models security groups, NACLs, and route tables together.

ANS Exam Angles

• Default association/propagation disabled → manual RT design
• TGW vs. VPC peering vs. PrivateLink (TGW = L3 connectivity; PrivateLink = L7/service endpoint consumer)
• Appliance mode on attachments (for stateful inspection — ensures symmetric flow through one AZ's firewall)
• MTU: TGW supports 8500 bytes with jumbo frames on supported instances — know when fragmentation breaks VPN paths
• Multicast (TGW multicast domain) — niche but testable on ANS

Related Reading

• AWS VPC Fundamentals — subnets, route tables, and the building blocks
• AWS Hybrid Connectivity — DX, VPN, and on-prem integration with TGW
• AWS Advanced Networking — broader ANS topic coverage
• Terraform for Network Engineers — codify TGW attachments and route tables

Explore the full stack on TechHub Learning.