Transit Gateway

By the end of this lesson you will be able to

• Explain why a mesh of VPC peerings stops scaling (n(n−1)/2 connections, per-VPC quotas, mixed VPN and Direct Connect “spaghetti”) and how a transit gateway turns it into a regional hub and spoke with transitive routing.
• Name the attachment types (VPC, Site-to-Site VPN, Direct Connect gateway, Connect, peering, and the newer VPN Concentrator and Network Firewall attachments) and what each is for.
• Design transit gateway route tables with associations, propagations, static and blackhole routes, so dev cannot reach prod while both reach shared services, and debug the two route tables every packet passes in each direction.
• Peer transit gateways across Regions and share one with other accounts through AWS RAM.
• Aggregate Site-to-Site VPN bandwidth with ECMP (and say why a virtual private gateway cannot), and calculate the result per connection, per tunnel and per flow.
• Share one Direct Connect line with hundreds of VPCs in many accounts: transit VIF → Direct Connect gateway → transit gateway → RAM.
• Know the details exams and incidents ask about: multicast, Connect for SD-WAN, MTU 8500 vs 1500, appliance mode, pricing, quotas, and when Cloud WAN, VPC sharing, PrivateLink or VPC Lattice fits better.

#Why a hub: when peering stops scaling

Lesson 22.1 showed that VPC peering is a private, cheap, point-to-point link between two VPCs, and that it is not transitive: if A is peered with B and B with C, A still cannot reach C. That is fine for three VPCs. It breaks down as a company grows:

• The mesh explodes. For every VPC to reach every other one, n VPCs need n(n−1)/2 peerings: 10 VPCs need 45, 100 VPCs need 4,950. Each one has to be requested, accepted, and given routes on both sides.
• Quotas end it anyway. A VPC can have at most 125 active peerings (50 by default), so a full mesh of more than 126 VPCs is impossible.
• Hybrid links multiply too. A virtual private gateway attaches to one VPC (lesson 22.4), and peering has no edge-to-edge routing, so a VPC cannot use its peer’s VPN or Direct Connect. Each VPC that needs the data centre needs its own VPN connection or its own virtual interface. The slides draw exactly this picture: VPN connections, peerings and a Direct Connect gateway crossing each other until nobody can tell which path a packet takes.

AWS Transit Gateway replaces the mesh with a star. Each VPC, VPN and Direct Connect gateway connects once, to a regional hub, and the hub routes between them. Routing through the hub is transitive: anything attached can reach anything else attached, as far as the hub’s route tables allow.

#What a transit gateway is

A transit gateway is a regional virtual router that AWS runs for you. It works at layer 3: for every packet it looks up the destination IP address in a transit gateway route table and sends the packet to the matching attachment. It scales with traffic by itself, it is highly available inside its Region, and it routes both IPv4 and IPv6.

• Regional. One transit gateway lives in one Region. To connect Regions, you peer transit gateways (below).
• Cross-account. One account (usually a central network account) owns it and shares it through AWS RAM; other accounts attach their VPCs.
• Big. 5,000 attachments per transit gateway by default, up to 100 Gbps per VPC attachment per AZ.

#What can attach

The first five are the classic list and the ones the exam asks about. The last two are recent additions worth recognising.

#A VPC attachment, step by step

1. Pick one subnet per AZ. The transit gateway puts a network interface (with one private IP) in that subnet. Once an AZ is enabled, every subnet in that AZ can use the attachment; resources in an AZ that you did not enable cannot reach the transit gateway. AWS recommends a small dedicated subnet (a /28) per AZ for attachments, with its own route table and an open network ACL, so the attachment’s path is not affected by application subnet rules.
2. Associate and propagate the attachment in the transit gateway route tables (next section). With the defaults, both happen automatically in the default route table.
3. Add routes in the VPC’s subnet route tables. Attaching a VPC does not change its route tables. Every subnet that should use the hub needs a route such as 10.0.0.0/8 → tgw-…. This is the most common reason a fresh attachment “does not work”.

