A flexible committed use discount on GCP is a spend based commitment: you agree to spend a fixed amount per hour on eligible Compute Engine usage for one or three years, and that spend is discounted whatever machine type, family, or region you run it on. The change that matters is the shift in posture it allows. Where a resource based CUD locks you to a specific amount of vCPU and memory of one family in one region for the deepest discount, a flexible CUD follows your spend, carries a smaller discount, and survives the instance and region changes that real estates go through. The practical answer is to layer both: deep resource based coverage on the workloads that never move, flexible coverage over the part that shifts, and on demand plus sustained use discounts on the uncertain top of the curve.
Commitment strategy is about covering demand you can defend, not about maximising a headline discount.
What is a flexible CUD and how does it work?
GCP committed use discounts come in two forms. Resource based CUDs commit you to a quantity of vCPU and memory for a specific machine family in a specific region for a one or three year term, and in return give the deepest per unit discount. The cost of that depth is rigidity: if you migrate to a newer machine family, change regions, or rearchitect, the commitment can strand because it only applies to the shape you bought. Flexible, or spend based, CUDs invert the trade. You commit to a dollar amount of eligible compute spend per hour, and the discount applies across machine types and regions automatically. The discount is smaller than the resource based equivalent, but the commitment moves with you, so a migration or a region shift does not waste it.
The instrument you choose is really a statement about how much you expect to change. Stable, well understood workloads can afford the rigidity of a resource based CUD for the deeper rate. Workloads you expect to migrate, resize, or move regions are safer under flexible coverage, because the smaller discount is cheaper than a stranded commitment.
What changed, and why does flexibility matter more now?
Two forces make flexible coverage more valuable than it used to be. The first is the pace of machine family change: GCP ships new generations regularly, and the savings from migrating to a newer, more efficient family can exceed the extra discount of a rigid commitment, so a resource based CUD that blocks the migration costs you twice. The second is the spread of multi region and workload mobility, where teams move services to follow latency, data residency, or capacity, and a region locked commitment punishes exactly the agility the business wants. Flexible CUDs let you keep committing, and keep collecting a discount, without betting that next year's estate looks like this year's. Treat any specific discount percentage as indicative and verify against the current GCP pricing page before you model it.
How much should you commit, and in which form?
Coverage is a forecast problem, not a discount problem. Start from a defensible view of steady state usage: the floor of compute that has run for months and that the business plan says will persist through the commitment term. That floor is what you commit to. Within it, split by stability. The portion that runs on a fixed machine family in one region and is unlikely to move can take resource based CUDs for the deeper rate. The portion that is steady in dollars but fluid in shape, because it migrates, resizes, or spans regions, takes flexible CUDs. Everything above the defensible floor, the growth you hope for but cannot yet prove, stays on on demand with sustained use discounts until it becomes a floor of its own. Reviewing coverage as the forecast updates keeps utilization high and stops a once correct commitment drifting into waste.
A European SaaS company held resource based CUDs on an older machine family across two regions. A planned migration to a newer family would have stranded much of that commitment, so the team had been delaying the move and paying for less efficient compute to protect the discount. Restructuring coverage solved both: flexible CUDs sized to the steady spend floor let the migration proceed without wasting the commitment, while a smaller layer of resource based CUDs stayed on the genuinely fixed workloads. The estate captured the newer family's efficiency and kept high commitment utilization at the same time. Figures are verified against billing data and anonymised; discount rates are indicative pending a check against current GCP pricing.
Where this sits in the wider GCP picture
Flexible CUDs are one piece of a commitment program that also covers how much to buy and when to walk away. Sizing the coverage ratio is covered in commitment coverage targets on GCP, and the discipline of letting a commitment expire rather than renewing on autopilot is in when to let a CUD lapse. The full estate playbook lives in the GCP cost optimization guide, and the cross cloud view, including how AWS Savings Plans and Azure savings plan handle the same flexibility trade, is in the cross cloud cost optimization guide.
Frequently asked questions
What is a flexible CUD on GCP?
What is the difference between spend based and resource based CUDs?
How much should I cover with CUDs?
Put a number on your coverage
We model your steady state demand, split it by how likely each workload is to move, and structure flexible and resource based CUDs so the discount holds through migrations instead of stranding. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
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.