GCP Committed Use Discounts vs Sustained Use Discounts

Sustained Use Discounts apply automatically when a Compute Engine instance runs a large share of the month, with no commitment and no paperwork. Committed Use Discounts (CUDs) give a deeper cut, roughly 55 to 70 percent off on-demand for three-year compute, in exchange for a one or three year promise. Use both: cover your steady baseline with a CUD and let the automatic discount handle the rest.

These are not an either/or choice. They stack, they target different parts of your usage, and the real decision is how much of your baseline to commit and for how long. Below are the questions GCP teams actually type into a search bar when compute is the biggest line item, answered in the order that gets you a defensible commitment plan.

What are GCP Committed Use Discounts?

Committed Use Discounts are price reductions you get for committing to a steady level of Google Cloud usage for one or three years. You promise the usage up front, GCP lowers the rate, and the discount applies whether or not you consume the full commitment. Overcommit and you pay for capacity you never used, which is the whole risk.

GCP offers CUDs on Compute Engine and on other services, including certain databases and GKE Autopilot. Compute is where most teams start because it is usually the largest and most stable spend. The commitment is billed monthly across the term, so a three-year CUD is thirty-six monthly charges you owe regardless of usage.

What are Sustained Use Discounts?

Sustained Use Discounts are automatic price reductions Compute Engine applies when an instance runs for a significant portion of the billing month. You do nothing to earn them. The longer a qualifying resource runs during the month, the lower its effective rate on the portion above each usage tier.

The discount is tiered by monthly usage and applies to eligible general-purpose and compute-optimized machine types. A workload that stays on all month already gets a discount off the sticker rate before you consider a commitment. Sustained Use Discounts do not apply to every machine family, and they do not stack on resources already covered by a CUD, because a committed resource is already billed at the committed rate.

What is the difference between committed and sustained use discounts?

The core difference is commitment. Sustained Use Discounts are automatic and require nothing, but they save less. Committed Use Discounts require a one or three year promise and carry real financial risk if you overcommit, but they save considerably more. One rewards you for running a machine; the other rewards you for promising future spend.

In practice they layer. Your steady baseline gets a CUD for the deep discount. Usage above the committed amount still runs, and where it is not covered by a commitment, Sustained Use Discounts trim the on-demand rate automatically. You never choose one over the other for the whole account.

Resource-based vs spend-based CUDs: which should you pick?

Pick resource-based CUDs when your machine types and region are stable and you want the deepest possible discount. Pick spend-based (flexible) CUDs when your workloads shift between machine families or regions and you value flexibility more than the last few percentage points of savings. Resource-based commits to hardware; spend-based commits to a dollar amount.

• Resource-based CUDs. You commit to a specific quantity of vCPU and memory in a specific region and machine family. The discount is the deepest available, but the commitment is rigid: if you move that workload to another region or a different machine type, the commitment does not follow it.
• Spend-based (flexible) CUDs. You commit to an hourly dollar amount of Compute Engine spend. The discount applies across eligible machine types and regions, so it keeps earning even as your fleet changes shape. The tradeoff is a somewhat shallower rate than an equivalent resource-based commitment.

A useful pattern for larger fleets is to layer them: a resource-based CUD on the truly fixed core and a spend-based CUD on top to catch the steady but more fluid spend around it. Teams that reorganize regions or migrate machine families often regret an aggressive resource-based commitment, so weigh how stable your architecture really is before you lock the hardware.

One-year vs three-year CUD: which is worth it?

Three-year CUDs save meaningfully more than one-year CUDs, often close to double the discount depth, but they demand confidence that the workload survives three years. Choose one-year when the workload is newer or the architecture is still moving. Choose three-year for mature, boring, load-bearing services you cannot imagine turning off.

The math is a confidence question, not a rate question. A three-year commitment on a service you retire in year two locks in spend on capacity you stopped using, which can wipe out the extra savings. Split the difference by term-laddering: put a three-year CUD under the stable core you are certain about, and one-year commitments on the layer you are only fairly sure about. As you renew each year, you tighten the estimate with real data instead of guessing it all on day one.

How much do Committed Use Discounts save?

For three-year compute commitments, CUDs commonly save in the range of roughly 55 to 70 percent off on-demand pricing, with one-year commitments saving less, often around half that depth. The exact rate varies by machine family, commitment type, and region, so treat these as approximate ranges and confirm the current numbers in the Google Cloud pricing calculator before you commit real money.

Two things change the effective savings. First, resource-based CUDs discount deeper than spend-based ones for the same workload. Second, the baseline you discount from already includes Sustained Use Discounts on uncommitted usage, so the marginal gain from a CUD is the difference between the committed rate and the sustained rate, not the difference from full sticker. When you model the committed baseline for finance, it helps to turn that spend forecast into board-ready financial statements so the multi-year commitment shows up as the fixed obligation it actually is, not a soft estimate. For the mechanics of building that forecast in the first place, our guide to budget forecasting for cloud spend walks through the inputs.

How much of my baseline should I commit?

Commit the floor, never the ceiling. Look at your compute usage over a representative window, find the level it rarely drops below, and commit a percentage of that steady baseline, commonly somewhere in the 60 to 80 percent range. Leave the variable peak on on-demand and Spot. The goal is to guarantee you always use every committed hour.

The failure mode is committing to average or peak usage. If you commit to your average, half the time you are paying for capacity you are not using, because usage below the commitment still bills at the committed amount. Base the number on a real utilization window, not a busy week, and rightsize the fleet first. Committing to machines you were about to shrink just locks in the waste, which is why rightsizing on real utilization should always come before a commitment. Then start conservative: it is easy to add a second CUD next quarter, and impossible to unwind one you regret. Our broader walkthrough on how to reduce your GCP bill puts commitment coverage in sequence with the free cleanup wins that should precede it.

Do CUDs and Spot VMs work together?

Yes, and they cover opposite ends of the same workload. CUDs cover the steady, always-on baseline that must keep running. Spot VMs cover interruptible, fault-tolerant work that can survive a reclaim. They do not overlap, because Spot instances are already discounted and are not what you commit to. Use the commitment for the floor and Spot for the burst.

Spot VMs run at roughly 60 to 91 percent off on-demand, deeper than most CUDs, but Google can reclaim the capacity with about 30 seconds of notice. That makes them ideal for batch jobs, CI runners, rendering, and stateless processing that can checkpoint and resume, and a poor fit for stateful databases or latency-critical services. When a workload can tolerate interruption, Spot usually beats a commitment on price and should carry the spiky peak above your committed baseline. Keep the two separated in your capacity plan so you never commit to usage that Spot should have handled for less. A dedicated Google Cloud cost optimization view makes the split visible, and if you are weighing platforms, we compared the leading GCP cost management tools and where each one fits.

Where to start

Rightsize first, then measure the floor. Pull a representative window of compute usage, find the level your fleet rarely drops below, and commit 60 to 80 percent of that baseline. Start with one-year terms while you build confidence, reserve three-year commitments for the mature core, and let Sustained Use Discounts handle everything uncommitted.

Then keep the plan honest. Review coverage every quarter, ladder your terms so renewals track real usage, and push interruptible work to Spot. Do the cleanup before the commitment, size the commitment to the floor, and the savings hold for the full term instead of quietly turning into paid-for idle capacity.