So every packet between two VPCs passes four route lookups: the source subnet’s route table, the transit gateway route table the source attachment is associated with, and on the way back, the destination subnet’s route table and the transit gateway route table that its attachment is associated with. A missing route in any of them gives a timeout, which looks exactly like a firewall problem.

#Transit gateway route tables

A transit gateway can have several route tables (20 by default). Each one is a separate routing domain, and two settings connect attachments to them.

#Association and propagation

• Association: every attachment is associated with exactly one route table. When a packet arrives on that attachment, the transit gateway looks up its destination in that table. Association answers “where do I look”.
• Propagation: an attachment can propagate its routes into one or more route tables. A VPC attachment propagates its CIDRs; a VPN or Direct Connect gateway attachment with BGP propagates the prefixes your routers advertise. Propagation answers “who can find me”.

A route table can be associated with many attachments, and can receive propagations from many. When you create a transit gateway with the defaults (default route table association and default route table propagation both on), every new attachment is associated with, and propagates into, the default route table: a flat network where everything reaches everything.

#Static, propagated and blackhole routes

• Propagated routes come and go with the attachment (and with BGP).
• Static routes are ones you add, for example a summary 0.0.0.0/0 → egress VPC attachment, or any route to a peering attachment (peering never propagates).
• A blackhole route is a static route that drops matching traffic. Use it to make sure a prefix can never be reached from a table, even if someone later adds a propagation, or to cut off a compromised VPC in seconds.

When several routes match, the transit gateway uses the most specific prefix first. For the same prefix, a static route beats a propagated one (so a blackhole wins), and among propagated routes AWS prefers, in order: VPC, then Direct Connect gateway, then Connect, then Site-to-Site VPN. Between BGP routes of the same type, a shorter AS path wins. This is why, with the same prefix learned over both Direct Connect and VPN, the transit gateway sends traffic over Direct Connect and keeps the VPN as backup (lesson 22.5).

#Segmentation: dev, prod and shared services

Turning the defaults off and creating one route table per security zone gives you segmentation in the network itself, controlled by the network account, not by each application team.

Now build it yourself. Start from the flat design, check every pair, then make dev isolated without breaking anyone’s replies.

#Across Regions and across accounts

#Transit gateway peering

A transit gateway is regional, so a company in Mumbai and Singapore runs one transit gateway per Region and joins them with a peering attachment:

• One side requests the peering (it can be another account and another Region), the other side accepts it.
• Peering attachments support static routes only: no propagation, no BGP. Add a static route for the other side’s CIDRs in each side’s route table.
• Inter-Region traffic stays on the AWS backbone, is encrypted, and has no single point of failure. You pay inter-Region data transfer plus the sending transit gateway’s data processing; the receiving side charges no processing.
• Peering is transitive through the hubs: a VPN on the Mumbai transit gateway can reach a VPC attached in Singapore, if both route tables have the routes. Compare VPC peering, where a VPC can never use its peer’s VPN.
• Two transit gateways can have one peering between them. Peering also works within one Region (since 2021), for example to join two business units’ hubs, and a transit gateway can peer with a Cloud WAN core network.
• Give each transit gateway its own Amazon-side ASN; it makes routing easier to read and is needed in some designs.

#Sharing a transit gateway with AWS RAM

The usual multi-account design has one network account that owns the transit gateway, its route tables, the VPN and Direct Connect attachments. It shares the transit gateway with other accounts through AWS Resource Access Manager (lesson 20.1):

1. The network account creates a resource share with the transit gateway and adds the organization, an OU or specific accounts. Inside an organization (with sharing enabled), no invitation is needed; an account outside it must accept an invitation.
2. Each application account creates a VPC attachment to the shared transit gateway from its own VPC.
3. The network account accepts the attachment (or turns on auto accept shared attachments) and decides which route table it is associated with and propagates into.

Application accounts cannot see or change the transit gateway’s route tables: segmentation stays with the network team. The VPC owner pays the attachment-hours and the data processing of the traffic its VPC sends.

