🚨 Azure Error Guide: 'PrivateIPAddressInReservedRange' — Pick an Allowed Subnet IP

Overview

Azure reserves five IP addresses in every subnet and rejects any attempt to statically assign one of them to a NIC, load balancer, or private endpoint. The control plane returns:

{
  "error": {
    "code": "PrivateIPAddressInReservedRange",
    "message": "The specified private IP address 10.1.0.1 is in the reserved subnet range and cannot be assigned to a NIC. Reserved addresses are the first four and the last address of each subnet."
  }
}

Two closely related errors come from the same static-IP validation. Assigning an address outside the subnet’s prefix returns PrivateIPAddressNotInSubnet, and assigning one already in use returns PrivateIPAddressIsBeingUsed / PrivateIPAddressIsAllocated.

Symptoms

• Creating or updating a NIC/load balancer/private endpoint with a static IP fails immediately with PrivateIPAddressInReservedRange.
• IaC (Bicep/ARM/Terraform) that hardcodes a low address like .0, .1, .2, .3 or the broadcast .255 fails on apply.
• The same template works in one subnet but fails in another with a different prefix, because “reserved” is relative to each subnet’s range.
• Related failures: PrivateIPAddressNotInSubnet (IP outside the CIDR) or PrivateIPAddressIsBeingUsed (IP already taken).

Common Root Causes

• Using one of the five reserved addresses. In every subnet Azure reserves the network address (first), the default gateway (.1), two for Azure DNS mapping (.2, .3), and the broadcast (last). None can be statically assigned.
• Assuming .1 is usable. In on-prem networks .1 is often a usable gateway host; in Azure it is reserved for the platform gateway.
• Off-by-one on subnet math. Miscalculating the network/broadcast for a non-/24 prefix and landing on a reserved boundary address.
• Hardcoded IPs copied across subnets. A static IP valid in one subnet lands in the reserved range of another with a different size/offset.
• Wrong subnet entirely. The chosen IP is not even in the subnet prefix (PrivateIPAddressNotInSubnet) — a different but adjacent mistake.
• IP already allocated. The target address is free-looking to you but already assigned to another resource (PrivateIPAddressIsBeingUsed).

Diagnostic Workflow

All commands below are read-only. Confirm the subnet’s exact prefix so you know which addresses are reserved:

# Get the subnet prefix; reserved = first four + last address of this range.
az network vnet subnet show --resource-group <rg> --vnet-name <vnet> --name <subnet> \
  --query "{name:name, prefix:addressPrefix}" --output table

Ask Azure which addresses are actually available and whether a specific one is free:

# List available (unallocated, non-reserved) IPs in the subnet.
az network vnet subnet list-available-ips --resource-group <rg> --vnet-name <vnet> --name <subnet> --output json 2>/dev/null \
  || az network vnet check-ip-address --resource-group <rg> --name <vnet> --ip-address 10.1.0.10 --output json

See what is already using addresses in the subnet:

# NICs and their private IPs in this subnet.
az network nic list --query "[?ipConfigurations[?subnet.id=='<subnet-id>']].{name:name, ip:ipConfigurations[0].privateIpAddress}" --output table

Get the subnet ID for matching:

az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query id --output tsv

Example Root Cause Analysis

A Bicep template deployed an internal load balancer with a static frontend IP of 10.20.0.1 in subnet 10.20.0.0/24. The deployment failed with PrivateIPAddressInReservedRange. The engineer, coming from on-prem networking, had chosen .1 as a “nice round gateway-style” address.

az network vnet subnet show confirmed the subnet was 10.20.0.0/24, so its reserved addresses were 10.20.0.0 (network), 10.20.0.1 (Azure gateway), 10.20.0.2 and 10.20.0.3 (Azure DNS), and 10.20.0.255 (broadcast). 10.20.0.1 was the platform gateway — permanently unusable for a static assignment. Running az network vnet check-ip-address on 10.20.0.10 showed it available.

The fix was to change the static frontend to 10.20.0.10 (or better, let Azure allocate dynamically for non-fixed cases). The deployment succeeded. Root cause: assigning the Azure-reserved .1 gateway address, a habit carried over from on-prem addressing.

Prevention Best Practices

• Never statically assign the first four or last address of any subnet; start host assignments at .4 (e.g. 10.1.0.4) and up.
• Check availability first with az network vnet check-ip-address / list-available-ips before hardcoding a static IP.
• Prefer dynamic allocation unless a resource truly needs a fixed IP; Azure never hands out reserved addresses dynamically.
• Compute reserved boundaries per subnet in IaC rather than copying static IPs between differently sized subnets.
• Right-size subnets so you are not fighting for a handful of addresses; account for the five reserved per subnet in capacity planning.
• Validate with what-if to catch reserved-range and not-in-subnet mistakes before deployment.

Quick Command Reference

# Get the subnet prefix (reserved = first four + last of this range).
az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query addressPrefix -o tsv

# Check whether a specific IP is available.
az network vnet check-ip-address -g <rg> -n <vnet> --ip-address 10.1.0.10

# List available IPs in the subnet.
az network vnet subnet list-available-ips -g <rg> --vnet-name <vnet> -n <subnet>

# See which IPs are already used by NICs.
az network nic list --query "[?ipConfigurations[?subnet.id=='<subnet-id>']].ipConfigurations[0].privateIpAddress" -o table

# Preview an assignment before deploying.
az deployment group what-if -g <rg> --template-file main.bicep

Conclusion

PrivateIPAddressInReservedRange is Azure enforcing its five reserved addresses per subnet: the network address, the .1 gateway, .2 and .3 for DNS, and the broadcast. Start static host assignments at .4, verify availability with az network vnet check-ip-address before hardcoding, and prefer dynamic allocation when a fixed IP is not required. Computing reserved boundaries per subnet in IaC keeps this — and its PrivateIPAddressNotInSubnet and already-allocated cousins — out of your deployments.