🚨 Azure Error Guide: 'OperationNotAllowed' Regional vCPU Quota Exceeded

Exact Error Message

When you deploy a virtual machine or a virtual machine scale set (VMSS) and the request would push a compute family past its approved core limit, Azure Resource Manager rejects the operation with a message like this:

{
  "code": "OperationNotAllowed",
  "message": "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 at https://aka.ms/ProdportalCRP/#blade/Microsoft_Azure_Capacity/UsageAndQuota.ReactView by specifying parameters listed in the 'Details' section for deployment to succeed."
}

The key fields are Code: OperationNotAllowed, the family name (standardDSv3Family), the location (eastus), and the three numbers that tell you exactly how far over you are: Current Limit, Current Usage, and Additional Required.

What the Error Means

Azure caps the number of vCPUs (cores) you can run, and it enforces these caps on two axes:

1. Per VM-family regional quota — e.g. standardDSv3Family Cores in eastus. Each SKU family (Dsv3, Fsv2, Esv5, NCv3, etc.) has its own independent limit per region.
2. Total regional vCPU quota — the aggregate cap across all families in a region (Total Regional Cores).

OperationNotAllowed for a Cores quota means the deployment you submitted would cause Current Usage + Additional Required to exceed Current Limit for that family (or the total regional pool). It is a soft, policy-level limit, not a hardware shortage. Your subscription is simply not authorized to allocate that many cores in that region yet. This is different from a capacity failure (AllocationFailed), where Azure physically cannot place the VM even though you have quota.

Common Causes

• Default low quota on new subscriptions. Pay-as-you-go and trial subscriptions often start with a per-family limit of 10 cores in a region.
• Large SKUs. A single Standard_D16s_v3 is 16 cores. One VM can blow past a 10-core limit on its own.
• Scale set scale-out. A VMSS scaling from 5 to 20 instances multiplies its per-instance core count — easy to exceed a family quota.
• Orphaned usage. Stopped-but-not-deallocated VMs, leftover VMSS instances, and disks attached to deleted VMs can keep cores counted against your quota.
• AKS node pools. Cluster autoscaler adds nodes from a specific family; a busy cluster can exhaust that family’s regional quota silently.
• Spot vs. regular confusion. Spot/low-priority cores draw from a separate *Spot quota; requesting regular VMs when only Spot quota was raised still fails.

How to Reproduce the Error

On a fresh subscription with the default 10-core standardDSv3Family limit in eastus, attempt to create a VM that needs more cores than remain available:

# Assumes ~8 Dsv3 cores already in use; D8s_v3 (8 cores) pushes past the limit of 10
az vm create \
  --resource-group rg-demo \
  --name vm-quota-test \
  --image Ubuntu2204 \
  --size Standard_D8s_v3 \
  --location eastus \
  --admin-username azureuser \
  --generate-ssh-keys

Resource Manager returns the OperationNotAllowed payload shown above instead of provisioning the VM.

Diagnostic Commands

All commands below are read-only — they inspect quota and usage without changing anything.

Check current usage versus limits for every compute family in a region:

az vm list-usage --location eastus -o table

Look for rows where CurrentValue is at or near Limit, and pay attention to both the specific family (e.g. Standard DSv3 Family vCPUs) and Total Regional vCPUs.

Confirm which subscription and tenant you are operating in:

az account show -o table

Find out how many cores a given SKU actually consumes and whether it is even offered in the region:

az vm list-skus \
  --location eastus \
  --size Standard_D8s_v3 \
  --query "[].{Name:name, vCPUs:capabilities[?name=='vCPUs'].value | [0]}" \
  -o table

Query the Capacity provider directly via the REST API for raw usage objects (useful in scripts and pipelines):

az rest --method get \
  --url "https://management.azure.com/subscriptions/$(az account show --query id -o tsv)/providers/Microsoft.Capacity/resourceProviders/Microsoft.Compute/locations/eastus/usages?api-version=2020-10-25" \
  --query "value[?currentValue > \`0\`].{Name:name.value, Used:currentValue, Limit:limit}" \
  -o table

You can also hit the Compute provider’s own usages endpoint:

az rest --method get \
  --url "https://management.azure.com/subscriptions/$(az account show --query id -o tsv)/providers/Microsoft.Compute/locations/eastus/usages?api-version=2024-07-01" \
  --query "value[].{Name:name.value, Used:currentValue, Limit:limit}" \
  -o table

