AWS Transit Gateway: route tables, segmentation and blackhole routes

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A transit gateway forwards a packet using the one route table associated with the attachment the packet came in on. Association therefore decides where an attachment can send, and propagation decides which route tables learn how to reach it. A segment is the result of those two settings, not a separate object.

A packet can be dropped because no route matches it or because it matches a blackhole route. AWS counts those separately, so find out which one you have before changing any routes.

Commands below come from the AWS CLI reference, except where marked as written for this article. None were run in a lab.

Why it matters

The defaults build a flat network. A new attachment is associated with and propagated to the default route table when those options are on, so every attachment can reach every other attachment.

That matters when development, production and on-premises networks share a gateway. A single wrong association can open a path between segments, or remove one that an application depends on.

It also matters for fault finding. Three separate configurations have to agree for a two-way conversation: the subnet route tables at each end, the transit gateway route table on each direction, and the routes inside the attachment subnets.

How the forwarding decision works

Association and propagation

A useful way to remember it, as an editorial shorthand: association answers "where can this attachment send?", and propagation answers "who can send to this attachment?".

What propagates depends on the attachment type:

• A VPC attachment propagates the VPC's CIDR blocks.
• A dynamic VPN, VPN Concentrator or Direct Connect gateway attachment propagates routes learned through BGP.
• A peering attachment supports static routes only, and the accepter side needs its own static route.

You cannot filter advertised routes on propagation. If a segment must not learn a route, do not propagate that attachment to the segment's table.

Association also shapes what on-premises networks learn. With dynamic routing, routes in the table associated with the VPN attachment are advertised to the customer gateway. Moving a VPN attachment to another table therefore changes the prefixes your router receives. Direct Connect gateway attachments are different: allowed prefixes control what is advertised.

Route evaluation order

AWS evaluates routes by the most specific destination first. For the same CIDR from different attachment types, the order is:

1. Static routes
2. System routes installed for 1:1 NAT
3. Prefix list referenced routes
4. VPC-propagated routes
5. Direct Connect gateway-propagated routes
6. Transit Gateway Connect-propagated routes
7. Site-to-Site VPN over private Direct Connect-propagated routes
8. Site-to-Site VPN-propagated routes
9. VPN Concentrator-propagated routes
10. Client VPN-propagated routes
11. Transit gateway peering-propagated routes (Cloud WAN)

For the same CIDR from the same attachment type, shorter AS path wins, then lower MED, then eBGP over iBGP where supported. AWS cannot guarantee a consistent order when all of those are equal.

Two behaviours catch people during a fault:

• When a static and a propagated route share a destination, the propagated route is not included in the table. It returns when the static route is removed.
• The table shows only the preferred route. A VPN backup behind Direct Connect stays invisible until the preferred route stops being advertised.

So a backup path you cannot see is not evidence that the backup is missing.

The VPC side

The transit gateway is only part of the path. The VPC needs three things:

• A route in the source subnet's route table pointing at the transit gateway.
• An attachment subnet in the same Availability Zone. Resources in a zone with no attachment cannot reach the transit gateway, even with a correct route.
• Routes in the attachment subnet's route table to destinations in the VPC that must be reached through the transit gateway, which AWS says includes other subnets, internet gateways, NAT gateways and VPC endpoints.

If a VPC's CIDR is identical to or overlaps an already attached VPC, the new VPC's routes are not propagated. The attachment can exist with no route to show for it.

Segmentation patterns

These are the patterns AWS documents. The association and propagation columns are the whole design.

In the isolated patterns no VPC propagates to the table its peers are associated with. A packet from one isolated VPC to another reaches the gateway and is blocked because no route matches.

AWS compares extra route tables to virtual routing and forwarding on traditional networks. It also advises you to limit the number of route tables unless the design needs more.

Moving an existing network off the default table

Turning off the default options does not fix existing attachments. Changes made with modify-transit-gateway apply to new attachments only. You must move each existing attachment yourself.

aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-0123456789abcdef0

Build the new table and check it before moving anything:

aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-0aaaaaaaaaaaaaaaa \
  --transit-gateway-attachment-id tgw-attach-0bbbbbbbbbbbbbbbb

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0aaaaaaaaaaaaaaaa \
  --filters "Name=state,Values=active,blackhole"

