AWS Transit Gateway Route Not Propagating, Fixed: Association vs Propagation, Subnet Routes, the Return Path, Overlapping CIDRs, Blackholes, Appliance Mode and TGW vs VPC Peering

A Transit Gateway route not propagating usually means the destination attachment has not propagated into the route table consulted by the source attachment, or an overlapping CIDR, static route, or incomplete attachment is preventing the expected entry. The most common mistake is confusing association with propagation: association selects the route table used to forward traffic arriving from an attachment; propagation installs that attachment’s advertised destinations into selected route tables. Even with both correct, each VPC subnet route table must direct remote CIDRs toward the transit gateway. To fix the path, inspect source association, destination propagation, matching transit gateway routes, reverse routing, and security controls—in that order.

aws ec2 describe-transit-gateway-attachments --filters Name=transit-gateway-id,Values="$TGW_ID" --region us-east-2
aws ec2 get-transit-gateway-route-table-associations --transit-gateway-route-table-id "$TGW_RTB_ID" --region us-east-2
aws ec2 get-transit-gateway-route-table-propagations --transit-gateway-route-table-id "$TGW_RTB_ID" --region us-east-2
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id "$TGW_RTB_ID" --filters Name=route-search.exact-match,Values=10.20.0.0/16 --region us-east-2

Jake runs a phone repair shop with separate VPCs for customer bookings and internal repair tracking. He attaches both VPCs to an AWS Transit Gateway, sees two available attachments, and expects the servers to ping each other immediately.

The first test times out. A developer finds that the destination VPC appears under Propagations, so Jake assumes the connection must be correct. Ethan shows him why that is only one part of the path: propagation places routes into a table, while association determines which table the arriving packet consults.

Understand the four pieces before troubleshooting

Your transit gateway is a managed regional router for connecting VPCs, VPNs, Direct Connect gateways, peering connections and other supported attachments. It does not replace your subnet route tables or security rules. Think of it as a central routing decision point between networks.

An attachment is the connection between one of your resources and the transit gateway. Each attached VPC normally has a VPC attachment with selected subnets, typically one per enabled Availability Zone. The same transit gateway can have many independent attachments.

A transit gateway route table maps destination prefixes to attachment targets. You can create several tables to separate production, development, and shared-services traffic. The table associated with an ingress attachment decides the next hop for traffic entering from that attachment.

Every attachment therefore gives you two separate things to check: its single route-table association and the zero-or-more route tables into which its destination prefixes propagate. When both VPCs are associated with a single common table and both propagate to it, each can usually see a route for the other—but the VPC-side routes and security still matter.

Association versus propagation: the mistake that breaks routes

Association answers: “When a packet enters from VPC A, which transit gateway route table must it search?” A VPC attachment is associated with at most one transit gateway route table at a time. This creates the ingress routing context.

Propagation answers: “Into which transit gateway route tables should VPC B’s CIDR be installed?” A destination attachment can propagate into more than one table. Propagation does not choose the table consulted by traffic arriving from B.

For a packet from VPC A to VPC B, examine A’s association first. Then examine B’s propagation into the table associated with A. For the return packet, reverse the analysis: B’s association determines its consulted table, which must contain a route to A.

You can have B propagating into one table while A is associated with another. Both settings appear healthy in isolation, yet A has no route to B. Fix the relationship rather than blindly enabling every attachment everywhere.

Jake: "B shows propagated, so why cannot A reach it?"

Ethan: "Check the table associated with A. B must propagate into that table for A to find it."

Default route table and automatic settings

When creating a transit gateway, you can enable default route-table association and default route-table propagation. With both on, new supported attachments normally associate with the default association table and propagate their destinations into the default propagation table. Often this is the same default route table.

Automatic behavior is convenient for a simple hub-and-spoke test, but it can let traffic flow between environments you meant to keep apart. A default table is not automatically a security boundary.

If you disable automatic association or propagation, explicitly configure those relationships for each attachment. If both default-table options are disabled when the transit gateway is created, a default route table might not be created at all.

