An AWS account is not a single product. Accounts differ in how much compute they can launch, whether they carry a promotional credit balance, and whether the AI services you want are enabled. Those are three independent decisions, and getting them wrong in either direction is expensive: too small and you hit a wall mid-project, too large and you have paid for headroom you never touch.
This guide explains what each axis actually controls so you can match a configuration to the workload rather than guessing.
Axis one: vCPU headroom
Every AWS account has service quotas that cap how many vCPUs you can run concurrently in a region. A brand new account starts low, often low enough that a single large training instance will not launch. Quota increases can be requested, but they are reviewed, and the review takes time you may not have.
Configurations are described by the vCPU ceiling they carry, from modest tiers through to 1,920 vCPUs. The number to look at is not the total you might eventually want, but the largest single burst you need to run at once.
| Workload | Typical concurrent vCPU need |
|---|---|
| Web application and API hosting | Low. A handful of general purpose instances. |
| CI and build farms | Moderate, but spiky. Size for the peak, not the average. |
| Batch data processing | Moderate to high, depending on how far you parallelise. |
| Model training and inference at scale | High. This is where the larger tiers earn their price. |
A practical rule: if you are running standard web infrastructure, vCPU ceiling is rarely your binding constraint. If you are doing anything involving parallel compute or GPUs, it usually is.
Axis two: credit balance
Promotional credits are a balance applied against usage on covered services. They reduce what you pay while they last; they do not raise your limits and they do not change what the account can do.
Credit tiers run from modest balances up to 100K. The question to ask is how long a balance actually lasts against your burn rate. A useful sanity check is to estimate monthly spend first, then work out the runway:
- A small always-on web stack might burn a few hundred dollars a month. A 1K balance is several months of runway.
- A team training models on GPU instances can burn a 5K balance in weeks.
- Large balances make sense when you have a defined, funded project that will consume them inside their validity window.
Credits expire. A balance you cannot spend before expiry is not worth what it looks like on paper, so buy the tier that matches your real consumption timeline rather than the biggest one available.
Axis three: Bedrock and AI service access
Amazon Bedrock is the managed service for running foundation models. Access is governed separately from raw compute, and requests-per-minute limits matter as much as vCPU count for inference workloads.
Bedrock enabled configurations are described by two numbers: the RPM ceiling and the vCPU tier alongside it. They pair differently depending on what you are building:
- Low RPM with modest vCPUs suits prototyping, internal tools and evaluation work, where you are making occasional calls and iterating on prompts.
- High RPM with modest vCPUs suits a production application that calls models frequently but does no heavy compute of its own.
- High RPM with large vCPU tiers suits pipelines that combine inference with substantial pre or post processing on the same account.
If your application is essentially a wrapper around model calls, RPM is the number that constrains you and paying for a large vCPU tier adds nothing.
Putting it together
Work through the three axes in order:
- What is my peak concurrent compute? That sets the vCPU tier.
- What will I actually spend, and over what period? That sets whether credits are worth it and at what size.
- Am I calling foundation models, and how often? That decides whether you need a Bedrock enabled configuration and at what RPM.
Most teams over-index on the credit balance because it is the most legible number, and under-index on quotas, which are the thing that actually stops work.
Before you deploy
Whatever configuration you choose, secure the account before you put anything real on it. Change the delivered credentials, enable multi-factor authentication on the root user, create scoped IAM users for day to day work, apply least privilege to every role, set a billing alert, and turn on CloudTrail so you have an audit record. Rotate access keys on a schedule after that.
Billing alerts matter especially on credit backed accounts: it is easy to assume a balance is covering you and discover it ran out three days ago.
Common questions
Can I raise vCPU quotas on an account later?
Yes. Quota increases are requested through the AWS console and reviewed by AWS. The review is the reason people buy a higher tier up front rather than waiting.
Do credits cover every AWS service?
Credits cover a defined set of services under the terms attached to the balance. They typically apply to core compute, storage and database usage. Check the terms that come with the specific balance rather than assuming blanket coverage.
Is a Bedrock enabled account required to use AI on AWS?
Not for everything. Training your own models on EC2 needs compute, not Bedrock. Bedrock matters when you want managed access to foundation models without running the infrastructure yourself.
Where to go next
Compare AWS against the other large platforms if you have not settled on one yet, or read the security checklist before your first deployment.