Committed use discounts cut Google Cloud rates in exchange for a one or three year commitment. Read where the lock in bites before you size the commitment off a peak month.
A committed use discount lowers the rate, but it only saves money if the committed baseline sits below your steady state usage rather than above it.
Google Cloud offers two committed use discount models. They lower the rate the same way but commit to different things, and the right one depends on how stable your machine mix is.
Google documents both models on the committed use discounts overview and the Compute Engine CUD documentation. Read the commitment unit carefully, because it sets how much flexibility you keep.
Google Cloud CUD models compared
| Attribute | Resource based | Spend based |
|---|---|---|
| Commits to | Resource quantity in a region | Hourly dollar spend on a service |
| Flexibility | Low, tied to machine type | Higher, flexes across types |
| Discount depth | Deepest | Moderate |
| Best fit | Stable, fixed workloads | Variable mix, steady baseline |
| Term options | One or three year | One or three year |
Size the commitment to your steady state floor, the level of usage that never drops below a line across a full year. Anything above that floor is better left on demand or covered by a smaller spend based commitment.
Google explains that sustained use discounts already apply automatically to some services, and the pricing principles sit on the Google Cloud pricing page. Account for those automatic discounts before you model the incremental CUD saving, or you will overstate the benefit.
Take the three year term only where the baseline is genuinely durable. Match the commitment term to the workload horizon, and never let the deeper headline discount pull you past the point where you are confident the usage persists.
CUDs are one lever in a larger negotiation. Many enterprises also hold a Google Cloud commitment contract with custom pricing, and the CUDs sit alongside it. Treat the two together.
Google describes spend based committed use discounts in more depth in its spend based CUD documentation. Use the figures there as the floor for what is publicly available, then negotiate the custom commitment on top.
The common advice is to maximize the three year commitment because it carries the deepest discount. We disagree. In roughly two thirds of the commitment reviews we ran in 2024 and 2025, the deeper term locked in capacity that the estate later could not use, and the idle commitment wiped out the rate saving. The buyer side move is to commit only to the durable steady state floor, take the longer term only where the baseline is certain, and cover everything above the floor with flexible spend based or on demand capacity. A smaller commitment you fully use beats a larger one you partly waste.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
A committed use discount only saves money when the committed baseline sits below your steady state floor, never above it.
Overcommitment is avoided with a year of usage data and a disciplined floor. Commit to the floor, layer flexibility above it, and negotiate the custom contract separately.
Start with a one year commitment on the clear floor, observe the actual utilization, then extend or deepen only on proven baseline. Staging avoids the lock in that off the shelf advice walks estates into.
Buyers over-index on the headline "up to 70 percent" and under-index on which SKUs actually hit it. Run the math for three profiles before you sign.
Steady, single-family fleet (say 200 N2 vCPUs running 24/7 in one region) is the textbook case for resource-based CUDs: a 3-year commit yields 55 percent off on-demand, a 1-year commit 37 percent. Mixed, shifting fleet (N2 today, C2D next quarter, some GKE Autopilot) is punished by resource-based commits because they lock to one machine family and region; flexible spend-based CUDs trade depth for portability at 28 percent (1-year) or 46 percent (3-year) across eligible families and all regions. Bursty workloads (baseline 60 vCPUs, peaks to 200) should commit only the trough on a 3-year resource-based CUD, let automatic sustained use discounts partially cover the volatile top, and never commit the peak.
CUD discount by type and term
Google-published rates, verified July 2026.
| CUD type | Scope | 1-year | 3-year |
|---|---|---|---|
| Resource-based (general/compute) | Compute Engine, per region+family | 37% | 55% |
| Resource-based (memory-optimized) | Compute Engine | — | up to 70% |
| Compute Flexible CUD | Compute Engine, GKE Autopilot, Cloud Run | 28% | 46% |
| Cloud SQL CUD | Enterprise + Enterprise Plus, per region | 25% | 52% |
| BigQuery editions CUD | Enterprise slots, per region | 10% | 20% |
| Sustained Use Discount (auto) | N2/N2D/C2 up to 20%; N1 up to 30% | auto | — |
Buyer move: the right CUD is a function of workload stability, not of the biggest advertised number. The classic error is sizing to average utilisation; you size to the floor.
Flexible spend-based CUDs are a dollar commitment that burns down against eligible usage rather than a reservation of specific hardware. Attribution is proportional: Google splits the credit across projects in the billing account and across SKUs by each one’s share of eligible spend, automatically. That is a genuine advantage over the fixed account-by-account priority of AWS Savings Plans.
Sharing is the catch. As of 16 June 2026, newly created Cloud Billing accounts have CUD sharing enabled by default, so commitments flow across all projects. Accounts created before that date may still have sharing off, meaning a commitment strands inside the single project that owns it while sister projects pay on-demand.
An older enterprise billing account with sharing disabled is the single most common cause of "we bought CUDs and coverage still looks terrible." Turn sharing on first, then size. And remember flexible CUDs cannot be cancelled once purchased — proportional attribution improves utilisation, but it does not rescue an oversized commit.
CUDs are no longer a compute-only tool, and the depth varies sharply by service. GKE Standard nodes inherit Compute Engine CUDs directly, while GKE Autopilot pods are covered by Compute flexible CUDs. Cloud SQL offers spend-based CUDs at 25 percent (1-year) and 52 percent (3-year) across both Enterprise and Enterprise Plus editions — covering vCPU and memory only, not storage, backups, IP or egress. BigQuery editions and slot CUDs are much shallower at 10 percent and 20 percent. Vertex AI, AlloyDB, Spanner and Dataflow now carry their own service-specific spend-based CUDs.
Resource-based vs flexible vs sustained-use
| Dimension | Resource-based | Flexible / spend-based | Sustained Use |
|---|---|---|---|
| Max depth | ~55–70% | 28% / 46% | ~20–30% |
| Commit unit | vCPU/RAM, one region+family | Dollars per hour | None |
| Portability | Locked to family + region | All families + regions | Automatic |
| Cancellable | No | No | N/A |
| Best for | Stable single-family floor | Mixed / shifting fleet | Volatile top layer |
Buyer move: never negotiate "a CUD" as one line. Build a per-service commit stack, because a 52 percent Cloud SQL commit and a 20 percent BigQuery commit carry very different overcommitment risk for the same dollar exposure.
A CUD is a billing obligation, not a usage discount. Once purchased, resource-based and flexible CUDs cannot be cancelled or refunded, and Google bills the committed amount every hour for the full term regardless of consumption. Commit $50k a month and drop to $35k, and you still pay $50k — that $15k gap is pure waste, with no marketplace to resell a Google CUD.
Four guardrails: commit to the trough of your trailing-12-month usage, not the average; ladder commitments so a chunk expires each quarter rather than one cliff renewal; prefer 1-year terms when confidence is below about 80 percent, since the premium over 3-year is cheap insurance against a re-architecture; and blend resource-based for the certain floor, flexible for the probable middle, and on-demand plus sustained use for the volatile top.
White Paper · Google Cloud
How to size committed use discounts to your usage floor, blend resource-based and flexible CUDs, and fold CUDs into a wider Google Cloud commitment without stranding spend. Read it free.
No — CUDs cannot be cancelled or refunded, and Google bills the full committed amount for the entire term regardless of actual usage, so size to your usage floor, not your forecast.
No — sustained use discounts apply only to usage not already covered by a CUD, and Google automatically applies whichever discount is more favourable per resource.
A committed use discount lowers your Google Cloud rate in exchange for a one or three year commitment to a level of usage or spend. The discount is real, but it only saves money when the committed baseline sits below your steady state usage rather than above it.
Resource based CUDs commit to a quantity of a resource, such as vCPU and memory in a region, and carry the deepest discount but the least flexibility. Spend based CUDs commit to an hourly dollar amount on a service and flex across machine types, usually at a smaller discount.
Take the three year term only where the baseline usage is genuinely durable, because it carries the deepest discount but the heaviest lock in. Match the term to the workload horizon, and never let the deeper headline rate pull you past the point where you are confident usage persists.
Size it to your steady state floor, the level of usage that never drops below a line across a full year of data. Commit at or below that floor, and cover everything above it with flexible spend based or on demand capacity to avoid paying for idle commitment.
Unused committed capacity is a sunk cost. You pay for the commitment whether or not you use it, so an oversized commitment can wipe out the rate saving entirely. In our reviews, peak sized commitments left 15 to 30 percent of committed capacity idle.
Sustained use discounts apply automatically to some services and should be netted out before you model the incremental CUD saving. Estates that ignore them double count the expected benefit and overstate the CUD payback.
Yes. Many enterprises hold a custom Google Cloud commitment contract that sits alongside the public CUDs. Treat the two together, using the public CUD figures as the floor and negotiating the custom commitment rate on top.
Stage the commitment. Start with a one year commitment on the clear steady state floor, observe actual utilization, then extend or deepen only on a proven baseline. Staging avoids the lock in that maximalist advice walks estates into.
The CUD comparison, the commitment sizing model, the overcommit traps, and the negotiation levers on the broader Google Cloud agreement.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