#Site-to-Site VPN on a transit gateway: ECMP

ECMP (equal-cost multi-path) routing means: when a router has several equally good paths to the same destination, it uses all of them at once and spreads flows across them. It gives two things: more total bandwidth, and fast failover, because a failed path is simply removed from the set.

• A virtual private gateway does not support ECMP. Its VPN connection has two tunnels, but AWS sends traffic over one of them; the other is a standby (active/passive). Adding more VPN connections to the same VGW adds more standby paths, not bandwidth. A single standard tunnel carries up to 1.25 Gbps, so that is the ceiling.
• A transit gateway supports ECMP for VPN attachments. With VPN ECMP support enabled on the transit gateway (the default), dynamic routing (BGP) on the VPN connections, and the same prefixes advertised with the same AS path on every tunnel, the transit gateway uses all tunnels at once (active/active). Your own router must also do ECMP for traffic going towards AWS.
• Bandwidth adds up per tunnel. One VPN connection on a transit gateway uses both its tunnels: 2 × 1.25 = 2.5 Gbps. Two connections = 4 tunnels = 5 Gbps; three connections = 7.5 Gbps. Compare the VGW: 1.25 Gbps, however many connections.
• Per flow, the cap stays. ECMP spreads flows (same source and destination address, ports and protocol), not packets. A single TCP connection always uses one tunnel and never goes faster than about 1.25 Gbps. Use parallel streams to fill the pipes.
• Static routing means no ECMP. ECMP on a transit gateway needs BGP.

#Sharing one Direct Connect line across many accounts

A Direct Connect line is expensive and takes weeks to deliver (lesson 22.5). An organization with hundreds of accounts cannot buy one per account, and private virtual interfaces do not scale either: each reaches one VGW (or a Direct Connect gateway associated with VGWs), and a connection carries a limited number of them. The pattern that scales:

1. Transit virtual interface

   On the Direct Connect connection, create a transit VIF: its own VLAN and BGP session. A private VIF cannot reach a transit gateway; only a transit VIF can.

2. Direct Connect gateway

   Attach the transit VIF to a Direct Connect gateway, a global object.

3. Associate it with the transit gateway

   Associate the Direct Connect gateway with the transit gateway in the network account, and list the allowed prefixes: the transit gateway does not advertise its VPC CIDRs to your network by itself, only the prefixes in this list (a summary such as 10.0.0.0/8 is common). One Direct Connect gateway can be associated with up to 6 transit gateways, for example one per Region.

4. Share the transit gateway with RAM

   Share the transit gateway with the organization through AWS RAM. Every account attaches its VPCs, and every attached VPC reaches the data centre over the same line.

#Transit Gateway Connect for SD-WAN appliances

Many companies join their branches with an SD-WAN product (a virtual router appliance that picks the best link for each application). To connect such appliances running in a VPC (or on-premises over Direct Connect) to the transit gateway, use a Connect attachment:

• It rides on top of an existing VPC or Direct Connect attachment (the “transport”).
• The appliance and the transit gateway build GRE tunnels (“Connect peers”) and run BGP over them, so routes are exchanged dynamically and ECMP works across peers.
• Each Connect peer carries up to 5 Gbps; up to 4 peers per Connect attachment give up to 20 Gbps. No IPsec, so no per-tunnel encryption overhead, and no extra data processing charge beyond the transport attachment.

Before Connect, the same thing needed IPsec VPNs from each appliance, with 1.25 Gbps tunnels and static or complex BGP setups.

#IP multicast

Multicast sends one packet to a group address, and the network copies it to every receiver that joined the group; the sender does not need to know who is listening. Plain VPC routing does not support multicast (or broadcast). A transit gateway can:

• Enable multicast support when you create the transit gateway, then create a multicast domain and associate the VPC subnets that take part.
• Register group members and sources statically (API) or let instances join with IGMPv2.
• Limits worth knowing: about 1 Gbps per flow and 20 Gbps per AZ; AWS warns it is not meant for high-frequency trading.

