Private subnet has no internet: check the NAT path

Two subnet routes, not one

Imagine a LetX practice worker that downloads a dependency but accepts no unsolicited public connections. Its own default route targets a public NAT gateway. The NAT gateway has to live on a path that can itself reach the internet; an available NAT resource is not proof that every route is correct.

Check the route table actually associated with the worker subnet. Then check the NAT subnet route and gateway attachment. A route in a different table or VPC cannot repair this path. The NAT gateway also needs the appropriate public address allocation.

Filters still apply

The worker security group needs matching outbound permission. NACLs are stateless, so both directions must be allowed at each relevant subnet boundary. The model uses fixed example addresses and ephemeral ports; those are teaching inputs, not universal production rules.

If only AWS service access is required, consider whether a supported VPC endpoint is a better fit. An endpoint does not provide general internet connectivity. Choose it for the service and access pattern you actually need.

Use an outbound test

Failure of internet-initiated SSH to a private instance is expected and says little about its outbound NAT path. Select outbound in the experiment. Keep the instance private, then remove the NAT public route. The trace should fail even when the NAT state remains available.

Restore the route and deny return traffic in the ACL. This separates routing from filtering. In a live account, test the actual destination and inspect DNS, application logs and supported network diagnostic tools too.

Check the bill before adding gateways

NAT gateway pricing includes multiple dimensions and varies by deployment and Region. Multi-AZ availability and cross-AZ paths affect the architecture decision. Use current pricing and traffic estimates rather than copying a fixed monthly number from a tutorial.

This synthetic LetX example does not describe its actual hosting. The purpose is to explain a cloud networking decision without requiring an AWS account or spending money.

Sources and scope

Reviewed against these official references. The model’s supported scope appears alongside its controls.

• AWS: NAT gateways
• AWS: NAT troubleshooting