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 (< 10 VMs, < 100 GB data)
│  └─ Quota rarely an issue
├─ Medium (10-100 VMs, 100 GB - 1 TB data)
│  └─ Plan quotas for compute tier
└─ Large (> 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):

   # 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
   

2. Storage quotas:

   # 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)
   

3. Database quotas:

   # 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
   

4. 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
   

5. 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:

   # 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
   

2. Calculate usage:

   # 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
   

3. Regional availability:

   # Check which regions have which SKUs available
   az vm list-skus --location "eastus" --resource-type virtualMachines \
     --query "[?name=='Standard_D4s_v3'].restrictions[].restrictionInfo" -o table
   
   # If no restrictions shown, SKU available in that region
   

Phase 3: Request Quota Increases

1. Request vCPU increase (most common):

   # 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
       }
     }'
   

2. Timeline for approval:

   vCPU quota increases:
   ├─ Low demand regions (< 10 vCPU increase) → Auto-approved, 5 minutes
   ├─ Medium increase (10-50 vCPU) → Reviewed, 1-2 business days
   ├─ Large increase (> 50 vCPU) → Manual review, 3-5 business days
   └─ Regional capacity issues → May be denied or partially approved
   

3. 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)
   

2. 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)
   

3. Reserved capacity (guaranteed slots):

   # 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: Standard_D4s_v3 in eastus → OK
   ✓ Fallback region: westus2 has same SKU available → OK
   
   Status: GREEN - Ready to deploy
   

2. Quota monitoring during scale:

   # 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
   

2. 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

2. Capacity Assessment

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

3. Risk Analysis

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

4. Recommendations

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

5. 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.