# Azure Quotas

> Assess and manage Azure service quotas and limits to prevent deployment and scaling failures. Use this skill when users ask about quota errors, capacity planning, regional availability, or resource limits.

- Skill: `manu14357/azure-quotas` (Agent Skill)
- Install (CLI): `npx skillmds add manu14357/azure-quotas`
- Raw SKILL.md: https://api.skillmd.com/api/skills/manu14357/azure-quotas/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: manu14357 (https://skillmd.com/u/manu14357)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/manu14357/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 (< 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):
   ```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
   ```

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

3. **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
   ```

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**:
   ```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
   ```

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

3. **Regional availability**:
   ```bash
   # 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):
   ```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
       }
     }'
   ```

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

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

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.