Amazon VPC Reachability Analyzer evaluates whether a modeled network path is reachable between supported AWS resources under current network configuration. It is particularly useful when a packet is blocked by a security group, route-table decision, network ACL, or other modeled control. The analyzer is not a synthetic probe that sends application traffic; it reasons about the configured path and identifies explanatory hops or blocking components.
That distinction matters when troubleshooting a service outage. A path analysis can confirm that configured IPv4 network controls allow a route while an application still fails because of DNS, TLS, a listening process, authorization, or a protocol mismatch. Operators should use the tool to narrow the infrastructure hypothesis rather than declaring the entire service healthy after one positive result.
Frame the question as a specific traffic flow
A meaningful analysis requires a source, destination, and relevant traffic details. Start from a failed business transaction: an application instance cannot reach a database listener on a particular port, or a private workload cannot connect to an endpoint. Record the observed source, destination, protocol, and direction before constructing a path.
AWS supports analysis for several resource types, including instances, network interfaces, gateways, endpoints, and other VPC networking components. The selected source and destination must represent the actual failure path. A path from a bastion host is not equivalent to a path from the application task that is failing.
Use the VPC routing model to check subnet associations, longest-prefix route selection, and route destinations. An expected route on the wrong subnet route table does not help the failing instance. Likewise, a gateway attachment that exists does not prove both traffic directions follow a permitted path.
Interpret reachable and unreachable outcomes
When Reachability Analyzer reports an expected path as unreachable, inspect the explanatory details and identified blocking component. A security group rule may not permit a destination port; a network ACL can block an ephemeral return port; a route may point to a missing or inappropriate target. Correct the specific modeled condition, then rerun the analysis.
A reachable result means the analyzed configuration permits the modeled packet flow within tool scope. It does not prove the operating system accepts traffic, the service is bound to the interface, a TLS handshake succeeds, or an endpoint policy allows application actions. Use endpoint logs, packet capture, and service metrics to investigate remaining failures.
Avoid using one analysis result to generalize to a different address family, destination port, or subnet. The tool’s documented path analysis focuses on IPv4 resource support; separate verification may be needed for IPv6 traffic or unsupported attachments. Preserve the precise input in incident notes so later reviewers can tell what was actually established.
Inspect security groups and network ACL interaction
Security groups are stateful controls associated with network interfaces or supported resource configurations. An allowed inbound connection generally permits the related return traffic without requiring an equivalent outbound ephemeral-port rule, according to service semantics. Network ACLs are stateless, so both directions must meet the relevant subnet rules.
Operators often diagnose only the obvious destination port and miss the path or return-direction restriction. For example, an application can reach a database port by one route but fail if an intervening stateless control rejects the response. Inspect which subnet and interface each ACL or security group actually protects rather than assuming the policy applies to every hop.
Security-group references and cross-VPC arrangements require particular attention. A group reference may behave differently depending on peering, transit, or supported architecture. The analyzer can expose model constraints, but all proposed changes still need a least-privilege review; temporarily opening broad CIDR ranges solely to make a path reachable is not a safe permanent fix.
Trace transit gateways and routing domains
Complex environments route between VPCs through transit gateway attachments and their associated route tables. Each attachment belongs to a routing domain with propagation and static-route decisions. A valid route in the source VPC does not guarantee the transit gateway will select the correct destination attachment or that a return path is available.
Verify transit gateway attachment health, route-table association, propagation, and route preference. Overlapping CIDR ranges or missing propagated routes can cause failures that appear similar to security-group denials from the application’s perspective. Model the specific path and compare each reported hop to intended segmentation boundaries.
Cross-account troubleshooting adds visibility and administration constraints. Reachability Analyzer supports cross-account path analysis in documented organization scenarios, but access setup must match the resource ownership structure. An analyst who can see the source VPC may lack permission to model all participating components, so incomplete visibility should not be reported as definitive packet reachability.
Imagine an EC2 workload failing to reach an S3 private endpoint. An analysis of the interface endpoint might find the network path permissible, yet AccessDenied persists because the endpoint policy excludes the requested bucket action. The next diagnostic step is not to change the route table. Operators should verify DNS resolution from the actual workload, endpoint type, endpoint policy, bucket policy, role authorization, and any relevant KMS key policy. A different failure mode exists when the application resolves a public name and never sends traffic to the intended endpoint. These cases require distinct evidence and fixes.
Evaluate endpoints and private service access
Private endpoints reduce exposure to public routing but introduce additional DNS, endpoint policy, and subnet placement decisions. A workload can have a modeled network route toward an endpoint while a service request still fails because the VPC resolver uses the wrong hostname or the endpoint policy rejects the requested API action.
Test reachability to the relevant endpoint interfaces and ports, then independently verify DNS answers from the workload’s resolver and service authorization at the target. Endpoint policy is an application-level authorization concern distinct from the network path. Relying on successful path analysis alone can lead an operator to relax the wrong security group.
Where a target uses load balancing, model the correct target resource and inspect health-check status. A load balancer that is reachable may be forwarding to no healthy targets, using the wrong listener, or expecting a protocol negotiation the client does not perform. The troubleshooting objective is to locate the failed layer, not to force a positive reachability result.
Pair static analysis with runtime evidence
Reachability Analyzer evaluates supported configuration rather than observing every packet in flight. For time-sensitive incidents, compare its output with VPC Flow Logs, DNS query logs, application traces, and endpoint-side telemetry. Flow logs may show actual accepted or rejected traffic, but they also have their own aggregation and coverage limitations.
If a path analysis is positive but connections time out intermittently, investigate runtime factors: host resource exhaustion, NAT or connection tracking, DNS variability, target failover, and service throttling. Those causes may not be visible in a configuration-derived path. Repeating the same positive analysis without testing runtime conditions adds little diagnostic value.
VPC Reachability Analyzer models supported network configuration, not the application exchange itself; SOA-C03 troubleshooting combines its result with flow logs and service telemetry. An operator must identify the layer each AWS diagnostic can actually observe. The analyzer narrows path-policy hypotheses; flow logs and service telemetry are needed for an end-to-end conclusion.
A network change record can contain two path assertions: a positive test from the application interface to its database on the intended port, and a negative test from an unrelated workload into the protected subnet. Running both before and after the change detects an accidental widening of trust. Record the exact source and destination resource IDs, source address family, protocol, port, and analysis timestamp. A future incident responder can then compare changes to the expected contract rather than starting from an undocumented assumption that two VPCs were always permitted to communicate.
Use analyses as change-review evidence
Before changing a route, gateway, or security policy, run a path analysis for the flow expected to become reachable and, where useful, another for traffic intended to remain blocked. A change that repairs the primary connection but inadvertently opens a lateral path may violate segmentation requirements. Negative tests are part of security validation, not optional troubleshooting extras.
After implementation, rerun the same source-to-destination analysis and record both the model result and a real connection test. Note which resource IDs or rules changed. When a network team cannot compare identical inputs before and after a modification, a reported improvement may reflect a different tested path rather than an actual repair.
In infrastructure-as-code deployments, path-analysis results can become evidence for change review and regression testing where service integration permits. Keep the expected path list aligned with application dependencies and policy ownership. A stale test that validates a decommissioned subnet offers little assurance to active workloads.
An analysis may show a permitted path across modeled AWS infrastructure but cannot establish that an on-premises router will return traffic through the same hybrid link. Where a boundary involves a VPN, Direct Connect, customer gateway, or another unsupported segment, the investigation must continue with route and firewall evidence from that environment. Treat the analyzer’s final modeled hop as an explicit scope boundary. Reporting a partial configured path as proof of complete hybrid connectivity can postpone diagnosis of an asymmetric route that exists outside the tool’s direct visibility.
Understand the tool’s scope and limitations
Reachability Analyzer has supported-resource, IPv4, and feature limitations; specific attachment types and network paths may not be modeled end-to-end. Verify the current AWS documentation before making promises about new services or cross-account traversal. If a supported path stops at a boundary, continue with an appropriate diagnostic in the next domain.
Do not infer data-plane performance from reachability. Latency, packet loss, bandwidth constraints, application authentication, and backend saturation need other evidence. A low-latency control-plane analysis can finish while a real workload is still experiencing unacceptable response time. Document these limits in the incident conclusion.
Useful reachability analysis ends with a narrow, testable explanation of the configuration. When operators specify the correct source and destination, inspect each modeled hop, verify the changed control, and corroborate with actual traffic, they turn a broad “network problem” into an actionable infrastructure diagnosis without weakening security unnecessarily.
