7.3 Public IP Addresses and NAT Patterns

Public IPs are resources, not just properties

In Azure, a public IP address is its own resource. It can be associated with supported targets such as a VM network interface, a public load balancer frontend, an application gateway, a VPN gateway, Azure Firewall, Bastion, or NAT Gateway depending on the design. The administrator chooses the SKU, allocation behavior, IP version, region, zone setting, and sometimes routing preference.

The main exam discipline is to ask why the public IP is needed. If the requirement is inbound web access to multiple VMs, a public load balancer or application gateway is usually better than individual VM public IPs. If the requirement is administrator RDP or SSH without exposing VM public IPs, Azure Bastion is the secure access pattern. If the requirement is outbound internet access from private VMs, NAT Gateway is often the clean answer.

Decision table:

Public IP SKU and association awareness

Azure public IPs have SKU and configuration constraints. Standard SKU is the normal production choice for modern secure designs and is used by many platform resources. Basic SKU is legacy in many scenarios and lacks features administrators expect from Standard. On the exam, pay attention to whether the public IP must be zone-redundant, used with a Standard load balancer, or associated with a service that requires Standard.

Allocation matters too. Static public IPs keep the address until the resource is deleted or dissociated according to resource behavior. Dynamic allocation can change when a resource is stopped and deallocated or recreated. If a partner must allowlist an IP address, dynamic is usually wrong. If a DNS record points to a public IP that must not change, choose static.

Portal path: Azure portal > Public IP addresses > Create. After creation, inspect Overview, Configuration, and Associated to. Many troubleshooting cases are solved by discovering that a public IP is unassociated, associated with the wrong target, or not compatible with the intended resource.

CLI example:

az network public-ip create \
  --resource-group rg-network \
  --name pip-appgw-prod \
  --location eastus \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

NAT Gateway for outbound access

NAT Gateway is associated with one or more subnets. Resources in those subnets use the NAT Gateway public IP or public IP prefix for outbound internet connectivity. This avoids assigning public IPs to every VM and gives a more predictable outbound source address for firewall allowlists and partner integrations.

Simple outbound diagram:

private VM 10.41.1.4
        |
subnet snet-app associated to NAT Gateway
        |
NAT Gateway -> public IP 20.50.60.70 -> internet API

This is outbound connectivity. NAT Gateway does not publish an inbound listener to your VM. If the requirement is that internet users must reach a website hosted on private VMs, use a public load balancer, application gateway, or another publishing service. If the requirement is only that private VMs call Microsoft updates, package repositories, or partner APIs from a consistent public source IP, NAT Gateway is a strong answer.

NAT Gateway also helps with SNAT port exhaustion compared with relying on default outbound access or a small number of load balancer outbound rules. If many VMs or high connection rates need outbound internet, NAT Gateway with sufficient public IP resources is a standard operational pattern.

CLI outline:

az network nat gateway create \
  --resource-group rg-network \
  --name nat-app-prod \
  --location eastus \
  --public-ip-addresses pip-nat-prod

az network vnet subnet update \
  --resource-group rg-network \
  --vnet-name vnet-prod-eastus \
  --name snet-app \
  --nat-gateway nat-app-prod

Inbound management is not the same as public access

A common AZ-104 trap is adding a public IP to a VM so administrators can connect. That may work technically, but it often violates the requirement to avoid exposing management ports. Azure Bastion lets administrators connect to private IPs over TLS through the portal or supported client flows. Just-in-time VM access can reduce exposure when public management is unavoidable, but Bastion is the better fit when the scenario explicitly says no public IPs on VMs.

NSGs still matter. A public IP associated to a VM NIC does not mean all ports are open. The subnet NSG, NIC NSG, VM host firewall, and application listener must all allow the traffic. Conversely, a NAT Gateway does not require inbound NSG rules for internet clients because it is not hosting inbound connections.

Troubleshooting workflow

For inbound failure, start at the published endpoint. Is the public IP associated with the intended load balancer, gateway, firewall, or NIC? Does DNS point to the correct IP? Does the frontend rule or listener exist? Does the backend health probe pass? Does the NSG allow the destination port? Is the application listening on the expected private port?

For outbound failure, start from the subnet. Is a NAT Gateway associated? Is a route table sending 0.0.0.0/0 to a firewall or virtual appliance instead? Does the firewall allow the destination? Does the remote service allowlist the NAT public IP or the firewall public IP? Are you testing from a VM in the correct subnet?

Network Watcher next hop is useful when the path is ambiguous. If next hop for internet is Internet, default system routing or NAT may be involved. If next hop is VirtualAppliance, an Azure Firewall or NVA route owns the path. If a forced-tunnel route sends all traffic to on-premises, NAT Gateway may not be used for that flow because the UDR is more specific or changes the next hop.

Scenario traps

Do not confuse public IP address with public DNS. You can have an address without a useful DNS name. Do not assign public IPs to backend VMs just because they need outbound updates. Use NAT Gateway or controlled egress. Do not assume NAT Gateway solves inbound publishing. Do not forget that load balancer outbound rules, NAT Gateway, Azure Firewall, and public VM IPs are different outbound source patterns.

A frequent exam scenario says that a partner allowlisted one IP, but outbound calls sometimes come from other addresses. Look for inconsistent egress: some subnets use default outbound, some use load balancer outbound rules, and some use NAT Gateway. The corrective action is to centralize and verify outbound through the intended NAT or firewall path, then update route tables and subnet associations.