Inspect your transit gateway configuration and verify the actual settings on each attachment. An attachment may not have inherited the defaults just because another VPC connected successfully.

Read attachment state before inspecting any route

An attachment must reach available before you expect consistent forwarding. Look for pendingAcceptance, pending, modifying, failing, or deleted states in the attachments list.

For a VPC attachment, select subnets in every Availability Zone where your resources need transit gateway access. AWS creates transit gateway attachment network interfaces in selected subnets. An instance in an Availability Zone without an enabled attachment subnet cannot use that VPC attachment as expected.

The route table associated with the attachment subnet can affect forwarding between the attachment and destination resources. Checking only your application subnet's route table is not enough when subnets use different route tables.

An attachment may be available but still have neither useful propagation nor association to the intended table. Attachment state is the start of diagnosis, not proof of end-to-end connectivity.

Search the transit gateway route table for the exact CIDR

Open VPC → Transit Gateway Route Tables and select the route table associated with the source attachment. The Routes tab can search by CIDR. Look for the destination prefix and inspect its type, state, and target attachment.

From the CLI, search-transit-gateway-routes reports matching routes. Use route-search.exact-match to search for a known CIDR or route-search.longest-prefix-match to find the route that applies to a particular destination IP.

Confirm that the target is your intended destination attachment and not a competing static route, a VPN, or a blackhole. A route shown in another transit gateway route table is irrelevant to the current packet unless that table is the source attachment’s associated table.

Then check the return direction separately. A route from A to B does not imply that B’s ingress table has a route to A, and the return packet may be dropped even when the forward route exists.

Use CLI commands to inspect associations and propagations

The get-transit-gateway-route-table-associations API identifies attachments using a selected table as their ingress lookup. The get-transit-gateway-route-table-propagations API identifies attachments contributing prefixes to that table.

Run both commands against the relevant transit gateway route table in its Region. Compare the attachment IDs against the actual VPC attachments rather than relying on name tags alone. Tags help humans but do not change routing decisions.

If a destination attachment is not propagating to the source-associated table, enable its propagation there. If the source attachment is associated with the wrong table, change its association carefully and assess all destinations reachable through the new table.

Your route-table changes affect multiple workloads if several source attachments share that table. Audit the table’s other routes before changing production associations.

aws ec2 get-transit-gateway-route-table-associations --transit-gateway-route-table-id "$TGW_RTB_ID" --region us-east-2
aws ec2 get-transit-gateway-route-table-propagations --transit-gateway-route-table-id "$TGW_RTB_ID" --region us-east-2
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id "$TGW_RTB_ID" --filters Name=route-search.longest-prefix-match,Values=10.20.2.20 --region us-east-2

Make the VPC subnet route tables point to the gateway

Transit gateway propagation affects transit gateway route tables—not ordinary VPC subnet route tables. Each of your source VPC subnets that sends traffic to the other VPC needs a route for the remote CIDR with the transit gateway as target.

For example, the application subnet in VPC A needs a destination of 10.20.0.0/16 targeted to tgw-.... VPC B needs a return route for 10.10.0.0/16. Its local VPC route remains in place for its own CIDR.

Check the route table actually associated with your instance’s subnet. Updating the VPC main route table has no effect on a subnet that uses a different custom route table.

Send all traffic through the transit gateway with 0.0.0.0/0 only when you intend centralized egress. Specific routes are easier to troubleshoot and limit accidental changes to internet paths.

Work through the packet in both directions

A to B follows: instance A → its subnet route table → transit gateway attachment A → associated TGW route table → route for B → VPC attachment B → destination subnet → instance B. The return traverses B’s subnet and TGW routing decisions in reverse.

Remember that routing is directional. The reply can fail when VPC B lacks a return route, when B’s ingress transit gateway table does not contain A’s CIDR, or when security controls block replies. This commonly produces the impression that connectivity works only in one direction.

