VPC subnets and routes: public reachability, NAT and return paths
Determine cloud reachability from routes, addresses and security controls. Trace outbound IPv4 through NAT, understand return paths and diagnose a private workload that cannot download updates.
TL;DR: A subnet's name does not determine reachability. Inspect its effective route table, destination address, gateways and security controls in both directions. For IPv4, a route to an internet gateway alone does not make every instance publicly reachable.
Routes choose the next hop
Using AWS VPC as the example, a subnet is associated with a route table, explicitly or through the main table. Destination matching determines the next hop, with more-specific prefixes generally taking priority under the service's route-selection rules. A default route covers destinations not matched by a more-specific route.
AWS's route-table guide describes routing components. Review effective association as well as the route entries: editing a table that the subnet does not use changes nothing for that workload.
A public IPv4 path commonly requires an internet-gateway route and an appropriate public address mapping, plus permitted security controls and a listening application. A private workload can use a supported outbound path such as a public NAT gateway without accepting arbitrary unsolicited inbound connections through that NAT path.
Trace outbound and return traffic
This is one IPv4 design. IPv6 has different addressing and egress options, and private service endpoints can avoid this internet path for supported services. Do not apply the diagram blindly to every destination.
The NAT gateway documentation explains public/private NAT behavior and availability considerations. Evaluate the deployment mode and failure scope actually used rather than assuming a gateway is automatically resilient to every zone failure.
Worked failure: private hosts cannot install updates
Suppose instances in a private subnet resolve a package repository hostname but time out connecting to it. Start with the resolved address family and destination. A correct IPv4 path cannot serve a client that selected an IPv6 address without a working IPv6 route.
For the IPv4 case, inspect the private subnet's effective default route, the NAT gateway state and the NAT subnet's path to the internet gateway. Then check security-group egress and network ACL rules, including return traffic. A host-side firewall or proxy configuration can still reject the connection after the cloud path is correct.
Use connection evidence to narrow the failure. TCP handshakes distinguish a missing SYN response from an application-layer rejection. DNS success establishes name resolution, not reachability to the returned address.
If the workload needs only a supported cloud service, evaluate a private endpoint and its policy instead of adding unrestricted internet access. That changes both the route and authorization path; test the actual API operation through the endpoint.
| Layer | Question | Evidence |
|---|---|---|
| DNS and address family | Which destination did the client choose? | Resolver response and connection target |
| Subnet association | Which table actually applies? | Effective route-table association |
| Routing | Where does the selected prefix send traffic? | Matching route and next-hop state |
| Security controls | Are forward and return flows permitted? | Security-group, ACL and host rules |
| Translation or endpoint | Does the intended egress mechanism work? | NAT/endpoint metrics and relevant logs |
| Application | Is the service listening and accepting this protocol? | Handshake and application response |
Return paths and stateful controls matter
Security groups track permitted connection state, while network ACLs are stateless and require appropriate directional rules. A route is not a firewall rule. Successful forwarding to a gateway does not imply that a security policy permits the packet or its response.
Asymmetric paths can make diagnosis difficult when different middleboxes observe each direction. Document where translation and inspection occur, then compare captures or flow logs at those boundaries. A log saying traffic was accepted at one interface is not proof that the application received and processed it.
Trace an HTTPS request and its reply through security groups and network ACLs. The packet table shows why allowing destination port 443 in both ACL directions does not admit the client's return traffic.
Design around availability and ownership
Place egress dependencies under the same availability review as application dependencies. If all workloads depend on one constrained or failed egress path, a nominally multi-zone application can lose outbound access together. Use failure-domain reasoning when selecting gateway placement and routing.
Keep changes reviewable: name the destination requirement, the selected path and the access policy. IAM evaluation may explain an API denial even when the network connection succeeds.
Does calling a subnet private make its workloads unreachable from everywhere? No. It describes a common internet-routing pattern, not all possible peering, transit, VPN or load-balancer paths.
Would allowing all security-group traffic fix a missing route? No. Permission and forwarding are separate prerequisites. Identify the failed layer before expanding access.