AWS Networking · Deep Dive18 min read

AWS Transit Gateway, Top to Bottom

The regional router that becomes the backbone of a real AWS network. We'll build it from the mental model all the way to multi-region segmentation, simplified, but at expert depth.

From your mentor

Transit Gateway is where networking gets serious. Don't memorise it, picture an airport hub. Once you see how attachments and route tables interact, every advanced pattern (isolation, central egress, inspection) is just a routing choice.

A Transit Gateway is just a regional router that every VPC plugs into.

In 12 minutes you’ll see how one hub replaces a mess of peering links. You do NOT need multi-region segmentation yet.

Pick your way in, same idea, 5 doors

Connect 10 VPCs with peering and you need ~45 cables, a hairball. A Transit Gateway is one central hub: every VPC plugs in once, and the hub routes between them all. That’s the whole idea.

Next: trace a packet from one VPC to another, through the hub.

The problem it kills

You met Transit Gateway as 'the hub' earlier. Here's the full picture, because at scale, it's the thing your entire network routes through.

Connect N VPCs with peering and you need N×(N−1)/2 links, and none of them are transitive. Ten VPCs is already 45 connections to create, route, and babysit. Transit Gateway turns that into N: each network attaches once.

In plain English

Think of an airport hub. Peering is a direct flight between every pair of cities, it explodes. A Transit Gateway is the hub: every city flies to one airport and connects onward from there. Attach once, reach everything.

What it actually is

A Transit Gateway is a regional, fully-managed virtual router. Networks attach to it; its own route tables decide where each packet goes next.

VPC AVPC BVPC C On-prem

Transit Gateway (hub)

A hub-and-switch in the middle. Every network attaches once to the Transit Gateway and can reach every other, it IS transitive, and scales to thousands of VPCs plus on-prem.

Regional, managed, transitive

One TGW lives in one Region (you peer them across Regions). AWS runs it, no instances to patch. And unlike peering, it’s transitive by default: any attachment can reach any other, subject to the route tables.

The five attachment types

Everything that plugs into a TGW is an 'attachment', think of each as a port on the router.

Attachment	Connects	Notes
VPC	One VPC (one attachment per VPC)	Up to 100 Gbps; jumbo frames (8500 MTU)
VPN	Site-to-Site VPN to on-prem	1500 MTU; scale bandwidth with ECMP (needs BGP)
Direct Connect gateway	A dedicated DX line (Transit VIF)	Private, predictable, global via DX Gateway
TGW peering	Another Transit Gateway (cross-Region)	Static routes only; traffic encrypted
Connect	SD-WAN / virtual appliance over GRE + BGP	4 peers, up to 20 Gbps total

It scales far

One TGW takes up to 5,000 attachments (adjustable), so “too many VPCs” is almost never the limit, your route-table design is what needs the thought.

Association vs propagation, the heart of it

This is the part that separates juniors from seniors. Each attachment talks to route tables in two independent ways.

Mechanism	Direction	The question it answers
Association	Attachment → exactly ONE route table	“When traffic LEAVES this attachment, which route table do I read?”
Propagation	Attachment → one or more route tables	“Which route tables LEARN about this attachment’s routes?”

Routes in a TGW table are either propagated (learned automatically from the attachment) or static (you add them). A blackhole route drops traffic to a CIDR on purpose, handy for hard isolation.

Worth pondering

Hold the two apart: association = “which map do I read when I leave?” propagation = “which maps get to know I exist?” Because they’re decoupled, you can let an attachment’s routes be visible in one table while it reads from another, and that single trick is what makes all the segmentation patterns below possible.

Segmentation: who talks to whom

Separate route tables let one TGW enforce isolation. The classic pattern: spokes reach shared services, but not each other.

Spoke route table

associated: Prod-A, Prod-B, Dev

10.50.0.0/16 → Shared-services VPC

0.0.0.0/0 → Egress VPC

(no routes to other spokes)

Shared route table

associated: Shared-services, Egress

10.0.0.0/16 → Prod-A

10.1.0.0/16 → Prod-B

10.2.0.0/16 → Dev

Spokes associate to a table that only knows shared services and egress, so they can use central services and reach the internet, but can’t reach each other. That isolation is exactly what a flat peering mesh can’t give you.

Pattern	How it’s built
Flat	One route table, everything reaches everything (simplest, no isolation)
Segmented (dev/prod)	Separate route tables per environment with no cross-routes
Shared services	Spokes route only to a shared VPC (logging, AD, CI)
Central egress	Spokes send 0.0.0.0/0 to one Egress VPC with NAT, one NAT bill, not many
Inspection	Force east-west traffic through a firewall VPC (with appliance mode)

Appliance mode (for inspection VPCs)

If you route traffic through a stateful appliance, a firewall or IDS, you need one extra setting, or you'll chase ghost packet drops.

