Cloud NAT and Egress
Managed outbound internet — one-way street
Egress is where private workloads touch the internet. Cloud NAT (GCP), NAT gateway (AWS), and Azure NAT/outbound rules provide managed outbound connectivity with stable IPs and cost control.
What you will learn
- Explain why private workloads need NAT for egress
- Configure managed NAT and stable egress IPs
- Trade off NAT vs endpoints for egress cost and security
Private subnets have no inbound internet but often need outbound (updates, APIs). NAT is a managed one-way translator: a pool of egress IPs sources outbound traffic, and unsolicited inbound is impossible. Endpoints are the alternative for service-specific traffic.
What is this?
NAT (GCP Cloud NAT, AWS NAT Gateway, Azure NAT gateway / default outbound) maps private instances to public source IPs for outbound traffic while exposing no inbound. It provides stable egress IPs (useful for allowlists), scales automatically, and costs per hour/GB (some providers bill data processed). Where services have endpoints (S3, DynamoDB, APIs), routing via endpoints avoids NAT egress entirely.
Why do you need it?
- Most private workloads still need reach via internet: OS updates, license servers, external APIs.
- Managed NAT means no NAT box to patch or fail over.
- Stable egress IPs support whitelisting with partners.
- Understanding NAT vs endpoints is a top networking cost question.
Mental model
A office's single outgoing mailbox
NAT gateway
Everyone in the office mails out via one mailbox; incoming mail (unsolicited packages) is not directed at individuals — the mailbox has no inbox. One-way, shared, managed.
How it works
- SNAT: the NAT gateway rewrites source to its IP pool; replies come back and are rewritten to the internal IP.
- AWS/Azure: one NAT per AZ (AZ-scoped); GCP Cloud NAT is regional with per-zone routers.
- Connections scale with elastic IP pool (AWS) or NAT IP addresses (GCP).
- Timeouts: each provider has idle timeout defaults; long-lived connections need tuning.
- Endpoints compete with NAT: gateway/interface endpoints keep service traffic on the backbone.
Egress paths from a private subnet.
In production
- A GKE cluster in private VPC uses Cloud NAT for image pulls from public registries.
- An AWS app uses a NAT gateway per AZ to reach payment APIs while whitelisting egress IPs.
- Azure: AKS workloads egress via NAT gateway with outbound IP allocation for sanctioned services.
Best practices
- One NAT per AZ with routes on each private subnet (avoid single-AZ NAT as a SPOF).
- Prefer endpoints for services to reduce NAT data and latency.
- Whitelist with the egress IP pool; reserve capacity for sudden bursts.
- Monitor NAT metrics (connections, bytes) and alert before exhaustion.
Common mistakes
- Single NAT in one AZ — an AZ loss kills all in-region egress.
- No idle-timeout tuning for long-lived connections.
- Running all egress through NAT when endpoints exist (cost + latency).
- Egress IP exhaustion during a snow-day spike.
Common issues
Private instance can't reach a public APINo default route to NAT, or NAT IP exhausted
Add 0.0.0.0/0 → NAT route and increase/check the egress IP pool.
High NAT data costsService traffic egressing via NAT instead of endpoints
Add endpoints (S3, DynamoDB, KMS, etc.) and update the app's target names.
Debugging tips
- Confirm the subnet's default route actually points to NAT and not IGW.
- For connection stalls, look at NAT connection limits and idle timeout.
- Whitelist drift: partners may cache your egress pool; communicate changes.
- If endpoints exist, verify the app uses the endpoint DNS name.
Interview checkpoint
Hands-on lab
- Model egress volume for NAT vs endpoint paths
- Quantify the cost gap with published formula
- Decide which services deserve endpoints
Compare NAT vs Endpoint Egress Cost
25 min · intermediate
Quick quiz
What does a NAT gateway do for a private instance?