Skip to content

AWS Updated 2026-07-04

VPC Reachability Analyzer: proving exactly where a connection dies

Reachability Analyzer walks your VPC configuration hop by hop and names the security group, route table, or NACL that blocks a path. How to run it, read the findings, and know its limits.

When a connection between two things in AWS fails and you have already stared at three security groups and four route tables, VPC Reachability Analyzer is the tool that ends the argument: you give it a source, a destination, and a port, and it returns either “reachable” with the full hop-by-hop path, or “not reachable” with the exact component — this security group, that route table, this NACL rule — that kills the traffic. It analyzes configuration, not live packets, so it works even when you cannot generate test traffic.

What’s happening

Reachability Analyzer builds a model of your network configuration — ENIs, security groups, NACLs, route tables, internet and NAT gateways, peering connections, Transit Gateways, VPC endpoints — and computes whether a packet with your five-tuple could traverse from source to destination. Two objects are involved: a path (source, destination, protocol, optional port — a reusable definition) and an analysis (one evaluation of that path against current config). You are billed per analysis run, so the path is cheap to keep and re-run after each change.

Because it is configuration analysis, the verdict comes with an explanation. A blocked path names the component and the reason with a specific code — the family of *_MISMATCH explanations such as a security group with no matching inbound rule, a route table with no route toward the destination, or a NACL denying the port. A reachable path lists every hop in order, which is itself useful for confirming traffic takes the path you designed (through the inspection appliance, not around it).

The equally important half is what it does not see: anything inside the operating system. Host firewalls (iptables, nftables, Windows Firewall), whether the process is listening, application authentication — all invisible. “Reachable” means the VPC network layer permits the flow; the service can still be down. It also analyzes within a Region (paths can cross accounts in the same AWS Organization and traverse Transit Gateways and peering), and it covers IPv4 paths — plan around that for dual-stack debugging.

What to check first

Before running an analysis, make sure the question is well-formed:

  • Pick the right source and destination types — instance IDs, ENIs, or gateways. For an instance with several ENIs, analyze the specific ENI carrying the traffic.
  • Know the port and protocol — an analysis for TCP 443 says nothing about TCP 5432.
  • Same Region? Cross-region paths need a different approach (analyze each side to the middle).
  • Cross-account? Both accounts must be in the same Organization with the analyzer’s cross-account access enabled.
  • IAM permissions — the caller needs ec2:CreateNetworkInsightsPath, ec2:StartNetworkInsightsAnalysis, and the tiros:* (the backing service) permissions the console wizard sets up.

How to verify

Console: VPC > Reachability Analyzer > Create and analyze path, choose source, destination, protocol, destination port, and run. Findings render as an ordered hop list with the blocking component highlighted. CLI:

# Define the path once
aws ec2 create-network-insights-path \
  --source i-0source123 \
  --destination i-0dest456 \
  --protocol tcp \
  --filter-at-source '{"DestinationPortRange":{"FromPort":5432,"ToPort":5432}}'

# Run an analysis against current config
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123

# Read the verdict and the blocking component
aws ec2 describe-network-insights-analyses \
  --network-insights-path-ids nip-0abc123 \
  --query 'NetworkInsightsAnalyses[0].{Reachable:NetworkPathFound,Explanations:Explanations[].{Code:ExplanationCode,Component:Component.Id}}'

The explanation codes and supported source/destination combinations are catalogued in the Amazon VPC documentation.

The runbook

  1. Reproduce the failure as a path. Source = the client ENI or instance, destination = the server, protocol and port exactly as the application uses them. Resist the urge to test “ping” when the app speaks TCP 5432 — ICMP results do not transfer.
  2. Run the analysis and read the first explanation. The finding names the component and direction. A security group mismatch on the destination ENI means the inbound rule is missing; a route table finding means the packet never got that far.
  3. Fix only the named component. The precision is the point — do not also “tidy up” three other groups mid-incident. If the finding is a NACL, remember the return direction; the stateless rules are covered in security groups vs NACLs.
  4. Re-run the same analysis. Same path object, one click or one start-network-insights-analysis. Iterate until NetworkPathFound is true — multiple blockers surface one at a time.
  5. Confirm at the OS layer. Reachable in the analyzer plus nc -vz host 5432 from the source closes the loop; if the analyzer says reachable and nc still fails, the problem is the host firewall or the service itself, and you have just saved hours of VPC archaeology.
  6. Keep the path for regression. Re-run it after security group refactors or route changes as a config-plane smoke test.

When this is the wrong move

Reachability Analyzer answers “could this flow work by configuration” — it does not answer “what is happening right now”. For intermittent drops, connection resets under load, or “it worked yesterday”, you want evidence of real packets: VPC Flow Logs analysis shows accepts and rejects as they happen. It is also the wrong tool for DNS problems (it tests IP paths, not name resolution) and for anything inside the instance. And if you run analyses in a tight loop from automation, remember each run is billed — per-analysis pricing is fine for debugging, wasteful as a monitor.

Common mistakes

  • Testing the wrong five-tuple — analyzing port 443 while the app fails on 8443, then trusting the green result.
  • Treating “reachable” as “working” and closing the ticket while the service is down at the OS level.
  • Analyzing instance-to-instance when the real path goes through a load balancer — analyze client-to-ALB and ALB-to-target separately.
  • Forgetting the analysis is a snapshot: config changed after the run means the verdict is stale.

Prevention

  • Create standing paths for your critical flows (app to database, ALB to targets, VPC to on-prem via TGW) and re-run them after every networking change.
  • Wire an analysis into change pipelines that touch security groups or route tables — a failed reachability check blocks the apply.
  • Tag paths with the flow they represent so the next engineer knows what nip-0abc123 proves.
  • Pair the analyzer with flow logs: analyzer for “should it work”, flow logs for “did it work”.

The habit that pays is running the analyzer before the group-therapy session where everyone re-reads security groups aloud — two minutes, one named blocker. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.