By Yair Knijn · September 15, 2025

The GCP committed-use discount that locked you into last year's architecture

The CFO looks at a three-year general-purpose commitment at roughly 46% off, a one-year at roughly 28%, and the math reads itself: take the deeper rate, lock it in, book the savings for the board deck. What that signature actually buys is a bet that the architecture running this quarter is the one you will still be running in 2028. Finance did not sign a discount. Finance signed a hardware plan and called it a discount.

A committed-use discount looks like a pricing decision. It is a forecasting decision, and the person signing usually has the least visibility into the engineering roadmap that decides whether the forecast holds for 36 months.

The deepest discount carries the most lock-in

Discount depth and commitment risk are the same dial. Google does not hand you 46% for being clever. You earn it by surrendering optionality for three years, and every extra point off the rate is a point of flexibility you sold back. Fine trade for a baseline that genuinely will not move. Bad trade for the part of the estate your platform team already has a migration ticket open against. The failure is silent: no outage, no alarm. The commitment keeps discounting a baseline that is quietly shrinking while you pay full freight on the new shape of the workload running on top.

Resource-based vs spend-based CUDs

This is the distinction the rate-chasing version of the decision skips. Resource-based CUDs buy a few more points because they pin you to a specific machine family in a specific region. Flexible, spend-based CUDs apply to any eligible usage under the billing account, so the discount follows your dollars rather than your N2 instances. Move from N2 to N4 under a resource-based commitment and your coverage stays behind. Do it under a flex CUD and the commitment never notices.

Google widened that gap in mid-2024. Flex CUDs now cover GKE Standard, Autopilot, and Cloud Run instance-based billing, not just bare Compute Engine VMs, so one commitment can sit across VMs, containers, and serverless. The resource-based rate is deeper; the flex rate survives a re-platform. Pick the one that matches how settled the design is, not the one with the bigger number on the slide.

Match the term to what you actually know

Size the term to the roadmap, not the rate card:

• Three-year resource-based for the workload nobody is touching: same family, same region, a named owner who will swear it does not move.
• One-year flex for the stable-but-evolving middle, where you trust the spend floor but not the machine family.
• On-demand for anything with an open migration ticket, a re-platform on the plan, or a lead who says "probably GKE next year."

If engineering cannot promise the shape for the length of the term, the term is too long. That is an architecture answer, and it has to come from the people who own the design before the rate enters the room.

What happens when the workload moves underneath

Finance signs the deep three-year resource-based commitment on a fleet of general-purpose VMs. Two quarters later the platform team shifts half of it to GKE Autopilot on a newer family because it runs cheaper and operates cleaner. The migration is a clear win on its own terms. The CUD now covers capacity the architecture left behind, so you pay for a baseline nobody runs for two and a half more years while the live workload bills at list. The savings line on the board deck did not go negative. It just stopped meaning anything.

This decision breaks when finance and engineering are reading different screens. In a Cloud Horizons workspace, your commitment coverage and your actual machine families and platforms land in one view, so a planned migration surfaces as the lock-in risk it is before the signature, not as a dead CUD afterward. See how the FinOps view ties commitment depth to the roadmap instead of the rate card.