Google Cloud CUDs, the discount that only works below the floor
A committed use discount lowers the rate in exchange for a one or three year commitment, and the rate is the easy part. Whether it saves money is decided by one number: where the committed baseline sits relative to your steady state usage. Above it, the discount becomes stranded spend with a contract attached.
Prepared by Redress Compliance · August 6, 2026 · Google Cloud advisory. Based on 20 to 30 commitment reviews run 2024 to 2026.
Executive summary
Two constructions, two behaviors. Resource based CUDs commit to a quantity of a specific resource, vCPU and memory in a region, and suit workloads that are stable in both size and shape. Spend based CUDs commit to an hourly dollar amount on a service and flex across machine types, buying flexibility at a shallower discount. The portfolio answer is layered: a resource based floor under the immovable base, spend based flexibility above it.
The sizing rule is the whole game: commit at or below the steady state floor, never at the average and never at a peak. Unused commitment is a sunk cost with no refund path, so every point of overcommitment converts the discount into stranded spend. Across our reviews, commitments sized off a high month left 15 to 30 percent of committed capacity idle, quietly erasing the saving the discount was supposed to deliver.
The term is a forecast confidence statement, not a discount menu. Three year commitments carry the deepest rates and fit only baselines you are confident will persist; in our reviews, three year commits on workloads with a clear two year horizon locked in stranded spend that no rate could recover. One year terms on the uncertain layers cost a few points and buy an exit.
Stacking blindness inflates the business case. Sustained use discounts already apply automatically to qualifying workloads, and estates that modeled CUD savings against list price double counted the saving they expected. The honest baseline for any CUD decision is the bill you actually pay today, sustained use included, priced against the committed alternative.
Resource versus spend, choosing the construction per layer
| Resource based CUD | Spend based CUD | |
|---|---|---|
| What you commit to | A quantity of resource, vCPU and memory, in a region | An hourly dollar amount on a service |
| What it flexes across | Nothing: the committed shape is the committed shape | Machine types and shapes within the service |
| Where it wins | The immovable base: stable production workloads with known shape and region | The layer above the base, where shape and machine families still move |
| The failure mode | Shape drift: the estate migrates machine families and the commit strands | Paying the flexibility premium on workloads that never needed it |
Sizing at the floor, the arithmetic that decides everything
The commitment bills whether you consume it or not, which makes the sizing asymmetry brutal: capacity above the commit simply bills at on demand rates, while commitment above your usage is pure loss. The correct baseline is therefore the steady state floor, the level usage reliably stays above, month after month, with seasonality and planned migrations subtracted.
- Pull twelve months of usage per service, region, and machine family, and find the floor, not the average. The average includes the peaks you must not commit to.
- Subtract the known futures: migrations, decommissions, re-platforming to managed services, and anything with a shorter horizon than the term.
- Commit in layers, and leave headroom deliberately: a 70 to 85 percent coverage target against the floor outperforms full coverage the moment anything changes.
The Google Cloud CUD negotiation playbook
The layered commitment design, the floor sizing worksheet, the resource versus flexible split, and the contract stack order that keeps CUDs and negotiated discounts compounding.
Get the white paper →The stacking rules, what CUDs actually combine with
Sustained use discounts apply automatically to qualifying Compute Engine workloads and already sit inside the bill you pay, which produces the most common modeling error in our reviews: CUD savings projected against list price, double counting a discount already received. The honest comparison is the current effective rate against the committed rate, workload by workload.
The second stacking question is contractual: how CUDs interact with a negotiated enterprise discount. In a properly structured agreement the contract percentage applies to the post CUD effective rate, and the stack order belongs in the ordering document in writing, because the difference is worth several points of total spend. The wider agreement mechanics sit in the enterprise negotiation playbook, and the discount benchmarks show what the combined position reaches at enterprise scale.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across commitment reviews, 2024 to 2026
Across roughly 20 to 30 Google Cloud cost reviews Morten Andersen ran between 2024 and 2026, the recurring finding was overcommitment sized against peaks rather than the steady state floor:
Commitments set off a high month, billing for capacity the steady state never consumed.
Three year commitments on workloads with a clear two year horizon, locking stranded spend past the workload's own life.
The third pattern was stacked discount blindness: savings cases built against list price when sustained use discounts already applied, which flattered the CUD by exactly the discount already in the bill. The reviews that recovered the most did the unglamorous sequence: effective rate baseline first, floor second, layered commitment third, and the ongoing ownership that the FinOps tooling never assigns, covered in the FinOps and CUD playbook.
Your first five moves
- Baseline the effective rate, sustained use included, per service and region. Every savings case starts from the bill you actually pay.
- Find the steady state floor from twelve months of usage, with migrations and decommissions subtracted, and target 70 to 85 percent coverage against it.
- Layer the constructions: resource based under the immovable base, spend based over the flexible middle, nothing over the volatile top.
- Match the term to forecast confidence: three years only where the baseline demonstrably persists, one year where it might not.
- Write the stack order into the ordering document, contract discount applied after CUD rates, and assign a monthly rebalance owner. The Google Cloud practice runs the design with you, on your side of the table.
Frequently asked questions
What is the difference between resource based and spend based CUDs?
Resource based CUDs commit to a quantity of a specific resource, vCPU and memory in a region, at the deepest rates, and suit stable workloads. Spend based CUDs commit to an hourly dollar amount on a service and flex across machine types at a shallower discount. Mature portfolios layer both: resource under the immovable base, spend above it.
How much should we commit to with Google Cloud CUDs?
At or below your steady state floor, the level usage reliably stays above with seasonality and planned changes subtracted, with a 70 to 85 percent coverage target against that floor. Committing at the average or a peak converts the discount into stranded spend: in our reviews, peak sized commitments left 15 to 30 percent of capacity idle.
Should we choose one year or three year commitments?
By forecast confidence, not discount depth. Three year terms carry the deepest rates and fit only baselines you are confident will persist through the term; three year commits on two year workloads locked in stranded spend in our reviews. One year terms on the uncertain layers cost a few points and preserve the exit.
What happens to unused Google Cloud commitment?
It bills anyway. Committed use is a floor, not a wallet: there is no refund path for unused commitment, which is why the sizing asymmetry favors undercommitting, where the excess simply bills at on demand rates, over overcommitting, where the excess is pure loss for the term.
Do CUDs stack with sustained use discounts?
Sustained use discounts apply automatically and already sit in your current bill, which is exactly why savings cases must be modeled against the effective rate rather than list price. CUDs replace sustained use on committed resources, so projecting CUD savings against list double counts the discount already received.
Do CUDs stack with a negotiated enterprise discount?
They should: in a properly structured agreement the contract percentage applies to the post CUD effective rate. The stack order belongs in the ordering document in writing, because the difference between applying the discount before and after CUD rates is worth several points of total spend.
