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.
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.
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
Here is the failure that makes engineers learn NAT Gateway the hard way. 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 — think 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.
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 — and, for new private subnets, effectively required — way to do outbound. "A NAT gateway on the subnet so the VMs can reach out through one predictable IP without any of them being publicly exposed" is the answer of someone who has debugged a SNAT-exhaustion outage and never wants to again.