Azure Quotas

Azure Quotas

Plan quota headroom early so deployments and scale events do not fail unexpectedly. Identify bottlenecks before they become crises.

Use This Skill When

• The user sees quota or capacity errors in Azure (DeploymentQuotaExceeded, etc.)
• The user plans a new deployment in a constrained region or subscription
• The user needs preflight checks before scaling operations
• The user wants to verify available capacity before committing to architecture

Context: Quota Management Maturity

Immature: Hit quota limits unexpectedly, manual increases, no planning Developing: Track some quotas, request increases reactively Managed: Automated quota tracking, capacity planning, reserved capacity → Target Optimized: Predictive quota management, auto-scaling to new regions, zero surprises

Required Inputs

• Subscription ID & region: Where are you deploying?
• Planned resources: How many VMs? App Services? SQL databases?
• Scale targets: Current vs. planned capacity?
• Timeline: Immediate (next week)? Next quarter? Next year?
• Compliance: Any data residency or region-specific needs?

Decision Tree

Where does this workload run?
├─ Single region (lowest complexity)
│  └─ Can fall back to alternative region if quota exceeded?
├─ Multi-region (higher complexity, but better resilience)
│  └─ Distribute across regions to avoid single-region limits
└─ Hybrid (on-premises + Azure)
   └─ Plan data transfer, bandwidth quotas

What's the expected scale?
├─ Small ( 100 VMs, > 1 TB data)
   └─ Request increases in advance, plan multi-region

Are quotas the risk, or SKU availability?
├─ Quota (limit per subscription) → Request increase
├─ SKU availability (no machines available) → Fallback to alternative SKU or region
└─ Cost (exceeding budget) → Use Reserved Instances to cap costs

Workflow

Phase 1: Identify Quota-Limited Services

1. Compute quotas (most common bottleneck):

```bash # Check vCPU quotas by family az vm list-usage --location "eastus" -o table

# Output Name CurrentValue Limit Standard D Family vCPUs 10 20 ← Can add 10 more Standard B Family vCPUs 5 20 ← Plenty available Standard E Family vCPUs 0 20 ← None used yet ```

1. Storage quotas:

```bash # Get current storage account usage az storage account list --query "[].{name:name, tier:sku.name, kind:kind}" -o table

# Limit: 250 storage accounts per subscription # Each can be up to 5PB (petabytes) ```

1. Database quotas:

```bash # SQL Server quota (per region, per subscription) az sql server list --query "[].{name:name, region:location}" -o table

# Limit: 15 servers per subscription, per region ```

1. Networking quotas:

`` Network Security Groups: 100 per region VNets: 100 per subscription Public IPs: 60 per region Load Balancers: 1 per region (basic), 100 (standard) Application Gateways: 20 per subscription ``

1. Other quota-limited services:

`` App Service Plans: 100 per resource group Batch Accounts: 1-3 per region Cognitive Services: Varies by service (Speech, Vision, etc.) Media Services: Limited slots per subscription Redis Cache: 50 per subscription Search Services: 15 per subscription ``

Phase 2: Check Current Usage vs. Limits

1. Get quota status:

```bash # All quotas for a region az provider show --namespace Microsoft.Compute \ --query "resourceTypes[?resourceType=='virtualMachines'].limits" -o table

# Output limitName limitValue vCpuCountPerRegion 20 vCpuCountPerVmFamily 20 standardBFamilyvCpusCount 20 standardDFamilyvCpusCount 20 ```

1. Calculate usage:

```bash # Count running VMs and vCPUs az vm list --query "[] | length(@)" -o json → 8 VMs az vm list --query "sum(hardwareProfile.vmSize)" → 24 vCPUs

# Available headroom Quota: 20 vCPUs Used: 24 vCPUs ← OVER QUOTA! Available: -4 ← Must request increase ```

1. Regional availability:

```bash # Check which regions have which SKUs available az vm list-skus --location "eastus" --resource-type virtualMachines \ --query "[?name=='StandardD4sv3'].restrictions[].restrictionInfo" -o table

# If no restrictions shown, SKU available in that region ```

Phase 3: Request Quota Increases

1. Request vCPU increase (most common):

```bash # Using Azure Portal or CLI az provider register --namespace Microsoft.Capacity

# Submit request az rest --method post \ --uri "https://management.azure.com/subscriptions/$SUBID/providers/Microsoft.Capacity/quotaRequests?api-version=2021-12-01" \ --body '{ "sku": { "name": "StandardDFamily" }, "properties": { "quotaIncreaseAmount": 20 } }' ```

1. Timeline for approval:

`` vCPU quota increases: ├─ Low demand regions ( 50 vCPU) → Manual review, 3-5 business days └─ Regional capacity issues → May be denied or partially approved ``

1. What if denied?

`` ├─ Fallback to alternative SKU (larger memory, different vCPU count) ├─ Deploy to different region (check availability first) ├─ Use spot VMs (temporary, interruptible, no quota cost) └─ Scale sequentially instead of all at once ``

