What Is a NAT Gateway?

A NAT gateway is a managed cloud service that lets resources in a private subnet — with no public IP addresses of their own — initiate outbound connections to the internet, while remaining completely unreachable from inbound internet traffic. It sits in a public subnet, translates traffic from private instances to a shared public IP, and routes replies back to whichever instance made the request. It’s the standard answer to “how does a database in a private subnet download a security patch?”

Why private resources still need outbound access

Putting a resource in a private subnet — no direct route to or from the public internet — is a core building block of a secure VPC design. It means nothing on the internet can initiate a connection to that resource directly. But “no inbound access” doesn’t mean the resource never needs to talk to the outside world: it still needs to pull OS and package updates, call third-party APIs, ship logs to an external service, or reach a managed service that lives outside the VPC. A NAT gateway gives it a one-way door — out, never in.

How the translation works

NAT stands for network address translation. The private instance sends a packet addressed to some public destination, sourced from its own private IP. The NAT gateway intercepts it, rewrites the source address to its own public IP (and tracks the mapping in a connection table), and forwards the packet on. When the response comes back addressed to the NAT gateway’s public IP, the gateway looks up the connection table, rewrites the destination back to the original private IP, and delivers it.

From the private instance’s point of view, it just made an outbound request like any other. From the internet’s point of view, every request from every instance behind the NAT gateway appears to originate from the same shared public IP — the private addresses are never exposed.

Private subnet                Public subnet              Internet
[ EC2 / VM ] --outbound-->  [ NAT gateway ] -------->  [ external API ]
  10.0.1.5                    public IP                 
              <--response--                <--response--

NAT gateway vs internet gateway vs bastion host

These three are easy to confuse because they all sit at the edge of a VPC, but they solve different problems:

	Internet gateway	NAT gateway	Bastion host
Direction	Bidirectional	Outbound only, from private subnets	Inbound, for human administrative access
Used by	Resources with public IPs	Resources with only private IPs	Operators who need to reach private instances
Purpose	Full internet connectivity	Outbound-only internet access	Controlled entry point for SSH/RDP

An internet gateway is what gives a public subnet bidirectional internet access at all — a NAT gateway actually depends on one, since it needs a route out to the internet itself. A bastion host solves a completely different problem: giving a human operator a single, tightly controlled entry point to reach private instances for administration, rather than giving private instances a way to reach the internet.

Managed NAT gateway vs a NAT instance

Cloud providers generally offer this as a managed service — you attach it to a subnet and configure routing, and the provider handles scaling, patching, and availability. The older pattern was running a “NAT instance” — a regular virtual machine configured to forward and translate traffic — which required you to manage its capacity, patch it, and handle failover yourself. Managed NAT gateways exist specifically to remove that operational burden, at the cost of being less customizable than a self-managed instance.

What happens without one

It’s worth being concrete about the failure mode a NAT gateway prevents. Skip it, and a private instance has no route to the internet at all — package managers can’t reach their repositories, outbound webhooks fail, and any managed service reached over the public internet becomes unreachable, even though the instance itself might be running perfectly. The usual first symptom is a deployment or provisioning script that hangs on a package install with no obvious error, because the request never leaves the private subnet. Adding a NAT gateway and pointing the private subnet’s route table at it is typically the fix — the private subnet’s own route table needs an explicit default route to the NAT gateway, separate from the public subnet’s route to the internet gateway.

Availability and cost considerations

A NAT gateway is typically deployed per availability zone: resources in a given zone route through the NAT gateway in that same zone, so if the zone goes down, so does its NAT gateway. High-availability designs deploy one NAT gateway per zone rather than a single shared one, trading some cost for the redundancy — the same tradeoff that shows up throughout multi-cloud and hybrid architectures, where availability and cost pull in opposite directions. Since a NAT gateway processes and translates every byte of outbound traffic from its subnet, it’s also usually billed by data processed, not just by the hour — worth checking before routing a high-throughput workload through one. If you need to reason through subnet layouts while designing around a NAT gateway, our free subnet calculator can help work out the ranges.

The takeaway

A NAT gateway gives private-subnet resources one-way outbound internet access by translating their private IPs to a shared public one, without ever exposing them to inbound traffic. It depends on an internet gateway to reach the internet at all, solves a different problem than a bastion host, and is usually deployed per availability zone for resilience. For anything in a private subnet that needs to phone out — but never wants to be called — it’s the standard piece of the puzzle.