🚨 Azure Error Guide: 'SubnetIsFull' Out of Subnet IP Addresses

Overview

An Azure SubnetIsFull happens when you try to attach a resource that needs an IP — a NIC, a private endpoint, an AKS pod — to a subnet that has no free addresses left. Every IP in the subnet’s CIDR range is either assigned or reserved by Azure, so ARM rejects the allocation and the resource operation fails. The subnet does not grow automatically; you must free addresses or resize the range.

You will see this in the CLI output or deployment log:

(SubnetIsFull) Subnet app-subnet with address prefix 10.10.1.0/27 does not have enough available IP addresses to satisfy the request for 1 IP addresses.
Code: SubnetIsFull
Message: Subnet app-subnet ... does not have enough available IP addresses ...

And the available-IP probe confirms there is nothing left:

$ az network vnet subnet list-available-ips -g rg-net --vnet-name vnet-app -n app-subnet
[]

It occurs when creating VMs/NICs, adding private endpoints, scaling an AKS node pool with Azure CNI, or any operation that consumes an address. Remember a /27 only offers 27 usable IPs, not 32 — Azure reserves 5 per subnet — so subnets fill faster than the raw CIDR math suggests.

Symptoms

• VM, NIC, or private-endpoint creation fails with (SubnetIsFull).
• AKS node-pool scale-out fails to schedule pods for lack of IPs (Azure CNI).
• list-available-ips returns an empty array [].
• The subnet’s used-IP count equals its usable capacity.

az network nic create -g rg-net --vnet-name vnet-app --subnet app-subnet --name nic-99

(SubnetIsFull) Subnet app-subnet with address prefix 10.10.1.0/27 does not have enough available IP addresses to satisfy the request for 1 IP addresses.

az network vnet subnet show -g rg-net --vnet-name vnet-app -n app-subnet \
  --query "{prefix:addressPrefix, ipConfigs:length(ipConfigurations)}" -o json

{ "prefix": "10.10.1.0/27", "ipConfigs": 27 }

Common Root Causes

1. Subnet CIDR too small / exhausted

The address prefix simply does not have room. A /29 gives 3 usable IPs, a /27 gives 27 — small ranges fill quickly as workloads grow.

az network vnet subnet show -g rg-net --vnet-name vnet-app -n app-subnet \
  --query "{prefix:addressPrefix, used:length(ipConfigurations)}" -o json

{ "prefix": "10.10.1.0/27", "used": 27 }

27 used in a /27 (32 total minus 5 reserved) means the subnet is completely full.

2. Azure reserves 5 IPs per subnet

Azure takes the first four addresses (network, gateway, two DNS) and the last (broadcast) of every subnet. A /29 therefore yields only 3 usable IPs, not 8 — a frequent surprise on tiny subnets.

az network vnet subnet list-available-ips -g rg-net --vnet-name vnet-app -n tiny-subnet

[ "10.10.2.4", "10.10.2.5", "10.10.2.6" ]

A /29 (10.10.2.0/29) exposes only .4, .5, .6 — the other 5 are reserved.

3. Private endpoints / extra NICs consuming IPs

Each private endpoint and each additional NIC takes an IP from the subnet, often invisibly compared to VM count.

az network private-endpoint list -g rg-net \
  --query "[?subnet.id != null] | length(@)" -o tsv
az network nic list -g rg-net \
  --query "length([?ipConfigurations[?subnet.id != null]])" -o tsv

9
27

9 private endpoints plus NICs together exhaust the subnet even with only a handful of VMs.

4. AKS node/pod IPs with Azure CNI

With Azure CNI, every pod gets a routable IP from the subnet, so node-pool scale-out multiplies IP consumption by --max-pods per node.

az aks show -g rg-aks -n aks-prod \
  --query "agentPoolProfiles[].{pool:name, count:count, maxPods:maxPods, subnet:vnetSubnetId}" -o json

[ { "pool": "nodepool1", "count": 3, "maxPods": 30, "subnet": "/subscriptions/.../subnets/aks-subnet" } ]

3 nodes x 30 max-pods plus the nodes themselves needs ~99 IPs — a /26 subnet (59 usable) cannot hold it.

5. Delegated subnet constraints

A subnet delegated to a service (for example Microsoft.Web/serverFarms or Microsoft.ContainerInstance) reserves capacity for that service and cannot be shared, so usable space is smaller than the raw range.

az network vnet subnet show -g rg-net --vnet-name vnet-app -n web-subnet \
  --query "{prefix:addressPrefix, delegations:delegations[].serviceName}" -o json

{ "prefix": "10.10.3.0/28", "delegations": ["Microsoft.Web/serverFarms"] }

The delegation plus the 5 reserved IPs leaves a /28 with far fewer usable addresses than expected.

6. Leaked / orphaned NICs holding IPs

NICs left behind by deleted VMs still hold their subnet IPs, silently consuming capacity until detached and removed.

az network nic list -g rg-net \
  --query "[?virtualMachine==null].{name:name, ip:ipConfigurations[0].privateIPAddress}" -o table

Name        Ip
----------  ----------
nic-old-04  10.10.1.18
nic-old-07  10.10.1.22

NICs with virtualMachine == null are orphaned — deleting them returns those IPs to the subnet.

Diagnostic Workflow

Step 1: Confirm the subnet is actually full

az network vnet subnet list-available-ips \
  -g rg-net --vnet-name vnet-app -n app-subnet

An empty [] confirms no free addresses.

Step 2: Compare the prefix size to usable IPs (minus the reserved 5)

