TL
The short answer

A sound GCP Committed Use Discount renewal follows a fixed sequence: review CUD utilisation and coverage on the expiring term, rebuild the forward forecast from current usage, choose between spend based and resource based CUDs for each part of the estate, size coverage to the baseline you are confident in, and stage the purchase so you are never overcommitted on the day the old term lapses. Sustained use discounts apply automatically on top, so the commitment only needs to cover the predictable baseline, not every hour.

The expensive habit is to roll the expiring commitment forward at the same size. Usage moves, machine families change, and sustained use discounts already cover part of the gap. Treat every renewal as a fresh sizing exercise against today's forecast.

What do I review before a GCP commitment renews?

Start with the expiring term's record. Pull CUD utilisation and coverage from the billing reports and the commitment analysis views. Utilisation tells you whether you used what you committed to; coverage tells you how much of eligible usage the commitment carried; and the effective discount tells you what the commitment returned against on demand, after sustained use discounts are accounted for. Low utilisation means you overcommitted and should size down. Full utilisation with low coverage means there is room to commit more.

Read these against the trend, not just the average. A commitment fully used on a workload that is shrinking is still a weak renewal candidate. Standing utilisation monitoring makes the picture clear long before expiry, as covered in commitment coverage targets on GCP.

Spend based or resource based CUDs at renewal?

This is the GCP specific decision. Resource based CUDs commit to a specific amount of vCPU and memory in a machine family and region, in exchange for a deeper discount, and they suit a stable, well understood baseline. Spend based CUDs commit to an hourly dollar amount across eligible services and flex more freely as the workload mix changes, in exchange for a slightly shallower discount. The risk adjusted answer is usually to cover the stable core with resource based CUDs and the moving or diversifying layer with spend based CUDs, so flexibility sits where change is most likely.

Worked example

A scaling fintech planned to renew its resource based CUDs unchanged. Rebuilding the forecast showed a migration toward newer machine families and a growing share of managed services that the existing resource based commitments would not cover. Splitting the renewal into a smaller resource based core for the stable families plus spend based CUDs for the rest matched the real estate and avoided stranding spend on families being retired. Figures are verified against billing data and anonymised.

One year or three year term?

Term length is a bet on forecast confidence. A three year CUD buys the deepest discount but assumes the workload still looks similar in three years. A one year CUD costs more per unit but keeps you flexible. Match term to certainty: three year on the stable core you would run regardless, one year on anything you expect to evolve, and leave the genuinely uncertain layer to sustained use discounts and on demand.

The renewal checklist

StepQuestion to answer
1. ReviewWhat were CUD utilisation, coverage, and effective discount on the expiring term?
2. ForecastWhat is the defensible forward baseline once migrations and shutdowns are removed?
3. InstrumentWhich spend suits resource based CUDs, and which needs spend based flexibility?
4. SizeWhat coverage keeps utilisation high once sustained use discounts are accounted for?
5. TermWhere does three year confidence end and one year flexibility begin?
6. StageHow do you ladder commitments so no single expiry forces a rushed renewal?

Ladder the commitments so they expire on different dates and you never face a single cliff that pressures a wrong sized renewal. The leverage that surrounds large GCP renewals is covered in the cloud commitment negotiation guide, and the renewal posture in renewing GCP commitments from strength.

Frequently asked questions

When should I start a GCP commitment renewal?
Begin in the months before expiry. That window gives time to review CUD utilisation on the expiring term, rebuild the forecast, choose between spend based and resource based CUDs, and ladder the purchase rather than renewing under deadline pressure.
Should I renew spend based or resource based CUDs?
Cover the stable, well understood baseline with resource based CUDs for the deeper discount, and cover the moving or diversifying layer with spend based CUDs for flexibility across services. Match the instrument to how likely the workload is to change.
Do sustained use discounts change how much I should commit?
Yes. Sustained use discounts apply automatically to eligible usage, so the commitment only needs to cover the predictable baseline rather than every hour. Size CUD coverage to the steady state you are confident in and let sustained use discounts handle part of the rest.

Renew GCP commitments from a defensible forecast

We rebuild your GCP forecast, size the renewal across spend based and resource based CUDs, and ladder the purchase so you cover the baseline without stranding spend across AWS, Azure, GCP, and OCI. Our guarantee: we reduce your cloud spend or we reimburse our service fee.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.