NAT gateway vs internet gateway: two different paths

Start from the access requirement

A public front end and an internal worker need different paths. For the public IPv4 instance modeled here, the subnet routes to an internet gateway and the instance has a public address. The private worker routes outbound through public NAT.

A public subnet does not make every resource publicly reachable. Addressing, routes and filters still matter. Likewise, a NAT gateway resource does not make an unrelated private subnet work without a route to it.

Public NAT still depends on an internet gateway

The worker default route targets NAT. The NAT public subnet needs its own internet-gateway path. The gateway attachment, NAT state and VPC relationships must agree. Try removing only the NAT subnet route below.

NAT is not a way to publish a private web server for unsolicited incoming connections. If inbound service exposure is the requirement, choose an appropriate front-end architecture and access controls.

Cost and availability belong in the decision

NAT has hourly and traffic-related costs. AZ placement and traffic paths affect resilience and the bill. Pricing varies; use current estimates for the workload rather than a tutorial total.

Service-specific VPC endpoints may serve some private AWS access needs. They are not a general internet substitute. IPv6 connectivity has different options and is outside this experiment.

Practice both directions

Switch between inbound SSH and outbound HTTPS. Observe that the same private instance can correctly fail inbound and pass outbound. That is the intended boundary, not a contradiction.

Use the trace to name the first failed control, then verify the complete path after repair. A green result means this local model passed its supported checks, not that an actual external endpoint was contacted.

Sources and scope

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

• AWS: internet gateways
• AWS: NAT gateways