Phase 4: Capacity Planning

1. Forecast future needs:

``` Current state (baseline): ├─ VMs: 5 × D4s_v3 (32 vCPUs) ├─ Target SLA: 99.9% uptime └─ Growth: 20% year-over-year

Planned expansion (6 months): ├─ Add new customer segment: +8 VMs (64 vCPUs) ├─ High-availability zones: Need redundant instances └─ Total needed: 96 vCPUs (3× current)

Recommendation: └─ Request 120 vCPU quota now (headroom for spikes) ```

1. Design for quota resilience:

``` Option 1: Single region (simpler, quota-constrained) ├─ All VMs in eastus ├─ If quota exhausted, deployment fails ├─ RTO: Long (manual intervention needed)

Option 2: Multi-region (resilient, but complex) ├─ Primary: eastus (60% of VMs) ├─ Secondary: westus2 (40% of VMs) ├─ If eastus quota full, auto-failover to westus2 ├─ RTO: Seconds (auto-failover) ```

1. Reserved capacity (guaranteed slots):

```bash # Reserve vCPU capacity for 1-3 year term # Cost: 30-50% savings vs. on-demand # Benefit: Guaranteed availability, no quota issues

# Example: 96 vCPU (24 × D4s_v3 for 3 years) Cost on-demand: ~$3,500/month = $126K/year Cost reserved: ~$1,750/month (50% off) = $63K/year Savings: $63K/year over 3 years ```

Phase 5: Pre-Deployment Validation

1. Quota checklist before major deployments:

``` Deployment: Production migration (100 VMs, 400 vCPUs)

✓ vCPU quota: 500 available, need 400 → OK ✓ Storage accounts: 10 used, limit 250 → OK ✓ SQL Servers: 2 used, limit 15 → OK ✓ App Service Plans: 8 used, limit 100 → OK ✓ Public IPs: 12 used, limit 60 → OK ✓ NSGs: 25 used, limit 100 → OK

✓ Regional availability: StandardD4sv3 in eastus → OK ✓ Fallback region: westus2 has same SKU available → OK

Status: GREEN - Ready to deploy ```

1. Quota monitoring during scale:

``bash # Set alert for quota usage az monitor metrics alert create \ --name "cpu-quota-warning" \ --resource-group $RG \ --scopes "/subscriptions/$SUBID" \ --condition "total ComputeQuotaUsage >= 80" \ --window-size "PT15M" \ --evaluation-frequency "PT5M" \ --actions email_action "ops@company.com" ``

Phase 6: Handle Quota Errors

1. Common errors & solutions:

``` Error: DeploymentQuotaExceeded ├─ Cause: vCPU quota exhausted ├─ Solution: Request increase or deploy to alternate region

Error: SkuNotAvailable ├─ Cause: SKU not available in chosen region ├─ Solution: Use different region, different SKU, or spot VMs

Error: ResourceQuotaExceeded (non-compute) ├─ Cause: Limit on databases, storage accounts, etc. ├─ Solution: Check specific service quotas, request if needed ```

1. Workarounds for immediate needs:

``` If quota exceeded AND request takes days:

Option 1: Use Spot VMs (low-cost, interruptible) ├─ Immediately available (no quota) ├─ 70-90% cost savings ├─ Risk: Can be evicted (5-30 min notice) └─ Use for: Non-critical workloads, batch jobs, auto-scale

Option 2: Fallback to different region ├─ Check alternate region quota (often more available) ├─ Deploy there temporarily ├─ Risk: Higher latency, data residency may not apply

Option 3: Downsize temporary ├─ Use smaller VMs to fit current quota ├─ Scale up later when quota increase approved ├─ Risk: Performance impact during wait ```

Output Contract

1. Current Quota Status

• Quotas per service (compute, storage, database, networking)
• Current usage vs. limit
• Headroom available

1. Capacity Assessment

• Can planned workload fit in current quotas?
• What quotas need increases?
• Timeline for requests

1. Risk Analysis

• Single point of quota failure?
• Regional availability constraints?
• Fallback regions and their quotas?

1. Recommendations

• Increase requests (which, how much, when?)
• Architectural changes (multi-region, different SKU)?
• Reserved capacity (cost savings)?

1. Pre-Deployment Checklist

• All quotas sufficient? (Yes/No)
• Fallback strategy documented?
• Monitoring alerts configured?

Guardrails

• Always check quotas before major deployments: Don't discover limits mid-cutover.
• Request increases in advance: Lead time can be days; don't wait until needed.
• Verify SKU availability by region: Not all sizes available everywhere.
• Plan multi-region for resilience: Single-region is quota-constrained and brittle.
• Monitor quota usage: Set alerts at 70% to plan proactively.
• Document quota-critical paths: Identify which failures are quota-related vs. other issues.
• Test fallback regions: Ensure workload actually runs in alternate region before relying on it.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: manu14357
• Source: manu14357/zskills
• License: MIT
• Homepage: https://zskills.vercel.app

Install and usage instructions live in the source repository linked above.