A committed use discount is only a discount if the usage shows up
Across the Google Cloud estates we benchmarked, committed use discounts were the least actively managed savings instrument in the FinOps stack. Coverage ratio is a moving target: the estates that rebalance monthly keep the discount, and the ones that set and forget strand the commit. CUDs are a portfolio, not a purchase, so coverage discipline is the whole game, and a stranded commit is a 100 percent markup on zero consumption.
Prepared by Redress Compliance · August 9, 2026 · Google advisory. Based on roughly 15 to 25 Google Cloud estates benchmarked 2024 to 2025.
Executive summary
Resource-based CUDs pay up to 55 percent but pin the workload, so buy portability only where workloads actually move.
Google Cloud sells two commit instruments: resource-based CUDs tied to a machine family in a region, paying up to 55 percent off on three-year terms, and spend-based flexible CUDs tied to an hourly dollar amount, paying less, roughly 46 percent, but following workloads across families and regions.
Sustained use discounts apply automatically to eligible compute with no commitment, setting the baseline any CUD must beat, so the arithmetic question is always the incremental discount per unit of flexibility surrendered.
Teams that bought flexible CUDs for stable single-region workloads paid 8 to 12 points more discount margin than resource-based would yield.
Healthy programs hold 70 to 85 percent coverage and rebalance monthly; set-and-forget leaks 20 to 35 percent.
A working program rebalances coverage monthly, holds it between roughly 70 and 85 percent of stable usage, and assigns ownership of the buy decision, because CUDs are a portfolio, not a purchase.
Maturity runs from reactive, bought at signing and never revisited at 20 to 35 percent on-demand leakage, through scheduled at 10 to 20 percent timing lag, to managed with a monthly rebalance and an owner at 5 to 10 percent residual, to optimized under 5 percent.
Set coverage at the trailing P25 of stable usage for resource-based commitments, then layer flexible CUDs to roughly 85 percent total, so the floor protects against shrinkage and the flexible layer absorbs drift.
Coverage above 90 percent strands commits when platforms migrate, so cap the resource-based floor at P25 of immovable compute.
The standard FinOps advice is to maximize CUD coverage because discounts always beat on demand.
We disagree, because in 8 of the estates we benchmarked, coverage above 90 percent turned into stranded commitment within a year, as platform teams migrated workloads to GKE Autopilot, new machine families or other clouds faster than the commit term expired.
Cap resource-based coverage at the P25 floor of genuinely immovable workloads and pay the flexibility premium on the rest, because a stranded commit is a 100 percent markup on zero consumption, and coverage discipline, not coverage maximization, is the whole game.
BigQuery commits separately on editions slots, and leaving it on pay-as-you-go is the most common program gap.
BigQuery is committed through editions slot commitments, not compute CUDs, and stable analytics spend above roughly 10K dollars a month on stable query patterns cuts the line 20 to 40 percent with a baseline slot commitment.
Commit slots to the P25 of sustained query load, let editions autoscaling absorb peaks at on-demand slot rates, and isolate reservations for ELT, BI and ad hoc so one team's spike does not buy capacity for everyone.
On top of the self-serve instruments sits the negotiated spend commit, and the contract discount must apply to the post-CUD rate, not instead of it, so get the stack order in writing.
CUD program maturity, and what changes at each level
| Level | Coverage behavior | Typical waste |
|---|---|---|
| Reactive | Bought at signing, never revisited | 20 to 35 percent on-demand leakage |
| Scheduled | Quarterly review, manual buys | 10 to 20 percent timing lag |
| Managed | Monthly rebalance, owner assigned | 5 to 10 percent residual |
| Optimized | Continuous coverage targets, automation | Under 5 percent |
Set coverage at the trailing P25 of stable usage for resource-based commitments, then layer flexible CUDs to roughly 85 percent total: the floor protects against shrinkage, the flexible layer absorbs drift.
Match the instrument to the workload: resource-based CUD for stable, region-pinned, family-pinned compute at the deepest discount; flexible CUD for workloads that migrate families or regions, paying for the portability.
Sustained use only for spiky or experimental workloads where any commitment risks waste; and BigQuery editions commitments for the analytics line, committed separately on slot capacity.
Above the self-serve instruments sits the negotiated spend commit that trades total contract value for percentage discounts and credits, and CUDs stack inside it, so the contract discount applies to the post-CUD rate in a properly structured deal.
Order of operations matters and the published SKU pricing is the verification baseline. The contract-side detail sits in the CUD negotiation guide, and the peer numbers in the discount benchmarks.
Which instrument fits which workload
- Resource-based CUD: stable, region-pinned, family-pinned compute, the deepest discount at up to 55 percent on three-year terms, and the instrument that strands if the workload moves.
- Flexible CUD: workloads that migrate families or regions, where you pay for the portability at roughly 46 percent, worth it only where workloads actually move.
- Sustained use only: spiky or experimental workloads where any commitment risks waste, sitting beneath both CUD types as the automatic baseline any CUD must beat.
- BigQuery editions commitments: the analytics line committed separately on slot capacity, where stable spend above roughly 10K dollars a month justifies a baseline slot commitment and cuts the line 20 to 40 percent.
- Cap the resource-based floor at P25 of immovable compute: because coverage above 90 percent strands commits when platforms migrate, and a stranded commit is a 100 percent markup on zero consumption, so pay the flexibility premium on the rest.
The Google Cloud FinOps and CUD white paper
Instrument decision trees, coverage math, stranded-commit avoidance, and the contract stack-order checklist.
Get the white paper →BigQuery, and the contract stack on top
BigQuery commits separately through editions slot commitments, and leaving it on pay-as-you-go is the most common gap in Google Cloud FinOps programs, because analytics spend above roughly 10K dollars per month on stable query patterns almost always justifies a baseline slot commitment.
Commit slots to the P25 of sustained query load, let editions autoscaling absorb peaks at on-demand slot rates, and isolate reservations for ELT.
BI and ad hoc so one team's spike does not buy capacity for everyone, which turns a single shared reservation into a set of workload-scoped commitments that each track their own P25.
On top of the self-serve instruments sits the negotiated contract, and four things go into it: the total spend commit, the CUD stacking confirmation, the BigQuery treatment, and the support pricing.
Get the stack order in writing, because the contract discount applies after the CUD rates, not instead of them, and the difference between the two orders is worth several points of total spend.
The standard FinOps advice to maximize CUD coverage because discounts always beat on demand is the trap, because aggressive coverage above 90 percent turned into stranded commitment within a year in 8 of the estates we benchmarked, as platform teams migrated to GKE Autopilot.
New families or other clouds faster than the term expired.
The buyer-side move is to cap resource-based coverage at the P25 floor of genuinely immovable workloads and pay the flexibility premium on the rest, then take twelve months of telemetry into the next contract negotiation, because a committed use discount is only a discount if the usage shows up.
The cross-provider levers apply the same discipline across GCP, AWS and Azure.
- 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 Google Cloud commit reviews, 2024 to 2025
Across roughly 15 to 25 Google Cloud estates we benchmarked between 2024 and 2025, committed use discounts were the least actively managed savings instrument in the FinOps stack, and the common advice makes it worse.
The standard FinOps advice is to maximize CUD coverage because discounts always beat on demand. We disagree:
Of stable compute left on full on-demand rates where coverage ratios were set once at purchase and never rebalanced.
Estates where aggressive coverage above 90 percent turned into stranded commitment within a year as platform teams migrated workloads.
Three patterns recurred: CUD coverage stuck at purchase day, set once and never rebalanced, left 20 to 35 percent of stable compute on full on-demand rates.
Resource-based and flexible CUDs were confused, with teams buying flexible for stable single-region workloads and paying 8 to 12 points more discount margin than resource-based would yield.
And BigQuery was left outside the program on pay-as-you-go while editions commitments would have cut the line 20 to 40 percent.
Coverage ratio is a moving target, so the estates that rebalance monthly keep the discount and the ones that set and forget strand the commit, which is why a working program rebalances monthly, holds 70 to 85 percent coverage, and assigns a named owner.
The sequence is to export twelve months of usage and map stable versus mobile workloads, compute the current effective discount rate and on-demand leakage, set resource-based coverage at the P25 floor of immovable compute, layer flexible CUDs to roughly 85 percent total.
Commit BigQuery baseline slots if analytics spend is stable, assign a monthly rebalance owner with a coverage dashboard, and take the telemetry into the next contract negotiation.
Assign a named owner for the monthly rebalance or the program decays to reactive. The wider Google Cloud library sits in the Google Cloud practice.
Your first five moves
- Export twelve months of usage and map stable versus mobile workloads, because the instrument choice turns on whether the workload will stay in its region and family for the term.
- Set resource-based coverage at the P25 floor of immovable compute, then layer flexible CUDs to roughly 85 percent total, because above 90 percent strands commits when platforms migrate.
- Commit BigQuery baseline slots if analytics spend is stable, to the P25 of sustained query load, because leaving it on pay-as-you-go is the most common program gap.
- Assign a monthly rebalance owner with a coverage dashboard, because CUDs are a portfolio not a purchase, and without an owner the program decays to reactive at 20 to 35 percent leakage.
- Take the telemetry into the next contract negotiation and get the stack order in writing, contract discount after CUD rates. The Google Cloud practice runs the program with you.
Frequently asked questions
What discount do Google Cloud committed use discounts give?
Resource-based CUDs pay up to 55 percent off on-demand for three-year commitments on eligible machine families, and flexible CUDs pay up to roughly 46 percent in exchange for portability across families and regions.
Sustained use discounts apply automatically beneath both with no commitment, setting the baseline any CUD must beat.
The arithmetic question is always the incremental discount per unit of flexibility surrendered, so resource-based suits immovable compute and flexible suits workloads that genuinely move.
Should we buy resource-based or flexible Google Cloud CUDs?
Buy resource-based for compute that will stay in its region and family for the term, because it pays the deepest discount, and flexible for everything mobile, paying for the portability.
In our 2024 to 2025 benchmarks, teams that bought flexible for stable single-region workloads gave up 8 to 12 discount points unnecessarily.
The test is whether the workload will migrate families, regions or platforms within the term: if it will, pay the flexibility premium; if it will not, take the resource-based depth.
What CUD coverage ratio should we target?
Target 70 to 85 percent total coverage: a resource-based floor at the P25 of immovable usage, with flexible CUDs layered above to roughly 85 percent. The floor protects against shrinkage and the flexible layer absorbs drift.
Above 90 percent, migration risk turns commits into stranded cost, because platform teams migrate to GKE Autopilot, new machine families or other clouds faster than the commit term expires, and a stranded commit is a 100 percent markup on zero consumption.
How does BigQuery fit a Google Cloud CUD program?
BigQuery is committed separately through editions slot commitments, not compute CUDs, and leaving it on pay-as-you-go is the most common gap in Google Cloud FinOps programs.
Stable analytics spend above roughly 10K dollars a month usually justifies a baseline slot commitment with autoscaling above it, cutting the line 20 to 40 percent.
Commit slots to the P25 of sustained query load, let editions autoscaling absorb peaks, and isolate reservations for ELT, BI and ad hoc so one team's spike does not buy capacity for everyone.
Do CUDs stack with negotiated Google Cloud contract discounts?
They should. In a properly structured agreement the contract percentage applies to the post-CUD effective rate, not instead of the CUD rates. Confirm the stack order in the ordering document, because the difference between the two orders is worth several points of total spend.
The negotiated spend commit sits above the self-serve CUDs and trades total contract value for percentage discounts and credits, so the four things to pin are the spend commit, the CUD stacking confirmation, the BigQuery treatment, and the support pricing.
Why do Google Cloud commit programs leak so much?
Because coverage ratio is a moving target and most programs set it once at purchase and never rebalance, leaving 20 to 35 percent of stable compute on full on-demand rates at reactive maturity.
CUDs are a portfolio, not a purchase, so a working program rebalances coverage monthly, holds 70 to 85 percent of stable usage, and assigns a named owner.
Without that owner the program decays to reactive, so coverage discipline, the monthly rebalance against a dashboard, is the whole game rather than the initial buy.
Negotiating Google 3: The Cloud Bill and the AI Bill
CUDs stack on private rates, the commit contract's three deciding clauses, support billed on list price, and the three layer AI bill with its double pay risk.
