VPC Connectivity and Private Access Baseline

A timeout inside a VPC can come from several different layers, and each layer fails in a way that looks almost identical from the application's point of view: the call hangs, then times out, with nothing useful in the logs on either end. Routing, security groups, NACLs, and endpoint policy can all produce that same symptom, which makes guessing expensive. The fix is a fixed order of checks that accumulates evidence at each layer, so the failure gets attributed to exactly one cause rather than several plausible ones.

Here's what that looks like in practice. A workload on an EC2 instance in a private subnet starts failing health checks after a deploy, because every call to an AWS service endpoint times out. The application logs show repeated connect timeouts, and the target service logs show nothing, which means the request likely never reached the service edge, or never got routed to the private path it was supposed to take.

Before touching security groups, pinning down a packet path hypothesis comes first. That means identifying which hostname the code is calling, what IP that name resolves to inside the VPC, and whether the intended path runs through a VPC endpoint or through NAT to a public endpoint. That single decision determines which constructs need to allow the flow, and it's what prevents time spent debugging the wrong layer entirely.

The same ordered checklist applies every time, so evidence ...