Treat an attachment move as a separate network change plan. An attachment can use only one associated table, so a move can interrupt traffic while the association changes. Before the window, record the original association, both forward and return routes, exact attachment identity and service acceptance tests. The plan must wait for the relevant asynchronous association states and specify how to recover if the new table is incomplete. No move sequence was rehearsed for this article, so an executable disassociate/associate procedure is omitted.

Review old propagation dependencies before retiring them. Removing a route that another segment still needs can remove its return path. Prove the intended reachability and isolation on non-production attachments first.

Blackhole routes

A blackhole route is a static route that drops traffic matching it:

For a design example, a blackhole for 10.20.0.0/16 drops matching traffic unless a more-specific route wins. Creating it is an intentional traffic-denial change; review the affected prefixes and rehearse it before production.

Its value comes from the evaluation order. Longest prefix wins, so a /16 blackhole beats a static 0.0.0.0/0.

AWS's own example is central internet egress. Every VPC reaches the egress VPC through a default route, which would also let the VPCs reach each other through it. You can prevent that with a blackhole route for each VPC CIDR.

Two limits follow from the same order:

• A more specific route for part of the range still wins, so a /16 blackhole does not stop a propagated /24. This is an inference from the longest-prefix rule.
• A blackhole on the exact CIDR of a propagated route is a static route, so it replaces the propagated route in the table.

The route state is visible with a filter:

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0aaaaaaaaaaaaaaaa \
  --filters "Name=state,Values=blackhole"

--filters is required on this command. Route states are pending, active, blackhole, deleting and deleted. If AdditionalRoutesAvailable is true, the output is incomplete: narrow the filter or use export-transit-gateway-routes to write the table to S3.

The pages opened for this article describe a blackhole only as a route someone creates. If you find one you did not expect, do not guess. CloudTrail records Transit Gateway API calls, and Event history covers the past 90 days, so search there for who made the change and when.

Finding the drop

Work through these in order. Check both directions, because the return traffic can use a different table: the one associated with the attachment it enters on.

1. Read the association for the attachment the packet enters on

# --query written for this article
aws ec2 describe-transit-gateway-attachments \
  --transit-gateway-attachment-ids tgw-attach-0cccccccccccccccc \
  --query 'TransitGatewayAttachments[].{State:State,Table:Association.TransitGatewayRouteTableId,Assoc:Association.State}'

Expect an attachment state of available, the state in which AWS says traffic can flow between the VPC and the transit gateway. A cross-account attachment can also sit in pendingAcceptance if auto-accept is off.

2. Search that table for the destination

# Filter value written for this article
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0aaaaaaaaaaaaaaaa \
  --filters "Name=route-search.longest-prefix-match,Values=10.2.3.4/32"

Repeat in the table associated with the destination attachment, searching for the source address. A route in one direction only is the classic result of a segmentation change.

3. Read the metrics

The AWS/TransitGateway namespace separates the two kinds of drop. Use the Sum statistic.

Metrics exist per gateway and per attachment. Only VPC attachments support per-Availability Zone metrics.

Zero on all four drop counters is a useful result, but not a clean bill of health. The published metrics have no drop counter for packets over the MTU, so that loss shows only in the flow log fields below. With those also clear, investigate subnet routes, network ACLs, security groups and the host next. Missing drop evidence does not prove that the gateway passed every packet: correlate the exact flow, time interval and log coverage before ruling out a layer.

4. Use Transit Gateway Flow Logs for the specific flow

Metrics count drops but do not name the flow. Transit Gateway Flow Logs record tgw-attachment-id, source and destination VPC, subnet and zone, plus these four fields:

• packets-lost-no-route
• packets-lost-blackhole
• packets-lost-mtu-exceeded
• packets-lost-ttl-expired

The default format includes the fields up to version 6, which covers these. Aggregation must be 60 seconds for transit gateway resources. Flow logs do not affect throughput or latency, but Connect attachments and multicast are not supported. Connect flows appear under the transport attachment, so enable logging on the transit gateway or on that attachment. Publishing can take several minutes to begin.

Only the transit gateway owner can create a flow log unless the owner grants permission.

5. Check the attachment subnet's network ACL

Network ACL evaluation is unusual here, and depends on where the attachment sits.

Rules use the destination address outbound and the source address inbound. AWS recommends a separate small subnet, for example /28, for each attachment, with its ACL left open in both directions. Filter in the workload subnets instead.

6. Check asymmetry through stateful appliances

Without appliance mode, the transit gateway tries to keep traffic in the originating Availability Zone. Across zones, a response can land on an appliance that never saw the request, and it is dropped.