Why it exists

By default a TGW may send the two directions of a single flow through different Availability Zones. A stateful appliance only sees half the conversation and drops it. Appliance mode on the inspection VPC attachment pins the whole flow to one AZ, so the firewall sees both directions. Forget it and you get baffling, intermittent failures.

Inter-region peering, going global

A TGW is regional. To build one network across regions, you peer Transit Gateways.

Property	Detail
Scope	Peer TGWs across Regions (and accounts)
Encryption	Traffic is encrypted and stays on the AWS global backbone
Routing	Static routes only across a peering, no dynamic propagation over the peer link
Limits	50 peering attachments per TGW; one peering between any two TGWs

The catch to remember

Across a peering you must add static routes pointing at the peering attachment, routes don’t propagate over it. Inside each Region, propagation still works as normal.

Connect attachments, SD-WAN & virtual routers

Bringing a third-party SD-WAN appliance or virtual router into the TGW with real dynamic routing.

A Connect attachment runs GRE tunnels with BGP on top of an existing VPC or Direct Connect attachment, so a virtual appliance can exchange routes dynamically with the TGW.

Bandwidth via ECMP

Up to 4 Connect peers (GRE tunnels) per Connect attachment, ~5 Gbps each = 20 Gbps, and you scale further with ECMP across peers. (ECMP for VPNs works the same way, but only with dynamic/BGP routing, never static.)

Bandwidth & MTU

The performance ceilings worth knowing, and the jumbo-frame gotcha that bites peering migrations.

Dimension	Value
Per VPC attachment	Up to 100 Gbps each direction · ~7.5M packets/sec (per AZ)
MTU, VPC / DX / Connect / peering	8500 bytes (jumbo frames)
MTU, VPN	1500 bytes
Scaling VPN bandwidth	Aggregate tunnels with ECMP (requires BGP / dynamic routing)
Connect peer	Up to 5 Gbps each; 20 Gbps per Connect attachment

Migration gotcha

VPC peering and TGW handle jumbo frames differently. When migrating peering → TGW, an MTU mismatch can silently drop jumbo packets, cut over both VPCs together.

The cost model

TGW's convenience has a price model you should know cold, it's a frequent surprise on the bill.

Charge	Amount	Note
Per attachment-hour	~$0.05/hr (~$36.50/mo) each	Billed even when idle
Data processing	$0.02 per GB sent to the TGW	On VPC / VPN / DX attachments
Inter-AZ via TGW (same Region)	Free	Recent change, no longer charged

Careful here

Two meters run at once: every attachment bills hourly whether used or not, plus $0.02/GB processed. For just two VPCs that need to talk, plain peering is cheaper (no hourly fee, cheaper data). TGW earns its keep on scale and manageability, not on a couple of VPCs.

Chargeback (2025)

Flexible Cost Allocation lets you attribute TGW data costs to the source account, the destination account, or a central networking account, handy when one team owns the TGW for everyone.

Quotas worth remembering

The numbers that shape real designs (most are adjustable on request).

Quota	Default
Transit gateways per account	5 (adjustable)
Attachments per transit gateway	5,000 (adjustable)
Route tables per transit gateway	20 (adjustable)
Total routes per transit gateway	10,000
Peering attachments per transit gateway	50
Direct Connect gateways per transit gateway	20

Sharing & operating it

In the real world a TGW lives in a central networking account and is shared out, and you need ways to see what it's doing.

Tool	What it gives you
AWS RAM (Resource Access Manager)	Share the TGW to other accounts/OUs so their VPCs can attach, the standard multi-account setup
AWS Network Manager	A global dashboard: topology, events, and health across your TGWs and on-prem
TGW route tables + Reachability Analyzer	Inspect effective routes and trace why a path does or doesn’t work

The climb, from mesh to managed network

Where teams start, and where a mature multi-account network ends up.

Network topologythe climb

Rung 0 · Naive
Full peering mesh
Wire every VPC directly to every other VPC with peering connections.
N×(N−1)/2 links, non-transitive, no isolation, unmanageable past a handful of VPCs.
Better
One flat Transit Gateway
Attach every VPC to a single TGW using the default route table; everything reaches everything.
Linear attachments and transitive routing, far simpler, but still no segmentation.
Best practice today
Segmented, multi-region TGW
Separate route tables for prod/dev, a shared-services + central-egress VPC, appliance-mode inspection, and TGW peering across regions, shared from a networking account via RAM.
Scales to thousands of VPCs and enforces who-talks-to-whom, central security, and egress, the production standard.

How this shows up in interviews

Interview angle

“Design connectivity for 30 VPCs across two regions, with central egress and dev/prod isolation.”

How to answer it

Reject the peering mesh immediately, build on a Transit Gateway per region, and use route tables for isolation. Naming association/propagation and appliance mode marks you as senior.

