An Azure vCPU family quota can show ten cores free while every size in that family is restricted for the subscription

The Azure command that checks vCPU quota, az vm list-usage, reports headroom per VM size family. A family can show free cores while none of the sizes inside it can be created in the target region, because a per-subscription restriction on individual sizes is reported by a different command, az vm list-skus, and the quota output carries no field for it. On the subscription measured below, the v2 B-series family also read a quota limit of 0, so the obvious fallback had no headroom either.

Last verified: 2026-09-15.

What the quota command reports

Microsoft's own description of the check is narrow. The Check vCPU quotas page, read 2026-09-15, states: "The vCPU quotas for virtual machines and scale sets are arranged in two tiers for each subscription, in each region. The first tier is the Total Regional vCPUs, and the second tier is the various VM size family cores such as the D-series vCPUs." The command for reading that number is named on the same page: "You can check your quota usage using az vm list-usage." The page's sample output lists rows such as "Standard DSv3 Family vCPUs" with a current value and a limit, one row per family. The Azure CLI reference for the command, read the same day, describes it in one line: "List available usage resources for VMs."

The same quotas page separates two ideas: "Azure checks quota and capacity separately. Quota is your subscription's permission to deploy a certain number of vCPUs or VMs. Capacity is the actual compute resources available in the selected region or availability zone." It follows with the consequence: "Even with sufficient quota, deployments can still fail if Azure doesn't have enough capacity for your requested VM size in the target region or zone." The page warns that capacity can fail. Its Check usage section offers only the quota command, and it does not name the command that shows, size by size, whether this subscription may deploy that size in that region.

What the SKU command reports

A distinct Microsoft page, Resolve errors for SKU not available, read 2026-09-15, describes a failure with its own error codes. Its Cause section names this scenario: "When the resource SKU you've selected, such as VM size, isn't available for a location or zone." In the Azure portal activity log the page says the error appears as SkuNotAvailable or InvalidTemplateDeployment. The Cause section lists exactly two triggers, unavailability for a location or zone, and Spot capacity. Quota is not among them.

The check for it is a different command. The same page: "To determine which SKUs are available in a location or zone, use the az vm list-skus command," and it names the flag that matters: "--all shows all information and includes sizes that aren't available for the current subscription." The page adds that by default only SKUs without restrictions are displayed, which is why the flag matters. The Azure CLI reference for that command, read 2026-09-15, states its scope directly: "This command incorporates subscription level restriction, offering the most accurate information." Its table output carries a Restrictions column, and the shape Microsoft prints in that page's own sample is NotAvailableForSubscription, type: Zone, locations: centralus, zones: 1,2,3.

The Resource Skus - List REST reference, API version 2021-07-01, read 2026-09-15, names the enumeration behind that value, ResourceSkuRestrictionsReasonCode, with exactly two values, QuotaId and NotAvailableForSubscription, and an empty description column for both. The nearest plain-English gloss this check found is on the Python API reference for the Azure Storage management SDK, which documents the same two value names for Storage SKU restrictions and says the second value "is related to capacity at DC." That page documents Storage SKUs. For Compute it is a hint about the meaning, and the Compute reference itself stays silent.

Why it is easy to get wrong

One command answers the family-quota question and reads as an answer to the deployment question too, because both are phrased in the same words: size, family, vCPU. An operator who runs az vm list-usage, sees a family well under its limit, and treats that as clearance to deploy has read a permission check as if it were an availability check. The quotas page does warn about capacity, but its only check is the quota command, so a reader who follows the page step by step finishes with a quota number and no per-size answer. The restriction measured below is reported by a different command, against a different object, with a reason code the quota output never surfaces.

What it costs

A deployment plan built from az vm list-usage alone can name a VM size that reads as available and is not. The SKU-not-available page describes where that surfaces: az vm create or New-AzVM fail with a message that the requested size is not available in the location or zone, and an ARM template or Bicep deployment fails validation with InvalidTemplateDeployment and does not start. Either way the answer arrives at deployment time, after the plan has already committed to a region and a size. On the subscription measured below every size in the family carries the restriction, so switching to a sibling size inside the same family would meet the same entry.

Test conditions

