Do CUDs and SUDs stack on Google Cloud?

They are alternative discounts on the same usage rather than additive on the same slice: committed-use discounts apply to the usage they cover at the committed rate, and sustained-use discounts apply to eligible on-demand usage that isn't covered by a commitment. In practice you use them together across your fleet — CUDs on the steady baseline you commit to, SUDs automatically on the variable usage above it — so together they lower the blended rate across the whole estate.

What is the difference between resource-based and spend-based CUDs?

Resource-based committed use discounts commit you to a specific amount of vCPU and memory in a particular machine family and region, for the deepest discount but the least flexibility. Spend-based (flexible) committed use discounts commit you to a fixed hourly dollar amount across services or across Compute Engine broadly, trading some discount depth for flexibility across families and regions. Teams whose shape is stable prefer resource-based; teams that change families or regions prefer spend-based.

How do I avoid stranded Google Cloud commitments?

Only commit to your steady-state floor, not your peak, and size the commitment against your product roadmap rather than last month's bill. Use the committed-use-discount recommender as a starting point, prefer spend-based commitments when your machine mix is likely to change, and track realized CUD/SUD savings from the BigQuery billing export so you can see coverage and utilization before you renew.

Google Cloud · Commitments · July 2026

GCP Committed Use Discounts vs Sustained Use Discounts: Which Saves More?

By the CloudFinOpsKit team. 8 min read.

Pay-as-you-go is the most expensive way to run a steady workload on any cloud — but Google Cloud is unusual in giving you a discount you don't even have to ask for. GCP has two rate levers: Sustained Use Discounts (SUDs), which are automatic, and Committed Use Discounts (CUDs), which you opt into. Used together they can cut your compute rate substantially. Here's how each works, how they combine, and a coverage strategy that gets the discount without stranding a three-year commitment.

Sustained Use Discounts — the automatic one

SUDs are the discount GCP applies on its own when eligible resources (Compute Engine predefined and custom machine types, sole-tenant nodes) run for a significant portion of the billing month. The longer a resource runs in the month, the higher the effective discount — with no purchase, no commitment, and no paperwork.

Because they're automatic, the main SUD mistake is defeating them: constantly destroying and recreating instances, or spreading a steady workload across many short-lived VMs, can reset the sustained-use clock and cost you the discount you'd otherwise earn. If a workload is steady, let the instance be steady.

Committed Use Discounts — the opt-in one

CUDs give a deeper rate in exchange for a 1-year or 3-year commitment. There are two flavours, and choosing between them is the real decision:

	Resource-based CUD	Spend-based (flexible) CUD
You commit to	An amount of vCPU + memory in a specific machine family and region.	A fixed hourly dollar amount (across Compute Engine, or across covered services).
Discount depth	Deepest.	Slightly less deep.
Flexibility	Least — tied to a family + region.	Most — floats across families and regions as your usage moves.
Best for	A stable fleet whose shape you're confident about.	Teams that change machine families or regions over the term.

How they stack

Think of it as coverage in layers. A committed-use discount applies to the usage it covers at the committed rate; sustained-use discounts apply automatically to eligible usage that a commitment doesn't cover. So across your fleet you get both: CUDs discount the steady baseline you committed to, and SUDs quietly discount the variable usage above it. The goal isn't to pick one — it's to cover the predictable floor with CUDs and let SUDs handle the rest.

A coverage strategy that doesn't strand commitment

Commit to the floor, not the peak. Look at your steady-state minimum over the last few months; that's the safe commitment level. Everything above it stays on-demand (and earns SUDs).
Prefer spend-based when your mix will change. If you're likely to move families or regions during the term, the flexibility of a spend-based CUD is usually worth the small discount give-up — it's how you avoid a stranded commitment.
Start from the recommender, but sanity-check against the roadmap. GCP's committed-use-discount recommender is a strong starting point, but it looks backward; a re-platforming you already have planned should shrink the commitment.
Track realized savings and utilization. Before you renew, know what you actually got. The BigQuery billing export carries CUD and SUD credits, so you can measure realized discount and commitment utilization rather than guessing.

See your CUD/SUD picture automatically. The CloudFinOpsKit tool's Google Cloud commitments check reports your active CUDs, flags any expiring within 45 days (they revert to on-demand on lapse), and computes your realized SUD and CUD savings from the billing export — so a rising on-demand bill with flat commitment credit is an obvious signal to buy more coverage. Read-only, priced from your real bill.

FAQ

Do CUDs and SUDs stack?

They're complementary layers on the same fleet: CUDs cover and discount the committed baseline; SUDs automatically discount eligible on-demand usage above it. You use both together to lower the blended rate.

Resource-based or spend-based CUD?

Resource-based is deepest but locks a family + region — best for a stable fleet. Spend-based (flexible) trades a little depth for the freedom to move across families/regions — best when your mix will change. That flexibility is the main defence against stranded commitment.

How do I avoid over-committing?

Commit only to your steady-state floor, size it against the roadmap rather than last month's usage, and track realized savings + utilization from the billing export before renewing.