Appliance mode keeps the flow on one zone of the appliance VPC for its lifetime:

Enabling appliance mode is a topology change. Review the attachment and both flow directions with the appliance owner, and validate the change and recovery path in an isolated environment before production.

Check these before relying on it:

• It is supported on VPC attachments only.
• Route propagation must be enabled for the table associated with the appliance attachment. Without it, the gateway cannot work out source and destination zones and uses flow-hash selection for everything.
• Connect exactly one transit gateway to the appliance VPC. Transit gateways do not share flow state.
• Traffic can drop if the source and destination are on two different attachments to the centralised VPC, or if it arrives through another gateway such as an internet gateway.

A Network Firewall attachment gets appliance mode automatically and supports static routing only.

7. Check packet size

A transit gateway supports an MTU of 8500 bytes between VPC, Direct Connect, Connect and peering attachments, and 1500 bytes over VPN. It generates Path MTU Discovery responses only for traffic entering on VPC and Connect attachments. A non-zero packets-lost-mtu-exceeded points here. AWS warns of drops during a move from VPC peering, and advises updating both VPCs at the same time.

8. Use Reachability Analyzer with its limits in mind

Reachability Analyzer can follow a path through transit gateway route tables, but with TCP it analyses forward traffic only on that part of the path. It does not support policy tables, and stops at Connect attachments. A positive result does not clear the return direction, so run a second path the other way.

What to choose and why

These are editorial recommendations.

• Separate subnets for attachments. Use AWS's small dedicated subnet from the start. It removes the most confusing network ACL behaviour.
• Fewest tables that express the policy. Each table is another place for one direction to be wrong. Most designs need a table per trust zone, not one per VPC.
• Prefer no route over a blackhole for isolation. If two segments should never talk, leave out the propagation. Keep blackholes for cases where a broader route would otherwise match, such as central egress.
• Keep auto-association off once you segment. A new attachment landing in the default table can bypass the design.
• BGP for VPN attachments. AWS recommends BGP connections, with multipath where the device supports it. ECMP is not available on static VPN connections.
• A unique ASN on each peered gateway. AWS recommends this to take advantage of future route propagation capabilities.
• One gateway per Region. AWS says you do not need additional transit gateways for high availability, and suggests a single gateway in each Region for disaster recovery.

Risks and limits

Quotas as published on the date checked. Check Service Quotas for your account.

Warning: Static routes that target a VPN attachment are not filtered by the Site-to-Site VPN. AWS notes this may allow unintended outbound traffic on a BGP-based VPN. Review them when you segment.

Warning: Associating a policy table with a VPN or Connect attachment stops all BGP advertisements to that peer. An attachment can use a policy table or a route table, not both.

Warning: Enabling appliance mode on an existing attachment can rebalance flows across zones. Treat it as a traffic-affecting change.

Other limits to plan around:

• Either account can delete a shared attachment at any time, so sharing is not a one-sided control.
• Security group referencing does not work across peering, or across a Gateway Load Balancer or Network Firewall in an inspection VPC.
• Private hosted zone names are not resolved across attached VPCs by the transit gateway itself, and need a separate DNS design.
• A failed or deleted VPC attachment stays visible for 2 hours, so its presence does not mean it is in use.

Cost scales with both attachments and traffic. AWS's Ohio example shows USD 0.05 per VPC attachment per hour, and a USD 0.02 data processing charge for 1 GB sent. A partial hour is billed as a full hour. The owner of the VPC sending the traffic pays for data processing, and each gateway owner is billed hourly for a peering attachment. Check the page for your Region before estimating.

Sources

Opened 2026-11-10. Sources behind the corrections reopened 10 November 2026.

• How AWS Transit Gateway works
• Transit gateways
• Amazon VPC attachments
• Design best practices
• Network ACLs for transit gateways
• Create a static route
• Export route tables to Amazon S3
• Peering attachments
• Add a route for peering
• Policy table limitations
• CloudWatch metrics
• Transit Gateway Flow Logs
• CloudTrail logs
• Quotas
• How Reachability Analyzer works
• AWS Transit Gateway pricing
• AWS CLI v2 reference: create-transit-gateway-route-table, associate, disassociate, enable propagation, disable propagation, create route, search routes, describe attachments, modify transit gateway, modify VPC attachment, create-flow-logs

This article was originally published on 10 November 2026.