Azure NAT Gateway: Managed Outbound Connectivity
Private VMs that need to reach the internet — to download packages, call external APIs, or send telemetry — need a way out. Assigning public IPs to every VM is expensive and creates unnecessary attack surface. Azure NAT Gateway gives your private VMs shared, managed outbound connectivity with a predictable set of source IPs and no risk of running out of connection ports.
The outbound connectivity problem
In Azure, there are several ways a private VM can reach the internet:
Default outbound (deprecated): Azure used to provide implicit outbound connectivity to VMs without a public IP. This is being retired and should not be relied on for new deployments.
Instance-level public IP: Give each VM its own public IP. Simple, but expensive, and every VM’s IP appears in outbound traffic — making it hard to manage allowlists at external services.
Load balancer outbound rules: Configure outbound NAT through a Standard load balancer. Works, but limited SNAT ports and requires a load balancer to exist for the purpose.
NAT Gateway: A dedicated managed service for outbound connectivity. Predictable source IPs, massive SNAT port scale, zero configuration on VMs, and fully managed by Azure. This is the right answer for most workloads.
Understanding SNAT port exhaustion
When a VM without a public IP makes an outbound internet connection, Azure translates the VM’s private IP to a public IP. This is Source NAT (SNAT). To track multiple concurrent connections from different VMs using the same public IP, Azure uses port numbers. Each connection uses one SNAT port on the public IP.
A single public IP has 64,000 usable ports. If 100 VMs share one public IP and each opens 640 connections simultaneously, the ports are exhausted. New outbound connections fail with timeout errors. Applications see this as slow or failed external API calls, package download failures, or telemetry loss.
NAT Gateway solves this by providing 64,512 ports per associated public IP, and you can attach up to 16 public IPs — giving you over a million SNAT ports. NAT Gateway also manages port allocation efficiently and recycles idle ports faster than the default SNAT behavior.
Creating a NAT Gateway with the CLI
Create a NAT Gateway and associate it with a subnet:
# Create static public IPs for the NAT Gateway (start with one, add more if needed)
az network public-ip create \
--name pip-nat-eastus-001 \
--resource-group rg-prod-networking \
--location eastus \
--sku Standard \
--allocation-method Static \
--zone 1 2 3
# Create the NAT Gateway
az network nat gateway create \
--name natgw-prod-eastus \
--resource-group rg-prod-networking \
--location eastus \
--public-ip-addresses pip-nat-eastus-001 \
--idle-timeout 4Associate the NAT Gateway with a subnet. All outbound traffic from this subnet will use the NAT Gateway:
az network vnet subnet update \
--name snet-app \
--resource-group rg-prod-networking \
--vnet-name vnet-prod-eastus-001 \
--nat-gateway natgw-prod-eastusAdd a second public IP to increase SNAT port capacity:
az network public-ip create \
--name pip-nat-eastus-002 \
--resource-group rg-prod-networking \
--location eastus \
--sku Standard \
--allocation-method Static \
--zone 1 2 3
az network nat gateway update \
--name natgw-prod-eastus \
--resource-group rg-prod-networking \
--public-ip-addresses pip-nat-eastus-001 pip-nat-eastus-002List all NAT Gateways and their associated subnets:
az network nat gateway list \
--resource-group rg-prod-networking \
--output tableShow details including associated public IPs and subnets:
az network nat gateway show \
--name natgw-prod-eastus \
--resource-group rg-prod-networkingNAT Gateway vs alternatives
| Outbound method | SNAT ports | Predictable IPs | Cost | Complexity |
|---|---|---|---|---|
| Instance public IP | 64,000 per VM | Yes (one per VM) | High (per VM IP) | Low |
| Load balancer outbound rules | 1,024 per VM by default | Yes (shared) | Medium | Medium |
| NAT Gateway | 64,512 per IP, up to 16 IPs | Yes (shared, consistent) | Medium (per hour + per GB) | Low |
| Azure Firewall | Very large (SNAT-managed) | Yes | High | High |
NAT Gateway is the right default for most workloads. Use Azure Firewall when you also need outbound traffic inspection and filtering. Use instance public IPs only for VMs that genuinely need inbound connections from the internet.
Monitoring SNAT utilization
Azure Monitor provides metrics for NAT Gateway. The most important one is SNAT Connection Count — if this approaches the total available ports, add another public IP before connections start failing:
# View NAT Gateway metrics (requires az monitor extension)
az monitor metrics list \
--resource /subscriptions/<sub-id>/resourceGroups/rg-prod-networking/providers/Microsoft.Network/natGateways/natgw-prod-eastus \
--metric SNATConnectionCount \
--interval PT1M \
--output tableSet an Azure Monitor alert at 80% SNAT port utilization. Adding a second public IP takes seconds and doubles available SNAT ports. Waiting until ports are exhausted means your application is already dropping connections.
Common mistakes
- Associating NAT Gateway with the AzureFirewallSubnet. Azure Firewall manages its own outbound connectivity and does not support NAT Gateway on its subnet. Attaching a NAT Gateway to the AzureFirewallSubnet causes routing conflicts and deployment failures.
- Not planning for allowlisting at external services. One of NAT Gateway’s benefits is predictable outbound IPs. But if your external partners or SaaS vendors haven’t added those IPs to their allowlists, traffic will be rejected. Communicate the NAT Gateway IPs to any external service that requires IP allowlisting before you cut over.
- Using a single public IP for high-traffic workloads. Each public IP on NAT Gateway provides 64,512 SNAT ports. For an application making thousands of outbound connections per second, a single IP may not be enough. Start with two or three public IPs for any high-throughput workload.
Summary
- NAT Gateway provides managed outbound internet connectivity for private VMs without assigning them individual public IPs.
- It solves SNAT port exhaustion by providing 64,512 SNAT ports per public IP and supporting up to 16 public IPs per gateway.
- Associate a NAT Gateway with a subnet — all outbound internet traffic from that subnet automatically uses the gateway.
- Monitor SNAT Connection Count metrics and add public IPs before exhaustion occurs.
- Do not attach NAT Gateway to the AzureFirewallSubnet — Azure Firewall manages its own outbound NAT.
Frequently asked questions
What is SNAT port exhaustion and how does NAT Gateway fix it?
SNAT (Source Network Address Translation) uses ports on a shared public IP to track outbound connections. When many VMs share a small set of SNAT ports, they run out, causing new outbound connections to fail with ETIMEDOUT errors. NAT Gateway provides 64,512 SNAT ports per public IP and supports up to 16 public IPs — giving you over 1 million SNAT ports.
Can I use a NAT Gateway with a load balancer?
Yes. When both a NAT Gateway and an outbound load balancer rule exist for a subnet, NAT Gateway takes precedence for outbound traffic. This means adding a NAT Gateway to a subnet overrides the load balancer's outbound rules.
Does NAT Gateway affect inbound traffic?
No. NAT Gateway only handles outbound traffic from resources in its associated subnet. Inbound traffic is not affected. Resources still use their public IPs, load balancer frontends, or Private Link for inbound connections.