Security groups are stateful, meaning permitted traffic receives stateful response handling. Network ACLs are stateless, so inbound and outbound rules—including return ports—must allow the path.

For ping diagnostics, allow ICMP where appropriate and verify instance operating-system firewalls. A failed ping alone does not prove the transit gateway route is missing, because ICMP can be blocked even when TCP application traffic works.

Worked example: VPC A and VPC B cannot ping

Jake’s VPC A uses 10.10.0.0/16 and its instance is 10.10.1.10. VPC B uses 10.20.0.0/16 and its instance is 10.20.2.20. Both VPC attachments are available on the same transit gateway in US East (Ohio).

The source attachment A is associated with TGW route table tgw-rtb-A. B’s CIDR propagates only into tgw-rtb-B, so A’s consulted route table lacks 10.20.0.0/16. At the same time, VPC B’s instance subnet has no route back to 10.10.0.0/16. There are two independent faults.

First, enable B’s propagation into A’s associated route table, and enable A’s propagation into B’s associated route table (or use a correctly designed common table). Next, add the correct remote-CIDR-to-TGW route in both VPCs’ relevant subnet tables. Confirm the destination attachment subnet tables also support traffic delivery.

Finally, temporarily permit a narrowly scoped ICMP test between the instance addresses, check NACLs and host firewalls, then test both directions. The repaired route path appears on the correct TGW tables and the return route exists, so ping can succeed if instance-level filters allow it.

aws ec2 enable-transit-gateway-route-table-propagation --transit-gateway-route-table-id "$A_TGW_RTB" --transit-gateway-attachment-id "$B_ATTACHMENT" --region us-east-2
aws ec2 enable-transit-gateway-route-table-propagation --transit-gateway-route-table-id "$B_TGW_RTB" --transit-gateway-attachment-id "$A_ATTACHMENT" --region us-east-2
aws ec2 create-route --route-table-id "$A_SUBNET_RTB" --destination-cidr-block 10.20.0.0/16 --transit-gateway-id "$TGW_ID" --region us-east-2
aws ec2 create-route --route-table-id "$B_SUBNET_RTB" --destination-cidr-block 10.10.0.0/16 --transit-gateway-id "$TGW_ID" --region us-east-2

The create-route calls are for route entries that do not already exist. If a conflicting entry exists, inspect and deliberately replace it instead of blindly repeating creation. Values are placeholders for a permitted test environment.

Recognize overlapping CIDRs and route preference

If two VPCs have identical or overlapping CIDRs, Transit Gateway does not automatically propagate the overlapping newly attached VPC’s CIDR into its route table. An attachment can be available while its expected propagated route is absent.

For overlapping VPCs, your durable fix is usually renumbering or redesigning the network with deliberate address translation. Adding random static routes can create ambiguous forwarding and does not eliminate the overlapping-address problem.

For the same destination prefix, a static TGW route takes priority over a propagated route. More-specific prefix matches can also determine where traffic goes. A deliberately configured blackhole route can therefore take traffic away from an otherwise valid propagation.

Inspect all routes matching the destination address, not only the entry you expected. A route that appears present may lose to a more specific route, while a static route of equal prefix can suppress its propagated equivalent.

Jake: "The attachment is available. Why is its 10.10 subnet absent?"

Ethan: "Check for an overlapping CIDR. Transit Gateway can suppress the new VPC’s propagation even though the attachment itself exists."

Static, propagated, and blackhole routes

Propagated routes are learned from attachments. VPC attachments contribute VPC CIDRs, and dynamic VPN attachments can contribute BGP-learned prefixes. Static routes are manually specified destinations pointing to an attachment.

Transit gateway peering attachments require static routes; peering does not automatically exchange route tables. Static routes are also useful for intentional traffic steering, service insertion, and certain VPN designs.

A blackhole TGW route is a route whose target is to drop matching traffic. This can enforce isolation or quickly prevent forwarding to a prefix. It is also an easy explanation for connectivity failure when someone forgets a temporary deny route.

