🚨 Azure Error Guide: 'QuotaExceeded' Operation Exceeds Approved Quota

Overview

A QuotaExceeded error means the requested deployment would push a subscription’s usage of some limited resource past its approved quota for a region. Azure enforces these limits per subscription, per region, and often per VM-family — so a request that succeeds in one region or for one VM size can fail in another. The deployment is rejected before any resource is created; nothing is partially provisioned.

You will see this from the CLI, an ARM/Bicep deployment, or a scale operation:

(QuotaExceeded) Operation could not be completed as it results in exceeding approved standardDSv3Family Cores quota. Additional details - Deployment Model: Resource Manager, Location: eastus, Current Limit: 10, Current Usage: 8, Additional Required: 4, (Minimum) New Limit Required: 12. Submit a request for Quota increase.
Code: QuotaExceeded

And in a Virtual Machine Scale Set scale-out, the operation log shows the same enforcement:

"statusMessage": "{\"error\":{\"code\":\"QuotaExceeded\",\"message\":\"Operation results in exceeding quota limits of Core. Maximum allowed: 20, Current in use: 18, Additional requested: 4.\"}}"
"operationName": "Microsoft.Compute/virtualMachineScaleSets/write"

It occurs whenever the sum of existing usage plus the new request exceeds the current limit for that counter — most commonly during scale-outs, multi-VM deployments, and new region rollouts where the default quota is low.

Symptoms

• A vm create, scale-set scale, or ARM deployment fails with (QuotaExceeded) naming a specific counter (...Family Cores, Total Regional Cores, Public IP Addresses, etc.).
• The error states Current Limit, Current Usage, and Minimum New Limit Required.
• The same template deploys fine in a different region or with a smaller/different VM size.
• An autoscale rule stops adding instances and the scale set stays below its target capacity.

az vm list-usage --location eastus \
  --query "[?currentValue >= limit].{Name:localName, Used:currentValue, Limit:limit}" -o table

Name                                Used    Limit
----------------------------------  ------  -------
Standard DSv3 Family vCPUs          8       10
Total Regional vCPUs                18      20

az network list-usages --location eastus \
  --query "[?currentValue >= limit].{Name:localName, Used:currentValue, Limit:limit}" -o table

Name                  Used    Limit
--------------------  ------  -------
Public IP Addresses   10      10

Common Root Causes

1. VM-family vCPU quota exhausted

Each VM family (Dsv3, Fsv2, Esv5, etc.) has its own vCPU quota per region. A family at its limit blocks any new VM of that family even if other families have room.

az vm list-usage --location eastus \
  --query "[?contains(localName, 'DSv3')].{Name:localName, Used:currentValue, Limit:limit}" -o table

Name                         Used    Limit
---------------------------  ------  -------
Standard DSv3 Family vCPUs   8       10

A 4-vCPU Standard_D4s_v3 needs 4 cores; 8 + 4 = 12 > 10, so the family quota is exceeded.

2. Total Regional vCPUs limit reached

Separate from per-family limits, every region has an overall Total Regional vCPUs cap. You can hit this even when each individual family still has headroom.

az vm list-usage --location eastus \
  --query "[?localName=='Total Regional vCPUs'].{Used:currentValue, Limit:limit}" -o table

Used    Limit
------  -------
18      20

With 18 of 20 regional cores in use, any request for more than 2 vCPUs in eastus fails regardless of family.

3. Low-priority / Spot vCPU quota

Spot and low-priority capacity is governed by its own counters (...Family vCPUs for spot, Total Regional Spot vCPUs), which default lower and are tracked separately from on-demand quota.

az vm list-usage --location eastus \
  --query "[?contains(localName, 'Spot')].{Name:localName, Used:currentValue, Limit:limit}" -o table

Name                            Used    Limit
------------------------------  ------  -------
Total Regional Spot vCPUs       0       0

A Total Regional Spot vCPUs limit of 0 means spot VMs cannot deploy at all until a quota increase is approved.

4. Public IP / network quota

Networking has independent quotas — Public IP Addresses, Standard SKU Public IPs, NAT gateways, load balancers. A deployment that allocates a new public IP can fail even when compute quota is fine.

az network list-usages --location eastus -o table

Name                          CurrentValue    Limit
----------------------------  --------------  -------
Public IP Addresses           10              10
Static Public IP Addresses    5               20
Standard SKU Public IP        10              10

Public IP Addresses is at its limit, so a VM that requests a new public IP is rejected with QuotaExceeded.

5. Per-subscription resource limits

Some limits are per-subscription rather than per-region — resource groups, deployments per RG, storage accounts per region, managed disks. These surface as quota errors that no vCPU increase will solve.

az quota list --scope "/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Storage/locations/eastus" \
  --query "[].{Name:properties.name.value, Limit:properties.limit.value}" -o table

Name                       Limit
-------------------------  ------
StorageAccounts            250

If existing storage accounts in the region equal the limit, a new account deployment fails on quota, not on compute.

6. Quota increase not yet approved (pending request)

A submitted increase may still be InProgress. Deployments keep failing at the old limit until the request is Succeeded, which is easy to mistake for the increase “not working”.

az quota request status list \
  --scope "/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Compute/locations/eastus" \
  --query "[].{Name:name, State:properties.provisioningState, Message:properties.requestSubmitTime}" -o table

Name                                   State
-------------------------------------  ----------
standardDSv3Family-eastus-increase     InProgress

The limit will not change while the request is InProgress; deployments continue to hit the old cap.

Diagnostic Workflow

Step 1: Identify the exact counter and numbers from the error

az vm create -g rg-prod -n batch-09 --image Ubuntu2204 --size Standard_D4s_v3 --debug 2>&1 \
  | grep -iE "QuotaExceeded|Current Limit|Current Usage|New Limit Required"