Run 2026-09-15 against one Azure subscription with Azure CLI 2.87.0. Two read-only list operations, neither creating anything: az vm list-usage --location <region> for the family quota, and az vm list-skus --resource-type virtualMachines --location <region> --all for the per-size restriction list. Run against northeurope in full, then repeated against swedencentral for the family-quota figures only. The full outputs were saved as JSON and cross-referenced by the family field each SKU entry carries. No virtual machine was created.

# Read-only. Family-level vCPU quota for two B-series families.
az vm list-usage --location northeurope \
  --query "[?name.value=='standardBSFamily' || name.value=='standardBsv2Family'].{family:name.value, used:currentValue, limit:limit}" \
  -o table

# Read-only. Every size in one family, with each restriction's type and reason.
az vm list-skus --resource-type virtualMachines --location northeurope --all \
  --query "[?family=='standardBSFamily'].{size:name, type:restrictions[].type, reason:restrictions[].reasonCode}" \
  -o json

Results

Measured 2026-09-15 in northeurope, az vm list-usage reported standardBSFamily at 0 used against a limit of 10, ten vCPUs free. The same call reported standardBsv2Family, the v2 B-series family, at 0 used against a limit of 0, no headroom at all. Both figures reproduced in swedencentral on the same subscription: standardBSFamily 0 of 10, standardBsv2Family 0 of 0.

az vm list-skus --resource-type virtualMachines --location northeurope --all returned ten VM sizes whose family field reads standardBSFamily: Standard_B1ls, B1s, B1ms, B2s, B2ms, B4ms, B8ms, B12ms, B16ms and B20ms. Every one of the ten carries two restriction entries, one with type: Location and one with type: Zone, both with reasonCode: NotAvailableForSubscription, both scoped to northeurope. Ten free vCPUs of quota, and none of the ten sizes that quota governs is free of a restriction in that region on this subscription. The eleven standardBsv2Family sizes each carry a Zone entry with the same reason code, on top of the limit of 0.

flowchart TD
  accTitle: Reading free vCPU quota before a VM deployment
  accDescr: A decision tree. If the family limit is not above current use, schedule a quota request. If it is, check the specific size in the SKU list, then act now and deploy when it has no restriction entry, or schedule a SKU request when it has one.
  A{Family limit above use?} -->|no| B[Schedule quota request]
  A -->|yes| C{Size restricted here?}
  C -->|no entry| D[Act now, deploy size]
  C -->|entry present| E[Schedule SKU request]

The same northeurope list-skus response held 1,298 virtualMachines entries, of which 195 carried no restriction of any kind. Cross-referencing the whole response against the family quota rows from the same run: of the 784 sizes that sit in a family with a nonzero limit, 754 carry a restriction, and of the 195 unrestricted sizes, 165 sit in a family whose limit is 0. The 30 sizes that are both unrestricted and inside a family with a nonzero limit fall into three families: 26 in two M-series v3 families, from 16 to 176 vCPUs each by the vCPUs capability in the same response, and 4 in standardNVSv4Family, from 4 to 32 vCPUs.

Failures

One planning assumption failed outright: that a family with quota headroom has at least one deployable size inside it. On this subscription, in northeurope, that assumption failed for all ten sizes in standardBSFamily at once. A second assumption, that the Compute reference documents what a restriction's reason code means, also failed: the Compute REST reference lists QuotaId and NotAvailableForSubscription with an empty description column, and the only explanatory sentence this check found sits on a Storage SDK reference page.

Limitations

One subscription, one day, two regions checked for the family quota figures and one region checked for the full per-size restriction list. The measurement does not establish that standardBSFamily is restricted on every subscription, in every region, or that it stays restricted after 2026-09-15. The SKU-not-available page directs a SKU request to Azure Support when a size is not available for a subscription in a location that meets business needs; that path was not tested here, and nothing in this note says how long such a request takes or whether it succeeds. The note does not cover Spot VM capacity, which the SKU-not-available page names as a separate cause, and it does not cover availability sets, disks or any resource type other than virtualMachines. The 30-size cross-reference is a property of this one subscription's quota limits and says nothing about which sizes are deployable on a different subscription.

Checking the restriction before trusting the quota number belongs in any Azure capacity plan, including the kind built for a client's own Azure cloud infrastructure landing zone.