Cloud NAT and Internet Gateways

Every cloud instance faces a fundamental tension: it needs to reach the Internet (for updates, APIs, external services), but the Internet shouldn't necessarily reach it. Cloud networking solves this with two mechanisms—Internet gateways for instances that need to be found, and NAT gateways for everything else.

The Two Doors

An Internet gateway is a front door. Traffic flows both ways. Instances behind it can reach the Internet, and the Internet can reach them. This is what you want for web servers, load balancers, anything that needs to accept incoming connections.

A NAT gateway is a one-way valve. Traffic flows out but not in. Private instances can initiate connections—download updates, call APIs, send logs—but nothing from the Internet can initiate a connection to them. They're invisible from outside.

This isn't just a networking detail. It's a security architecture. Most of your instances shouldn't be directly addressable from the Internet. Database servers, application backends, batch processors—they need to reach out, not be reached.

How Internet Gateways Work

Internet gateways perform network address translation between your VPC's private addresses and public addresses visible on the Internet.

When an instance with a public IP sends traffic outbound:

1. The packet leaves the instance with a private source IP
2. The Internet gateway rewrites the source to the public IP
3. The packet travels across the Internet
4. Return traffic arrives addressed to the public IP
5. The gateway translates it back to the private IP and delivers it

Cloud providers manage Internet gateways entirely—they're horizontally scaled, redundant, highly available. You attach one to your VPC and route traffic to it. That's it.

Making an Instance Public

For an instance to be reachable from the Internet:

1. Assign a public IP—either ephemeral (changes if the instance stops) or static (persists independently)
2. Route to the gateway—the subnet's route table needs 0.0.0.0/0 pointing to the Internet gateway
3. Allow the traffic—security groups must permit inbound connections on the ports you want

All three are required. Miss one and connections fail silently.

How NAT Gateways Work

NAT gateways sit in public subnets—they have public IPs and routes to the Internet gateway. Private subnets route their Internet-bound traffic to the NAT gateway instead of directly out.

The flow:

1. Private instance sends a packet to an Internet destination
2. Packet routes to the NAT gateway (per the subnet's route table)
3. NAT gateway rewrites the source IP to its own public IP
4. Traffic flows through the Internet gateway to the destination
5. Response returns to the NAT gateway's public IP
6. NAT gateway translates back and delivers to the original instance

The NAT gateway maintains connection state. It knows which internal instance initiated each connection, so it can route responses correctly. But it won't forward unsolicited inbound traffic—there's no connection state to match it against.

NAT gateways are bouncers who only let your friends out. They won't let strangers in.

NAT Gateway vs. NAT Instance

Before managed NAT gateways existed, people ran NAT instances—regular VMs configured to forward and translate traffic. You can still do this. You probably shouldn't.

Managed NAT gateways:

• Scale automatically with traffic
• Are highly available within their availability zone
• Require zero maintenance
• Handle far more bandwidth than typical instances

NAT instances:

• Require you to manage the VM (patching, monitoring, scaling)
• Become single points of failure unless you build redundancy
• Offer more customization (if you need it)
• Can be cheaper for very low traffic volumes

For most workloads, the operational overhead of NAT instances isn't worth the cost savings.

High Availability Patterns

Internet gateways are regionally redundant by default—cloud providers handle this.

NAT gateways vary by provider:

AWS: NAT gateways are zonal. One gateway serves one availability zone. For multi-AZ resilience, deploy a NAT gateway in each zone, with each zone's private subnets routing to their local gateway.

GCP: Cloud NAT is software-defined and regionally redundant automatically.

Azure: NAT Gateway can be zone-redundant when deployed with availability zones.

The AWS pattern is worth understanding even if you use other clouds—it illustrates the general principle. NAT gateways are stateful devices. If one fails, active connections through it break. Multi-zone deployment means a zone failure only affects instances in that zone.

The Cost Reality

NAT gateway costs can surprise you:

• Hourly charge for running the gateway (even with zero traffic)
• Data processing fee per GB flowing through
• Data transfer charges for traffic leaving the cloud to the Internet
• Cross-zone fees when traffic crosses availability zone boundaries

For a high-traffic workload, NAT gateway costs can exceed the compute costs of the instances using it.

Optimization strategies:

• Place NAT gateways in the same zones as the instances using them
• Use VPC endpoints for cloud service access (no NAT needed)
• Consider whether instances actually need Internet access or just access to specific services

The IPv6 Angle

IPv6 makes NAT philosophically unnecessary. Every device can have a globally unique address—no translation required.

Cloud providers offer egress-only Internet gateways for IPv6. Same concept as NAT gateways (outbound yes, inbound no) but without address translation. The instance uses its real IPv6 address; the gateway just enforces directionality.

This is cleaner. It's also not widely adopted yet. Most organizations still run IPv4 internally with NAT gateways, sometimes dual-stacked with IPv6 for external connectivity.

The irony: we built this elaborate NAT infrastructure because IPv4 addresses ran out, and IPv6 has existed for decades with enough addresses for every atom on Earth. The hack became the standard.

VPC Endpoints: Avoiding NAT Entirely

Much of what private instances access isn't actually "the Internet"—it's cloud provider services. S3, databases, APIs, container registries.

VPC endpoints let private instances reach these services without going through NAT gateways:

Gateway endpoints (AWS S3 and DynamoDB) work through route table entries. Traffic to these services routes directly to the endpoint, never touching the NAT gateway.

Interface endpoints create network interfaces in your subnets. Private DNS resolves the service to private IPs, so your application code doesn't change—it just routes internally instead of through NAT.

Using endpoints where possible reduces NAT gateway traffic, lowering costs and keeping traffic on the provider's backbone rather than transiting the public Internet.

Security Model

The security filtering happens in layers:

Private instances have security groups controlling what they can reach and what can reach them.

NAT gateways don't have security groups—they forward whatever the route table sends them. They're transparent to security policy.

Subnet-level controls (network ACLs) can restrict traffic at the subnet boundary, affecting all instances including the NAT gateway.

The practical implication: your security posture comes from instance-level security groups, not from the NAT gateway itself. The NAT gateway provides architectural security (not addressable from outside), not policy security (what traffic is allowed).