Teams comparing AWS accounts usually look at the credit balance first. That is the wrong number to look at. Credits control what your usage costs. Quotas control what you can launch, and a quota wall stops work dead in a way a spending limit never does.
What a quota actually is
A service quota is a per-account, per-region ceiling on a specific resource. The most commonly hit one is the vCPU limit for on-demand EC2 instances, which is counted per instance family. Others include Elastic IPs, VPCs per region, Lambda concurrent executions, and RDS instances.
Two properties catch people out. Quotas are regional, so headroom in one region does nothing for another. And they are counted against running resources, not lifetime usage, so what matters is your peak concurrent footprint.
Why new accounts start low
A brand new AWS account is deliberately constrained. AWS has no usage history for it, and low starting limits are how they contain abuse such as crypto mining on stolen cards. The practical effect is that a fresh account often cannot launch a single large GPU instance.
You can request an increase through the Service Quotas console. The request is reviewed, sometimes automatically and sometimes by a human, and the wait is the reason teams buy accounts with higher limits already in place rather than starting from zero against a deadline.
Reading the tiers on a listing
Our AWS account listings describe configurations by their vCPU ceiling, from entry tiers up to 1,920 vCPUs. Match that number to your peak concurrent need, not your aspiration:
| Workload | Concurrent vCPU pressure |
|---|---|
| Web application and API tier | Low. Rarely the binding constraint. |
| CI and build farm | Spiky. Size for the peak, not the average. |
| Batch and ETL processing | Moderate to high, depending on parallelism. |
| Model training on GPU instances | High. This is where the large tiers earn their price. |
Quotas are not the only limit
Separate from vCPU quotas, some capabilities are gated in their own way:
- Amazon Bedrock is governed by requests per minute, not vCPUs. If your application is mostly model calls, RPM is your real ceiling and a large vCPU tier adds nothing. Our configuration guide covers how the two pair.
- Amazon SES starts in a sandbox with a daily sending quota and a per-second rate, which is a different system again. See SES production access.
- Spot capacity is availability, not quota. You can be within your limit and still be unable to launch.
Planning around quotas
- Decide your region first, then check quotas in that region specifically.
- Count peak concurrency, including anything that runs in parallel during a deploy.
- Request increases before you need them, not on the day.
- Watch the Service Quotas console for utilisation, and set a CloudWatch alarm on approaching limits.
- Keep environments in separate accounts so a load test cannot exhaust production headroom. Our guide on separate accounts explains why.
Common questions
Do credits raise my quotas?
No. They are unrelated systems. Credits offset spend; quotas cap provisioning. See cloud credits explained.
Are quota increases guaranteed?
No. Requests are reviewed and can be declined or partially granted, and account history influences the outcome.
Does a higher tier account keep its limits?
Limits belong to the account, so they persist. Your own usage and payment history from that point onward still matter to AWS.
Comparing AWS against another platform first? Put them side by side on the comparison page.