The message names the counter (e.g., standardDSv3Family Cores), the limit, current usage, and the minimum new limit required.

Step 2: Confirm compute usage vs. limits in the region

az vm list-usage --location eastus \
  --query "[?currentValue >= limit].{Name:localName, Used:currentValue, Limit:limit}" -o table

This shows every compute counter at or over its limit — the family quota and the Total Regional vCPUs cap are the usual culprits.

Step 3: Check network and other resource quotas

az network list-usages --location eastus \
  --query "[?currentValue >= limit].{Name:localName, Used:currentValue, Limit:limit}" -o table

If compute has headroom, the blocker is often a Public IP or other networking limit hit by the same deployment.

Step 4: Decide whether to relocate, resize, or request an increase

# Is the size offered in a less-constrained region?
az vm list-skus --size Standard_D4s_v3 --all \
  --query "[].{Region:locationInfo[0].location}" -o table
# Smaller size to fit current headroom?
az vm list-sizes --location eastus \
  --query "[?numberOfCores <= \`2\`].{Name:name, Cores:numberOfCores}" -o table

A smaller size or a different region may fit existing headroom without any quota change.

Step 5: Submit and track the quota increase

az quota update \
  --resource-name standardDSv3Family \
  --scope "/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Compute/locations/eastus" \
  --limit-object value=20 limit-object-type=LimitValue
az quota request status list \
  --scope "/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Compute/locations/eastus" -o table

Wait for the request to reach Succeeded, then re-run the deployment.

Example Root Cause Analysis

A nightly batch job scales a VM Scale Set from 4 to 8 Standard_D4s_v3 nodes in eastus and fails:

(QuotaExceeded) Operation could not be completed as it results in exceeding approved Total Regional Cores quota. Current Limit: 20, Current Usage: 18, Additional Required: 16, (Minimum) New Limit Required: 34.

The error points at Total Regional Cores, not a family counter, so checking regional usage:

az vm list-usage --location eastus \
  --query "[?localName=='Total Regional vCPUs' || contains(localName,'DSv3')].{Name:localName, Used:currentValue, Limit:limit}" -o table

Name                         Used    Limit
---------------------------  ------  -------
Standard DSv3 Family vCPUs   16      40
Total Regional vCPUs         18      20

The DSv3 family has plenty of room (16/40), but the region-wide cap is nearly full (18/20). Adding 4 nodes × 4 vCPUs = 16 cores would need 34 against a 20-core regional limit — the family quota is irrelevant here.

Fix: request a Total Regional vCPUs increase for eastus:

az quota update \
  --resource-name "TotalRegionalvCPUs" \
  --scope "/subscriptions/aaaa1111-bbbb-cccc-dddd-eeee22223333/providers/Microsoft.Compute/locations/eastus" \
  --limit-object value=40 limit-object-type=LimitValue

Once the request reads Succeeded, the scale-out completes and the set reaches 8 nodes.

Prevention Best Practices

• Track headroom proactively: schedule az vm list-usage / az network list-usages and alert when any counter crosses a threshold (e.g., 80%), so increases are requested before a deploy fails.
• Request quota for both the VM-family counter and Total Regional vCPUs together — raising one without the other still blocks at the cap you forgot.
• Remember spot, networking, and per-subscription limits are separate counters; size them for the workload’s full footprint, not just on-demand cores.
• Standardize on a small set of VM families per region so quota planning stays simple and predictable, and confirm sizes with az vm list-skus before committing a region.
• Submit increases ahead of known scale events and verify they read Succeeded before the event, rather than during the incident.
• For fast triage of a failing deploy, the free incident assistant can map a QuotaExceeded message to the exact counter and required limit. More walkthroughs are in the Azure guides.

Quick Command Reference

# Compute usage vs. limits (find counters at/over limit)
az vm list-usage --location <REGION> --query "[?currentValue >= limit].{Name:localName, Used:currentValue, Limit:limit}" -o table

# Specific family
az vm list-usage --location <REGION> --query "[?contains(localName, 'DSv3')]" -o table

# Network quotas
az network list-usages --location <REGION> -o table

# Other resource quotas
az quota list --scope "/subscriptions/<SUB_ID>/providers/<NAMESPACE>/locations/<REGION>" -o table
az quota show --resource-name <COUNTER> --scope "/subscriptions/<SUB_ID>/providers/Microsoft.Compute/locations/<REGION>"

# Where is the size offered / smaller alternatives
az vm list-skus --size <VM_SIZE> --all -o table
az vm list-sizes --location <REGION> -o table

# Request and track an increase
az quota update --resource-name <COUNTER> --scope "/subscriptions/<SUB_ID>/providers/Microsoft.Compute/locations/<REGION>" --limit-object value=<N> limit-object-type=LimitValue
az quota request status list --scope "/subscriptions/<SUB_ID>/providers/Microsoft.Compute/locations/<REGION>" -o table

Conclusion

A QuotaExceeded error means existing usage plus the new request would cross an approved limit for a specific counter in a specific region. The usual root causes:

1. The VM-family vCPU quota for that size is exhausted.
2. The region-wide Total Regional vCPUs cap is reached, independent of family headroom.
3. A low-priority/Spot vCPU counter (often defaulting to 0) blocks spot deployments.
4. A Public IP or other networking quota is hit by the same deployment.
5. A per-subscription resource limit (storage accounts, disks, RGs) is reached.
6. A requested increase is still InProgress and the old limit is still enforced.

Read the counter and numbers straight from the error, confirm with az vm list-usage / az network list-usages, then either resize, relocate, or submit and verify a quota increase. The fix is almost always raising the one counter the error names — or noticing the increase has not landed yet.