Diagnose private VPC connectivity without opening everything

Understand the likely causes

• A missing or mismatched route, an inappropriate NAT or endpoint path, a restrictive security group, a stateless ACL return-path rule, resolver configuration, or an unhealthy destination can produce similar symptoms. One permissive rule cannot prove that the complete path works.

Describe one flow and its failure stage

Write down the source interface and subnet, destination name and resolved address, address family, protocol, port, direction and time. Compare a working and failing observation only when those properties are equivalent. The synthetic timeline below resolves the name but never establishes TCP, so changing application JSON is premature. Gather approved observations for one small diagnostic window; a broad traffic generator adds noise and may create new costs without isolating the fault.

09:00:00 DNS lookup: api.example.test -> 198.51.100.25
09:00:01 TCP destination: 198.51.100.25:443
09:00:11 TCP result: connection timeout
TLS stage: not reached

Trace the selected route and return path

Inspect the route table actually associated with the source subnet, including more specific prefixes that can beat a default route. Then identify the intended egress architecture. A public NAT gateway can support private-initiated internet traffic when its surrounding route and internet-gateway design is correct; it does not create unsolicited inbound access to the instance. A private NAT gateway has a different connectivity purpose. An IPv6 design may use an egress-only internet gateway, while an AWS-service endpoint changes the relevant path. Do not apply an IPv4 recipe blindly to every destination.

Check stateful and stateless controls separately

Match the attached security groups to the actual interfaces and required application flow. Their stateful behavior differs from network ACLs, whose subnet rules must also accommodate appropriate return traffic. Inspect ACL rule order and both directions instead of adding an unrelated inbound rule to the source. Also consider host firewall rules, listening processes and any approved network appliance on the chosen path. Document what each control permits. Avoid changing multiple layers together, because a later successful request would not reveal which change repaired the path.

Use evidence at the correct layer

Configuration analysis can help identify a blocked virtual path; Reachability Analyzer is an example and is charged per analysis. It does not replace checking DNS answers, operating-system state, TLS identity and application health. Flow observations are also bounded evidence: an accepted network flow does not prove that an application completed its work. Endpoint paths may additionally involve an endpoint policy and service authorization. If connectivity succeeds but a service returns AccessDenied, keep the network evidence and move to the identity investigation rather than repeatedly widening network rules.

Correct and document the intended path

Propose one correction that restores the documented requirement while preserving the private-workload boundary. Record the original association or rule, the exact proposed replacement, the owner and rollback condition. A private service dependency may justify an endpoint or internal route rather than public egress. Where internet egress is required, verify the complete forward and return design. The decision record below is a lab artifact, not deployable infrastructure. Retest from the original source after approval, and verify that unrelated inbound access remains unavailable.

{
  "source": "private-app-subnet",
  "required_flow": "HTTPS to approved external API",
  "hypothesis": "source subnet uses an unintended route-table association",
  "change": "review the intended association with the network owner",
  "rollback": "restore the recorded original association",
  "negative_check": "unsolicited inbound traffic remains unavailable"
}

Keep it from recurring

• Maintain a dependency-flow inventory, reviewed subnet associations and explicit network requirements. Include permitted and forbidden paths in change reviews so the next incident can be narrowed without exposing private workloads.