Amazon · AWS security · Lesson 8 of 10

TGW hub: one transit, two VPN tunnels, route tables are policy

Hub VPC 10.50.0.0/16 and app VPC 10.51.0.0/16 plus on-prem 10.20.30.0/24 behind FortiGate 203.0.113.10. Do not peer-mesh the next twenty VPCs. Attach them to Transit Gateway tgw-lab. Site-to-Site VPN uses two tunnels. TGW route tables are the policy — not a full-mesh hope.

Updated 2026-08-18·20 min read·L2 primary·Quiz at end

After this page you can

Attach hub and app VPCs to tgw-lab instead of a peering spaghetti.
Terminate Site-to-Site VPN on the TGW (or explain VGW 203.0.113.60 as the single-VPC older path).
Treat two tunnels as the design, not a nice-to-have.
Read TGW route tables as the isolation policy.

The ticket

Third app VPC is coming. Someone already requested peering to hub, to app, and to tomorrow’s VPC. Phase-1 to 203.0.113.60 is “up” on one tunnel. Priya on 10.20.30.80 still cannot reach 10.51.0.0/16. The missing object is a TGW route, not another peer.

Quick interview answer

Transit Gateway is a regional hub: VPC attachments, Site-to-Site VPN attachments, Direct Connect, peering. You do not mesh twenty VPCs with peering. TGW route tables (association + propagation, or static) decide which attachments can talk — that is the isolation policy. AWS Site-to-Site VPN creates two tunnels for the connection; design for both, not one green peer. A virtual private gateway (VGW) attaches VPN to one VPC (this lab’s dummy VGW public 203.0.113.60). Prefer VPN on the TGW when many VPCs must reach on-prem FortiGate 203.0.113.10 / 10.20.30.0/24.

Transit Gateway connecting hub VPC, app VPC, and two VPN tunnels to FortiGate — Peering mesh is a ticket factory. TGW route tables are the policy.

Lab data · dummy only

Account 111122223333 · OUs Security / Workloads · hub VPC 10.50.0.0/16 · app VPC 10.51.0.0/16 · SG sg-web · NACL acl-app · bucket tc-lab-app-logs · role AppEC2Role · TGW tgw-lab · VGW public 203.0.113.60 · on-prem FortiGate WAN 203.0.113.10. Dummy account ID. Not yours.

Mental model

Object	Job	This lab
`tgw-lab`	Hub for many VPCs + VPN	Attachments: hub 10.50.0.0/16, app 10.51.0.0/16, VPN
TGW route table	Who can reach whom	Shared-services RT vs isolated-app RT
Site-to-Site VPN	Two tunnels to the customer gateway	CGW = FortiGate 203.0.113.10
VGW 203.0.113.60	VPN onto a single VPC	Fine for one VPC; do not scale it as a mesh

Hub with two tunnels

One tunnel down is a maintenance event, not an outage — if you built both.

https://111122223333.signin.aws.amazon.com/console

Training mock · not live

AWS console

VPCIAMS3CloudTrail

VPC → Transit gateways / Site-to-Site VPN

tgw-lab + vpn-onprem

TGW

tgw-lab

VPC attachments

hub 10.50.0.0/16 · app 10.51.0.0/16

Customer gateway

203.0.113.10 (FortiGate) · static / BGP as designed

VPN

Two tunnels · attached to tgw-lab (not a 20-VPC peer mesh)

TGW RT

Association + routes · 10.20.30.0/24 via VPN · isolation if required

TGW route tables are the policy. Training mock.

How to choose

Need	Use	Do not
2–3 VPCs, never more, no on-prem	Peering can still be honest	Promise it stays at three
Many VPCs + on-prem	TGW hub + VPN attachment	Peer-mesh 20 VPCs
One VPC only + on-prem	VGW 203.0.113.60 is valid	Pretend VGW is a multi-VPC hub
Isolate prod from sandbox	Separate TGW route tables	One RT with every attachment propagated

Runbook

Side A — attachments
Create tgw-lab. Attach hub and app VPCs (subnets in each AZ you actually use). Associate each attachment to the intended TGW RT.
Side B — VPN
Customer gateway 203.0.113.10. VPN on the TGW. Configure both tunnels on the FortiGate. On-prem LAN 10.20.30.0/24 must be in the TGW RT; AWS prefixes must be on the FortiGate.
Side C — prove
Both tunnels up. Ping from 10.20.30.80 to an app IP. describe-transit-gateway-route-tables shows the prefix. One tunnel down — traffic still flows.

aws cli · TGW + VPN

aws ec2 describe-transit-gateways --filters Name=tag:Name,Values=tgw-lab

aws ec2 describe-transit-gateway-attachments --filters Name=transit-gateway-id,Values=tgw-labxxxxxxxxx
# vpc-hub, vpc-app, vpn-onprem

aws ec2 describe-vpn-connections --query 'VpnConnections[].{State:State,Tunnels:VgwTelemetry}'
# two tunnels  ·  both UP

aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id tgw-rtb-lab \
  --filters Name=route-search.exact-match,Values=10.20.30.0/24
# Type: static/propagated   Attachment: vpn-onprem

Four failures

1 · One tunnel “is fine”

AWS gives you two. Patch day on the FortiGate will prove why.

2 · Attachments exist, TGW RT does not have the prefix

Blackhole. Association ≠ a route. Search the TGW RT.

3 · VPC route table still has no 10.20.30.0/24 → tgw-lab

TGW can be perfect. The VPC RT never sent the packet to the attachment.

4 · Peer-mesh plus TGW

Two control planes, asymmetric paths, duplicate CIDRs. Pick the hub.

How to prove it

Close only when

1) Both VPN tunnels are up. 2) TGW RT has 10.20.30.0/24 and the VPC CIDRs. 3) Each VPC RT points those prefixes at tgw-lab. 4) You did not add another peering “just in case.”

Traps

Symptom	Look at
IKE up, no ICMP	Phase-2 / TGW RT / VPC RT / SG / NACL
Works to hub, not to app	Separate TGW RT isolation — often intentional
Only tunnel-1 up	FortiGate second peer, PSK, or replay window — not “AWS is down”

AWS security class series: Shared + IAM · Org / OU · SG vs NACL · Role not key · KMS + Secrets · VPC endpoint · Trail + GuardDuty · TGW hub · S3 public · Interview