Renewing every GCP Committed Use Discount by reflex is how estates end up paying for capacity they no longer run. A CUD should lapse when the workload it covered is shrinking, moving, or being rearchitected, because a commitment is only a saving if the usage underneath it is real for the full term. The decision is a forecast question, not a habit.
This sits in the GCP compute and commitments cluster. The right frame is risk adjusted: a CUD that no longer matches the workload is a liability dressed as a discount, and letting it lapse can be the cheaper, lower risk choice.
What a CUD actually commits you to
GCP offers two shapes. Resource based CUDs commit to a specific amount of vCPU and memory in a region and machine family, giving the deepest discount but the least flexibility. Spend based CUDs commit to an hourly dollar amount across eligible services, trading some discount for flexibility as your mix changes. Both are use it or lose it: if the usage falls away, you still owe the commitment.
Before you renew, factor the discount you already receive for free. On Compute Engine, sustained use discounts apply automatically to steady usage with no commitment, so a CUD on top of that is only worth what it adds beyond the sustained use baseline.
The four signals that say let it lapse
- Declining usage. The workload the CUD covered is being wound down or its footprint is shrinking. Committing again locks you to a number the usage will not reach.
- A migration or rearchitecture in the term. If the workload is moving regions, changing machine families, or being redesigned within the next year, a resource based CUD pinned to the old shape becomes stranded.
- Sustained use already covers it. If automatic sustained use discounts already discount most of the steady spend, a new CUD adds little.
- No defensible forecast. If you cannot defend the usage number for the full term, the safe default is to let it lapse and revisit with better data.
A simple decision frame
| Workload trajectory | Discount already from sustained use | Call |
|---|---|---|
| Stable or growing, defensible forecast | Partial | Renew, sized to the floor |
| Migrating or rearchitecting this term | Any | Let it lapse, recommit after |
| Declining footprint | Any | Let it lapse or downsize |
| Stable but mostly covered by sustained use | High | Let it lapse, the CUD adds little |
A scaling fintech was about to renew a set of resource based CUDs in a region it was migrating away from. We mapped the CUDs to the workloads, found the covered usage was leaving within the term, and let those commitments lapse while recommitting only against the stable estate. The avoided commitment was larger than the discount the renewal would have delivered. Figures are verified against billing data and anonymised.
Monitor utilization so the decision is data led
You can only make this call if you watch CUD utilization continuously. Track coverage and utilization on the same weekly cadence you use for the rest of the bill, so a commitment drifting away from its workload is visible months before the renewal date rather than discovered at it.
Frequently asked questions
When should you let a GCP CUD lapse instead of renewing?
What is the difference between spend based and resource based CUDs?
Do sustained use discounts change the CUD decision?
Decide commitments with us
We help enterprises decide which GCP Committed Use Discounts to renew and which to let lapse, sized to a defensible forecast. It connects to the full approach in the GCP cost optimization guide. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
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.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.