Committed use discounts in Google Cloud, and the order to buy them in
CUDs come in two flavours that behave very differently, and buying the wrong one locks you to a machine family for three years. Here is the sequence we follow.
Google Cloud's discount model is more forgiving than most, and that is precisely why teams get it wrong: sustained use discounts apply automatically, so the bill already looks discounted, and nobody examines the commitment options until the finance team asks.
There are real savings here — 20 to 55 percent depending on term and type — but the order matters, and one of the two commitment types is much easier to regret.
Know which discounts you are already getting
Sustained use discounts apply automatically to Compute Engine instances that run most of a month. No action, no commitment. They are already in your invoice.
Committed use discounts are a one or three year commitment in exchange for a deeper discount, and they come in two kinds that are not interchangeable.
Spend-based versus resource-based, and why it matters
Spend-based CUDs commit you to a dollar amount per hour on a service. They are flexible: they apply across machine types, across regions, and to the newer generations that appear during your term. Available for Cloud Run, GKE Autopilot, Cloud SQL, Spanner, Memorystore and, importantly, Compute Engine via the flexible variant.
Resource-based CUDs commit you to a quantity of vCPU and memory in a specific region and machine family. They discount more deeply, and they are a trap for anyone whose architecture might change. A three-year n2 commitment in europe-west1 is worth nothing to a workload you move to c4 or to another region, and the commitment continues billing regardless.
Our default: spend-based for everything, resource-based only for a workload that is provably static — a database cluster that will not move, a licensed application with fixed sizing. The extra few percent from resource-based is rarely worth losing the freedom to adopt a newer machine family that is itself cheaper per unit of work.
The order
1. Remove the waste first. A commitment locks in today's footprint. Idle VMs, oversized instances, unattached persistent disks, forgotten dev clusters and old snapshots should be gone before you compute a baseline. This is the same principle as the five layers of the AWS bill and it applies unchanged here.
2. Rightsize with the recommender. The GCP Recommender gives machine-type recommendations from real metrics, idle resource detection and idle IP detection, all free and all in the console. Apply them, then wait two weeks for the new baseline to settle.
3. Move what should be preemptible or Spot. Batch, CI runners, stateless replicas. Spot VMs are 60 to 91 percent off and no commitment covers them — but a commitment bought before you move a workload to Spot is a commitment covering capacity you are about to stop using.
4. Measure the baseline properly. Export billing to BigQuery and take the p10 of hourly usage over 90 days per service. That is the floor you can safely commit to: the level you are above 90 percent of the time.
5. Commit to 60 to 70 percent of that floor, on a one-year term first. One-year commitments discount less than three-year ones and cost far less to be wrong about. Once you have a year of stable data and a roadmap you believe, extend the base layer to three years and keep the top layer on one.
6. Recheck quarterly. CUDs stack, so you can add layers as the baseline grows. Set a calendar reminder for a month before each expiry — an expired commitment silently reverts to on-demand pricing and the invoice jumps.
Two things people miss
CUDs are shared across projects under the same billing account if you enable CUD sharing. Without it, a commitment bought in one project does not help another, which produces the confusing outcome of an underused commitment next to on-demand charges.
GKE Autopilot and Cloud Run have their own spend-based CUDs. Teams that moved off VMs often keep committing on Compute Engine out of habit and leave the newer commitments unbought.
What to expect
On a typical estate, removing waste is 15 to 25 percent, Spot for the right workloads is another 5 to 15, and commitments on the remaining baseline are 20 to 30 on top of that. Doing them in the wrong order is what produces a committed discount on capacity you did not need — which is a loss, not a saving. We work through this sequence in the cost phase of most cloud engagements.
What to do this week
Open the Recommender in the console and look at idle resource and machine type recommendations across your production projects. Apply them. Then, and only then, look at the commitment analysis page, which will now be showing you a baseline worth committing to.