AWS vCPU quotas explained, and why your instance launch fails

You have requested more vCPU capacity than your current vCPU limit of 5 allows for the instance bucket that the specified instance type belongs to.

That error stops more first deployments than any billing problem. It is not a capacity shortage on the AWS side and it is not a payment issue. It is a per account, per region quota doing exactly what it was designed to do.

What the quota actually counts

AWS used to limit the number of running instances per type. That was replaced years ago with a vCPU based model, which is more sensible: the limit now scales with the size of what you launch, so one c6i.4xlarge and sixteen t3.micro instances draw on the same budget in the same way.

The limit applies to running on demand instances. Stop an instance and its vCPUs are returned to the pool immediately, which is why a fleet you scale down overnight does not eat into the next morning’s headroom.

The buckets, and why they matter

Instance families are grouped into separate quota buckets, and each bucket has its own number. The grouping is the part people miss.

• Standard. The general purpose, compute optimised and memory optimised families sit together in one pool. This is the bucket most workloads consume.
• G and VT. Graphics and video transcoding instances.
• P. The large GPU training instances.
• Inf and Trn. AWS designed inference and training silicon.
• X, HPC, DL and others. Each with its own quota.

Spot capacity is tracked in an entirely separate set of quotas, so a healthy on demand limit tells you nothing about how much spot you can run. Dedicated hosts are separate again.

The consequence is blunt: an account advertised with a large standard vCPU allowance may still refuse to launch a single GPU instance, because the accelerated bucket is at zero by default on most accounts. If GPU work is the goal, that is the number to ask about.

Reading your real limit

Open the Service Quotas console, choose Amazon Elastic Compute Cloud, and search for “Running On-Demand”. You will see one entry per bucket, each showing the applied quota value. Two things to watch:

• Switch region first. Service Quotas shows the current region only. A 64 vCPU limit in us-east-1 does not exist in ap-southeast-2 until you ask for it there.
• Applied value beats default value. The console shows both. The applied value is yours; the default is what a new account starts with.

From the CLI, aws service-quotas get-service-quota --service-code ec2 --quota-code L-1216C47A returns the standard on demand vCPU quota for whichever region your profile points at. That quota code is worth remembering, it comes up constantly.

Getting an increase approved

Requests are submitted from Service Quotas or through a support case. Modest increases on an account with a payment history often clear automatically within a few minutes. Everything else goes to a reviewer, and reviewers respond to specifics.

A request that gets approved quickly usually contains:

• The exact quota and region, not a general plea for “more capacity”.
• The instance families you intend to run and roughly how many.
• A one line description of the workload. Batch rendering, CI runners and a web tier all read very differently to a reviewer.
• A realistic number. Asking for 10,000 vCPUs on a two week old account invites questions; asking for 96 does not.

Two failure modes are worth avoiding. Requesting a huge jump in one step tends to stall, so step up in stages if you have time. And filing the request in the wrong region is common enough that it is worth double checking the console header before you submit.

Where account age comes in

AWS does not publish a formula, but the pattern is consistent: default quotas on a brand new account are conservative, and they loosen as the account accrues paid usage. This is the practical difference behind accounts sold with a stated vCPU figure. You are buying the state of the quota, not a different service.

It is also why the number should be matched to the plan rather than maximised. A 256 vCPU standard limit is dead weight if your workload is four web servers and a database, and it will not help at all if the real bottleneck is an accelerated family or a Bedrock throughput limit.

The other limits that look like this one

vCPU quotas are the most visible, but they are not alone. Elastic IP addresses default to five per region. VPCs default to five per region. EBS volume storage has a per region ceiling by volume type. Lambda concurrency starts at 1,000 across the account. Each of these produces its own confusing error the first time you meet it, and each is adjustable through the same console.

If your bottleneck turns out to be networking rather than compute, the VPC networking basics guide covers what the default limits are protecting you from. If it turns out to be model throughput, read the Bedrock guide instead.

And if you are still choosing an account, AWS account types explained lays out how quotas, credits and the free tier interact.