GCP sustained use discounts apply automatically but do not stack with commitments. How the four layers fit together.
GCP has the most layers of any of the five — four in total. One of them is unusual: you do nothing at all and it applies anyway.
That is Sustained Use Discount (SUD) — run long enough and the price falls automatically. No application, no commitment, nothing to sign. Neither AWS nor Azure has an equivalent.
It is also the layer most often miscalculated: SUD does not stack with Committed Use Discounts (CUD). Plenty of third-party articles treat them as additive — they are not, and Google's documentation states it plainly. This page covers all four layers and dwells on that trap. All five compared side by side are in cloud discount mechanisms compared — the automatic layer is GCP's alone.
Four layers — and one of them needs nothing from you
The full picture, ordered by whether you have to do anything:
| Layer | Do you act | What you give up | Published figure |
|---|---|---|---|
| Sustained Use Discount (SUD) | No — automatic | Nothing | up to 30% |
| Committed Use Discount (CUD) | Yes — buy 1 or 3 years | Committed usage | up to 37% for 1 year / 55% for 3 years (70% for memory-optimised) |
| Flex CUD | Yes — shorter term | Committed usage, shorter | around 28% / 46% |
| Spot | Yes — opt in | Accepting reclamation | up to 91% |
⚠️ The percentages above are published in Google's billing documentation and are here to explain the mechanism; actual discounts vary by machine type, region and term, and the official live pricing is authoritative. Our own channel figure remains one number: 30–50% lower total bill.
The important caveat belongs here: these four do not simply add up — particularly layers one and two. See the section on the most common miscalculation.
Layer 1: Sustained Use Discounts (automatic, no equivalent elsewhere)
The logic is simple: the longer a given resource class runs within a billing cycle, the lower the unit price. No application, no commitment, nothing to configure — it shows up on the bill by itself.
- Why it is unusual: AWS and Azure have no "run long enough and it discounts itself" mechanism. On AWS, an equivalent discount must be bought — Reserved Instances or Savings Plans.
- What it means in practice: if you run a stable fleet on GCP, your bill is already below the pure on-demand rate even though you did nothing.
- Published figure: up to about 30% (varies by resource type; official documentation is authoritative).
A useful consequence: when evaluating GCP, comparing its on-demand rate against another provider's on-demand rate is not a fair comparison — GCP's on-demand rate drops automatically once you run a full month. Compare GCP's actual bill after a full month.
This is part of why GCP "looks expensive and turns out reasonable".
Layer 2: Committed Use Discounts (one or three years)
CUD is the same shape as everywhere else: commit usage for a period, get a lower unit rate. GCP offers one-year and three-year terms.
| Term | Published figure | Cost |
|---|---|---|
| 1 year | up to about 37% | Locked a year |
| 3 years | up to about 55% (70% for memory-optimised) | Locked three years — machine or region changes carried |
The judgement is universal: commit the steady baseline (what runs every day), not peak or average; batching costs nothing; settle the architecture before you commit (changing machine type drops coverage). The full method is in how to buy AWS Reserved Instances.
⛔ A GCP-specific trap sits here: because SUD already applies a layer automatically, it is tempting to assume "CUD discounts further on top of SUD". It does not — that is the next section, and it is the most important one on this page.
Layer 3: Flex CUD (more flexible, shallower)
Flex CUD is a shorter-term commitment (shorter terms are offered), discounting less than the 1/3-year CUD (published figures around 28% / 46%), in exchange for a shorter lock-in.
- Good for: a real baseline exists but you do not want to lock three years; or you are still observing and want to try a commitment first.
- Bad for: an early stage where no baseline exists yet — an unfilled commitment is waste regardless of term length.
- Versus standard CUD: no conflict. Start short, convert to longer once stable.
A safe sequence: run a month for a real baseline → cover part of it with short-term Flex CUD → watch the coverage → convert part of it to a longer term once stable. Every step rests on data from the step before, which beats gambling three years upfront.
Layer 4: Spot (cheapest, but reclaimed)
Spot uses reclaimable spare capacity at the lowest price (published figure up to 91%), in exchange for being reclaimed.
| Good for | Not for |
|---|---|
| Batch / offline compute / transcode queues | Database primaries |
| Automated testing, CI builds | Services with an external SLA |
| Stateless, reschedulable workers | Jobs needing a human after interruption |
⛔ Define "interruptible" strictly: only automatic retry counts. If a person must restore it, it does not count — the saving is eaten by operations time. Full boundaries are in AWS Spot Instances; Spot works nearly identically across providers, so that checklist transfers.
The most commonly miscalculated rule: SUD does not stack with CUD
This is the most important section here, and where many third-party articles go wrong.
The documentation states that discount types cannot be combined. Concretely:
- CUD takes priority: usage inside your commitment prices at the CUD rate.
- SUD applies only above the commitment: usage beyond what you committed gets the automatic sustained-use discount.
- They neither multiply nor add. The committed portion is not "discounted by CUD and then by SUD".
| Usage band | Discount applied |
|---|---|
| Within the commitment | CUD |
| Above the commitment | SUD (automatic) |
| The same usage | ⛔ Not stacked — only one applies |
⛔ So "SUD up to 30% + CUD up to 55% = 85%" is wrong. The correct model is banded: committed usage at CUD, excess at SUD. The more accurately you size the commitment, the closer the blended discount sits to the CUD band; over-commit and the excess only earns SUD.
That yields a practical rule: if you over-estimate the CUD commitment, the excess is not merely wasted — it also displaces usage that would have earned SUD with a more expensive commitment. So err on the side of under-committing and let the excess take SUD automatically. The penalty is milder than over-buying elsewhere, but still worth avoiding.
How the four fit together
In the order automatic first, flexible next, locked last:
- Step 1 (no action): SUD is already applying. You do nothing — but know it exists, or you will misread the bill and compare GCP unfairly.
- Step 2 (no commitment): put interruptible work on Spot. Batch, testing and offline compute move first.
- Step 3 (reversible): clear idle resources and review storage tiering. Unused machines, unattached disks, cold data on a hot tier — the baseline drops.
- Step 4 (short commitment): Flex CUD over part of the baseline. Size it from the real data the first three steps produced; start with the short term.
- Step 5 (long commitment): standard CUD, from one year. By now you know what the steady state is.
| Order | Action | Cost |
|---|---|---|
| 1 | SUD (automatic) | None |
| 2 | Spot for interruptible work | Interruption risk |
| 3 | Clean-up / storage tiering | None |
| 4 | Flex CUD (short) | Short commitment |
| 5 | Standard CUD (1/3 years) | Locked commitment |
A sixth step, which does not conflict with the others: settle through a reseller to lower what you actually pay (the first five lower the unit price on the GCP bill). Different layers, stackable — see GCP discounts and reseller pricing.
GCP's programme is Partner Advantage (Member through Diamond, with Diamond added in 2026). Do not map another provider's tiers onto GCP.
Common questions
Do I need to apply for SUD?
No. Sustained Use Discounts are automatic — run a resource long enough within a billing cycle and the discount appears on the bill. No application, no commitment, no configuration. Neither AWS nor Azure has an equivalent (on those, an equivalent discount must be bought as reservations or savings plans).
Do SUD and CUD stack?
No. The documentation states discount types cannot be combined: CUD covers usage within the commitment and SUD applies only to usage above it. So "30% + 55% = 85%" is wrong — the model is banded. Which also means size the commitment carefully: over-commit and the excess only earns the lower SUD.
Is GCP on-demand more expensive than elsewhere?
Not directly comparable. GCP's on-demand rate drops automatically after a full billing cycle (SUD), while other providers' on-demand rates do not move on their own. Compare GCP's actual bill after a full month, or you will overestimate its cost. Part of why GCP looks expensive and then turns out reasonable.
Flex CUD or standard CUD?
Depends how far you can see. Still observing, or unwilling to lock three years → Flex CUD (shorter term, shallower discount). Baseline settled and definitely running → standard CUD (from one year, deeper). Safest is short first, then convert using real data. The judgement is universal — see how to buy AWS Reserved Instances.
Spot goes up to 91% — should I run everything on it?
No. 91% is the published ceiling (it floats with machine type and supply), and Spot gets reclaimed. Only workloads whose re-run cost is acceptable belong on it — batch, testing, offline compute, retryable queues. Database primaries, SLA-bearing services and jobs needing human recovery do not. Boundaries in AWS Spot Instances.
Do official and reseller discounts conflict?
No — different layers. Official discounts (CUD / Flex CUD / SUD / Spot) lower the unit price on the GCP bill; a reseller discount lowers what you actually settle. Both apply together; not either/or. See GCP discounts and reseller pricing.