Azure NAT Gateway

Azure NAT Gateway is a fully managed, elastically scalable, and highly available Network Address Translation (NAT) service that allows all instances in a private subnet to connect outbound to the internet while preventing inbound connections from the internet. It uses Source Network Address Translation (SNAT) to map private IP addresses to one or more public IP addresses, enabling thousands of concurrent outbound flows per public IP.

NAT Gateway is a regional resource that can be attached to up to 10 subnets within the same virtual network. It does not require any routing configuration beyond default routes – once attached to a subnet, the subnet's route table automatically gets a default route (0.0.0.0/0) with the NAT Gateway as the next hop (though this is implicit, not a user-defined route).

Before NAT Gateway, outbound connectivity in Azure was provided by: - Azure Load Balancer outbound rules – required a load balancer and incurred costs even if not used for inbound traffic. - Azure Firewall – expensive and overkill for simple outbound-only scenarios. - Instance-level Public IPs – each VM got its own public IP, which is insecure and hard to manage. - Default outbound access – Azure provides temporary public IPs for VMs without public IPs, but these are not predictable and have SNAT port exhaustion risks.

NAT Gateway solves these problems by providing a dedicated, scalable, and secure outbound connectivity solution. It is the recommended method for outbound connectivity in Azure (as per Azure best practices).

When a VM in a subnet attached to a NAT Gateway initiates an outbound connection, the following happens:

This process is transparent to the VM. The VM never knows its source IP was translated.

Create NAT Gateway via Azure CLI:

az network nat gateway create \
  --resource-group myResourceGroup \
  --name myNATGateway \
  --location eastus \
  --public-ip-addresses myPublicIP \
  --idle-timeout 10

Attach to a subnet:

az network vnet subnet update \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name mySubnet \
  --nat-gateway myNATGateway

Verify outbound IP:

az vm run-command invoke \
  --resource-group myResourceGroup \
  --name myVM \
  --command-id RunPowerShellScript \
  --scripts "(Invoke-WebRequest -Uri https://api.ipify.org).Content"

Check SNAT port usage (metrics):

Azure Monitor metrics: SNATConnectionCount, TotalConnectionCount, DroppedPackets.

A large e-commerce company runs thousands of VMs in a virtual network that need to fetch product data from external APIs and send analytics to third-party services. Previously, they used a Standard Load Balancer with outbound rules, but managing the load balancer for outbound-only traffic was costly and complex. They migrated to Azure NAT Gateway with 16 public IPs to handle over 1 million concurrent connections. They configured idle timeout to 10 minutes to avoid port exhaustion during long-lived API calls. The NAT Gateway automatically scales to handle spikes during Black Friday. The team monitors SNATConnectionCount metric and set alerts when usage exceeds 80%. One issue they faced: initially they forgot to remove the load balancer's outbound rules, causing dual NAT and asymmetric routing. They resolved by disabling outbound rules on the load balancer and ensuring only NAT Gateway is attached to the subnet.

A healthcare provider needs to send patient data to a cloud-based EHR system via HTTPS. They require a fixed outbound IP for firewall whitelisting. They deployed a NAT Gateway with a single public IP (static). They attached it to the subnet hosting the application VMs. To ensure security, they locked down NSGs to only allow outbound to the EHR's IP on port 443. They also enabled TCP reset on idle timeout to immediately close stale connections. The challenge was that the EHR system required a dedicated outbound IP, and using NAT Gateway was simpler than reserving a public IP per VM. They also needed to ensure high availability; they deployed the NAT Gateway as zone-redundant. In production, they monitor for dropped packets due to SNAT port exhaustion; they have a runbook to add additional public IPs if needed.

A common mistake is attaching NAT Gateway to a subnet that already has a route table with a default route (0.0.0.0/0) pointing to Azure Firewall. The NAT Gateway's implicit route does not override the UDR. Traffic still goes through the firewall, bypassing NAT Gateway. To fix, either remove the UDR or ensure the firewall is the intended next hop. Another misconfiguration: using Basic SKU public IPs (not supported). The NAT Gateway creation will fail. Also, forgetting that NAT Gateway does not support inbound connections; if a VM needs to be accessed from the internet, a separate inbound method (like Load Balancer) is required.