Episode 2 — Public IP Addresses & Outbound Connectivity (NAT Gateway)

In Episode 1 we carved out a private address space with Virtual Networks, Subnets & the Azure Address Space; now we open a controlled door to the internet — first with public IP addresses, then with the outbound-only path of Azure NAT Gateway.

Learning objectives

• Explain what an Azure public IP address resource is, which resources can use one, and the difference between inbound and outbound connectivity.
• Choose the correct public IP SKU (Standard vs Basic) and allocation method (static vs dynamic) for a given scenario, accounting for the Basic-SKU retirement.
• Design scalable, secure outbound connectivity for a subnet using Azure NAT Gateway and its SNAT port model.
• Troubleshoot SNAT port exhaustion and reason about which outbound method Azure actually uses when several are configured.

Why it matters

Almost every real workload eventually needs to talk to the internet — to pull OS updates, call an API, or serve inbound traffic to users. In Azure, that reachability is not automatic or free-form: it is expressed through discrete, billable resources (public IP addresses, NAT gateways, load balancers) with distinct security postures. Getting these choices right is where administration meets architecture: pick the wrong SKU and you can't attach it to a Standard load balancer; rely on the old implicit outbound path and your VMs may silently lose internet access as Microsoft retires it. This episode gives you the vocabulary and the decision rules an AZ-104 administrator is expected to apply.

The public IP address resource

In Azure Resource Manager, a public IP address is a resource with its own properties — it is not just an attribute buried inside a VM. That independence matters: you create it, name it, configure it, and associate or dissociate it from other resources, and it survives on its own until you delete it. While associated, the address remains dedicated exclusively to that resource.

Public IPs enable two things:

• Inbound communication from the internet to an Azure resource (a VM, Application Gateway, load balancer, VPN gateway, and others).
• Outbound connectivity to the internet using a predictable IP address.

A resource without a public IP can still reach outbound — historically Azure would assign a temporary, non-dedicated dynamic address for that traffic. Keep this distinction in mind; the "implicit" outbound path is exactly what is being retired (covered below).

What can have a public IP

The following resources can be associated with a public IP address:

• Virtual machine network interfaces
• Virtual Machine Scale Sets (use Public IP Prefixes for these)
• Public Azure Load Balancers
• Virtual Network Gateways (VPN / ExpressRoute)
• NAT gateways
• Application Gateways
• Azure Firewalls
• Bastion Hosts
• Route Servers
• API Management

A public IP is associated at a specific attachment point — for a VM it binds to the network interface (NIC); for a load balancer, gateway, or firewall it binds to a front-end / IP configuration.

IP version and DNS name label

A public IP can be IPv4, IPv6, or a dual-stack pair. You may also give it a DNS name label, which creates a mapping of domainnamelabel.location.cloudapp.azure.com to the address in Azure-managed DNS. For example, contoso in West US yields the FQDN contoso.westus.cloudapp.azure.com. Each label must be unique within its Azure location.

SKU: Standard vs Basic (and why Basic is gone)

The SKU of a public IP determines its allocation method, feature support, and which resources it can attach to. There are two: Standard (v1 or v2) and Basic.

Important — retirement: On September 30, 2025, Basic SKU public IPs were retired. New designs must use Standard; existing Basic IPs should be upgraded to Standard. You will still see the concept on exams and in legacy environments, so understand the contrast — but treat Standard as the only forward-looking choice.

Two nuances worth memorizing:

• SKUs must match. You can't mix Basic and Standard between a load balancer and its public IP; a Standard load balancer requires a Standard public IP.
• Standard v2 is niche. A Standard v2 public IP can currently be used only with the Standard v2 NAT Gateway product — nothing else.

Mnemonic — "Standard is Static, Secure, Zone-smart." All three S's flip the Basic defaults: Standard is always Static, Secure-by-default (needs an NSG), and zone-capable.

Static vs dynamic allocation