az network vnet subnet show -g rg-net --vnet-name vnet-app -n app-subnet \
  --query "{prefix:addressPrefix, used:length(ipConfigurations)}" -o json

Step 3: Account for non-VM consumers (endpoints, AKS, delegations)

az network private-endpoint list -g rg-net --query "length(@)" -o tsv
az aks show -g rg-aks -n aks-prod --query "agentPoolProfiles[].{count:count, maxPods:maxPods}" -o json

Step 4: Hunt orphaned NICs that hold IPs

az network nic list -g rg-net \
  --query "[?virtualMachine==null].{name:name, ip:ipConfigurations[0].privateIPAddress}" -o table

Step 5: Free addresses or resize the subnet, then retry

# remove an orphaned NIC
az network nic delete -g rg-net --name nic-old-04
# or widen the subnet prefix (requires free space in the VNet address space)
az network vnet subnet update -g rg-net --vnet-name vnet-app -n app-subnet \
  --address-prefixes 10.10.1.0/26

Example Root Cause Analysis

An AKS cluster on Azure CNI fails to scale nodepool1 from 3 to 5 nodes; the pods stay Pending and the activity log shows SubnetIsFull on aks-subnet.

The subnet looks reasonably sized at first glance:

az network vnet subnet show -g rg-aks --vnet-name vnet-aks -n aks-subnet \
  --query "{prefix:addressPrefix, used:length(ipConfigurations)}" -o json

{ "prefix": "10.20.0.0/25", "used": 123 }

A /25 has 128 addresses, minus 5 reserved leaves 123 usable — and all 123 are in use. Checking the node-pool configuration explains why:

az aks show -g rg-aks -n aks-prod \
  --query "agentPoolProfiles[].{pool:name, count:count, maxPods:maxPods}" -o json

[ { "pool": "nodepool1", "count": 3, "maxPods": 30 } ]

With Azure CNI, each of the 3 nodes reserves maxPods (30) IPs plus one for the node itself — roughly 93 for the running pool, and the remaining addresses are taken by private endpoints in the same subnet. Scaling to 5 nodes needs ~62 more IPs the /25 does not have.

Fix: there is no free space adjacent to the /25, so the node pool is moved to a new, larger subnet sized for the target node count and maxPods:

az network vnet subnet create -g rg-aks --vnet-name vnet-aks -n aks-subnet2 \
  --address-prefixes 10.20.2.0/23
# new node pool on the larger subnet
az aks nodepool add -g rg-aks --cluster-name aks-prod -n pool2 \
  --node-count 5 --max-pods 30 --vnet-subnet-id "/subscriptions/.../subnets/aks-subnet2"

The /23 provides 507 usable IPs, comfortably covering 5 nodes x 30 pods plus headroom, and the scale-out succeeds.

Prevention Best Practices

• Size subnets for Azure CNI by node count x maxPods plus the nodes plus the 5 reserved IPs, then add headroom — undersized AKS subnets are the most common SubnetIsFull.
• Always subtract 5 reserved IPs when planning capacity; never assume a /29 gives 8 usable addresses (it gives 3).
• Put private endpoints and delegated services in their own dedicated subnets so they do not silently starve workload subnets.
• Reap orphaned NICs as part of VM teardown automation so deleted VMs return their IPs instead of leaking capacity.
• Allocate VNet address space with room to widen subnets later, and monitor available IPs with list-available-ips before subnets approach exhaustion. See more in the Azure guides.
• For ad-hoc triage, the free incident assistant can correlate a SubnetIsFull error with the consumers (endpoints, AKS pods, orphaned NICs) eating the range.

Quick Command Reference

# Confirm the subnet is full
az network vnet subnet list-available-ips -g <RG> --vnet-name <VNET> -n <SUBNET>

# Prefix size vs. IPs in use
az network vnet subnet show -g <RG> --vnet-name <VNET> -n <SUBNET> \
  --query "{prefix:addressPrefix, used:length(ipConfigurations)}" -o json

# Check delegations on the subnet
az network vnet subnet show -g <RG> --vnet-name <VNET> -n <SUBNET> \
  --query "delegations[].serviceName" -o tsv

# Private endpoints consuming IPs
az network private-endpoint list -g <RG> --query "length(@)" -o tsv

# AKS pod IP consumption (Azure CNI)
az aks show -g <RG> -n <CLUSTER> \
  --query "agentPoolProfiles[].{count:count, maxPods:maxPods}" -o json

# Orphaned NICs still holding IPs
az network nic list -g <RG> \
  --query "[?virtualMachine==null].{name:name, ip:ipConfigurations[0].privateIPAddress}" -o table

# Free an IP or resize the subnet
az network nic delete -g <RG> --name <ORPHANED_NIC>
az network vnet subnet update -g <RG> --vnet-name <VNET> -n <SUBNET> --address-prefixes <WIDER_CIDR>

Conclusion

A SubnetIsFull error means every usable address in the subnet’s CIDR is assigned or reserved, and Azure has nothing left to hand out. The usual root causes:

1. The subnet CIDR is too small and has been fully consumed.
2. Azure’s 5 reserved IPs per subnet leave fewer usable addresses than the raw range suggests.
3. Private endpoints and extra NICs silently consume IPs alongside VMs.
4. Azure CNI gives every AKS pod a subnet IP, multiplying consumption by maxPods per node.
5. A delegated subnet reserves capacity for its service, shrinking usable space.
6. Orphaned NICs from deleted VMs still hold their IPs until removed.

Probe with list-available-ips, account for the non-VM consumers, and reap orphaned NICs — if the workload genuinely needs the space, widen the subnet or move it to a larger range.