Context
A network path is marked reachable, yet the application still cannot connect. This is not necessarily a contradiction. AWS VPC Reachability Analyzer evaluates a model of supported network configuration; it does not send packets through the application path. The result can eliminate some configuration questions, but it cannot prove that a process is listening, a hostname resolves as expected, or a database accepts the caller.
State the question precisely
AWS documents that Reachability Analyzer models the path between a chosen source and destination using network configuration. It can identify blocking components within its supported scope and may show a reachable path. It does not analyse the live data plane. Use the result as evidence about the modelled path, then perform tests that address the remaining layers.
Describe the failed flow with source identity, source network interface or execution environment, destination address, protocol, port, and direction. Include whether the application uses a proxy, private endpoint, or different address family. “The server cannot reach the database” is too broad to guarantee that the analysis and the application are describing the same flow.
An illustrative private API incident
Imagine a worker whose operator analyses a TCP path to the API's private address. The model reports reachability, while the worker resolves the API hostname to a public address because its DNS configuration differs from the test environment. Both observations can be correct: the analysis did not evaluate the address the application actually used.
Capture resolution from the worker's runtime environment. Record the selected address and connection attempt, not only a lookup from an administrator's laptop. Containers, host processes, and managed workloads may have different resolver configuration or proxy variables. Compare the observed destination with the one supplied to the network analysis.
Confirm the source and route
Identify the actual egress path for the application. A shell test from a bastion is useful only if the bastion represents the same relevant network boundary. If it uses a different subnet, security group, identity, or proxy, label it as a comparison rather than proof about the failing workload.
Re-run the supported analysis using the most accurate source and destination resources available. Review assumptions and unsupported portions of the path. If several possible paths exist, check whether the modelled one is the path used by the application. Preserve the analysis identifier and configuration time so later infrastructure changes do not invalidate the interpretation silently.
Move from configuration to live evidence
Perform a bounded connection test from the failing environment. Separate name resolution, TCP establishment, TLS negotiation, protocol authentication, and the business request. A timeout at one stage should not automatically be described as a firewall issue at every stage.
Check the destination host's listener and local firewall where you control them. A permitted VPC path does not start the service or bind it to the intended interface. If the connection reaches the server, correlate server-side logs with the test time and client address. Use packet capture only where necessary and handle captured application data appropriately.
Read flow evidence with its limits
VPC flow records can help investigate observed traffic, but their scope and fields must be understood. A network-level acceptance does not demonstrate that the application returned a valid response. Conversely, an absence of the expected record may reflect the wrong interface, time window, or collection configuration.
Align clocks and use a distinct test window. Repeated uncontrolled probes create noisy evidence and can trigger rate controls. A small sequence of labelled tests is usually easier to correlate across the source, network, and destination than a long-running connection loop. Retain enough context to reproduce the successful or failing condition.
Do not repair the wrong layer
If TCP succeeds but TLS fails, inspect trust, hostname verification, protocol compatibility, and certificates. If TLS succeeds but the service returns an authorisation error, investigate application or database permissions. Opening more network access is unlikely to correct those boundaries.
If the service responds slowly only under load, examine capacity and dependency latency. The model may correctly report that the route is allowed while queues, connection pools, or worker saturation delay the request. Compare the failing operation with a lightweight protocol check to distinguish connectivity from useful service completion.
Validate a focused correction
Change one identified cause and repeat the same labelled test. Keep the network model result and application result side by side. If a security rule was the cause, confirm the intended flow works and an unrelated flow remains blocked. If DNS was the cause, confirm the application now chooses the expected address.
Test the application's real operation after lower-layer checks pass. A successful socket connection is necessary for many services but insufficient to prove a customer workflow. Verify an authorised read or another representative action with the production-like runtime identity and timeout budget.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Model passes; TCP fails | Live boundary untested | Inspect listener evidence |
| Runtime uses another address | Resolution context differs | Compare selected destination |
| TLS succeeds; request denied | Application permission boundary | Inspect actual principal |
A focused operator exercise
Run the analysis and live test from an explicitly identified workload environment. Record the modelled source, destination, protocol, and port alongside the hostname and address the application actually selects. If they differ, correct the comparison before changing network rules. A path analysis is useful only when it represents the flow under investigation.
Perform a short staged probe covering resolution, connection establishment, TLS negotiation where relevant, and one authorised application operation. Correlate the attempt with destination logs and available network evidence. Keep the test rate low and the time window labelled so observations remain attributable. A successful lower-layer stage should narrow the investigation without claiming that later stages also succeeded.
Introduce one controlled failure at the destination listener, then a separate application authorisation failure. Confirm the runbook distinguishes them from a modelled network block. Restore each condition and repeat the same operation. The exercise passes when the operator can explain precisely what the model established, what the live test established, and why the chosen correction addressed the failed boundary.
Keep an evidence-based runbook
A useful incident record includes the exact flow, analysis assumptions, runtime DNS result, live connection stage, destination evidence, correction, and acceptance test. Explain what each observation established and what remained untested. This makes the handover understandable to both network and application engineers.
Clouvenix can help combine AWS network analysis with operating system and application diagnostics. The result is a narrower investigation and a correction tied to the failing layer, with clear proof that the business operation recovered.
Explore Clouvenix network architecture for implementation and operational handover.