1A Transit Gateway per region, not a 30-VPC peering mesh (which would be 435 connections and non-transitive).
2Attach every VPC once; use separate TGW route tables so prod and dev associate to tables with no routes to each other.
3A shared-services VPC every spoke can reach, and a central egress VPC with NAT that spokes route 0.0.0.0/0 to, one NAT bill instead of many.
4An inspection VPC with appliance mode for east-west traffic that must be firewalled.
5Peer the two regional TGWs (static routes) for cross-region; own the TGW in a central networking account and share it via RAM.

Green flags

Uses TGW route tables for isolation, not a flat mesh
Knows peering across the TGW peer needs static routes
Mentions central egress + appliance mode unprompted

Red flags

Proposes peering for 30 VPCs
Thinks one route table can isolate environments
Forgets attachments bill hourly

Q.Association vs propagation, in one breath?

A.Association = the one route table an attachment reads; propagation = which tables learn its routes. Decoupling them is what enables segmentation.

Association

Propagation

The ONE table an attachment reads

Which table(s) learn its routes

“Where does its traffic look?”

“Who can find it?”

One per attachment

Can be many, or none

They’re checking: That you keep the two straight, the heart of TGW segmentation.

Q.How does routing work across a TGW peering?

A.Static routes only, dynamic propagation doesn’t cross a peering attachment.

Inside each region, propagation works normally.
Across the peer, you manually add routes pointing at the peering attachment.

They’re checking: That you know propagation stops at the region boundary.

Q.When do you need appliance mode?

A.When a stateful appliance (firewall/IDS) in an inspection VPC must see both directions of a flow.

It pins both directions of a flow to the same AZ.
Without it you get asymmetric routing and dropped flows.

They’re checking: That you connect appliance mode to stateful-inspection symmetry.

Q.TGW vs peering on cost?

A.Peering: no hourly fee, best for a few VPCs. TGW: per-attachment + per-GB, but scales and adds segmentation.

Peering

Transit Gateway

No hourly fee

~$0.05/hr per attachment

Cheaper data

+ $0.02/GB processed

Best for: a couple of VPCs

Best for: many networks + segmentation

They’re checking: That you pick by VPC count and need, not reflex.

Your turn, stand up a Transit Gateway

Attach two VPCs to a TGW and route between them. NOTE: unlike peering, a TGW bills hourly, do this in one sitting and tear it down.

Now do it in your own account

~25 min Not free, TGW bills ~$0.05/hr per attachment. Tear down today.

Attach two VPCs to a TGW and route between them. Unlike peering, a TGW bills hourly, do this in one sitting and tear it down.

Before you start

3 to have ready

Your IAM admin user from Lesson 1.

AWS CLI v2 signed in.

aws sts get-caller-identity

Two VPCs with non-overlapping CIDRs (e.g. 10.0.0.0/16 and 10.1.0.0/16).

1
Create the Transit Gateway (default association + propagation are on).
Costs money
Your terminal
aws cli
```
$ aws ec2 create-transit-gateway --description "learn-tgw"
```
AWS docs: create-transit-gateway
You should see: a TransitGatewayId; it reaches available after a minute or two.
Billing starts now. Run the teardown today.
2
Attach each VPC (a subnet per AZ for the attachment ENIs).
Costs money
Your terminal
aws cli
```
$ aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id <tgw-id> --vpc-id <vpc-id> --subnet-ids <subnet-id>
```
AWS docs: create-transit-gateway-vpc-attachment
You should see: one attachment per VPC, each reaching available.
3
In EACH VPC’s route table, send the other VPC’s CIDR to the TGW.
Free tier
Your terminal
aws cli
```
$ aws ec2 create-route --route-table-id <rtb-id> --destination-cidr-block 10.1.0.0/16 --transit-gateway-id <tgw-id>
```
AWS docs: create-route
You should see: each VPC’s RT sends the other’s CIDR → tgw-….
4
Launch a tiny instance in each VPC and ping across.
Costs money
Your terminal / Console
You should see: the ping succeeds, traffic flowing through the TGW hub.
Free-tier instances, but terminate them in the teardown.

Last step: tear it down

Once you’ve seen it work, remove everything so nothing keeps billing.

A TGW is NOT free: each attachment bills ~$0.05/hour. Delete it the same day you build it.

Tear down in order: terminate test instances, delete the VPC route entries, delete the VPC attachments.

Delete the Transit Gateway last.

aws ec2 delete-transit-gateway --transit-gateway-id <tgw-id>

Confirm no attachments remain before you walk away, a forgotten TGW quietly bills every hour.

Next up

Back to the track, or go deeper

Transit Gateway sits inside the Connecting VPCs lesson. From here, the natural next deep dives are PrivateLink endpoint services and AWS Network Firewall in an inspection VPC.