AWS Transit Gateway Route Tables Explained
Published on · Updated on
Rebuilt the guide around attachment association vs. propagation, routing in both directions, segmentation, route priority, blackholes, peering, and practical troubleshooting.
A Transit Gateway (TGW) route table selects the next attachment for packets that enter a transit gateway. It works alongside VPC subnet route tables; it does not replace them. A working connection needs a forward route at every routing layer and a return path.
This guide explains how association and propagation differ, how to segment traffic, and how to trace a packet through both VPC and transit gateway routes. For current service quotas and per-AZ capacity, see Transit Gateway scalability and limits.
How Transit Gateway Routing Works
Routing crosses three tables or decisions. A packet first follows its source subnet's VPC route table to the transit gateway. The table associated with the packet's ingress attachment then chooses a destination attachment. The destination VPC's routes deliver the packet to the workload. Replies repeat the process in reverse.
| Layer | What it decides | Example entry |
|---|---|---|
| Source VPC subnet route table | Whether the destination should be sent to the TGW | 10.20.0.0/16 → tgw-… |
| TGW route table | Which attachment receives the packet next | 10.20.0.0/16 → VPC B attachment |
| Destination VPC route tables | How traffic reaches the target subnet and returns to remote networks | Remote CIDR → the TGW where required |
Association selects the table used by an attachment
An attachment can be associated with at most one TGW route table, and it can be disassociated. When a packet arrives from an associated attachment, the association determines which table is consulted; without an association, there is no TGW route table for that attachment's traffic to use. A route table can be associated with many attachments. A transit gateway can use a default association table, but separate tables let you define different routing policies for different ingress attachments.
Do not treat an association as a route import. It selects the table used for traffic arriving from an attachment; it does not install that attachment's destinations in the table.
Default association is separate from a default route
When default route-table association or default propagation is enabled, AWS creates a default TGW route table and uses it for the enabled default behavior. If both options are disabled, AWS does not create that default table. The default association setting decides which table a new attachment uses; the default propagation setting decides where its routes are installed. Neither setting creates a destination route such as 0.0.0.0/0. A packet with no matching route is dropped unless you add an applicable route. AWS describes these defaults in its Transit Gateway routing guide.
Propagation installs destinations into a table
Propagation adds routes learned from an attachment to a selected TGW route table. An attachment can propagate to more than one table, even though it can be associated with only one. A VPC attachment propagates the VPC's CIDR blocks. It does not copy arbitrary entries from the VPC's subnet route tables, and AWS does not let you filter the routes advertised by an attachment during propagation.
For a VPN or Direct Connect gateway using dynamic routing, propagated routes can include prefixes learned through BGP. Use a static TGW route when you need to define a destination explicitly, such as routing a remote prefix to a peering attachment. AWS documents the association, propagation, and route evaluation model.
VPC route tables still need the TGW next hop
Propagation in the TGW does not make a VPC send traffic to it. Add routes for the required remote CIDRs to the route tables used by the source workloads, with the transit gateway as the target. Check the destination VPC's relevant subnet routes as well. Where return traffic to the source network must leave the VPC through the TGW, its route table needs a matching remote-prefix route to the TGW.
A VPC attachment also uses one selected subnet in each enabled Availability Zone as an entry and exit point. A resource in an AZ without an attachment subnet there cannot reach the transit gateway through that AZ. The attachment-subnet route tables and target-subnet route tables must support the intended paths; see AWS's VPC attachment routing requirements.
Designing Associations, Propagation, and Segmentation
Design the route tables around which attachments may send traffic to which destinations. Association answers “which policy table does this source use?” Propagation answers “which destinations are installed in that table?” Keeping those decisions separate makes segmentation easier to review.
For example, an organization can use three tables: a prod table associated with the production attachment and propagated with shared-services routes; a dev table associated with the development attachment and also propagated with shared-services routes; and a shared table associated with the shared-services attachment and propagated with both production and development routes. Production and development can reach shared services, while neither table contains a route to the other environment. The shared VPC must also have VPC routes for both environments so replies return through the TGW.
This controls reachability through the transit gateway; it does not replace security groups, network ACLs, or application authorization. Review both directions whenever you change an association or propagation.
Choose route sources and priorities deliberately
The transit gateway uses longest-prefix match first: a route for 10.20.4.0/24 wins over a broader 10.20.0.0/16 route for destinations inside that /24. For identical prefixes from different route sources, AWS's documented priority is static routes, prefix-list references, VPC-propagated routes, Direct Connect gateway-propagated routes, Connect-propagated routes, Site-to-Site VPN over private Direct Connect, Site-to-Site VPN, VPN Concentrator, Client VPN, then Cloud WAN peering-propagated routes. Standard Transit Gateway peering uses static routes. For BGP routes of the same prefix and attachment type, AWS prefers a shorter AS path, then a lower MED, and then eBGP over iBGP where supported. It does not guarantee a consistent order when those attributes are also equal.
A blackhole route deliberately drops packets that match it. Because it is a static route, it takes priority over a propagated route with the same destination. Longest-prefix match still comes first, so a more-specific route can win over a broader blackhole. Check the exact prefix and selected target before removing a blackhole or changing propagation. See AWS's detailed Transit Gateway route evaluation order.
Overlapping CIDRs and transit gateway peering
A transit gateway does not route between VPCs with identical or overlapping CIDRs. If a newly attached VPC overlaps an existing attachment, its routes are not propagated to the TGW route table. Plan non-overlapping address ranges before connecting VPCs; a route-table change alone cannot resolve an address collision. See AWS's VPC attachment limitations.
Transit Gateway peering uses static routes. On each transit gateway, add a route for the remote prefixes to that side's peering attachment, including prefixes needed for the return path. Peering does not automatically propagate remote VPC prefixes between the two transit gateways; AWS documents this in its peering route guidance. For hybrid attachment choices, see AWS Direct Connect vs. Site-to-Site VPN.
A Practical Configuration and Verification Sequence
- Inventory the paths. Record each attachment, its CIDRs, the traffic it should receive, and the return destinations. Resolve overlapping VPC CIDRs before relying on propagation.
- Create tables for routing policy. Use a default table only when its shared policy is intended. Name and document tables by the traffic policy they implement.
- Associate ingress attachments. Give each attachment the one route table that should evaluate packets entering from it.
- Install only the needed destinations. Enable propagation from the attachments whose prefixes belong in each table, or add explicit static routes where needed. A VPC attachment contributes its VPC CIDRs, not selected subnet-table entries.
- Configure VPC routes. Point source workload routes for remote CIDRs at the TGW. Verify destination and return routes, including the selected attachment subnets in each AZ used by the traffic.
- Test forward and return paths. Review the route entry that matches each destination and then run a real connection test with security controls in place.
AWS Network Manager's Route Analyzer can inspect a TGW route-table path and its return path when the transit gateways are registered in a global network. It does not inspect VPC route tables, customer gateway routes, security groups, or network ACLs, so use it as one part of the check.
Troubleshooting a Failed Path
| Symptom | Check |
|---|---|
| No route or an unexpected TGW attachment | Inspect the route table associated with the source attachment. Check exact and more-specific prefixes, propagation state, static routes, and blackholes. |
| Traffic reaches the TGW but not the destination | Confirm the destination CIDR is routed to the correct attachment and that the VPC attachment is available. Check the destination attachment subnet's AZ and the VPC routes to the workload. |
| One-way traffic | Trace the reply as a new packet: the destination VPC needs a route to the source, and the TGW table associated with the destination attachment needs a route back to the source attachment. |
| VPC route does not appear in the TGW table | Confirm propagation is enabled for the intended table. Check for identical or overlapping CIDRs; arbitrary VPC subnet routes are not propagated. |
| Path changes unexpectedly | Compare the matching prefix lengths and same-prefix route types. A static route can shadow a propagated route, and BGP attributes can change which equal-prefix route is active. |
For live packet evidence, correlate the test time with VPC Flow Logs and the transit gateway's CloudWatch drop metrics. A route-table result shows configuration-level reachability; it does not prove that security rules or the application accept the connection.
Frequently Asked Questions
Can one transit gateway have multiple route tables?
Yes. Additional route tables can isolate attachment groups. Each attachment can be associated with at most one table, while its routes can be propagated to multiple tables. If it has no association, traffic from that attachment has no associated TGW table to use.
Do VPC subnet route-table entries propagate to the TGW?
No. A VPC attachment propagates its VPC CIDR blocks. Routes in VPC subnet tables decide whether packets use the TGW; they are not copied into the TGW route table.
Does Transit Gateway peering propagate routes?
No. Configure static routes to the peering attachment for the required remote prefixes on both transit gateways, including the return path.