Google Cloud CUDs and FinOps. Commit to telemetry, not to hope.

Google Cloud committed use discounts reward coverage discipline: a P25 resource based floor, a flexible layer to 85 percent, BigQuery slots committed separately, and a monthly rebalance.

How do Google Cloud CUDs actually work?

Google Cloud sells two commit instruments: resource based CUDs tied to machine families in a region, and spend based flexible CUDs tied to an hourly dollar amount. Resource based pays up to 55 percent off on three year terms; flexible pays less but follows workloads across families, per the Google Cloud CUD documentation.

Sustained use discounts apply automatically to eligible compute with no commitment, which sets the baseline any CUD must beat. The arithmetic question is always incremental discount per unit of flexibility surrendered.

Which instrument fits which workload?

• Resource based CUD: stable, region pinned, family pinned compute; the deepest discount.
• Flexible CUD: workloads that migrate families or regions; pay for the portability.
• Sustained use only: spiky or experimental workloads where any commitment risks waste.
• BigQuery editions commitments: the analytics line, committed separately on slot capacity.

What does the commit ladder look like at contract level?

Above the self serve instruments sits the negotiated spend commit, which trades total contract value for percentage discounts and credits. CUDs stack inside it; 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.

What does a working CUD program look like?

A working program rebalances coverage monthly, holds coverage between roughly 70 and 85 percent of stable usage, and assigns ownership of the buy decision. CUDs are a portfolio, not a purchase.

How do you set the coverage target?

Set coverage at the trailing P25 of stable usage for resource based commitments, then layer flexible CUDs to roughly 85 percent total coverage. The floor protects against shrinkage; the flexible layer absorbs drift.

Where the common advice on Google Cloud CUDs is wrong

The standard FinOps advice is to maximize CUD coverage because discounts always beat on demand. We disagree. In roughly 8 of the 15 to 25 Google Cloud estates Morten Andersen benchmarked in 2024 to 2025, aggressive coverage above 90 percent turned into stranded commitment within a year, because platform teams migrated workloads to GKE Autopilot, new machine families, or other clouds faster than the commit 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. A stranded commit is a 100 percent markup on zero consumption.

A committed use discount is only a discount if the usage shows up. Coverage discipline is the whole game.

How does BigQuery fit the commit strategy?

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. Analytics spend above roughly 10K dollars per month on stable query patterns almost always justifies a baseline slot commitment, per the BigQuery pricing schedule.

1. Baseline commitment: commit slots to the P25 of sustained query load.
2. Autoscaling above baseline: let editions autoscaling absorb peaks at on demand slot rates.
3. Workload isolation: separate reservations for ELT, BI, and ad hoc so one team's spike does not buy capacity for everyone.

What goes into the negotiated contract on top?

Total spend commit, CUD stacking confirmation, BigQuery treatment, and support pricing. Get the stack order in writing: contract discount applies after CUD rates, not instead of them. See the Google Cloud contract terms guide for the clause detail.

What to do next

1. Export twelve months of usage and map stable versus mobile workloads.
2. Compute current effective discount rate and on demand leakage.
3. Set resource based coverage at the P25 floor of immovable compute.
4. Layer flexible CUDs to roughly 85 percent total coverage.
5. Commit BigQuery baseline slots if analytics spend is stable.
6. Assign a monthly rebalance owner with a coverage dashboard.
7. Take the telemetry into the next contract negotiation.

The CUD negotiation guide covers the contract side, and the discount benchmarks show what peers achieve. Vendor Shield keeps coverage and rates reviewed between renewals.

Further reading: the cross provider cloud cost optimization guide from MultiCloud Optimization applies the same levers across GCP, AWS, and Azure.

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.

Should we buy resource based or flexible CUDs?

Buy resource based for compute that will stay in its region and family for the term, and flexible for everything mobile. In our 2024 to 2025 benchmarks, teams that bought flexible for stable workloads gave up 8 to 12 discount points unnecessarily.

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. Above 90 percent, migration risk turns commits into stranded cost.

How does BigQuery pricing fit a CUD program?

BigQuery is committed separately through editions slot commitments, not compute CUDs. Stable analytics spend above roughly 10K dollars per month usually justifies a baseline slot commitment with autoscaling above it, cutting the line 20 to 40 percent.

Do CUDs stack with negotiated contract discounts?

They should. In a properly structured agreement the contract percentage applies to the post CUD effective rate. Confirm the stack order in the ordering document, because the difference is worth several points of total spend.