Three different things
| Type | Example | Can you raise it? |
|---|---|---|
| Quota (per subscription/region) | vCPUs per VM family, public IPs | Yes, by request (often automatic) |
| Service limit | Max storage account request rate, max NSG rules, Key Vault transactions per 10 s | Some adjustable, many fixed |
| Capacity | GPU or large VM sizes physically available in a zone/region | Not a quota; reservations or region choice |
Treat each differently in design.
1. Inventory what your design depends on
For a new platform or major scale event, list:
| Area | Typical items to check |
|---|---|
| Compute | vCPU per family per region, total regional vCPU, GPU families, VMSS instances |
| Network | Public IPs, VNet peerings per VNet, private endpoints per VNet, NSG rules, route table entries, Firewall IP/FQDN counts |
| Storage | Storage accounts per region per subscription, request/ingress limits per account |
| AKS | Nodes per cluster, pods per node (CNI choice), clusters per subscription |
| App Service | Instances per plan, apps per plan (performance) |
| Key Vault | Transactions per vault per 10 seconds |
| Monitoring | Log Analytics ingestion rate, alert rules per subscription |
| AI services | Tokens/requests per minute per deployment and region |
Check the current documented values. They change, and many vary by SKU.
2. Monitor usage
az vm list-usage --location centralindia -o table
az network list-usages --location centralindia -o table
az quota usage list --scope /subscriptions/<sub>/providers/Microsoft.Compute/locations/centralindia -o table
The Quotas page in the portal can create usage alerts; set alerts at ~80% for the quotas your scale depends on.
3. Request increases ahead of need
- Before each go-live, migration wave or seasonal peak, request quota with headroom (peak + DR failover need).
- Include the DR region. Failover fails if the secondary has no quota.
- Automate common requests with the Quota API for subscription vending.
4. Capacity reservations for critical scale
On-demand capacity reservations guarantee VM capacity in a region/zone for a size, billed whether used or not (can be combined with reserved-instance pricing). Use for:
- Tier 1 workloads that must scale or fail over at a known moment.
- GPU or large memory sizes known to be scarce.
5. Design to avoid hard limits
| Limit pressure | Design response |
|---|---|
| Storage account request rate | Spread data across accounts, use partition-friendly naming |
| Key Vault throttling | Cache secrets in apps; vault per app |
| Subscription-level limits | Subscription per workload/environment (subscription vending) |
| AKS pod IPs | Overlay CNI or larger subnets; plan IP space early |
| Peering count on a hub | Virtual WAN or multiple hubs |
| Private endpoints per VNet | Distribute or centralise thoughtfully |
6. Make it part of change and design reviews
Add "quotas, limits and capacity checked for primary and DR regions" as a design review gate and a go-live checklist item, with evidence (screenshots or command output).
Warning
"Allocation failed" during a scale-out or DR failover is a capacity problem, not a quota problem. A quota increase won't fix it. Alternatives are other sizes, other zones, another region, or capacity reservations.
Checklist
- Quotas, limits and capacity dependencies listed
- Usage monitored with alerts at ~80%
- Increases requested ahead of peaks, including DR region
- Capacity reservations for critical/scarce sizes
- Architecture spreads load away from hard limits
- Gate in design reviews and go-live checklists