NAT Gateways & Egress
NAT already covered how address translation and PAT work at the packet level: rewrite the source IP and port, keep a translation table, reverse the rewrite for replies. A cloud NAT gateway is that exact mechanism, offered as a managed service so you don't have to run and patch a NAT instance yourself.
The problem it solves
Instances in a private subnet (see
VPCs, Subnets & Routing) have no route to an internet
gateway, so they can't be reached from the internet - that's the point. But
they usually still need outbound access: pulling OS patches, hitting a
package registry, calling a third-party API. A NAT gateway sits in a public
subnet, and the private subnet's route table sends its 0.0.0.0/0 traffic to
the NAT gateway instead of to an internet gateway. The NAT gateway translates
the source address to its own public IP, keeps the translation table, and
returns replies to the originating private instance - inbound connections
initiated from outside are never accepted, only replies to connections the
private instance itself opened.
| Concept | AWS | GCP | Azure |
|---|---|---|---|
| Managed outbound NAT | NAT Gateway | Cloud NAT | NAT Gateway / Virtual Network NAT |
| Placement | Public subnet, one per AZ | Regional, per network/subnet | Regional, associated to subnet |
| IPv6 outbound-only | Egress-only Internet Gateway | N/A (IPv6 handled differently) | N/A (comparable NAT config) |
Egress-only internet gateway (IPv6)
IPv6 addresses are globally routable by design - there's no private RFC 1918 equivalent that needs translating, so you don't run PAT for IPv6 the way you do for IPv4. But you can still want the same policy: instances can initiate outbound IPv6 connections but nothing outside can initiate inbound ones. An egress-only internet gateway provides exactly that - it's stateful like a NAT gateway for the purposes of permitting return traffic, but it does not translate addresses at all, since IPv6 doesn't need it.
The gotcha: NAT gateways are also a cost and scaling unit
Because a NAT gateway lives in one AZ and its subnet's route table points to it, a design that wants AZ-independence needs one NAT gateway per AZ - if you route every private subnet across every AZ to a single NAT gateway in one zone, you've quietly made that one zone a single point of failure and paid a cross-AZ data transfer cost on every packet.
A managed NAT gateway isn't free infrastructure glue - it's a metered resource with an hourly charge and a per-GB processed charge, and it has a per-connection and bandwidth ceiling. Teams that route a large, chatty fleet of instances through a single NAT gateway hit two surprises in production: a NAT gateway data-processing bill that dwarfs the compute bill it's attached to, and port exhaustion - a NAT gateway has a finite pool of source ports per destination, so a service making very high volumes of outbound connections to the same destination IP can start seeing connection failures once every port is in use. The fix is usually to shard traffic across multiple NAT gateways or destinations, not to make one gateway bigger.
Practical takeaways
- Route private-subnet egress through a NAT gateway, never through a direct internet-gateway route - that's what keeps the subnet "private" in the sense defined in VPCs, Subnets & Routing.
- Provision one NAT gateway per AZ if you want a zone failure to be isolated rather than taking down every private subnet's outbound path at once.
- Watch data-processing cost and connection/port limits as first-class capacity concerns, not just an implementation detail - a NAT gateway is infrastructure you can outgrow.