1.3 Azure NAT Gateway & Outbound Connectivity
Key Takeaways
- Azure NAT Gateway is a fully managed, software-defined outbound SNAT service associated at the subnet level that provides dynamic, on-demand SNAT port allocation.
- Unlike Azure Load Balancer which assigns a fixed/static number of SNAT ports per instance, NAT Gateway dynamically allocates ports from a shared pool, eliminating SNAT port exhaustion for bursty workloads.
- A single NAT Gateway supports up to 16 Standard Public IP addresses (or a Public IP prefix up to /28), delivering up to 1,024,000 concurrent outbound SNAT flows (64,000 per IP).
- NAT Gateway takes highest routing precedence for outbound internet egress on its assigned subnet, overriding Load Balancer outbound rules and legacy default internet access.
- Microsoft's mandatory architecture milestone permanently retires Default Outbound Access for all new VNets on March 31, 2026, making explicit egress mechanisms mandatory.
Azure NAT Gateway & Outbound Connectivity
Connecting private cloud workloads to internet-hosted APIs, software repositories, and external SaaS endpoints requires Source Network Address Translation (SNAT). SNAT rewrites a virtual machine's private IP and port to a public IP and port, tracking the connection state in a translation table so return packets can be delivered back to the private originator.
Historically, Azure provided implicit outbound internet connectivity (termed Default Outbound Access). However, default access is unmanaged, subject to unpredictable SNAT port exhaustion, and insecure. Azure NAT Gateway provides the modern, scalable, production-standard solution for enterprise egress.
1. The March 31, 2026 Default Outbound Access Retirement
Microsoft has established a fundamental architectural deadline for all cloud network engineers:
[!IMPORTANT] March 31, 2026 Egress Mandate: Effective March 31, 2026, Default Outbound Access is permanently retired for all newly created Virtual Networks. VMs provisioned without an explicit outbound connectivity method (NAT Gateway, User-Defined Route to Azure Firewall/NVA, or Standard Load Balancer Outbound Rules) will have zero outbound internet connectivity.
+-----------------------------------------------------------------------------+
| AZURE OUTBOUND CONNECTIVITY METHODS MATRIX |
| |
| Method Scope SNAT Allocation Recommended Scenario |
| ------------------ ---------- --------------- -------------------- |
| Azure NAT Gateway Subnet Dynamic On-Demand Production Workloads |
| Azure Firewall / NVA Subnet / VNet Stateful / FQDN Security Inspection |
| Public Load Balancer Backend Pool Static Allocated Inbound + Return SNAT |
| Default Access Implicit Static Small Pool RETIRED (Do Not Use) |
+-----------------------------------------------------------------------------+
2. Azure NAT Gateway Architecture & Mechanics
Azure NAT Gateway (Virtual Network NAT) is a distributed, fully managed software-defined service that provides direct outbound internet connectivity for all virtual machines and private endpoints residing in an associated subnet.
+-----------------------------------------------------------------------------+
| AZURE NAT GATEWAY SUBNET ARCHITECTURE |
| |
| [Public Internet] <===================================================+ |
| ^ | |
| | (Static Public IPs: 20.50.10.1, 20.50.10.2 -> 128,000 Ports) | |
| +-------------------------------------------------------------------+ | |
| | Azure NAT Gateway Resource (Zone-Redundant / 50 Gbps Throughput) | | |
| +-------------------------------------------------------------------+ | |
| ^ ^ | |
| | (Associated to Subnet) | (Associated to Subnet) | |
| +--------------------------+ +--------------------------+ | |
| | Subnet: Web-Tier | | Subnet: Worker-Tier | | |
| | - VM-1 (10.0.1.4) | | - Worker-A (10.0.2.4) | | |
| | - VM-2 (10.0.1.5) | | - Worker-B (10.0.2.5) | | |
| | Dynamic SNAT on Demand | | Dynamic SNAT on Demand | | |
| +--------------------------+ +--------------------------+ | |
| |
| NOTE: A Subnet can bind to exactly ONE NAT Gateway. |
| A NAT Gateway can bind to MULTIPLE Subnets within the SAME VNet. |
+-----------------------------------------------------------------------------+
Core Structural Rules:
- Subnet-Level Association: A NAT Gateway is attached directly to one or more subnets within a virtual network. It cannot span multiple VNets.
- One Gateway Per Subnet: A subnet can have at most one NAT Gateway attached.
- No GatewaySubnet Attachment: NAT Gateway cannot be deployed in or attached to a
GatewaySubnet,AzureFirewallSubnet, orAzureFirewallManagementSubnet. - Zone-Resiliency: NAT Gateways can be deployed as Zone-Redundant (automatically spanning availability zones) or pinned to a specific Zonal boundary.
3. SNAT Port Allocation: Static vs. Dynamic On-Demand
Understanding why applications encounter outbound connection drops during high concurrency requires analyzing how SNAT ports are allocated.
The 5-Tuple Connection Flow
Every outbound TCP/UDP session uses a unique 5-tuple:
Each public IP address provides 64,000 ephemeral SNAT ports (ports 1024 through 65535).
Load Balancer Static Allocation vs. NAT Gateway Dynamic Allocation
| Attribute | Azure Standard Load Balancer Outbound | Azure NAT Gateway |
|---|---|---|
| Allocation Model | Static Pre-Allocation: Pre-assigns a fixed number of SNAT ports (e.g., default 1,024) per backend VM instance. | Dynamic On-Demand: Ports are allocated in real time from a shared pool to whatever VM needs them. |
| Port Exhaustion Risk | High: If a single busy VM exhausts its 1,024 allocated ports, its new outbound flows fail immediately—even if other VMs have thousands of unused ports. | Zero Port Waste: A single VM running bursty microservice calls can consume all 64,000 ports across the entire pool without artificial per-VM ceilings. |
| Idle Timeout | 4 to 30 minutes (TCP) | 4 minutes (default), configurable up to 120 minutes for long-lived flows. |
| TCP Reset (RST) | Configurable on idle timeout | Sends bidirectional TCP RST on idle timeout to cleanly tear down dead client/server sockets. |
4. Scaling Capacity & Public IP Prefixes
A single Azure NAT Gateway can scale outbound egress to massive enterprise levels:
- Public IP Scaling: You can attach up to 16 Standard Public IP addresses or a Public IP Prefix (up to
/28) to a single NAT Gateway. - Concurrent Flow Capacity:
- Throughput Performance: Scales automatically up to 50 Gbps of total outbound data transfer without manual bandwidth provisioning.
5. Routing Precedence & Inbound/Outbound Asymmetry
When multiple network services coexist on the same subnet, Azure evaluates outbound routing according to strict precedence rules:
+-----------------------------------------------------------------------------+
| OUTBOUND ROUTING PRECEDENCE ORDER |
| |
| 1. User-Defined Route (UDR) pointing 0.0.0.0/0 to Virtual Appliance / FW |
| 2. Azure NAT Gateway (Overrides Load Balancer & Default Outbound) |
| 3. Instance-Level Public IP (Standard PIP directly on VM NIC) |
| 4. Azure Load Balancer Outbound Rules |
| 5. Default Outbound Access (Deprecated / Retired) |
+-----------------------------------------------------------------------------+
Inbound / Outbound Asymmetric Flow Handling
When a VM sits behind a Public Standard Load Balancer (for inbound web traffic) and its subnet is attached to a NAT Gateway (for outbound egress):
- Inbound Connections: Traffic arriving through the Load Balancer's public frontend IP is returned back through the Load Balancer's connection tracking table, maintaining flow symmetry.
- New Outbound Connections: Traffic initiated by the VM to external APIs egresses through the NAT Gateway's public IP, fully separating inbound application traffic from outbound operational traffic.
An e-commerce application deployed on 20 virtual machines behind an Azure Standard Load Balancer experiences intermittent HTTP connection timeouts during peak flash sales when calling a third-party credit card gateway. Network metrics show that only 2 of the 20 VMs are experiencing drops, while the remaining 18 VMs have almost no outbound traffic. What is the root cause and the optimal Azure architectural remedy?
A subnet hosting a cluster of web servers is configured with both an Azure NAT Gateway (attached to the subnet) and an Azure Standard Public Load Balancer with inbound load balancing rules for port 443. How does Azure handle network traffic routing for inbound customer requests versus outbound software update requests initiated by the web servers?
An enterprise financial application running in an Azure subnet must establish up to 300,000 concurrent outbound TCP sessions to external market data streaming endpoints. What is the minimum number of Standard Public IP addresses that must be assigned to the subnet's Azure NAT Gateway to support this connection load?