AWS discounts are not one list but five layers: credits, commitments, spare capacity, architecture work, and enterprise agreements - each behaving differently.
Search for AWS discounts and you meet two kinds of content: official pages, and a long line of "N official discounts" listicles. The lists look informative, but after reading one you usually still do not know which layer to start from - because they lay out fundamentally different things side by side.
This page offers a more usable structure: five layers, ordered by how hard each one is to obtain and what it actually does. Once layered, two questions locate you: do I qualify, and is my usage stable.
This is a navigation page: each layer points at its own detailed page. To start with the one distinction everything rests on (credits are not discounts), see AWS credits and discounts are not the same thing.
Split "discounts" into five layers first
The offers look scattered, but by nature there are only five kinds:
| Layer | Nature | Commitment? | Typical size |
|---|---|---|---|
| 1 Credits | Offsets an amount (price unchanged) | No, but eligibility required | Tens to tens of thousands of USD |
| 2 Commitment discounts | Changes the unit price | Yes (one or three years) | Two-digit percentages |
| 3 Spare capacity | Changes the unit price, at the cost of interruption | No, but must tolerate interruption | The deepest |
| 4 Architecture work | Lowers total usage or unit cost | No | Varies by architecture |
| 5 Enterprise / channel | Changes the price or the amount you pay | Scale threshold | Negotiated or channel-set |
The most important information here is the second column: only layers 2, 3 and 5 are "discounts" (they change the unit price or what you pay). Layer 1 is a credit - it offsets part of the bill. Layer 4 is not even a discount, it is engineering. Conflate them and you arrive at "a few thousand in credits has solved my cost problem".
Layer 1: credits (no commitment, but eligibility)
What defines this layer is that it requires no usage commitment - the price is eligibility, and eligibility is segmented by who you are:
| Source | Who it is for | Detail |
|---|---|---|
| Free tier | All new accounts | how to get the 200 USD |
| Startup programme (Activate) | Qualifying startups (tiered) | three tiers and eligibility |
| Education (Educate) | Students and educators (age and region limits) | what students and educators get |
| Limited-time campaigns | Accounts registered in the window that meet the conditions | four rules and why people miss out |
| Targeted promotional credits | Accounts issued credits directly | where redemption lives |
Three practical points for this layer: (1) it is a budget with an expiry - unused credit is lost (how to spend it well is in how to use AWS service credits); (2) buy your discounts first and it stretches further - lower unit prices mean the same credit covers more usage; (3) it does not cover data transfer and similar, so credits are not the same as zero cost.
Layer 2: commitment discounts (change the unit price)
The mainstream layer: commit in advance, get a lower unit price. AWS has four instruments, and what matters is what you commit to and whether it locks the spec:
| Instrument | What you commit to | Coverage |
|---|---|---|
| Compute Savings Plans | An hourly spend amount | Most flexible: across families, regions, OS, plus Lambda and Fargate |
| EC2 Instance Savings Plans | Spend on one instance family in one region | Locks the family (sizes, OS and tenancy stay flexible) |
| Database Savings Plans | An hourly spend amount | Database services (Aurora / RDS / DynamoDB / ElastiCache and more) |
| Reserved Instances | A specific instance configuration | Most locked in, but resellable, with optional capacity reservation |
Which to buy, how much, and what to do if you get it wrong are in how to buy AWS Savings Plans and how to buy AWS Reserved Instances.
⛔ Two things must happen before buying this layer: right-size first (bring over-provisioned resources down) and settle the architecture (moving to better price-performance silicon, for example). A commitment discount applies to the usage you have now - if the architecture is inherently costly, committing locks the waste in for a year or two. The ordering is in what Graviton actually saves.
Layer 3: spare capacity (deepest, and interruptible)
AWS sells spare capacity at a deep discount, in exchange for the resource being reclaimable at any time (usually with a short warning). The test is blunt:
- Fits: batch processing, rendering, CI builds, re-runnable data jobs, the stateless elastic tier.
- Does not fit: primary database nodes, stateful services, production endpoints that must stay up.
- Not all-in, but a mixed base: cover the steady part with layer 2, let the elastic part eat layer 3.
Details in a practical guide to AWS Spot Instances. One note: how deep the discount goes and whether you can use it are different questions - a workload that cannot survive interruption cannot use this layer at any discount.
Layer 4: architecture work (not a discount, same money)
This is the layer discount lists skip, because it is not a discount at all - no commitment, no redemption, no percentage. But for whoever pays the bill, money saved by changing architecture is the same money as money saved by buying a discount - and the former carries no lock-in.
- Move to better price-performance silicon: Arm-based instances improve price-performance directly and can be reverted at will - see what Graviton actually saves.
- Clean up resources nobody uses: volumes, snapshots, addresses, idle load balancers - orphaned resources are the most common persistent charge, see why your AWS bill jumped.
- Optimise the data path: co-locate chatty services in one zone, add gateway endpoints for object storage, put static content behind a CDN. Its share of the bill is routinely underestimated - see why AWS data transfer costs so much.
- Go service by service: outside EC2, databases, storage and logs are often the bulk - see saving beyond EC2.
Why this layer belongs before commitments: it requires no commitment and is fully reversible, and once done, layer 2 discounts apply to a lower base. Do it the other way round (commit first, change architecture later) and coverage drops - and a commitment cannot be returned.
Layer 5: enterprise agreements and channels
The first four layers are "obtained by rule"; this one is "negotiated". Two paths, different in nature:
| Path | Essence | Precondition |
|---|---|---|
| Enterprise agreement / private pricing | Negotiate a cross-service discount with AWS | Annual spend at real scale |
| Channel settlement | Provision and settle through a channel; the margin comes from the channel | More about sign-up barriers and settlement convenience |
The channel path is often misread as competing with official discounts. In reality they act in different positions: an official discount lowers the unit price on the bill; a channel discount lowers what you actually pay, and both can apply. Three questions will vet any channel - see where to find AWS discount information you can trust; the AWS-specific channel pricing and sign-up barriers are in AWS discounts and reseller pricing.
How to choose: match your current stage
You do not need all five. Work by stage and the order falls out:
| Your stage | Start with |
|---|---|
| Not registered yet / just registered | Layer 1: claim every credit you qualify for (free tier, campaigns, eligibility programmes) |
| Running, usage still moving | Layer 4: right-size and settle architecture - this is the worst moment to buy commitments |
| Load has stabilised | Layer 2: cover the already stable portion (start at 70-80%, do not fill it) |
| Clearly interruptible work exists | Layer 3: move batch, CI and rendering onto spare capacity |
| The bill is already substantial | Layer 5: compare channels, or negotiate an enterprise agreement |
The order in one line: claim eligibility-based credits, then fix architecture, then buy commitments, then talk channels. The first three have a strict sequence (getting it wrong loses twice), while layer 5 can be added at any time because it conflicts with none of them.
FAQ
Are the "8 official AWS discounts" lists reliable?
As an index, yes, with two habitual flaws: they mix credits with discounts (entirely different in nature - see AWS credits and discounts are not the same thing), and the specific numbers go stale. This page sorts by nature; check amounts and terms against the official pages.
Can all of these be stacked?
Not as a blanket "yes". What is certain: credits and commitment discounts apply together (one offsets the amount, one changes the price), and official discounts and channel discounts apply together (one changes the price, one changes what you pay). Within a layer, though, two commitments do not double-discount the same usage - coverage is capped.
I just want to spend less - what is the least effort?
The two easiest things in layer 4: delete resources nobody uses, and put static content behind a CDN. No commitment, no approval, immediate effect. For the systematic version, see AWS billing: six actions that actually work.
What should I confirm before buying a commitment discount?
Three things: is usage already stable (if not, wait), will the architecture change again (commitments lock the spec, so coverage drops if it does), and how much to buy (start at 70-80% of the steady baseline; filling it wastes money). See how to buy AWS Savings Plans.
Do other providers structure discounts the same way?
No, and the differences are significant. Only GCP has a layer that applies automatically with nothing to do; Alibaba Cloud International savings plans commit an amount while Tencent Cloud International reservations lock the spec; Azure channel discounts are set by the partner. All five compared in cloud discount mechanisms compared.
Will the bill jump when the credits run out?
Yes - which is why this page keeps saying make the structure cheaper while the credits last. Credits buy time; discounts and architecture work change long-term cost. Do nothing in the meantime and the bill returns to its original level. How to use that window is in how to use AWS service credits.