🚨 Azure Error: 'PublicIPCountLimitReached' — Cause, Fix, and Troubleshooting Guide

What this error means

Azure returns PublicIPCountLimitReached when a deployment tries to create a public IP address but the subscription has already reached its per-region quota for public IPs (Basic or Standard). This is a networking quota limit, distinct from vCPU or storage quotas. The literal error looks like this:

{
  "code": "PublicIPCountLimitReached",
  "message": "Cannot create more than 1000 public IP addresses with sku type 'Standard' for this subscription in this region 'eastus'. Current count: 1000, requested count: 1. Please reduce the requested count, remove unused public IPs, or request a quota increase."
}

The message names the SKU (Basic vs Standard are counted separately), the region, the current count, and the ceiling — everything you need to decide between cleaning up and raising the limit.

Warning signs

• Creating a VM, load balancer, NAT gateway, App Gateway, or VPN gateway fails because its associated public IP cannot be created.
• The error names a region and an exact count at the quota ceiling (often the default of 1000 Standard IPs).
• Scale-out or blue/green deploys that briefly double the IP footprint fail at peak even though steady-state is under quota.
• Terraform/Bicep reports the failure on the Microsoft.Network/publicIPAddresses resource, cascading to the dependent resource.

Measuring the limit

Check the network usage counters for the region to see the current count against the limit:

az network list-usages --location eastus \
  --query "[?contains(name.value, 'PublicIPAddresses')].{Name:name.localizedValue, Current:currentValue, Limit:limit}" \
  -o table

List every public IP in the subscription and flag the ones not attached to anything:

az network public-ip list \
  --query "[].{Name:name, RG:resourceGroup, SKU:sku.name, Associated:ipConfiguration.id!=null}" \
  -o table

Isolate the orphans (no ipConfiguration) that are safe cleanup candidates:

az network public-ip list \
  --query "[?ipConfiguration==null].{Name:name, RG:resourceGroup, SKU:sku.name, Address:ipAddress}" \
  -o table

Break the count down by region so you can see whether spreading load helps:

az network public-ip list \
  --query "[].location" -o tsv | sort | uniq -c

Limits and pressure causes

• Genuine growth — the subscription legitimately needs more public IPs than the default quota in that region.
• Orphaned public IPs — IPs left Unassociated after VMs, NICs, or load balancers were deleted, silently consuming quota.
• Per-region counting — quota is per subscription per region; concentrating everything in one region hits the wall while other regions sit empty.
• SKU split — Basic and Standard public IPs have separate quotas; a fleet migrating to Standard can exhaust the Standard limit while Basic looks fine.
• Deployment overshoot — automation that creates new IPs before deleting old ones temporarily exceeds the ceiling.

Remediation

Delete orphaned public IPs to reclaim quota immediately:

az network public-ip delete --name orphaned-pip-01 --resource-group net-rg

Consolidate outbound connectivity so many VMs share a small number of IPs instead of one each — a NAT gateway or a Standard Load Balancer outbound rule replaces dozens of per-VM public IPs:

az network nat gateway create \
  --resource-group net-rg --name egress-nat \
  --public-ip-addresses egress-pip --idle-timeout 10

Distribute across regions if the workload allows it, so no single region hits its per-region ceiling.

Request a quota increase when the need is real. Open a support/quota request for the Public IP Addresses - Standard counter in the region:

# Surfaces the exact quota name/scope to reference in the request
az network list-usages --location eastus \
  --query "[?contains(name.value,'PublicIPAddressesStandard')]" -o json

Quota increases for public IPs are typically approved quickly, but design toward shared egress rather than one-IP-per-resource so you are not back at the ceiling next quarter.

Capacity headroom

• Basic public IPs are retiring. Do not solve a Standard quota problem by falling back to Basic SKU IPs; plan for Standard-only going forward.
• Deletes are not instant to quota. After deleting IPs, allow a short propagation before retrying the deployment or the count may still read at the limit.
• Deployment ordering matters. In blue/green rollouts, release the old IPs (or reuse them) before allocating new ones so you never transiently double the count.
• Static IPs pin the address, not the quota. Reserving a static IP still consumes one unit of the public IP quota whether or not it is attached.

Related capacity errors

• QuotaExceeded — the general approved-quota rejection; same request-an-increase workflow for other counters.
• OperationNotAllowed (vCPU quota) — the compute-core quota sibling of this networking limit.
• NicInUse — dissociate NICs and their public IPs cleanly before deleting to avoid orphaned quota consumers.