Disabling propagation may not remove all reachability. A static route might remain and still forward traffic. Audit both propagated and static entries when segmenting networks.

Use Route Analyzer without mistaking it for a packet test

AWS Network Manager Route Analyzer can inspect routing paths between source and destination transit gateway attachments registered in a global network. You can specify source/destination IPs and request return-path analysis.

The tool shows you whether the relevant TGW route tables have a plausible forward and return path. It can reveal wrong association, missing destination routes, or unexpected next hops before you run traffic.

Its scope is limited: it analyzes transit gateway routing, not VPC route tables, security groups, network ACLs, or customer-gateway BGP devices. It also does not work with intra-Region transit gateway peering.

Combine Route Analyzer with VPC Reachability Analyzer when applicable, VPC Flow Logs, instance tests, and subnet route-table inspection. A positive TGW routing analysis is not a guarantee that application traffic succeeds.

Jake: "The Analyzer says the TGW route is fine, but ping still fails."

Ethan: "It only analyzes TGW routes. Check VPC routing, ACLs, security groups, and the host firewall next."

Cross-account attachments through AWS RAM

An owner can share a transit gateway using AWS Resource Access Manager. Another account can then attach its VPC. Depending on the share context, the recipient may first need to accept the RAM resource-share invitation.

If the transit gateway does not have auto-accept shared attachments enabled, its owner must explicitly accept the incoming cross-account VPC attachment. A pendingAcceptance attachment will not forward traffic as an available attachment.

After acceptance, inspect the attachment’s association and propagation. The transit gateway owner controls TGW route tables and their associations/propagations; the attached VPC owner controls its VPC-side route tables.

Account boundaries often explain your partial fix: the central network team sees correct TGW routes, but the application account has not added the remote CIDR to its subnet route table. Coordinate both owners rather than waiting for propagation to correct missing VPC routes.

aws ec2 accept-transit-gateway-vpc-attachment --transit-gateway-attachment-id "$PENDING_ATTACHMENT" --region us-east-2

VPN attachments and BGP route propagation

For Site-to-Site VPN with dynamic routing, BGP can advertise on-premises prefixes to the transit gateway. When propagation is enabled, the learned routes are placed in relevant TGW route tables. The associated route table controls routes advertised back to the customer gateway.

An active VPN attachment is not enough if your BGP session is down or advertises an unexpected prefix. Inspect tunnel health, BGP session state, customer-gateway route advertisements, and the receiving TGW table.

Static VPN routing uses manually configured routes rather than BGP-learned propagation. A static VPN will not learn on-premises networks on its own, so troubleshoot it differently.

Route priority and overlapping advertisements can affect which tunnel or attachment carries traffic. When changing VPN routing, inspect the return route on the on-premises device as well as the AWS side.

How quickly should routes propagate?

Transit gateway route and attachment updates are asynchronous. New associations and propagations may take a short period to become available and visible after the API or console change. There is no useful universal guarantee such as “exactly 30 seconds.”

Wait until your attachment and propagation status show an established state, then search the actual route table. Retrying ping repeatedly is less informative than verifying the control-plane route has appeared.

For BGP-based VPNs, reconvergence also depends on tunnel and BGP session behavior. Changes can take longer during failover or unstable network conditions.

If the expected prefix never appears after the attachment and propagation stabilize, investigate configuration and route conflicts. A persistent missing entry is not a propagation delay.

Security groups and NACLs across a transit gateway

Transit Gateway supports cross-VPC security-group referencing for inbound security-group rules when enabled on the transit gateway and both relevant VPC attachments. It is not supported for outbound security-group rules across TGW.

The feature also has specific restrictions, including lack of support across TGW peering and certain Availability Zone or endpoint contexts. Verify that the relevant attachment configuration actually enables security-group referencing.

Without this feature, security-group rules typically reference the remote CIDR. For ping tests, inbound ICMP permissions and host firewalls must be checked. Stateful security groups do not remove the need for VPC routing.

