GCP Committed Use vs Sustained Use Discounts

GCP's discount story is different from AWS in one way that trips people up: part of it is automatic and you don't buy anything. The other part you do buy, and the buying comes in two flavors that behave nothing alike. After a couple of years running Compute Engine and GKE spend on Google Cloud, here's how the pieces fit and how we size the paid part.

Sustained Use Discounts: the free one#

Sustained Use Discounts (SUDs) apply automatically to Compute Engine when a VM runs for a large fraction of the billing month. No commitment, no contract, no console button. Run an instance the whole month and you land around 30% off the on-demand rate for general-purpose and compute-optimized machine types (the exact curve varies by family).

The mechanics: GCP measures how long each vCPU and GB of memory runs during the month and discounts on a sliding scale. Run 25% of the month, you get a small discount. Run 100%, you get the full ~30%. GKE nodes inherit this because they're Compute Engine VMs underneath.

Two things worth knowing:

• SUDs apply per resource type at the project level (and Google reshuffles usage across instances to maximize the discount for you). You don't optimize this. It just happens.
• SUDs do not apply to some newer families. This is the one that surprises teams. As Google pushed people toward committed use, several recent machine types earn no sustained use discount at all. If you're on those, the free discount is zero and committing is the only lever.

There's no AWS equivalent to SUDs. AWS has no automatic tenure discount — everything below on-demand requires a commitment or Spot. So the mental model "steady-state gets cheaper on its own" is a GCP-specific thing.

Committed Use Discounts: the one you buy#

Committed Use Discounts (CUDs) are the deeper cut. You promise to consume a certain amount for one or three years, and in return you pay 20% to 70% less depending on the term and type. There are two kinds, and choosing wrong is where money leaks.

Resource-based CUDs. You commit to a specific amount of vCPU and memory in a specific region, for a specific machine family. Deepest discount — roughly 37% for one year and up to ~57% for three years on general-purpose. The catch: it's bolted to the family and region. Commit to N2 in us-central1 and then migrate workloads to C3 or another region, and the commitment sits there billing you for capacity you're not using. This is the classic over-commit trap, same shape as an AWS Reserved Instance tied to an instance family.

Flexible (spend-based) CUDs. You commit to a dollar-per-hour spend on Compute Engine instead of specific hardware. It floats across machine families and regions. The discount is shallower — around 28% for one year, ~46% for three — but it doesn't strand when you change instance types. This is close in spirit to an AWS Compute Savings Plan: commit to how much, not what.

If those AWS analogies are useful, the AWS commitment models map cleanly: resource CUD ≈ Reserved Instance, flexible CUD ≈ Savings Plan.

How they stack#

This is the part people get wrong. SUDs and resource-based CUDs don't stack on the same usage. A CUD covers a slice of your baseline; the discount on that slice comes from the commitment, not sustained use. Sustained use then applies to whatever usage sits above the committed baseline (for eligible families).

So the picture for a steady workload:

• Committed baseline → billed at the CUD rate.
• Usage above the baseline → on-demand rate, reduced by SUD if the family qualifies.

The practical read: you commit to your floor, and the automatic discount mops up the variable layer on top. You never want to commit to your peak, because the peak isn't steady and you'll pay for a commitment that idles.

Sizing the commitment#

The method is the same one that works everywhere: measure the floor, commit under it.

Pull trailing 90-day usage per machine family per region. Find the daily minimum — the level below which usage never drops. That's your true baseline. Commit somewhere around 70-80% of it, not 100%. Reasons to leave headroom:

• Migration drift. You will move families. GCP ships new generations that are cheaper per unit of performance, and you'll want to migrate. A resource CUD pinned to last year's family blocks that.
• Rightsizing. If you commit before rightsizing, you lock in bloat. Audit and shrink first, then commit to the smaller baseline.
• Growth uncertainty. Under-committing costs you a little discount. Over-committing costs you the full commitment on idle capacity. The downside is asymmetric.

A worked example#

Say a service runs a steady 100 vCPU of N2 in us-central1 around the clock, plus bursts to 160 vCPU during business hours.

On-demand, no discounts, call it a round $X/hour baseline rate. The steady 100 vCPU runs all month, so SUD alone already knocks ~30% off that layer for free.

Now commit. A one-year resource CUD for 80 vCPU (80% of the floor) gets ~37% off that slice — better than the 30% SUD would have given, and locked in. The remaining 20 vCPU of the floor plus the daytime burst to 160 stays on-demand, cushioned by SUD where eligible.

Rough monthly shape:

• 80 vCPU at CUD rate (~37% off).
• 20 vCPU of baseline + burst at on-demand, ~30% off via SUD.
• Net blended discount lands north of 30% with almost no over-commit risk.

Compare that to the tempting mistake: committing to the full 160 vCPU peak. The burst is only ~8 hours a day, so for two-thirds of every day you'd pay the commitment on 60-80 idle vCPU. The deeper per-unit rate never recovers what the idle hours waste.

The flexible CUD tradeoff#

The honest tension: resource CUDs discount deeper but strand when you move; flexible CUDs discount shallower but follow you anywhere. Our rule of thumb — if a workload's machine family has been stable for a year and you don't expect to touch it, resource CUD earns the extra points. If the workload is young, growing, or likely to migrate families, flexible CUD is worth the few percentage points you give up. We default new commitments to flexible and only reach for resource CUDs on genuinely frozen, well-understood baselines.

Term length: we default to one year. Three-year commitments roughly double the discount but ask you to predict your compute shape three years out, and that prediction is usually wrong at our scale. Very large, very stable footprints can do the three-year math. Ours moves too much.

Where this fits the bigger picture#

CUDs and SUDs are the discount layer, not the savings strategy. The biggest wins come from rightsizing and killing idle capacity — a 40% discount on an oversized VM loses to a 50% rightsizing every time. Get the usage right first, then discount what's left. If you want the full workflow, our cloud cost optimization guide walks the measure-then-commit loop end to end.

We also watch a few numbers monthly: CUD utilization (target above 95% — anything lower is a commitment you're paying for and not consuming), coverage (what fraction of steady-state is under commitment, target ~70-80%), and on-demand spend as a share of total (if it climbs, we're under-committed).

The call we'd make#

Take the free SUD, always — it costs nothing and it's already applied. Buy CUDs against your measured floor, not your peak, sized to 70-80% of the true baseline. Default to flexible CUDs and one-year terms unless the workload is genuinely frozen on a known family, in which case a resource CUD for that slice pays a little better. And rightsize before you commit, so you're locking in the lean number. The discount is the last 30%, not the first move.