Azure NAT Gateway

Azure NAT Gateway: predictable outbound without a public IP on every VM

Your VMs need to reach the internet to pull updates, call an API, or download a package — but you do not want each one wearing a public IP like a target on its back. Azure NAT Gateway is the one managed resource that gives a whole subnet a clean, private way out, and it quietly solves a scaling bug most people only meet at 2am.

New to cloud? CAMPUX is a free, build-first course. Start here →

Outbound connectivity sounds like the boring half of networking until it breaks. Azure NAT Gateway is Microsoft's answer, and their one-line framing is exactly right: it is "a fully managed and highly resilient network address translation (NAT) service" that lets "all instances in a subnet connect outbound to the internet while remaining fully private." Attach it to a subnet, give it a public IP, and every VM in that subnet can reach out — with no public IP of its own.

Private out, nothing in

The direction is the whole point. A NAT gateway is a one-way valve: it lets your resources start connections to the internet, and it lets the responses come back — but it "doesn't permit unsolicited inbound connections from the internet." Only packets that are replies to a flow your VM opened can pass. So your machines get to download the update and call the API, while the internet gets no way to knock on their door. Outbound is a NAT gateway's entire job; inbound is simply not something it does.

Figure — A NAT gateway gives resources in a private subnet a way out to the internet without exposing them to it. VMs with only private IPs send outbound traffic through the gateway, which source-NATs it behind one (or a few) stable public IPs — so external services see a predictable address you can allow-list, and you get a large, managed pool of SNAT ports that avoids port-exhaustion. It is outbound only: nothing on the internet can initiate a connection back in.

Static IPs you can put on an allowlist

Because all outbound traffic from the subnet leaves through the NAT gateway's public IP (or a small, fixed set of them), you get something operationally precious: a predictable outbound address. A partner who needs to allowlist your traffic can add that one IP — or the contiguous block from a public IP prefix — and be done. Compare that to VMs with their own ever-changing public IPs, where the "what IP are we coming from?" question has no stable answer. One managed resource turns outbound identity from a moving target into a fixed fact.

A NAT gateway is a one-way valve: your VMs can reach out, the replies come back, and the internet never gets a way in.

The problem it really solves: SNAT port exhaustion

Engineers tend to learn NAT Gateway the hard way, through this exact failure. Every outbound connection needs a SNAT port, a translation slot on the shared public IP. The older ways of getting outbound (default outbound access, or a load balancer's outbound rules) give you a limited, fixed budget of these ports. A chatty workload, say a swarm of microservices hammering an external API, burns through them, and when they run out, new connections just fail, intermittently and maddeningly. NAT Gateway's design directly targets this: it "dynamically allocates secure (SNAT) ports to automatically scale outbound connectivity and minimize the risk of SNAT port exhaustion," drawing from a large pool and assigning ports on demand. If you have ever chased a phantom "connection timed out" that only appears under load, this is often the cure.

Why it is now the default answer for outbound

Microsoft explicitly recommends NAT Gateway as the method for outbound connectivity, and the ground has shifted underneath the alternatives: as of 31 March 2026, new virtual networks default to private subnets and no longer get free "default outbound access" — you must choose an explicit method. NAT Gateway is that method. It is fully managed and scaled out from creation (no ramp-up), needs no route-table configuration (attach it and outbound works immediately), and it takes precedence over other outbound paths like a load balancer or instance-level public IPs. The Standard SKU lives in a single availability zone; the newer StandardV2 is zone-redundant with higher throughput.

How it sits next to the load balancer

A point that trips people up: a load balancer and a NAT gateway are not competitors, because they face opposite directions. A load balancer is about inbound — spreading incoming connections across your VMs. A NAT gateway is about outbound — giving those same VMs a clean way to reach the internet. A real architecture often uses both: the load balancer at the front taking requests in, the NAT gateway at the back letting the workload call out. When both are present on a subnet, NAT Gateway takes priority for new outbound flows — which is exactly what you want, since it is the one built to not run out of ports.

The takeaway

Azure NAT Gateway gives an entire subnet outbound internet access through static, allowlist-friendly public IPs while keeping every VM private and closed to inbound. It is fully managed, scales its SNAT ports dynamically so a busy workload does not exhaust them, and it is now the recommended way to do outbound, effectively required for new private subnets. "A NAT gateway on the subnet so the VMs can reach out through one predictable IP without any of them being publicly exposed" is what you write down once you have chased a random connection failure under load back to exhausted ports and resolved never to relive that afternoon.

Questions people also ask

What is Azure NAT Gateway used for?

It gives every VM in a subnet outbound internet access through a shared, static public IP, without any VM holding a public IP of its own. VMs stay fully private and closed to inbound traffic while still being able to reach out for updates, package downloads, or external APIs. Attach it to a subnet and outbound works immediately, with no route-table changes.

Does Azure NAT Gateway replace the load balancer?

No. They face opposite directions. A load balancer distributes inbound connections across your VMs; a NAT gateway handles outbound connections those VMs make to the internet. Many architectures use both together — load balancer in front for inbound, NAT gateway behind it for outbound. When both sit on a subnet, NAT gateway takes priority for new outbound flows.

How much does Azure NAT Gateway cost?

You pay an hourly rate for the resource plus a per-gigabyte data processing charge, and a Standard Load Balancer with outbound rules is generally cheaper on both counts. The tradeoff is SNAT capacity: NAT gateway supports up to 64,000 ports per IP versus roughly 1,024 pre-allocated per VM on a load balancer, so it costs more but scales outbound connections much further before failing.

What is SNAT port exhaustion in Azure?

Every outbound connection consumes a SNAT port, a translation slot on the shared public IP. Older outbound methods hand each VM a small, fixed allocation of these ports. A chatty workload burns through its share, and once exhausted, new outbound connections fail intermittently. NAT gateway avoids this by dynamically allocating ports from a large shared pool across the whole subnet on demand.

Is Azure NAT Gateway zone redundant?

It depends on the SKU. The Standard SKU lives in a single availability zone, so it is not zone redundant on its own. The newer StandardV2 SKU is zone-redundant, offers higher throughput, and adds IPv6 and flow log support. Choose StandardV2 when the design needs the NAT gateway itself to survive a zone failure.