Even though Standard is always static, understanding the two assignment types clarifies why:

• Dynamic — the address is not assigned at creation; it is assigned when the IP is associated to a running resource, and released when the resource is stopped (deallocated) or the IP is removed. Good when nothing depends on the specific address. A VM that is stopped and started can come back with a different address.
• Static — the address is assigned at creation and does not change until the IP resource is deleted (and once deleted it cannot be recovered). You can't choose the exact address; Azure picks it from the region's pool.

Use static whenever the address is baked into something external: firewall allow-lists, DNS A records, IP-based security models, or TLS/SSL certificates linked to an IP.

Public IP prefix

A public IP prefix gives you a contiguous, reserved range of Standard public IP addresses. It is the recommended way to assign addresses to Virtual Machine Scale Sets and, as we'll see, to a NAT gateway — because a predictable contiguous range lets a downstream partner configure destination firewall rules against a known IP list.

# Create a zone-redundant Standard public IP (default in AZ-enabled regions)
az network public-ip create \
  --resource-group rg-net \
  --name pip-nat-01 \
  --sku Standard \
  --allocation-method Static

Admin note: Managing public IPs requires the built-in Network Contributor role (or a custom role with the Microsoft.Network/publicIPAddresses/* actions, including .../join/action to associate one to a resource). CLI verbs follow the pattern az network public-ip create | show | list | update | delete; PowerShell uses New-/Get-/Set-/Remove-AzPublicIpAddress.

Exercise 1 — Choose SKU + allocation

Scenario. You are deploying a public-facing web VM fronted by a Standard Load Balancer. The security team maintains an on-prem firewall that must allow-list your Azure front-end address, and that address must never change. Which SKU and allocation method do you pick, and what extra configuration does the SKU force on you?

Solution. Pick the Standard SKU — it is mandatory anyway because a Standard load balancer requires a matching Standard public IP, and Basic is retired. Standard public IPs are always Static, which is exactly what the firewall allow-list and stable-address requirement need, so allocation is decided for you. Because Standard is secure by default (closed to inbound), you must also create and associate a network security group (NSG) that explicitly allows the intended web traffic (e.g. TCP 443); until you do, connectivity to the resource fails. Net answer: Standard SKU, Static allocation, plus an NSG allow rule.

Outbound connectivity: the problem

Inbound is the intuitive case — a public IP lets the world reach in. Outbound is subtler because Azure historically gave it to you implicitly.

Default outbound access is being retired

If a VM has no public IP and isn't behind an outbound-capable load balancer, Azure has provided a default outbound access IP — an automatic, non-configurable address for outbound traffic. This implicit path is disabled the moment you attach an explicit method:

• a public IP is assigned to the VM, or
• the VM joins the backend pool of a Standard load balancer (with or without outbound rules), or
• an Azure NAT Gateway is assigned to the VM's subnet.

Important — direction of travel: As of March 31, 2026, new virtual networks default to private subnets, and default outbound access is no longer provided. You must configure an explicit outbound method (NAT gateway recommended) — otherwise VMs can't even do Windows Update or Windows Activation. VMs created via Virtual Machine Scale Sets in flexible orchestration mode never had default outbound access to begin with.

This is why NAT Gateway has moved from "nice to have" to the recommended default for outbound.

Azure NAT Gateway

Azure NAT Gateway is a fully managed, highly resilient network address translation service. Attach it to a subnet and every instance in that subnet reaches the internet outbound while staying fully private — no instance needs a public IP of its own.

Crucially, it is outbound-only: a NAT gateway does not permit unsolicited inbound connections. Only response packets to an outbound flow the VM initiated can return. That one-way property is what makes it a natural fit for back-end tiers, batch workers, and anything that should call out but never be reachable from the internet.

How it works — SNAT and dynamic port allocation

NAT Gateway performs Source Network Address Translation (SNAT): it rewrites the private source IP/port of each outbound flow to one of its static public IP addresses and a port. Its headline benefit is that it dynamically allocates SNAT ports to automatically scale outbound connectivity and minimize the risk of SNAT port exhaustion — the classic failure mode of the older methods.

The diagram contrasts the two directions: outbound rides subnet → NAT gateway → public IP → internet, while inbound to a hosted service arrives via a public IP on a load balancer front end. NAT Gateway plays no part in inbound.

SKUs: Standard vs StandardV2

NAT Gateway comes in two SKUs:

Two facts to lock in: you cannot upgrade Standard to StandardV2 (you replace the resource), and each SKU demands a matching-SKU public IP. Both SKUs share the same core behavior — dynamic SNAT, secure outbound, and no routing configuration required.

Why administrators like it

• Simple setup — attach a NAT gateway to a subnet and a public IP, and outbound works immediately. No UDRs or route tables needed.
• Security (Zero Trust) — private instances need no public IP; you SNAT behind static IPs/prefixes and can build destination firewall rules on a predictable IP list.
• Resiliency — distributed and fully managed; it doesn't depend on any single VM or device and has multiple fault domains.
• Scalability — scaled out from creation; all subnets in a VNet can share one NAT gateway, and you can add up to 16 public IPs (or a prefix that auto-scales) for more SNAT capacity.

It supports TCP, UDP, and ICMP (Echo Request/Reply), and works in a hub-and-spoke model (e.g. on an Azure Firewall subnet in the hub serving peered spokes) — though a single NAT gateway can't span multiple VNets, and you can't attach two NAT gateways to one subnet, nor deploy one in a gateway subnet.

Exercise 2 — Design outbound for a private subnet

Scenario. A subnet hosts 30 back-end worker VMs that must call external payment and update APIs but must never be reachable from the internet. The downstream payment provider will only accept traffic from a known, contiguous set of source IPs. Design the outbound connectivity.

Solution. Attach an Azure NAT Gateway to the workers' subnet — it gives outbound-only connectivity (no unsolicited inbound), so the VMs need no public IP of their own and stay fully private, satisfying the "never reachable" requirement. To meet the provider's fixed-source-IP rule, associate the NAT gateway with a public IP prefix (a contiguous range) rather than individual IPs; the provider can then allow-list that predictable block. Give the VMs no public IPs and no inbound rules. Because NAT Gateway performs dynamic SNAT port allocation shared across the subnet, all 30 VMs scale their outbound flows without you sizing anything. Pick StandardV2 if you want zone redundancy/IPv6/flow logs, otherwise Standard; match the public IP/prefix SKU accordingly.

When methods collide: the outbound precedence order

A subnet can, in principle, have several outbound-capable things configured. Azure resolves this with a strict precedence for new connections (existing flows on other methods aren't dropped):

1. UDR to a next hop of virtual appliance or virtual network gateway (VPN/ExpressRoute) — highest
2. NAT gateway
3. Instance-level public IP on the VM
4. Load balancer outbound rules
5. Default system route to the internet (implicit) — lowest

So NAT Gateway takes precedence over instance-level public IPs, load-balancer outbound rules, and Azure Firewall — unless a UDR sends 0.0.0.0/0 to an NVA or gateway, which overrides even NAT Gateway. Remember: NAT Gateway itself needs no route table; the subnet's built-in default route to 0.0.0.0/0 already points at the internet, and NAT simply replaces the source-side translation for that path.

Mnemonic — "Routes Rule, NAT Next." A user-defined route always wins; if there's no overriding UDR, NAT is the next thing Azure reaches for.

SNAT port exhaustion

Every outbound TCP connection to a unique destination IP:port consumes a SNAT port on the source public IP. With the older methods (default outbound, load balancer outbound rules), a fixed, pre-allocated pool of ports could run out under many concurrent connections — causing new outbound connections to fail or time out intermittently while existing ones work. That is SNAT port exhaustion.

NAT Gateway mitigates this by allocating SNAT ports dynamically on demand across all its public IPs, so it doesn't share the same exhaustion limits as default outbound or LB outbound rules. Two timer behaviors still matter when diagnosing:

• After a connection closes, its SNAT port isn't instantly reusable to the same destination — it enters a cooldown. UDP has a fixed 65-second port-reuse hold-down.
• The TCP idle timeout defaults to 4 minutes and can be raised up to 120 minutes; UDP idle timeout is fixed at 4 minutes. NAT Gateway sends a TCP RST for any flow it no longer recognizes (idle-timed-out or already closed).

Exercise 3 — Troubleshoot SNAT port exhaustion

Scenario. A fleet of VMs behind a Standard Load Balancer with outbound rules starts throwing intermittent "connection timed out" errors when calling a single external REST API under load. Existing long-lived connections are fine; it's the new ones that fail, and only at peak. What is the likely cause and the fix?

Solution. The symptoms — new outbound connections failing intermittently under high concurrency to the same destination endpoint, while established flows keep working — are classic SNAT port exhaustion. Load-balancer outbound rules draw from a finite, pre-allocated SNAT port pool; hammering one destination IP:port with many parallel connections drains it, so new flows can't get a port. Short-term mitigations include adding more front-end IPs / raising the port allocation and shortening idle timeouts so ports free up sooner. The recommended architectural fix is to move outbound to an Azure NAT Gateway on the subnet: it dynamically allocates SNAT ports and doesn't share the exhaustion limits of LB outbound rules, and by precedence it will take over new connections without dropping existing ones. Optionally attach a public IP prefix (more IPs = more ports) for extra headroom.

Key takeaways

• A public IP address is a standalone ARM resource; it enables inbound reach and predictable outbound. Resources bind it at a NIC or front-end/IP configuration.
• Basic SKU public IPs were retired on Sept 30, 2025 — use Standard. Standard is always Static, secure by default (needs an NSG to allow inbound), and zone-capable; SKUs must match between a public IP and its load balancer.
• Static = fixed at creation, survives stop/start, needed for firewall/DNS/cert/IP-based dependencies. Dynamic = assigned on association, can change on deallocate.
• Default outbound access is going away (private subnets by default as of Mar 31, 2026). Configure an explicit outbound method.
• Azure NAT Gateway = the recommended outbound-only, fully managed SNAT service. No routing config, all subnets in a VNet can share one, up to 16 public IPs, dynamic SNAT ports that avoid port exhaustion. Standard = zonal/50 Gbps; StandardV2 = zone-redundant/100 Gbps/IPv6/flow logs (no upgrade path between them).
• Outbound precedence: UDR (NVA/gateway) > NAT gateway > instance public IP > LB outbound rules > default route.

Quick recall

1. Q. Which public IP SKU should new designs use, and what is its only allocation method? A. Standard (Basic is retired) — allocation is Static only.
2. Q. Name two things a Standard public IP forces compared with Basic. A. It is secure by default (you must add an NSG to allow inbound), and it must be matched in SKU to a Standard load balancer (and it's always static).
3. Q. Can traffic from the internet initiate a connection inbound through a NAT gateway? A. No. NAT Gateway is outbound-only; only response packets to an outbound flow return.
4. Q. Why does NAT Gateway avoid SNAT port exhaustion? A. It dynamically allocates SNAT ports on demand across its public IPs, rather than using a fixed pre-allocated pool like default outbound or LB outbound rules.
5. Q. If a subnet has both a NAT gateway and a UDR sending 0.0.0.0/0 to an NVA, which wins for new outbound connections? A. The UDR — a user-defined route to a virtual appliance/gateway overrides NAT gateway connectivity.

Coming up

Next, in Episode 3 — Connecting Virtual Networks: Peering, we link VNets together over the Microsoft backbone and confront why peering is non-transitive — the key to hub-and-spoke design.