Network ACLs are stateless and can prevent replies even when the initial packet reaches its destination. Review both directions and ephemeral ports for TCP tests.

Jake: "Can I point B’s inbound security rule to A’s security group?"

Ethan: "With SG referencing enabled on the TGW and both attachments, for supported inbound rules. It does not replace routing and has limitations."

Isolate one VPC without breaking the shared services path

Use separate transit gateway route tables as your routing domains. Associate isolated VPC attachments with a table that contains only the destinations they are permitted to reach. Propagate shared-services destinations to multiple tables when shared connectivity is intended.

For example, associate production attachments with a production table and development attachments with a development table. Keep production CIDRs out of development tables unless you have an approved connectivity requirement.

The shared-services VPC may use another table that includes routes back to both domains. That can allow each environment to reach approved shared services without providing automatic direct development-to-production routing.

Route-table isolation is one layer of your network security. Also use security groups, NACLs, firewalls where required, and explicit tests for accidental transitive connectivity. A TGW is not automatically a stateful firewall.

Estimate attachment and data-processing costs

AWS Transit Gateway pricing usually has an attachment-hour charge and a data-processing charge for traffic entering the transit gateway from charged attachment types. Additional AWS data-transfer and VPN connection charges can apply.

In US East (Ohio), Transit Gateway costs $0.05 per VPC attachment-hour and $0.02 per GB processed. Rates differ by Region and attachment type, so check yours.

For two VPC attachments running 730 hours, the example attachment cost is 2 × 730 × $0.05 = $73.00. If 1,000 GB enters TGW through charged VPC attachments, the example processing charge is $20.00, producing $93.00 before other applicable data transfer, taxes, or VPN-related charges.

Billing follows attachment ownership rules: the VPC owner ordinarily pays hourly attachment and associated data-processing charges for its VPC traffic. Size your network by actual directional traffic: traffic sent from each VPC into TGW can contribute to processed GB.

Transit Gateway or VPC peering: which one you actually need

If you only need to connect two VPCs, you may not need a transit gateway at all. VPC peering connects exactly two VPCs directly. There is no hourly charge for the peering connection itself, and traffic over a peering connection between resources in the same Availability Zone is free; traffic that crosses Availability Zones is billed as normal data transfer. A transit gateway is a hub instead: every VPC attaches once, and its route tables decide who can reach whom.

The deciding difference is transitive routing. Peering is not transitive: if VPC A peers with B and B peers with C, A still cannot reach C through B. Five VPCs that all need to talk to each other take ten peering connections, each with routes on both sides. With a transit gateway, the same five VPCs take five attachments, and adding a sixth means one more attachment instead of five more connections.

For two VPCs that will stay two VPCs, peering is cheaper and has fewer moving parts. Jake chose a transit gateway because a site-to-site VPN to the shop and a third VPC for backups are on the way; for a network that keeps growing, the hub pays for itself once the third or fourth connection arrives.

Jake: "Should I tear down the transit gateway and use peering instead?"

Ethan: "Not with the VPN and the backup VPC coming. For two VPCs forever, peering wins on cost. For a growing network, the hub is simpler to run."

Firewall in the middle? Turn on appliance mode

If you route traffic between VPCs through an inspection VPC with a stateful firewall, you can hit a failure that looks like a routing bug: connections start, then hang or reset. The usual cause is asymmetric routing across Availability Zones. Without appliance mode, the transit gateway tries to keep traffic in the Availability Zone it came from, so the request can pass through the firewall in one zone and the reply through the firewall in another zone. The second firewall has never seen that connection, so it drops the reply.

Appliance mode fixes this. When you turn it on for the inspection VPC's attachment, the transit gateway picks one network interface in that attachment for each flow and keeps both directions of the flow on it, so the same firewall sees the request and the reply.

aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id "$INSPECTION_ATTACHMENT" --options ApplianceModeSupport=enable --region us-east-2