#Details that matter in production

#MTU

A transit gateway supports an MTU of 8500 bytes for traffic between VPC, Direct Connect, Connect and peering attachments, but only 1500 bytes over VPN attachments (and the IPsec tunnel itself leaves room for 1446, lesson 22.4). Inside a VPC, instances can use 9001-byte jumbo frames; packets larger than the transit gateway path allows are dropped. The transit gateway clamps TCP MSS and sends “fragmentation needed” messages for traffic entering from VPC and Connect attachments (path MTU discovery), but not for VPN, Direct Connect or peering. When you migrate from VPC peering (which supports 9001 inside a Region) to a transit gateway, move both VPCs at the same time so jumbo frames do not meet an 8500 limit in one direction only.

#Appliance mode and centralised inspection

A common design sends all traffic between VPCs, or to the internet, through an inspection VPC with firewalls (AWS Network Firewall, lesson 22.7, or third-party appliances behind a Gateway Load Balancer, lesson 6.3). Stateful firewalls must see both directions of a flow. By default the transit gateway may send the request through the appliance in one AZ and the reply through another AZ, and the second firewall, which never saw the request, drops the reply. Turning on appliance mode on the inspection VPC attachment makes the transit gateway keep both directions of a flow in the same AZ for its lifetime. Since 2025 you can also attach AWS Network Firewall directly to the transit gateway as a network function attachment, which builds the inspection VPC for you with appliance mode already on.

#DNS, flow logs and monitoring

• DNS support (on by default) lets a public DNS hostname of an instance in one attached VPC resolve to its private IP when queried from another attached VPC.
• Transit Gateway Flow Logs record traffic per attachment, the same idea as VPC Flow Logs (lesson 22.3), with transit gateway fields such as the attachment IDs.
• Network Manager draws the global network of transit gateways, VPNs and sites, and Reachability Analyzer can trace a path through a transit gateway without sending packets.

#What it costs

Transit Gateway charges two things (us-east-1 and most Regions; check the pricing page for yours):

• Per attachment-hour: about $0.05 per attachment per hour (VPC, VPN, Direct Connect gateway, Connect, peering), billed to the attachment’s owner (the VPC owner for VPC attachments). A 730-hour month is about $36.50 per attachment.
• Per GB processed: about $0.02 per GB sent into the transit gateway from a VPC, VPN or Direct Connect attachment. Data arriving from a peering attachment is not charged again, and Connect adds no extra processing. Normal data transfer charges (inter-Region, internet egress) apply on top, and VPN connection-hours are separate. Crossing AZs inside the transit gateway costs nothing extra: AWS stopped charging inter-AZ data transfer through Transit Gateway in April 2022.

Example for the conglomerate: 120 VPC attachments + 1 Direct Connect gateway attachment + 2 VPN attachments = 123 × 730 × $0.05 ≈ $4,490 a month, plus 50 TB a month between VPCs = 51,200 GB × $0.02 = $1,024.

Peering vs Transit Gateway on cost. Peering has no hourly fee and no processing fee: you pay only data transfer (same-AZ traffic over a peering is free; cross-AZ and cross-Region is charged, lesson 22.1). For two VPCs that exchange 100 TB a month, the transit gateway adds about 102,400 × $0.02 = $2,048 a month that peering would not. The usual answer is both: the hub for everything, plus a direct peering for one very chatty pair (its more specific route wins in the subnet route tables). Lesson 22.8 puts all network prices side by side.

#Quotas worth knowing

#Transit Gateway, peering or something else?

#What goes wrong

