This chapter covers Azure NAT Gateway, a fully managed and resilient outbound connectivity service for virtual networks. For the AZ-305 exam, understanding when to use NAT Gateway versus other outbound methods (like Azure Load Balancer outbound rules or Azure Firewall) is critical, as questions appear in the 'Design for Network Solutions' domain (objective 4.2). Approximately 5-10% of exam questions touch on outbound connectivity patterns, and NAT Gateway is a key design choice for scalable, production-grade architectures.
Jump to a section
NAT Gateway is like a company with one public phone number and 200 employees with internal extensions. When an employee calls out, the receptionist records which extension placed the call and replaces the internal extension with the company's public number. When the response comes back, she looks up the log and routes it to the correct extension. From outside, nobody can dial employees directly — they only ever see the company number. Critically, the receptionist does not store the mapping indefinitely; after a short time (e.g., 4 minutes for TCP) without activity, she forgets the mapping, and any late response goes unanswered. The receptionist also cannot handle an unlimited number of simultaneous calls — she has a finite switchboard capacity (ports). If all lines are busy, new calls are dropped. Unlike a PBX, she does not accept incoming calls that were not preceded by an outbound call. This mirrors NAT Gateway's stateful translation: it uses SNAT port exhaustion, configurable idle timeouts (default 4 min TCP, 2 min UDP), and only allows outbound-initiated traffic.
What is Azure NAT Gateway and Why It Exists
Azure NAT Gateway provides outbound-only connectivity for virtual networks. It translates private IP addresses of resources (VMs, VMSS, etc.) to a public IP address or prefix, enabling outbound internet access while preventing inbound connections from the internet. This is a fundamental requirement for many workloads that need to download updates, communicate with external APIs, or send telemetry.
Before NAT Gateway, Azure resources used default outbound access (implicit SNAT) via the platform's shared public IPs, or you configured outbound rules on a Load Balancer. Both approaches had limitations: default outbound access had no guaranteed performance and was not under your control; Load Balancer outbound rules tied SNAT to load balancing rules and had port exhaustion issues. NAT Gateway solves these problems by providing dedicated, scalable, and predictable outbound connectivity.
How NAT Gateway Works Internally
NAT Gateway is a regional, zonal (or zone-redundant) resource that operates at the subnet level. It uses Source Network Address Translation (SNAT) to map private IP:port pairs to the public IP:port of the NAT Gateway. The translation is stateful: the gateway maintains a mapping table (conntrack) that records outbound flows. When a response packet arrives, the gateway looks up the mapping and forwards it to the original private source.
Packet Flow Step-by-Step:
A VM in a subnet with NAT Gateway sends a TCP SYN packet to an internet destination (source IP 10.0.0.4:12345, dest IP 203.0.113.5:80).
The packet hits the NAT Gateway. The gateway selects an available SNAT port from its pool (associated with the public IP). It creates a mapping: (10.0.0.4:12345 ↔ public IP:SNAT port).
The gateway rewrites the source IP and port to the public IP and the chosen SNAT port, then forwards the packet to the internet.
The destination responds to the public IP:SNAT port.
The NAT Gateway receives the response, looks up the SNAT port in its mapping table, and rewrites the destination to 10.0.0.4:12345.
The packet is forwarded to the VM.
Key Components and Defaults:
Public IP or Prefix: NAT Gateway can be associated with a standard SKU public IP or a public IP prefix (up to 16 IPs). Using a prefix provides a larger pool of SNAT ports (64,512 per IP).
Subnet Association: NAT Gateway is attached to one or more subnets. All outbound traffic from resources in those subnets uses the NAT Gateway. Only one NAT Gateway can be attached to a subnet, but a NAT Gateway can serve multiple subnets.
SNAT Port Pool: Each public IP provides 64,512 SNAT ports (ports 1024-65535, minus the first 64 reserved). For a prefix with N IPs, the total ports = N * 64,512. Ports are dynamically allocated per flow.
Idle Timeout: Default is 4 minutes for TCP, 2 minutes for UDP. Can be configured between 4 and 120 minutes. After the timeout, the mapping is removed, and subsequent packets may be dropped.
TCP Reset: When enabled (default off), NAT Gateway sends a TCP RST to the private resource when a mapping times out or is reclaimed. This helps applications detect broken connections faster.
Scaling: NAT Gateway automatically scales out to handle up to 1 million concurrent flows per public IP (per gateway). There is no manual scaling or SKU selection; it scales based on demand.
Configuration and Verification
NAT Gateway is deployed via Azure Portal, CLI, or PowerShell. Example CLI deployment:
# Create a public IP
az network public-ip create --resource-group MyRG --name MyPublicIP --sku Standard
# Create NAT Gateway
az network nat gateway create --resource-group MyRG --name MyNATGateway --public-ip-addresses MyPublicIP --idle-timeout 10
# Associate with subnet
az network vnet subnet update --resource-group MyRG --vnet-name MyVNet --name MySubnet --nat-gateway MyNATGatewayVerification commands:
# Check NAT Gateway metrics (in Azure Monitor)
# Key metrics: SNAT Connection Count, SNAT Port Allocation, Packets Count
# Use Azure Network Watcher to trace flows
az network watcher show-flow-log --resource-group MyRG --nsg MyNSGInteraction with Related Technologies
Azure Firewall: NAT Gateway can be used in combination with Azure Firewall for outbound traffic. Typically, you place Azure Firewall in a hub VNet and route traffic through it, while NAT Gateway is used for direct outbound from spoke VNets. However, they can conflict if both are applied to the same subnet — only one outbound method should be used per subnet.
Load Balancer (Standard): Load Balancer outbound rules also provide SNAT but are tied to the backend pool and load balancing rules. NAT Gateway is simpler and more scalable when you only need outbound connectivity without load balancing.
Private Endpoints: Resources using Private Endpoints do not need outbound internet access through NAT Gateway for the private endpoint traffic; they use private IPs. However, if those resources also need internet access, NAT Gateway can be used.
VNet Peering: NAT Gateway is not transitive across peered VNets by default. If you want outbound from a peered VNet to use a NAT Gateway in the hub, you must configure User-Defined Routes (UDRs) to send traffic to the hub's NAT Gateway.
Performance and Limits
Port Exhaustion: The primary failure mode is SNAT port exhaustion. Each flow (TCP connection or UDP datagram) consumes a port. If the pool is exhausted, new connections fail. Mitigation: use a larger public IP prefix, reduce idle timeout, or use connection pooling.
Throughput: NAT Gateway can scale up to 50 Gbps aggregate throughput per gateway. No manual scaling is required.
Concurrent Flows: Up to 1 million per public IP, up to 2 million per gateway with multiple IPs.
Availability: Zone-redundant by default (if deployed in a region that supports availability zones). Can be pinned to a specific zone for zonal workloads.
Edge Cases
TCP RST on Idle Timeout: If enabled, NAT Gateway sends a RST to the private resource when the mapping times out. This can cause application errors if the application expects to reuse idle connections. Disable TCP Reset if needed.
Asymmetric Routing: If a subnet has both NAT Gateway and another outbound method (e.g., default route to Azure Firewall), traffic may be asymmetrically routed. Ensure only one outbound path per subnet.
ICMP: NAT Gateway translates ICMP (e.g., ping) but only for echo requests. Fragmented ICMP may not be supported.
Exam Relevance
For AZ-305, you must know when to choose NAT Gateway over other outbound options. The exam tests your ability to design outbound connectivity that meets requirements for scalability, security, and cost. Key scenarios: large-scale internet access from many VMs, avoiding SNAT port exhaustion, and needing a stable outbound public IP. You should also understand the interaction with Azure Firewall and how to design a hub-and-spoke topology with NAT Gateway for outbound traffic.
Create Public IP or Prefix
First, you must provision a Standard SKU public IP resource or a public IP prefix. A public IP prefix allows you to reserve a contiguous block of IPs (e.g., /28 = 16 IPs) for larger SNAT port pools. Each IP provides 64,512 SNAT ports. The public IP must be created in the same region as the NAT Gateway. This step is critical because the NAT Gateway cannot function without an associated public IP. In the Azure Portal, you create the resource with a name and SKU (Standard). The SKU must be Standard; Basic SKU is not supported. The IP address is allocated when the resource is created (for a static IP) or on first use (for dynamic). For production, use static to ensure the IP doesn't change.
Create NAT Gateway Resource
Next, create the NAT Gateway resource itself. You specify the region, availability zone (if required), and idle timeout. The idle timeout defaults to 4 minutes for TCP and 2 minutes for UDP, but you can set it between 4 and 120 minutes. You also associate the public IP or prefix created in step 1. You can associate multiple public IPs or a prefix. The NAT Gateway automatically distributes traffic across all associated IPs. Optionally, enable TCP Reset, which sends a TCP RST packet to the private resource when an idle connection times out. This helps applications detect broken connections faster but may cause issues with long-lived idle connections. The NAT Gateway resource itself has no cost; you pay only for data processed and the public IP.
Attach NAT Gateway to Subnet
The NAT Gateway must be attached to one or more subnets within a virtual network. This is done by updating the subnet configuration. Once attached, all outbound traffic from resources in that subnet (except traffic to Azure services via Private Link or service endpoints) will flow through the NAT Gateway. You can attach a single NAT Gateway to multiple subnets, but a subnet can only have one NAT Gateway. If you need different outbound configurations for different subnets, create separate NAT Gateways. This step is performed via the subnet's properties in the portal or using CLI/PowerShell. After attachment, existing resources in the subnet will immediately use the NAT Gateway for new outbound connections. Existing connections may continue using the previous path until they are re-established.
Configure Routing (if needed)
NAT Gateway automatically becomes the default route (0.0.0.0/0) for the subnet. No explicit User-Defined Routes (UDRs) are required. However, if you have a hub-and-spoke topology and want outbound traffic from a spoke to go through a NAT Gateway in the hub, you must add a UDR in the spoke subnet to send 0.0.0.0/0 traffic to the hub's NAT Gateway (via the hub's virtual appliance IP). Similarly, if you have forced tunneling (e.g., VPN to on-premises), you may need to adjust routes to ensure internet traffic goes to the NAT Gateway instead of the VPN. NAT Gateway does not support IP forwarding or being used as a next hop in a route table; it is a transparent service. The routing is handled by the platform.
Monitor and Scale
After deployment, monitor SNAT port usage and connection metrics via Azure Monitor. Key metrics: SNAT Connection Count (current number of SNAT connections), SNAT Port Allocation (percentage of ports used), and Packets Count. If SNAT Port Allocation approaches 100%, you may experience connection failures. Mitigations: increase the number of public IPs (add more to the NAT Gateway), reduce idle timeout, or use connection pooling at the application level. NAT Gateway automatically scales out to handle traffic up to 50 Gbps and 1 million concurrent flows per public IP. No manual scaling is needed. For high availability, deploy a zone-redundant NAT Gateway (if region supports zones) or pin to a specific zone for zonal workloads. The service is managed by Azure and has a 99.95% SLA.
Scenario 1: Large-Scale Web Application with Outbound API Calls
A SaaS company runs thousands of VMs in a Virtual Machine Scale Set (VMSS) that need to call external payment APIs. Each VM makes hundreds of short-lived HTTPS connections per minute. Without NAT Gateway, they used default outbound access, which caused frequent SNAT port exhaustion and dropped connections during peak hours. They deployed a NAT Gateway with a /28 public IP prefix (16 IPs), providing 16 * 64,512 = 1,032,192 SNAT ports. They set the idle timeout to 5 minutes to balance port reuse and connection reliability. They also enabled TCP Reset to quickly close stale connections. The result: zero connection failures due to port exhaustion, and the NAT Gateway automatically scaled to handle the load. They monitor SNAT Port Allocation metric, keeping it below 80% for headroom.
Scenario 2: Hub-and-Spoke Network with Centralized Outbound
A financial services company uses a hub-and-spoke topology with Azure Firewall in the hub for inbound traffic inspection. They want outbound internet traffic from spoke VNets to also go through a NAT Gateway in the hub to provide a stable outbound IP for whitelisting with third-party services. They deploy a NAT Gateway in the hub VNet, associated with a public IP. In each spoke subnet, they add a UDR: 0.0.0.0/0 next hop to the NAT Gateway's private IP (the NAT Gateway has a private IP in the hub subnet). However, they discovered that NAT Gateway does not support being a next hop in a UDR; they needed to route traffic to an Azure Firewall first, which then forwards to the NAT Gateway. Alternatively, they attached the NAT Gateway directly to the spoke subnets, but that required multiple NAT Gateways. They settled on a design where each spoke has its own NAT Gateway for outbound, and the hub handles inbound traffic via Azure Firewall. This avoided complexity but increased cost.
Scenario 3: Gaming Platform with Real-Time UDP Traffic
A gaming company uses UDP for real-time player communication. They need low-latency outbound connectivity from game servers to a matchmaking service. They chose NAT Gateway because it supports UDP translation with a 2-minute idle timeout (configurable). They deployed a zone-redundant NAT Gateway to survive zone failures. They also enabled TCP Reset (though not used for UDP). They monitored SNAT port usage and found that UDP flows consumed ports quickly due to the short timeout. They increased the public IP count to 4 (providing 258,048 ports). They also implemented application-level keep-alives to prevent idle timeout. The NAT Gateway handled millions of concurrent UDP flows without issues. A common misconfiguration they avoided was not using a prefix; using individual IPs would have required managing multiple resources.
What AZ-305 Tests on NAT Gateway
The AZ-305 exam objective 4.2 focuses on 'Design for outbound connectivity' and evaluates your ability to choose the appropriate outbound method: NAT Gateway, Azure Load Balancer outbound rules, Azure Firewall, or default outbound access. Exam questions will present a scenario with specific requirements (e.g., need for a static IP, high connection counts, security requirements, cost constraints) and ask you to recommend the best solution.
Common Wrong Answers and Why Candidates Choose Them
Choosing Load Balancer outbound rules over NAT Gateway when the requirement is simply outbound internet access from many VMs. Candidates often pick Load Balancer because they are familiar with it. However, Load Balancer outbound rules are designed for scenarios where you already need a Load Balancer for inbound traffic. Using Load Balancer solely for outbound adds unnecessary complexity and ties SNAT to the backend pool. NAT Gateway is simpler, more scalable, and has no inbound dependency.
Selecting Azure Firewall as the outbound method when the requirement does not include inspection or filtering. Azure Firewall can provide outbound connectivity via SNAT, but it is more expensive and adds latency. If the scenario only needs a stable outbound IP and high performance, NAT Gateway is the better choice. Candidates over-engineer by choosing Firewall for security even when no inspection is needed.
Assuming NAT Gateway supports inbound connections. A common trap: questions describe a need for both inbound and outbound connectivity. NAT Gateway is outbound-only. If inbound is required, you need a Load Balancer or Application Gateway in addition to NAT Gateway. Candidates may incorrectly choose NAT Gateway for both directions.
Misunderstanding SNAT port exhaustion and scaling. Some candidates think NAT Gateway has a fixed port limit per gateway (like Load Balancer). In reality, it scales with the number of public IPs. They may choose a single IP when the scenario requires thousands of connections, leading to port exhaustion. The correct approach is to use a public IP prefix.
Specific Numbers and Terms on the Exam
Default idle timeout: 4 minutes for TCP, 2 minutes for UDP.
SNAT ports per public IP: 64,512.
Maximum concurrent flows per public IP: 1 million.
Maximum throughput per gateway: 50 Gbps.
NAT Gateway supports Standard SKU public IPs only.
It can be zone-redundant or zonal.
It does not support IP forwarding or being used as a next hop in UDRs.
Edge Cases and Exceptions
Forced tunneling: If you have forced tunneling (all internet traffic goes to on-premises via VPN/ExpressRoute), NAT Gateway will not be used for internet traffic unless you add a UDR to override the forced tunnel for internet traffic. The exam may test this.
Service endpoints and Private Link: Traffic to Azure services using service endpoints or Private Link does not go through NAT Gateway. The exam expects you to know that NAT Gateway only handles traffic destined to the internet.
Multiple NAT Gateways per VNet: You can have multiple NAT Gateways, each attached to different subnets. This is useful for segmenting outbound traffic by security requirements.
How to Eliminate Wrong Answers
Identify the primary requirement: is it only outbound? If yes, eliminate options that provide inbound (Load Balancer, Application Gateway).
Check if security inspection is needed. If not, eliminate Azure Firewall.
Look for scale requirements: if many VMs or high connection counts, NAT Gateway with a prefix is best. Load Balancer may have port exhaustion issues.
If the scenario mentions 'stable outbound IP', ensure the chosen method supports static public IPs. NAT Gateway does; default outbound does not.
If cost is a concern, default outbound is cheapest but not scalable; NAT Gateway is moderately priced; Firewall is expensive.
NAT Gateway is a fully managed outbound-only connectivity service for Azure subnets.
Each associated public IP provides 64,512 SNAT ports; use a prefix for larger pools.
Default idle timeout is 4 minutes for TCP and 2 minutes for UDP; configurable from 4 to 120 minutes.
NAT Gateway automatically scales to up to 50 Gbps throughput and 1 million concurrent flows per public IP.
It only supports Standard SKU public IPs; Basic SKU is not compatible.
NAT Gateway cannot be used for inbound connections; it is outbound-only.
A subnet can only have one NAT Gateway attached, but one NAT Gateway can serve multiple subnets.
Traffic to Azure services via service endpoints or Private Link bypasses NAT Gateway.
NAT Gateway does not support IPv6; only IPv4.
For hub-and-spoke outbound, you must attach NAT Gateway to spoke subnets or use UDRs to route to a central NAT Gateway (but NAT Gateway cannot be a next hop).
These come up on the exam all the time. Here's how to tell them apart.
Azure NAT Gateway
Dedicated outbound-only service; no inbound dependency.
Automatically scales up to 50 Gbps and 1M flows per IP.
Supports public IP prefixes for large port pools.
Simple configuration: attach to subnet, no load balancing rules needed.
Cost: pay only for data processed and public IPs.
Azure Load Balancer Outbound Rules
Outbound rules are part of a Standard Load Balancer; requires inbound rules if needed.
SNAT port pool is tied to backend pool size; limited to 64,512 ports per load balancer frontend IP.
Cannot use public IP prefixes; only individual IPs.
More complex: requires backend pool, health probes, and load balancing rules even if only outbound is needed.
Cost: Load Balancer hourly fee plus data processing; may be cheaper for low volume but less scalable.
Mistake
NAT Gateway can be used for inbound traffic as well as outbound.
Correct
NAT Gateway is strictly outbound-only. It does not allow inbound connections initiated from the internet. If inbound connectivity is required, you must use a separate service like Azure Load Balancer or Application Gateway.
Mistake
NAT Gateway requires a separate VM or appliance to function.
Correct
NAT Gateway is a fully managed Azure service. There is no infrastructure to manage, patch, or scale. It is deployed as a resource and automatically scales.
Mistake
NAT Gateway provides the same SNAT port capacity per gateway regardless of the number of public IPs.
Correct
Each public IP associated with a NAT Gateway provides 64,512 SNAT ports. The total port pool is the sum of ports from all associated IPs. Using a public IP prefix (e.g., 16 IPs) provides 1,032,192 ports.
Mistake
You can attach multiple NAT Gateways to the same subnet.
Correct
A subnet can only have one NAT Gateway attached. However, a single NAT Gateway can be attached to multiple subnets.
Mistake
NAT Gateway supports both IPv4 and IPv6.
Correct
Currently, NAT Gateway supports only IPv4. IPv6 outbound connectivity is not supported. For IPv6, you would need a different solution, such as an IPv6 public IP on a Load Balancer.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. NAT Gateway requires a Standard SKU public IP or public IP prefix. Basic SKU public IPs are not supported. If you have a Basic SKU IP, you must upgrade it to Standard or create a new Standard IP. This is a common exam point: always use Standard SKU for NAT Gateway.
To avoid SNAT port exhaustion, you can: (1) associate a public IP prefix to increase the port pool (e.g., /28 prefix gives 16 IPs = 1,032,512 ports), (2) reduce the idle timeout to free ports faster, (3) use connection pooling at the application level, (4) monitor SNAT Port Allocation metric and scale out by adding more IPs. The exam expects you to recommend a prefix for large-scale scenarios.
Yes, but they serve different purposes. NAT Gateway provides outbound connectivity with SNAT, while Azure Firewall provides inbound inspection and filtering. You can use both in the same architecture: for example, route traffic through Azure Firewall for inspection, then to NAT Gateway for outbound. However, they cannot both be attached to the same subnet; you would use UDRs to direct traffic appropriately.
NAT Gateway is not transitive across VNet peering by default. If a spoke VNet needs outbound through a NAT Gateway in a hub VNet, you must add a User-Defined Route (UDR) in the spoke subnet with 0.0.0.0/0 next hop to the hub's NAT Gateway private IP. However, NAT Gateway cannot be a next hop; you need to route to a virtual appliance (like Azure Firewall) that can forward to NAT Gateway. Alternatively, attach a NAT Gateway directly to the spoke subnet.
Default outbound access (implicit SNAT) uses Azure-managed public IPs that are not under your control. It has no SLA, limited performance, and no scaling guarantees. NAT Gateway gives you dedicated public IPs, predictable performance, automatic scaling, and a 99.95% SLA. For production workloads, NAT Gateway is recommended over default outbound access.
Yes, NAT Gateway supports UDP and ICMP (echo requests) in addition to TCP. For UDP, the default idle timeout is 2 minutes. ICMP is translated but may have limitations with fragmented packets. The exam may test that NAT Gateway works with all IP protocols that use ports (TCP/UDP) but not with non-port protocols like GRE.
Use Azure Monitor metrics for NAT Gateway. Key metrics: 'SNAT Connection Count' (current number of SNAT connections), 'SNAT Port Allocation' (percentage of ports in use), and 'Total SNAT Connections' (cumulative). Set alerts when SNAT Port Allocation exceeds 80% to proactively add more IPs. You can also use Network Watcher to diagnose connectivity issues.
You've just covered Azure NAT Gateway for Outbound Connectivity — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?