Azure OpenAI deployment creation fails: InsufficientQuota, model not available in region and policy denials

A pipeline or a person tries to create a new Azure OpenAI deployment, or raise the capacity of an existing one, and it fails. The portal shows a red banner, or az, Bicep or Terraform stops with an error. Existing deployments keep working. This is a control-plane problem, not an outage, but it can block a release or a scale-up during peak load.

Read the error code first. Almost every failure falls into one of the rows below.

#Symptom → cause → fix

Error codes and message text change between API versions. If your error isn't listed here, search the full message for the words "quota", "capacity", "region" or "policy".

Set these variables for the checks:

RG=rg-ai-prod
ACCT=aoai-prod-swc
LOC=swedencentral
SUB=$(az account show --query id -o tsv)

#Check 1: quota

Quota belongs to the subscription and region, and is tracked per model and deployment type. Every account in the same subscription and region draws from the same pool. When another team's account in Sweden Central uses 400K TPM of gpt-4.1, you have that much less.

az cognitiveservices usage list -l $LOC \
  --query "[?contains(name.value,'OpenAI')].{quota:name.value, used:currentValue, limit:limit}" -o table

Quota names look like OpenAI.GlobalStandard.gpt-4.1. The format varies by deployment type, so match the name to what you are creating. Available capacity is limit - used. For token-based SKUs the unit is 1,000 TPM, so --sku-capacity 50 needs 50 units free.

To find who is using the quota, list deployments for each account in that region:

az cognitiveservices account list \
  --query "[?location=='$LOC' && (kind=='OpenAI' || kind=='AIServices')].[resourceGroup, name]" -o tsv |
while read -r rg acct; do
  echo "== $rg/$acct"
  az cognitiveservices account deployment list -g "$rg" -n "$acct" \
    --query "[].{deployment:name, model:properties.model.name, sku:sku.name, capacity:sku.capacity}" -o table
done

Look for test deployments with large capacity that get no traffic. Check their AzureOpenAIRequests metric before you change anything.

#Fixes for quota errors

# Request less capacity
az cognitiveservices account deployment create -g $RG -n $ACCT \
  --deployment-name chat-canary \
  --model-format OpenAI --model-name gpt-4.1 --model-version 2025-04-14 \
  --sku-name GlobalStandard --sku-capacity 20

# Reduce an over-sized deployment to free quota for others
az cognitiveservices account deployment update -g $RG -n $ACCT \
  --deployment-name chat-test --sku-capacity 10

Warning

Lowering capacity on a deployment that serves traffic lowers its TPM and RPM limits immediately, and its callers start getting 429s. Check the deployment's peak token usage over the last week before you reduce it.

Other options:

• Use a different deployment type. Standard, GlobalStandard and DataZoneStandard have separate quota pools. Only do this if the data residency of the new type is acceptable.
• Deploy in another region where you have quota, and route to it through your gateway.
• Request a quota increase in the Foundry portal's quota page. Approval is not instant, so don't rely on it during an incident.

Some deleted deployments can keep their quota reserved for a while after deletion. If usage list still shows quota as used after you delete something, wait and check again before you raise a ticket.

#Check 2: model, version and SKU availability

A model name that works in one region may not exist there with the version or deployment type you asked for. Check what the region and the account actually offer:

# What this account can deploy, with lifecycle status
az cognitiveservices account list-models -g $RG -n $ACCT \
  --query "[?name=='gpt-4.1'].{model:name, version:version, lifecycle:lifecycleStatus, skus:skus[].name}" -o json

# What the region offers
az cognitiveservices model list -l $LOC \
  --query "[?model.name=='gpt-4.1'].{version:model.version, skus:model.skus[].name}" -o json

Field names in this output vary by CLI and API version. If a query comes back empty, run it without --query and look at the raw JSON.

Common causes:

• The version string in your template is wrong or out of date. Bicep and Terraform files often hard-code a version that has since been retired for new deployments.
• The SKU isn't offered for that model in that region, for example Standard when only GlobalStandard exists.
• The account is kind=OpenAI but the model is only offered on AIServices accounts, or the reverse.

Tip

Don't hard-code model versions in several templates. Keep them in one parameter file, and check that file against list-models in CI so a retired version fails the pipeline before deployment.

#Check 3: permissions

Creating deployments is a control-plane write. Data-plane roles such as Cognitive Services OpenAI User let you call models but not create deployments.

ID=$(az cognitiveservices account show -g $RG -n $ACCT --query id -o tsv)
az role assignment list --scope $ID --include-inherited \
  --query "[].{who:principalName, role:roleDefinitionName}" -o table

The pipeline identity needs Cognitive Services Contributor, Contributor, or a custom role that includes Microsoft.CognitiveServices/accounts/deployments/write. New role assignments can take a few minutes to take effect.

#Check 4: Azure Policy

A RequestDisallowedByPolicy error names the policy assignment. Read it:

az policy assignment list --disable-scope-strict-match \
  --query "[?contains(displayName,'OpenAI') || contains(displayName,'Cognitive')].{name:name, display:displayName, scope:scope}" -o table

az policy state list --resource $ID \
  --query "[?complianceState=='NonCompliant'].{policy:policyDefinitionName, assignment:policyAssignmentName}" -o table

Platform teams often allow only approved models, deployment types or regions. Ask for the change through the policy owner rather than creating an exemption to get past it.

#Verify

az cognitiveservices account deployment show -g $RG -n $ACCT --deployment-name chat-canary \
  --query "{state:properties.provisioningState, model:properties.model.name, version:properties.model.version, sku:sku.name, capacity:sku.capacity}"

Wait for provisioningState to be Succeeded, then send a test call before you switch traffic to the new deployment.

#Prevent it next time

• Run usage list for every region you use each week, and alert when any model's quota is more than 80% allocated.
• Keep a register of deployments with owner and purpose, and remove test deployments that have had no traffic for 30 days.
• Run a what-if or plan step in CI (az deployment group what-if, terraform plan) and check model versions against list-models there.
• Request quota increases weeks before a launch, not on launch day.
• Give pipeline identities a narrow custom role with deployment write rights instead of subscription Contributor.