• The attachment is available but nothing works: the VPC subnet route tables have no route to the transit gateway. Attaching changes the transit gateway, not your VPC.
• One-way traffic, timeouts: the reply’s route is missing, either in the destination subnet’s route table or in the transit gateway route table the destination attachment is associated with.
• Instances in one AZ cannot reach the hub: that AZ was not enabled on the VPC attachment (no subnet chosen there).
• Dev reaches prod: the transit gateway kept default association and propagation, so everything is in one flat route table; or an old peering with a more specific route bypasses the hub.
• Peering attachment up, no traffic: nobody added the static routes; peering attachments never propagate.
• VPN bandwidth stuck at 1.25 Gbps on a transit gateway: static routing (no ECMP), different AS paths on the tunnels, ECMP disabled on the transit gateway, the on-premises router not doing ECMP, or one big flow.
• On-premises cannot reach a new VPC over Direct Connect: its CIDR is not in the Direct Connect gateway association’s allowed prefixes, so your routers never learn it; or a private VIF was created where a transit VIF is needed.
• Large file copies hang, small requests work: MTU. A VPN path allows 1500 bytes; jumbo frames from a VPC-to-VPC path are dropped somewhere that does not send “fragmentation needed”.
• The firewall drops replies: stateful inspection VPC without appliance mode, so the two directions of a flow cross different AZs.
• A new VPC attaches but nothing reaches it: its CIDR overlaps one already attached. The attachment itself succeeds, but the transit gateway does not propagate the overlapping route into its route table. A transit gateway, like peering, routes by destination address, so ranges must be unique (plan with IPAM; for an unavoidable overlap use PrivateLink or a private NAT gateway, lesson 3.4).
• A surprise bill: a few VPCs exchanging tens of terabytes through the hub; give that pair a direct peering.

#Transit Gateway in system design

• Hub and spoke landing zone: a network account owns one transit gateway per Region, shared through RAM; route tables for production, non-production, shared services and on-premises; blackholes as guard rails.
• Centralised egress: spoke VPCs have no NAT gateways; a 0.0.0.0/0 static route in the transit gateway sends internet traffic to an egress VPC with NAT gateways (and a firewall). Fewer NAT gateways and one place to log, at the price of $0.02 per GB through the hub.
• Centralised inspection: east-west and north-south traffic through an inspection VPC (appliance mode) or a Network Firewall attachment.
• Shared services and endpoints: DNS resolvers, Active Directory, package mirrors and interface endpoints in one VPC that every spoke reaches (lesson 10.10 showed this for S3).
• Hybrid hub: Direct Connect through a transit VIF as the main path, Site-to-Site VPN with ECMP as backup, both attached to the same transit gateway; branches through SD-WAN with Connect.
• Multi-Region: one transit gateway per Region, peered, or Cloud WAN when the number of Regions and sites grows. For disaster recovery across Regions see chapter 23 (RPO and RTO strategies); blocking bad addresses across such a network is part of lesson 24.3.

#Try it yourself

# 1. Create a transit gateway with segmentation in mind: no default association/propagation
aws ec2 create-transit-gateway --description "core-hub-ap-south-1" \
  --options AmazonSideAsn=64512,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable,VpnEcmpSupport=enable,DnsSupport=enable,AutoAcceptSharedAttachments=enable
# {"TransitGateway": {"TransitGatewayId": "tgw-0a1b2c3d4e5f67890", "State": "pending", ...}}

# 2. Attach a VPC with one small subnet per AZ
aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0a1b2c3d4e5f67890 \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example subnet-0ccc3333example
# {"TransitGatewayVpcAttachment": {"TransitGatewayAttachmentId": "tgw-attach-0dev1234example", "State": "pending", ...}}

# 3. Route tables: create, associate, propagate
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-0a1b2c3d4e5f67890 \
  --tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=rt-dev}]'
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --transit-gateway-attachment-id tgw-attach-0dev1234example
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --transit-gateway-attachment-id tgw-attach-0shared9example

# 4. Guard rail: blackhole prod in the dev table
aws ec2 create-transit-gateway-route --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --destination-cidr-block 10.20.0.0/16 --blackhole

# 5. What does the dev table contain?
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --filters Name=type,Values=static,propagated \
  --query "Routes[].[DestinationCidrBlock,Type,State]" --output table
# |  10.20.0.0/16 |  static     |  blackhole |
# |  10.30.0.0/16 |  propagated |  active    |