Turn it on for the attachment of the VPC that holds the appliances, not for every spoke VPC. Designs with AWS Network Firewall or a Gateway Load Balancer in a central inspection VPC use this pattern. If your connections through a firewall work for a few seconds and then stall, check appliance mode before you change a single route.

See where packets stop: Transit Gateway Flow Logs

When the routes look right and traffic still fails, look at the traffic itself. Transit Gateway Flow Logs record the traffic that passes through your transit gateway, attachment by attachment, and you can send them to CloudWatch Logs, Amazon S3 or Amazon Data Firehose. VPC Flow Logs on the subnets at each end complete the picture.

Read them like a relay race. If the flow shows up in VPC A's flow log but does not reach the transit gateway, the subnet route in VPC A is missing or a network ACL dropped it. If it reaches the transit gateway but not VPC B, look at the transit gateway route table associated with A. If it reaches VPC B and the reply does not come back, look at B's return route and the table associated with B.

aws ec2 create-flow-logs --resource-type TransitGateway --resource-ids "$TGW_ID" --log-destination-type cloud-watch-logs --log-group-name tgw-flow-logs --deliver-logs-permission-arn "$FLOW_LOGS_ROLE_ARN" --region us-east-2

Flow logs cost money for ingestion and storage, so turn them on for the investigation and decide afterward whether you want to keep them running. For a short test, a few minutes of logs with one ping or one TCP connection in each direction is usually enough to see where the packet stops.

Terraform and CloudFormation: the two settings that differ silently

If you build the transit gateway as code, the default-table behavior lives on each attachment, and that is where many "it worked in the console" problems come from. In Terraform, every aws_ec2_transit_gateway_vpc_attachment has transit_gateway_default_route_table_association and transit_gateway_default_route_table_propagation, and both are true unless you set them. If you manage associations yourself with separate association and propagation resources, set both to false, or the attachment also joins the default table and you get routes you did not plan.

resource "aws_ec2_transit_gateway_vpc_attachment" "booking" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.booking.id
  subnet_ids         = aws_subnet.tgw[*].id

  transit_gateway_default_route_table_association = false
  transit_gateway_default_route_table_propagation = false
}

resource "aws_ec2_transit_gateway_route_table_association" "booking" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.booking.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.prod.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "booking_to_shared" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.booking.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.shared.id
}

Remember the VPC side too: an aws_route in each subnet route table that points the remote CIDR at the transit gateway. The transit gateway resources do not create those for you. In CloudFormation, the matching resources are AWS::EC2::TransitGatewayRouteTableAssociation and AWS::EC2::TransitGatewayRouteTablePropagation, with the VPC routes as AWS::EC2::Route entries that depend on the attachment.

Peering and Direct Connect: the routes you add by hand

Two attachment types leave your route tables empty until you act. For transit gateway peering, between Regions or between two transit gateways, you add static routes on both transit gateways that point the remote CIDRs at the peering attachment, and the other side must accept the peering attachment first. Propagation does not cross a peering link.

aws ec2 create-transit-gateway-route --transit-gateway-route-table-id "$LOCAL_TGW_RTB" --destination-cidr-block 10.30.0.0/16 --transit-gateway-attachment-id "$PEERING_ATTACHMENT" --region us-east-2

For Direct Connect, you associate a Direct Connect gateway with the transit gateway and list the allowed prefixes: the AWS-side prefixes advertised to your on-premises routers. If an office network cannot reach a VPC, check that the VPC's CIDR is covered by the allowed prefixes, then check that your on-premises prefixes appear in the transit gateway route table through the Direct Connect gateway attachment. Both directions again, as with every other path on this page.

Operational checklist before escalating a missing route

Confirm your AWS account and Region, attachment IDs, VPC CIDRs, subnets, and route-table IDs. Record whether each attachment is available, associated with the intended TGW table, and propagating to the intended destination tables.

For each traffic direction, identify source subnet table, source-associated TGW table, matching destination route, destination attachment subnet, destination subnet, and return route. Verify prefixes do not overlap and static or blackhole routes do not override the learned path.

