Add quota and capacity pre-flight checks before ARM deployment

[spboyer]

Problem

Quota and capacity errors account for ~3,605 errors (2.82%) over 90 days. Users deploy templates, wait for provisioning, then fail with InsufficientQuota, SkuNotAvailable, or LocationIsOfferRestricted. These failures are predictable and could be caught before deployment begins.

Current Behavior

azd has excellent quota pre-checks for AI model deployments in pkg/ai/model_service.go (ResolveModelDeploymentsWithQuota(), ListLocationsWithQuota(), FilterModelsByQuota()). However, standard ARM provisioning in pkg/infra/provisioning/bicep/bicep_provider.go has no quota pre-checks.

azd already runs ARM preflight validation (ValidatePreflightToResourceGroup()) and what-if preview before deployment, but these do not check subscription quota.

Proposed Solution

1. After the what-if preview step, parse the output to identify resource types being created (VMs, Cognitive Services, OpenAI, etc.)
2. For high-quota-failure resource types, query the ARM quota/usage APIs:
   • Microsoft.Compute/locations/{location}/usages for VM SKUs
   • Microsoft.CognitiveServices quota endpoints for AI resources
3. Compare required capacity against remaining quota
4. If quota is insufficient, warn the user before deploying:
   • Warning: Your subscription has N of M vCPUs remaining in <region>. This deployment requires K vCPUs. Consider changing region with 'azd env set AZURE_LOCATION <region>' or requesting a quota increase.
5. Consider the AI model quota system in pkg/ai/model_service.go as an architectural reference for this feature

Data Reference

Source: AzdProvisionErrorsByTemplate + AzdDeploymentErrorsByTemplate (DevCli on ddazureclients)

• Quota / Capacity errors: 3,605 (2.82%)
• AI templates: 3.12%, Awesome-azd: 2.26%
• Key ARM codes: InsufficientQuota, SubscriptionIsOverQuotaForSku, SkuNotAvailable, LocationIsOfferRestricted, DeploymentModelNotSupported

[vhvb1989]

Consider changing region with 'azd env set AZURE_LOCATION ' or requesting a quota increase.

Ideally, I would like azd to look my entire resource-tree and give me the list of locations where I could deploy it all.

The use of templates with one single location for all resources makes it easy to wire things up in bicep/ARM and reduce the number of decisions to make. At the same time, as the number of resources increases, it set customers into a corner to find a valid location for a full set of resources.

I would try to break the idea of one-location-for-all and try to make azd to just find a valid location for each resource. I will create a POC for how that would look like.

[spboyer]

@JeffreyCA Your recent work on AI model quota (PR #6741, #6749) already covers the AI/Cognitive Services portion of this issue. The remaining gap is general-purpose quota pre-checks for non-AI resources (VMs, App Service plans, compute SKUs, etc.) which still account for a meaningful chunk of InsufficientQuota/SkuNotAvailable errors. Your pkg/ai/model_service.go pattern would be the architectural reference for extending this to standard ARM resources.

[spboyer]

Updated Telemetry: Quota Is 30% of InvalidTemplateDeployment

Deep dive into InvalidTemplateDeployment ARM error chains (March 2026, 23 days) using deepest-frame analysis:

Quota/SKU limits = 1,431 errors across 500 unique machines (30.3% of all InvalidTemplateDeployment errors). This is the single largest preventable root cause category. Projected ~1,860/month.

Specific Quota Error Breakdown

Error Code	Count	Top Service
SubscriptionIsOverQuotaForSku	526	App Service
InternalSubscriptionIsOverQuotaForSku	349	App Service
InsufficientQuota	298	Container Apps, AI
MaxNumberOfRegionalEnvironmentsInSubExceeded	177	Container Apps
MaxNumberOfGlobalEnvironmentsInSubExceeded	30	Container Apps
ServiceQuotaExceeded	34	Mixed

Retry Behavior Makes This Urgent

Of the 1,100 machines that experience 2+ InvalidTemplateDeployment failures:

• 66% never change their subscription or environment — they retry the exact same doomed deployment an average of 3.6 times
• For quota errors, retrying can never succeed without a quota increase or region change, but the error message does not communicate this
• Only 7% of retriers try a different subscription (90.3% recovery rate when they do)
• ~225 machines eventually give up without ever succeeding

User Time Cost

• 39.7 user-hours wasted per 23 days on quota failures alone
• Average wait: 100 seconds per failed attempt
• Multiply by 3.6 retries = ~6 minutes per user before they give up or figure it out

Impact of Implementing This

A quota preflight check would:

1. Eliminate ~1,431 deployment failures per 23 days (~1,860/month)
2. Save ~52 user-hours/month (including retry waste)
3. Guide users to actionable fixes immediately (change region, request increase)

The pattern exists in pkg/ai/model_service.go — ResolveModelDeploymentsWithQuota() already does this for AI models. Extending it to App Service, Container Apps, and Compute SKUs in the bicep_provider.go preflight pipeline would cover the majority of these errors.

[spboyer]

Reviewed during issue triage — keeping open.

Status update:

• AI model quota preflight landed in PR feat: add AI model quota preflight validation check #7672 (feat: add AI model quota preflight validation check), covering the Cognitive Services / OpenAI portion.
• The 30% InvalidTemplateDeployment finding from March 2026 confirms this is still the single largest preventable category — primarily App Service (SubscriptionIsOverQuotaForSku, InternalSubscriptionIsOverQuotaForSku) and Container Apps (MaxNumberOfRegionalEnvironmentsInSubExceeded, InsufficientQuota).

TL;DR remaining work:

• Extend the pkg/ai/model_service.go quota pattern into the Bicep provider's what-if step in bicep_provider.go.
• Cover Compute SKUs (Microsoft.Compute/locations/{location}/usages), App Service plans, and Container Apps environment limits.
• Surface results as an actionable warning before deployment — region suggestion + quota-increase link (matches @vhvb1989's "find a valid location for the whole resource tree" intuition).
• Avoid blocking provision; this is a warn-then-proceed gate, not a hard fail.

Pairs naturally with #7263 (soft-delete preflight) and #5424 (region filtering by provider) — same pipeline integration point.