Capacity Planning
Purpose
Analyze current resource utilization, quota consumption, and growth trends to predict capacity risks and recommend scaling actions before limits are hit.
When to use this skill
- User asks "will our infrastructure handle the traffic spike?"
- User asks about quotas, limits, or capacity
- Pre-event planning (Black Friday, product launch, marketing campaign)
- Quarterly capacity review
- After hitting a quota or throttling limit
Pre-check
Confirm with the user:
- Scope: which subscriptions and regions
- Time horizon: when is the expected load increase? (default: 30 days)
- Expected growth factor (e.g., 2x, 5x, 10x current load)
- Critical workloads to prioritize
Assessment procedure
Step 1: Quota utilization
Check current quota usage across all critical resource providers.
az vm list-usage --location <region> -o table
az network list-usages --location <region> -o table
az storage account list --query "length(@)"
Check for:
- vCPU quotas: Total and per-family (Dv5, Ev5, etc.) — flag if > 70% utilized
- Public IPs: Usage vs. limit
- Load balancers: Usage vs. limit
- Network interfaces: Usage vs. limit
- Storage accounts per subscription: Usage vs. 250 limit
- App Service plans per region
- AKS clusters per subscription
Build a quota utilization table. Use Unicode emoji characters directly (🟢🟡🔴) — never use emoji shortcodes like :green_circle: or :red_circle:.
| Resource | Region | Used | Limit | Utilization | Risk |
|---|---|---|---|---|---|
| Total vCPUs | East US | 85 | 100 | 85% | 🔴 |
| Dv5 vCPUs | East US | 32 | 50 | 64% | 🟡 |
| Public IPs | East US | 8 | 20 | 40% | 🟢 |
Step 2: Compute capacity
Analyze current compute utilization and headroom.
VM utilization (last 14 days):
- Average and P95 CPU across all VMs
- Average and P95 memory (if available via Log Analytics)
- Flag VMs consistently > 80% CPU or memory
App Service plan utilization:
az appservice plan list --query "[].{name:name, sku:sku.name, workers:numberOfWorkers, maxWorkers:maximumElasticWorkerCount}" -o table- Current instance count vs. max
- CPU/memory % of the plan
- Autoscale rules and current headroom
AKS cluster capacity:
az aks list --query "[].{name:name, nodeCount:agentPoolProfiles[0].count, maxCount:agentPoolProfiles[0].maxCount, vmSize:agentPoolProfiles[0].vmSize}" -o table- Node count vs. max count
- Pod density per node
- Cluster autoscaler configuration
Container Apps:
- Current replicas vs. max replicas
- Autoscale rules (HTTP concurrency, CPU, custom)
Step 3: Data layer capacity
SQL Database:
- DTU/vCore utilization (avg and P95)
- Storage usage vs. max size
- Connection count vs. limit
Cosmos DB:
- RU consumption vs. provisioned (or autoscale max)
- Storage per container
- 429 (throttling) rate from metrics
Redis Cache:
- Memory usage %
- Connection count vs. max
- Server load %
Storage accounts:
- Ingress/egress patterns
- Transaction rates vs. limits
- Blob count growth rate
Step 4: Networking capacity
- ExpressRoute / VPN Gateway: Bandwidth utilization %
- Application Gateway / Front Door: Connection count, throughput
- NAT Gateway: SNAT port utilization
- DNS zones: Query volume trends
Step 5: Growth projection
Based on the data collected:
- Plot utilization trends for the last 90 days
- Apply linear projection to estimate when each resource hits 80% and 100%
- If the user specified a growth factor, multiply current usage and check against limits
Build a risk timeline:
| Resource | Current | At 2x Load | At 5x Load | Hits Limit | Action Needed |
|---|---|---|---|---|---|
| vCPUs East US | 85/100 | 170 ❌ | 425 ❌ | Now | Quota increase |
| SQL DTU | 60% | 120% ❌ | 300% ❌ | At 1.7x | Scale up tier |
| AKS nodes | 5/10 | 10/10 ⚠️ | 25 ❌ | At 2x | Increase max |
| Redis memory | 45% | 90% ⚠️ | 225% ❌ | At 2.2x | Upgrade SKU |
Step 6: Quota increase requests
For any quota that needs increasing, generate the correct request command:
# Request a quota increase via the Azure portal Support + Troubleshooting flow,
# or use the REST API directly:
az rest --method patch \
--url "https://management.azure.com/subscriptions/<sub-id>/providers/Microsoft.Capacity/resourceProviders/Microsoft.Compute/locations/<region>/serviceLimits/StandardDv5Family?api-version=2020-10-25" \
--body '{"properties":{"limit":{"limitObjectType":"LimitValue","value":<new-limit>}}}'
Note: The az quota CLI extension is in preview and syntax may change. The REST API approach above is stable. Alternatively, guide users to submit quota requests via the Azure portal: Help + support > New support request > Service and subscription limits (quotas).
Step 7: Recommendations
For each risk identified:
- Immediate: Quota increase requests, SKU upgrades
- Short-term (1-2 weeks): Autoscale configuration, caching layers
- Long-term: Architecture changes (sharding, async patterns, CDN)
Accepted exceptions (optional)
If the user provides a list of accepted exceptions, do not flag those items. Instead, note them in the report as Accepted Exception with the reason provided.
Example format the user may provide:
| Check | Reason |
|---|---|
| 1.1 vCPU quota utilization | Quota increase already submitted, awaiting approval |
| 2.3 AKS cluster capacity | Cluster is scheduled for decommission next month |
| 4.2 Application Gateway throughput | Traffic is seasonal, current capacity is intentional |
When exceptions are provided:
- Skip the flagged checks in scoring
- List them in a separate "Accepted Exceptions" section at the end of the report
- Recalculate the overall score excluding excepted checks
Expected output
Report header (mandatory — use this exact format)
Capacity Planning Report
| Field | Value |
|---|---|
| Subscription | (name + ID) |
| Assessment Date | YYYY-MM-DD |
| Region(s) Assessed | (list) |
Capacity summary
| Metric | Value |
|---|---|
| 🏗️ Resources scanned | X |
| ⚠️ Resources at risk (>70% capacity) | Y |
| 🔴 Resources critical (>90% capacity) | Z |
| 📈 Projected limit breach within 30 days | W resources |
Risk matrix
Table with all resources, current utilization, projected utilization at specified growth factor, and recommended action.
Scaling runbook
Step-by-step actions to prepare for the expected load increase, ordered by priority and dependency.
Remediation guidance
For each capacity risk identified, include in the output:
- The specific
azCLI command to remediate (quota increase, scale-up, autoscale config) - Use
GetAzCliHelpto validate the command syntax before suggesting - The official Microsoft Learn documentation link
References
- Quotas Overview: https://learn.microsoft.com/en-us/azure/quotas/quotas-overview
- VM Sizes: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/overview
- Autoscale: https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-overview
- App Service Scaling: https://learn.microsoft.com/en-us/azure/app-service/manage-scale-up
Sample output
The following is a redacted example of what the report looks like when run against a subscription.
Capacity Planning Report
| Field | Value |
|---|---|
| Subscription | contoso-prod-001 (a1b2c3d4-e5f6-7890-abcd-ef1234567890) |
| Assessment Date | 2026-07-15 |
| Region(s) Assessed | East US, West Europe |
Capacity summary
| Metric | Value |
|---|---|
| 🏗️ Resources scanned | 47 |
| ⚠️ Resources at risk (>70% capacity) | 5 |
| 🔴 Resources critical (>90% capacity) | 2 |
| 📈 Projected limit breach within 30 days | 1 resource |
Risk matrix (sample)
| Resource | Region | Current | At 2x Load | Hits Limit | Action Needed |
|---|---|---|---|---|---|
| Total vCPUs | East US | 85/100 (85%) | 170 ❌ | Now | Quota increase |
| Dv5 vCPUs | East US | 32/50 (64%) | 64 ⚠️ | At 1.6x | Quota increase |
SQL DTU sql-contoso-prod |
East US | 78% avg | 156% ❌ | At 1.3x | Scale up tier |
AKS nodes aks-app-prod |
West Europe | 7/10 | 14 ❌ | At 1.4x | Increase max count |
| Public IPs | East US | 8/20 (40%) | 16 🟢 | At 2.5x | Monitor |
Scaling runbook (sample)
| Priority | Action | Resource | Estimated Time |
|---|---|---|---|
| 1 | Request vCPU quota increase to 200 | East US subscription | 1–3 business days |
| 2 | Scale SQL DB from S3 to S4 | sql-contoso-prod |
15 min (online) |
| 3 | Increase AKS max node count to 20 | aks-app-prod |
5 min |
Remediation guidance (sample)
# Request vCPU quota increase via REST API
az rest --method patch \
--url "https://management.azure.com/subscriptions/a1b2c3d4-.../providers/Microsoft.Capacity/resourceProviders/Microsoft.Compute/locations/eastus/serviceLimits/StandardDv5Family?api-version=2020-10-25" \
--body '{"properties":{"limit":{"limitObjectType":"LimitValue","value":200}}}'
# Scale up SQL Database
az sql db update --resource-group rg-data-prod --server sql-contoso-prod --name appdb --service-objective S4