# 6. Do not forget the VPC side
aws ec2 create-route --route-table-id rtb-0dev1111example \
  --destination-cidr-block 10.0.0.0/8 --transit-gateway-id tgw-0a1b2c3d4e5f67890

# 7. Share it with the whole organization
aws ram create-resource-share --name core-hub \
  --resource-arns arn:aws:ec2:ap-south-1:111122223333:transit-gateway/tgw-0a1b2c3d4e5f67890 \
  --principals arn:aws:organizations::111122223333:organization/o-exampleorgid

# 8. Two VPN connections with BGP for ECMP (dynamic routing is the default)
aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id cgw-0router1example \
  --transit-gateway-id tgw-0a1b2c3d4e5f67890
aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id cgw-0router2example \
  --transit-gateway-id tgw-0a1b2c3d4e5f67890

# 9. Peer with the Singapore transit gateway, accept there, then add static routes on both sides
aws ec2 create-transit-gateway-peering-attachment --transit-gateway-id tgw-0a1b2c3d4e5f67890 \
  --peer-transit-gateway-id tgw-0f9e8d7c6b5a43210 --peer-account-id 111122223333 \
  --peer-region ap-southeast-1
aws ec2 accept-transit-gateway-peering-attachment --region ap-southeast-1 \
  --transit-gateway-attachment-id tgw-attach-0peer777example
aws ec2 create-transit-gateway-route --transit-gateway-route-table-id tgw-rtb-0prod999example \
  --destination-cidr-block 10.70.0.0/16 --transit-gateway-attachment-id tgw-attach-0peer777example

# 10. Direct Connect: associate the Direct Connect gateway and say what to advertise
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id 5f8e2c1a-1234-4bcd-9abc-0123456789ab \
  --gateway-id tgw-0a1b2c3d4e5f67890 \
  --add-allowed-prefixes-to-direct-connect-gateway cidr=10.0.0.0/8

From an instance in the dev VPC, traceroute 10.30.4.10 should reach shared services, and ping 10.20.8.5 (prod) should time out with no reply at all: the blackhole drops it silently.

#Summary

Key takeaways

• A peering mesh needs n(n−1)/2 connections (100 VPCs → 4,950) and hits 125 peerings per VPC; a transit gateway is a regional hub with one attachment per network and transitive routing.
• Attachments: VPC (one subnet per AZ), Site-to-Site VPN, Direct Connect gateway (transit VIF), Connect (GRE + BGP for SD-WAN), peering (static routes only), plus VPN Concentrator and Network Firewall attachments.
• Each packet passes two route tables each way: the VPC subnet route table (you must add a route to tgw-…) and the transit gateway route table its attachment is associated with.
• Association (one per attachment) = where the lookup happens; propagation (many) = who appears in a table. Static beats propagated; blackhole drops. Turn off the defaults to segment dev, prod and shared services.
• Peer transit gateways across Regions (encrypted backbone, static routes); share with AWS RAM from a network account.
• ECMP on a transit gateway (BGP, VPN ECMP support) uses every tunnel: 1 connection = 2.5 Gbps, 2 = 5 Gbps; a VGW never does ECMP; one flow is capped at one tunnel (1.25 Gbps, or 5 Gbps with the 2025 large tunnels).
• One Direct Connect for many accounts: transit VIF → Direct Connect gateway (allowed prefixes, up to 6 transit gateways) → transit gateway → RAM.
• Multicast between VPCs → Transit Gateway multicast (IGMPv2 or static members).
• MTU 8500 (VPC, Direct Connect, Connect, peering) vs 1500 (VPN); appliance mode for stateful inspection VPCs.
• Cost ≈ $0.05 per attachment-hour + $0.02 per GB processed; peering has neither, so keep peering for a very chatty pair. Cloud WAN for global policy-driven networks, PrivateLink for one service or overlapping CIDRs, VPC sharing to avoid connecting at all.

Self-check: Transit Gateway31 questions