The five clouds do not mean the same thing by "discount": only GCP has an automatic layer, and Azure discounts are set by the partner.
If you are choosing between the five, or already running on one and want to squeeze the bill further, the easiest mistake is this: assuming "discount" means the same thing at all five, and only the number differs.
It does not. There are at least four layers, and the mechanics differ at every one of them - some layers do not exist at some providers. This page does not rank providers by "who discounts most" (that depends on which layer your workload lands on, so the comparison is meaningless in the abstract). It explains how the mechanisms differ, so you can work out which layer is actually available to you.
Start with the conclusion: the five "discounts" are not the same thing
Sort every discount by "do you have to do anything", and the differences line up immediately:
- Layer 1 (automatic): nothing to do - run long enough and the discount appears. Only GCP has this.
- Layer 2 (commitment): promise usage or term, get a discount. All five, but what you commit to varies enormously.
- Layer 3 (channel): provision and settle through a partner. All five - but on Azure it means something different from the other four.
- Layer 4 (spare capacity): deliberately use capacity that can be reclaimed. All five, differing in how you get interrupted and how deep the discount goes.
⛔ The one that matters most: on AWS, Azure, Alibaba Cloud International and Tencent Cloud International, if you do nothing, you pay list price - there is no hidden discount waiting to be discovered. GCP is the only exception. So "let us just start running and optimise later" means giving up layers 2 and 3 on those four.
Four layers, one table
The full picture, ordered by whether you have to do anything:
| Layer | AWS | Alibaba Intl | Tencent Intl | Azure | GCP |
|---|---|---|---|---|---|
| 1 Automatic | None | None | None | None | Sustained Use Discount |
| 2 Commitment | Reserved Instances / Savings Plans | Term subscription + savings plan | Term subscription + reserved instances | Reservations / savings plans | CUD / Flex CUD |
| 3 Channel | Yes | Yes | Yes | Yes (CSP - partner prices it) | Yes |
| 4 Spare | Spot Instances | Preemptible instances | Spot instances | Spot | Spot |
The line worth memorising first is the top one: "None" does not mean that provider has no discounts. It means no discount will come looking for you. The layers below expand on that.
Layer 1: automatic, no commitment (GCP only)
GCP has Sustained Use Discounts: run a given resource long enough within a billing cycle and the discount appears on the bill - no application, no commitment, no configuration. Google billing documentation puts the ceiling at up to 30% (official live pricing is authoritative).
None of the other four has an equivalent. On AWS, Azure, Alibaba Cloud International and Tencent Cloud International, a comparable discount has to be bought - which is layer 2.
Why this layer matters in practice: workloads that run steadily get a floor on GCP that costs nothing to obtain. Elsewhere there is no floor, which means the optimisation work has to happen eventually, and every month of delay is a month at list price.
The full four-layer picture is in how to get GCP discounts; the channel side is in GCP discounts and reseller pricing.
Layer 2: commitment discounts (Alibaba and Tencent are easiest to confuse)
Commitment discounts are the main instrument at all five, but what you are committing to differs a lot - which is what makes this the easiest layer to get wrong:
| Provider | Commitment discount | What you commit | Locks specs? |
|---|---|---|---|
| AWS | Reserved Instances | A specific instance configuration | Yes (family + region) |
| AWS | Savings Plans | An hourly spend amount | No (portable across families / regions) |
| Alibaba Intl | Savings plan | A spend amount | No (specs can change) |
| Tencent Intl | Reserved instances | A specific spec | Yes (spec) |
| Azure | Reservations / savings plans | Spec or spend, by product | Yes |
| GCP | CUD / Flex CUD | A specific resource quantity | Yes |
⛔ The pair people mix up - and they run in opposite directions: Alibaba Cloud International savings plans commit a spend amount (specs stay flexible), while Tencent Cloud International reserved instances lock the spec. The names sound interchangeable; the mechanics are not. Get the spec wrong on Alibaba and you can still recover; get it wrong on Tencent and your commitment coverage drops straight away.
AWS has the same pairing internally (Reserved Instances lock the family, Savings Plans commit spend), and the judgement travels: will the workload shape change? If yes, commit spend. If it has settled, commit specs. More detail in how to buy AWS Reserved Instances without regretting it.
Layer 3: the channel discount (Azure works differently)
Provisioning and settling through a partner produces extra margin at all five - but the position the channel occupies in pricing is very different:
| Provider | Channel model | Who sets the discount |
|---|---|---|
| AWS | Partner Central | Official pricing plus partner rebate |
| Alibaba Intl | Partner Program (four tiers) | Official pricing plus channel margin |
| Tencent Intl | Partner (five tiers) | Official pricing plus channel margin |
| Azure | CSP (Cloud Solution Provider) | The partner sets the discount |
| GCP | Partner Advantage | Official pricing plus partner benefits |
In one line: at the other four a reseller helps you obtain the official discount, then adds a little; on Azure the reseller is part of the pricing itself. That is why Azure quotes vary far more between providers - not because anyone is making numbers up, but because the model allows a much wider spread.
The per-provider channel pages:
- AWS discounts and reseller pricing
- Azure discounts and reseller pricing
- GCP discounts and reseller pricing
- Alibaba Cloud International discounts and reseller pricing
- Tencent Cloud International discounts and reseller pricing
Layer 4: spare capacity (all five, different interrupt behaviour)
All five offer the same trade - use someone else leftover capacity, get a deep discount, accept that it can be taken back. Only the names differ: Spot Instances at AWS, preemptible instances at Alibaba Cloud International, spot instances at Tencent Cloud International, and Spot at both Azure and GCP.
Two things actually differ: how much warning you get (from tens of seconds up to roughly two minutes, depending on provider), and how deep the discount goes (Google billing documentation puts GCP ceiling at up to 91%, the highest of the five; official live pricing is authoritative).
- Fits: batch processing, rendering, CI builds, re-runnable data jobs, the stateless elastic part of a fleet.
- Does not fit: primary database nodes, stateful services, production endpoints that must stay up, anything where recovering from reclamation costs more than the saving.
- The right pattern is not all-in: cover the steady baseline with layer 2, let the elastic part eat layer 4. That is a mixed base, and it is the standard approach on all five.
The practical judgement - which workloads qualify, how to spread across instance types and zones - is in a practical guide to AWS Spot Instances; the reasoning carries over to the other four.
The three things people get wrong
These are the most common errors when comparing providers side by side - and each provider has its own version of them:
- Adding GCP SUD and CUD together. Billing documentation states discount types cannot be combined: committed usage is priced at CUD, and only usage above the commitment earns SUD. So "SUD up to 30% plus CUD up to 55% = 85%" is wrong - the correct model is banded.
- Assuming official and channel discounts are either/or. They are not: official discounts lower the unit price on the provider bill; a channel discount lowers what you actually pay. Different layers, stackable at all five.
- Buying the commitment before fixing the architecture. Spec-locking commitments are tied to an instance family; change family or architecture later and your coverage drops. The order is always: architecture first, then commitment.
A quick self-check order: is there a layer that costs nothing to obtain (GCP only) - then, once the workload is steady, buy commitment - then push anything interruptible onto spare capacity - and the channel layer can be added at any point, because it does not conflict with any of the previous steps.
FAQ
Which of the five discounts the most?
There is no answer to that, because your workload decides which layer you can reach. Mostly steady - layer 2 matters most. Can tolerate interruption - layer 4 goes deepest (GCP published ceiling: up to 91%). Want to do nothing at all - only GCP has layer 1. Work out the workload shape first, then pick the provider - not the other way round.
If I do nothing, which one is cheapest?
GCP - it is the only one with an automatic layer. At the other four, doing nothing means list price, and it will not get cheaper just because you have been there a while. This is the most commonly missed point on the whole page.
Do official discounts conflict with using a reseller?
No - they stack. Official discounts lower the unit price on the provider bill; a channel discount lowers what you actually pay. They act on different parts of the bill, at all five. See the per-provider pages listed under layer 3. When assessing a channel, also look at who controls the account and subscription - see how to pay for overseas cloud services.
What if I buy the wrong commitment?
It depends which kind. Spend-based commitments (AWS Savings Plans, Alibaba Cloud International savings plans) keep their specs flexible, so the downside is limited. Spec-locking ones (AWS Reserved Instances, Tencent Cloud International reserved instances, Azure and GCP commitments) lose coverage if the spec turns out wrong, and the remedies differ by provider. Detail in how to buy AWS Reserved Instances without regretting it.
Small team, just starting - which layer first?
Start with layer 3, the channel. Lowest barrier, available immediately, and it does not conflict with anything you do later. Once the workload shape settles, add layer 2. Once you have clearly interruptible work, add layer 4. Do not lock a three-year commitment on day one - running on real data for a while and then buying beats guessing correctly up front.