Use this runbook when a create, scale or failover call fails with a quota, vCPU, family or API-rate limit. First action: copy the error text and look up that quota in Service Quotas, Azure Quotas, Cloud Quotas or Alibaba Quota Center for the same account and region. Do not raise autoscaler max or retry in a loop. Some quotas are adjustable; some are hard. An increase is a request, not an instant guarantee. If the standby region is the one that is exhausted, fix quota before you invoke region failover.
A quota is a documented cap on how much of a service an account, subscription or project may use. Exhaustion looks like an outage. Read the applied limit, then free usage or ask for more.
Symptoms
Create, scale or API calls fail with VcpuLimitExceeded, InsufficientQuota, QuotaExceeded, RESOURCE_EXHAUSTED, HTTP 429, or a console banner that usage equals the limit. Autoscaling activities cite quota (autoscaling failure). A DR test cannot create the standby footprint. Rate quotas and resource quotas both block work and need different fixes.
Business impact
You cannot grow or fail over until usage drops or the applied quota rises. Retries make API-rate exhaustion worse. Increases can require approval. Request them before the event that needs the capacity.
Immediate checks
- Copy the full error, including region, SKU family and quota code if present.
- Confirm the scope: AWS account and Region, Azure subscription and region, Google Cloud project (and sometimes organization), Alibaba account and region.
- Open the quota console for that service. Compare current usage to the applied value, not to a blog post of “defaults.”
- List unused resources of the same type (idle VMs, unattached public IPs, leftover load balancers).
- If this is the standby region for DR, stop the failover until headroom exists.
Provider commands and console paths
AWS Service Quotas. Service Quotas console, or AWS Support if the quota is not listed there. Service Quotas.
aws service-quotas list-service-quotas --service-code ec2
aws service-quotas get-service-quota --service-code ec2 --quota-code L-1216C47A
aws service-quotas list-requested-service-quota-change-history-by-quota \
--service-code ec2 --quota-code L-1216C47AL-1216C47A is the example quota code in the get-service-quota reference (On-Demand standard instances). Look up the code for your family with list-service-quotas. Do not assume that code is the one you hit.
Azure Quotas. Subscriptions, Usage + quotas, or the Quotas blade. Azure quotas overview. The quota CLI is an extension.
az quota list --scope SCOPE
az quota show --scope SCOPE --resource-name RESOURCE
az vm list-usage --location REGION -o table--scope is the resource-provider scope documented on az quota. If you do not have the extension, az vm list-usage still shows Compute usage in that region.
Google Cloud Quotas. IAM & Admin, Quotas, or the service-specific quota page. Cloud Quotas.
gcloud quotas info list --service=compute.googleapis.com --project=PROJECT
gcloud compute project-info describe --project=PROJECTgcloud quotas info examples: manage quotas with gcloud. gcloud compute project-info describe is the older Compute Engine view documented under Compute quotas.
Alibaba Cloud Quota Center. Quota Center console, or the quota page inside the product (ECS, NAT, SLB). Quota Center.
aliyun quotas ListProductsFor a specific quota, use the Quota Center console or GetProductQuota with the ProductCode and QuotaActionCode from that page. Do not guess codes.
Interpretation
Usage equals applied quota: you are at the cap. Free resources or request an increase.
Usage is below the quota and creates still fail: wrong scope (other subscription/project), a different quota (public IPs, not vCPUs), stock (InsufficientInstanceCapacity is not a quota), or an organization policy / SCP deny that only looks like a limit.
API 429: slow down callers. An increase of a rate quota may be possible; a retry storm is not a fix.
Adjustable = false in the quota API: you need a design change (more accounts, different SKU, or a documented exception process), not a console click.
Standby region at zero unused vCPU: DR will not launch. This is a preparedness finding if you are not in an incident, and a blocker if you are.
Safe mitigation
Release unused resources of that type in the same scope. Submit the increase through Service Quotas, Azure quota request, Google quota adjustment, or Alibaba Quota Center. Include region, quota code and why. Wait for the applied value to change before you retry at scale. If the owner accepts a different region or family that already has headroom, move only that workload and record it as temporary. For API-rate limits, add backoff and stop parallel apply pipelines.
Risky actions to avoid
Do not loop create in a script. You will hit rate quotas and still have no capacity.
Do not open a second cloud account as a stealth quota increase without identity, billing and logging. That is a new landing zone, not a mitigation.
Do not assume an increase is approved because you submitted it.
Do not lower a quota on a production subscription to “clean up” during an incident.
Do not treat InsufficientInstanceCapacity as quota. That is regional stock. Pick another AZ or family, or wait.
Validation
Usage is below the applied limit and the previously failing create or scale call succeeds. If you requested an increase, confirm the applied value, not only the request state. For DR, run a small scale-out in the standby region after the increase lands.
Prevention
- List the quotas a launch template, node pool or failover needs when you choose the region, not during the incident.
- Alert when usage crosses a documented fraction of the applied quota (defaults differ by account).
- Include a quota read in region failover drills and in autoscaling failure reviews.
- Stop CI or deploy retries that hammer a 429 or quota error; they consume the remaining headroom.
- Always read the applied value in Service Quotas, Azure quota, Google Cloud quotas or Alibaba Quota Center. The console number is the one that matters.