NAT Gateway Egress
This is what actually answers 'how does a private-subnet resource reach the public internet': a NAT Gateway (in a public subnet) translates and forwards outbound traffic, without making the private resource inbound-reachable.
Why we need this / what value this brings
Without this, a private-subnet resource has zero path to the internet — no third-party API call, no package install, no external DNS-dependent request works at all.
When to use this
Any private-subnet resource that needs to initiate outbound connections to the internet (calling a third-party API, pulling a package) but must not be inbound-reachable.
How to use or implement this
Provision a NAT Gateway in a public subnet, then add a 0.0.0.0/0 route in the private subnet's route table pointing to it — verify both the route and that the NAT Gateway itself has a route to the Internet Gateway.
Research questions
- For the EC2-in-private-subnet-calling-OpenRouter scenario: confirm the private subnet's route table has a 0.0.0.0/0 route pointing at a NAT Gateway sitting in a public subnet. Answered — see NAT Gateway vs. NAT Instance.
- NAT Gateway vs NAT Instance — why is the managed NAT Gateway almost always preferred today (availability, no patching, but per-GB cost to budget for)? Answered — see NAT Gateway vs. NAT Instance: managed HA/throughput vs. self-managed cost savings, and the pitfall of sharing one NAT Gateway across AZs.