A complete walkthrough of diagnosing a silent Transit Gateway routing failure across 10 VPCs — using AWS Reachability Analyzer to pinpoint the exact broken hop without touching a single security group rule.
Logical path analysis — walks your real network config hop by hop. No traffic sent. $0.10 per analysis.
Hub-and-spoke TGW connecting all VPCs across regions. Route tables, attachments, propagations.
Destination VPC subnet route table had no route back through TGW — traffic arrived and had nowhere to go.
AWS networking is deceptively quiet when it's broken. No alarms. No flashing red lights. Just a ping that never returns, a replication agent going offline, and a jump server that's an island in its own VPC. That's exactly what we faced last week.
The environment: a hub-and-spoke Transit Gateway connecting 10 VPCs. A Windows jump server at 10.110.10.174 that couldn't reach anything in the 10.13.0.0/16 range. The routing looked correct everywhere we checked. The security groups looked open. The TGW route tables looked fine. Everything looked fine — until we actually traced it.
The complaint was simple: connectivity from the jump server (10.110.0.0/16 VPC) to the target network (10.13.0.0/16) was completely broken. No error messages, no timeout logs — just silence. Before touching anything, we needed to understand the full picture.
Windows jump server at 10.110.10.174, hosted in vpc-dummy-hub-01. Subnet route table had a route for 10.13.0.0/16 pointing at the TGW. Looked correct.
Central hub with 10 VPC attachments. TGW route table tgw-rtb-dummy-01 had a propagated active route for 10.13.0.0/16. Also looked correct.
Target network hosting the internal network appliance. VPC attachment tgw-attach-dummy-corenet was active and propagated. Still looked fine on paper.
Jump server SG allowed all outbound. NACLs on both sides had Rule 100: Allow ALL. No obvious blocks anywhere in the chain.
After checking 6 separate console sections across two AWS accounts, the network still appeared correctly configured. Time to stop guessing.
Manual AWS network debugging means checking Security Groups → NACLs → Route Tables → TGW Route Tables → Destination SGs → return path. That's 6+ console hops per direction, and you're still only as confident as your ability to read static config. Human error loves static config.
AWS Reachability Analyzer doesn't send real traffic. It performs logical path analysis — walking your actual network configuration as AWS sees it, hop by hop, and telling you exactly where a packet would die. It evaluates Security Groups, NACLs, route tables, TGW route tables, peering connections, and VPN attachments in a single analysis run.
One analysis. One definitive answer. The route table rtb-0dummy8b7fd02136c64be in the destination VPC had no route back to the TGW for the 10.110.0.0/16 network. Traffic was arriving at the spoke VPC correctly — but the return path was completely absent.
That's the cost of one Reachability Analyzer run. Ten cents for a definitive, auditable, hop-by-hop network trace that would have taken an experienced network engineer an hour of console archaeology. Run it before you touch a single security group rule.
The forward path from the jump server to the TGW attachment was fully reachable. Here's every hop the analyzer walked, with all identifiers replaced with dummy values:
Forward path: fully reachable. But the analyzer also ran the reverse path — and that's where it found the break.
The reverse path analysis returned a definitive error code pointing to a single resource. No ambiguity, no guesswork:
The destination VPC's subnet route table was pointed entirely at an internet gateway for external traffic and had a local route for its own CIDR — but no route back through the Transit Gateway for any of the internal 10.x.x.x networks. Traffic from the jump server was arriving at the spoke VPC successfully. The response packets had nowhere to go.
Asymmetric routing is the most common Transit Gateway mistake. Forward path and return path use different route tables — both must be configured correctly. Reachability Analyzer exposes this instantly. Manual inspection almost always misses it.
| Component | Manual check | Analyzer result |
|---|---|---|
| Jump server Security Group | Looks open ✓ | ✓ Confirmed open |
| Jump server NACL | Looks open ✓ | ✓ Rule 100 Allow ALL |
| Source subnet route table | Has TGW route ✓ | ✓ 10.13.0.0/16 → TGW |
| TGW route table | Has 10.13 route ✓ | ✓ Propagated, Active |
| Destination VPC attachment | Active ✓ | ✓ Reachable |
| Destination subnet route table | Not checked ✗ | ✗ NO_ROUTE_TO_DESTINATION |
Navigate to VPC → Route Tables → rtb-0dummy8b7fd02136c64be → Edit routes → Add route:
VPC → Route Tables → filter by VPC vpc-0dummy4602d8c81581a19 (AZ-CORENET-SPOKE)
Destination: 10.0.0.0/8 · Target: Transit Gateway → select tgw-0dummy8a75e8d36b34e481 · Save
Create a new analysis on the same path. Status changes from NOT REACHABLE to REACHABLE within 90 seconds.
Run ping 10.13.10.1 or traceroute 10.13.10.1 from the Windows jump server. Response arrives. Problem closed.
The ExplanationCode: NO_ROUTE_TO_DESTINATION output was the standout — a machine-readable, unambiguous diagnosis pointing to a specific route table in a specific VPC. No interpretation required. Compare this to the manual approach where we had already checked 5 of the 6 components correctly and still had no answer.
The reverse path analysis was equally critical. Forward path was reachable — if we'd stopped there, we would have concluded the network was fine. Always run both directions. Asymmetric routing failures are invisible from one side.
Don't touch a security group rule, NACL, or route table until you've run Reachability Analyzer first. It will tell you exactly what's wrong — and exactly what isn't wrong, so you stop changing things that don't need changing and creating new problems in the process.
AWS Reachability Analyzer is the single most underused tool in the VPC console. For $0.10 and 90 seconds you get a hop-by-hop audit trail of your network path — the kind of diagnosis that used to require a senior network engineer, a whiteboard, and an hour of console archaeology. Run it first. Always.
Before running an analysis, it helps to know exactly what resource types are supported. Here's the complete list verified directly from the official AWS documentation.
These resource types can be used as either the source or destination of a path:
| Resource Type | Example Use Case | Notes |
|---|---|---|
EC2 Instance | Instance A → Instance B | ✓ Supported |
Network Interface (ENI) | ENI → RDS ENI · Web → DB | ✓ Supported |
Internet Gateway (IGW) | IGW → EC2 instance (inbound) | ✓ Supported |
Transit Gateway | TGW → spoke VPC instance | ✓ Supported |
Transit Gateway Attachment | VPC attachment → attachment | ✓ Supported |
Virtual Private Gateway (VGW) | On-prem VPN → VPC | ✓ Supported |
VPC Endpoint | EC2 → S3 VPC endpoint | ✓ Supported |
VPC Endpoint Service | PrivateLink consumer → service | ✓ Supported |
VPC Peering Connection | Peered VPC A → VPC B | ✓ Supported |
IP Address | Any source → specific IP | Destination only |
These can be included or excluded from analysis when creating a path — useful when you want to test connectivity bypassing a specific appliance:
| Intermediate Component | Include / Exclude Use Case |
|---|---|
Load Balancers (ALB, NLB, CLB, GWLB) | Test path through or around a load balancer |
NAT Gateway | Verify private subnet outbound via NAT |
AWS Network Firewall | Exclude firewall to test underlying routing |
Transit Gateway | Trace cross-VPC path via TGW |
Transit Gateway Attachment | Verify specific VPC attachment routing |
VPC Peering Connection | Test peering path between VPCs |
Source and destination must be in the same AWS Region. Cross-region paths are not supported.
Resources must be in the same VPC, or connected through a VPC peering connection or a Transit Gateway.
Source and destination can belong to different AWS accounts within the same AWS Organization. Requires trusted access to be enabled.
Reachability Analyzer supports only resources with an IPv4 address. If a resource has both IPv4 and IPv6, only IPv4 is analyzed.
Analysis stops at Connect attachments — connectivity through them cannot be verified.
Internet gateways cannot be used as an intermediate component. If your path goes through an IGW, split it into two analyses: source → IGW, then IGW → destination. This is a documented AWS limitation.
AWS Reachability Analyzer is available in the VPC console under Network Manager. Create a path, run an analysis, and get a definitive answer in 90 seconds.
Open Reachability Analyzer →