Use TGW route search and Network Manager Route Analyzer for the routing control plane, then VPC Flow Logs and narrowly scoped connectivity tests for packet behavior. Check operating-system firewalls, SGs, NACLs, and appliance routes.

If all checks pass but traffic fails, collect timestamps, source/destination IPs and ports, both direction paths, attachment/table identifiers, route-search outputs, flow logs, and relevant status transitions before opening an AWS Support case.

Frequently asked questions about Transit Gateway routing

What does Transit Gateway route not propagating mean?

The expected destination prefix is not installed in the transit gateway route table being inspected. Check the destination attachment propagation, overlapping CIDRs, route conflict, and attachment state.

What is the difference between association and propagation?

Association chooses the one transit gateway route table consulted by traffic arriving from an attachment. Propagation installs that attachment’s advertised destinations into one or more transit gateway route tables.

Do I need routes in both VPC route tables?

Yes. Each relevant source subnet route table needs a route for the remote CIDR to the transit gateway, and the return subnet normally needs a matching route back.

What does the default transit gateway route table do?

When default association and propagation are enabled, new attachments are normally associated with and propagate to the designated default tables. These automatic behaviors can be disabled.

How long does Transit Gateway route propagation take?

Changes are asynchronous and often become visible shortly after attachments and propagations stabilize; AWS does not provide a useful guaranteed universal number of seconds. Check actual route and attachment states.

How do I search for a route in the transit gateway console?

In VPC, open Transit Gateway Route Tables, select the route table associated with the source attachment, and use the Routes tab to search for the destination prefix.

How do I diagnose one-way connectivity through Transit Gateway?

Trace both directions separately: source subnet route, associated TGW table, target attachment, destination subnet, and reverse path. Also check security groups, network ACLs, and host firewall.

What happens if two attached VPCs use overlapping CIDRs?

Transit Gateway does not propagate the newly attached VPC’s overlapping or identical CIDR into the TGW route table. Address renumbering or a carefully designed translation strategy is usually necessary.

Does a static transit gateway route override a propagated route?

A static route takes priority over a propagated route with the same destination prefix. More-specific prefix matching can affect the actual route selected.

What is a transit gateway blackhole route?

A blackhole route deliberately drops traffic matching its destination prefix. Check for these routes when propagated paths appear present but traffic is blocked.

How do I accept a cross-account transit gateway attachment?

The TGW owner accepts a pending shared VPC attachment unless auto-accept is enabled. The recipient might also need to accept the RAM resource-share invitation.

Why is a VPN route not propagating to the transit gateway?

Check VPN tunnel and BGP status, advertised prefixes, destination TGW propagation settings, route preferences, and whether the VPN uses dynamic rather than static routing.

Can security groups reference each other across a transit gateway?

Yes, supported inbound SG rules can reference groups across VPC attachments to the same TGW if feature support is enabled on the TGW and relevant attachments. Outbound referencing and TGW peering are not supported.

How do I isolate one VPC from all other attachments?

Associate it with a TGW route table that excludes disallowed destination prefixes, and control propagation into other route tables. Audit static routes and apply security controls as additional layers.

How much does Transit Gateway cost per attachment and GB?

In US East (Ohio), the rate is $0.05 per VPC attachment-hour and $0.02 per GB of charged processed traffic. Actual prices vary by Region and attachment type, with additional transfer charges possible.

Does Route Analyzer prove that packets can pass?

No. It examines transit gateway route tables but does not validate VPC subnet routes, security groups, NACLs, or customer gateway routing. Combine its analysis with packet-path and flow-log checks.

For Jake’s two VPCs, the route failure came from two missing decisions: B had not propagated into the table associated with A, and B’s subnet lacked a return route. Correcting both restored a complete packet path. A transit gateway should be debugged as a two-way routing system, not as a single switch that becomes connected the moment an attachment turns available.

Revision note. Written October 19, 2026. "It takes two to tango," the saying goes; a transit gateway route needs a way there and a way back.