Step-by-Step Resolution

1. Confirm the exact shortfall. Read the error’s Additional Required and (Minimum) New Limit Required fields, then cross-check with az vm list-usage --location eastus -o table. Verify whether you are blocked on the family quota, the Total Regional vCPUs quota, or both — raising one without the other leaves you stuck.

2. Reclaim wasted cores first. Deallocate (not just stop) idle VMs with az vm deallocate, and delete orphaned VMSS instances. A stopped VM in the “Stopped” (not “Stopped (deallocated)”) state still consumes quota. This is the fastest fix and costs nothing.

3. Request a quota increase. The portal route is the most reliable: open Subscriptions → Usage + quotas, filter to Compute, find the family and region, and select Request increase. Set the new limit to at least the (Minimum) New Limit Required value (round up for headroom). Small increases on standard families are frequently auto-approved within minutes.

To script it, install the quota extension and submit a request via az quota:

az extension add --name quota

Then use az quota update/az quota create against the relevant standardDSv3Family resource. Note the az quota extension is still in preview and its resource paths differ from az vm list-usage names, so the portal is usually faster for one-off requests.

4. Pick a different SKU family or region. If the increase is denied or slow, switch to a family with available quota (check az vm list-usage output) — for example move from Dsv3 to Dsv5 or Dasv5. Or deploy to a less-constrained region. Both keep you unblocked without waiting on approval.

5. Use Spot or smaller SKUs. Spot VMs draw from a separate *Spot quota pool, so they can succeed even when regular quota is exhausted (request that quota separately). Choosing smaller SKUs — two D4s_v3 instead of one D8s_v3 — does not reduce total cores but can fit better when you have fragmented headroom across families.

6. Retry the deployment. Once usage plus required cores sits below the new limit, re-run your az vm create or az deployment group create. Quota changes generally apply within minutes.

Prevention and Best Practices

• Provision quota in IaC pipelines. Add a pre-flight az vm list-usage check to deployment pipelines that fails fast with a clear message before Resource Manager rejects the request.
• Right-size before scaling. Map planned VMSS/AKS scale-out to core counts and request quota ahead of launch events.
• Monitor at 80%. Alert on family usage crossing 80% of its limit using the Microsoft.Capacity usage data so you request increases before they block deploys.
• Standardize on a few families. Spreading workloads across many SKU families fragments quota and makes shortfalls harder to predict.
• Track total regional cores. Even if every family looks healthy, the aggregate Total Regional vCPUs cap can still bite — keep it in your dashboards.

For more compute optimization patterns, see our Azure cost and capacity guides.

Related Errors

• QuotaExceeded — the generic quota rejection; same root cause as OperationNotAllowed here and resolved the same way (request an increase or reduce usage).
• SkuNotAvailable — the chosen SKU is not offered in the region/zone at all; pick a different size or region rather than raising quota.
• AllocationFailed — you have quota, but Azure has no physical capacity right now; retry, change zone/region, or try another SKU.
• ZonalAllocationFailed — capacity is unavailable in the specific availability zone you requested; try a different zone or remove the zone constraint.
• OverconstrainedAllocationRequest — too many simultaneous constraints (zone + proximity group + SKU) can’t be satisfied together; relax one constraint.

Frequently Asked Questions

What is the difference between low-priority/Spot quota and regular quota? They are entirely separate pools. Spot (formerly low-priority) cores are tracked under *Spot family quotas, while standard on-demand VMs draw from the regular family quota. Raising your regular standardDSv3Family limit does nothing for Spot deployments and vice versa — request the pool that matches your VM priority.

Why does the total regional cores quota matter if my family quota looks fine? Azure enforces both a per-family limit and an aggregate Total Regional vCPUs limit. A deployment can pass the family check but still trip the total regional cap if your other families are consuming cores. When you request a family increase, request a matching bump to the total regional quota so the aggregate ceiling does not become the new bottleneck.

How long does a quota increase take to apply after approval? Auto-approved increases on common families typically take effect within a few minutes. After approval, re-run az vm list-usage to confirm the new limit appears before retrying your deployment. Requests that route to manual review (large jumps, specialized GPU families, constrained regions) can take hours to a couple of business days.

Can I avoid quota errors entirely by using a bigger region? Not entirely — quota is per subscription, per family, per region, and defaults are independent of region size. A larger region may have more physical capacity (fewer AllocationFailed errors), but you still start from the same default core limits and must request increases there too.