Committed Use Discount Planning: Forecast-Driven vs Usage-Based

There are two ways to decide how many Google Cloud committed use discounts (CUDs) to buy. Almost every tool uses the first. If you have contractual or otherwise known demand, the second saves you more.

The usage-based default: size from history, then hedge

Google's own recommender and third-party optimizers like ProsperOps and nOps all start from the same input: your recent usage. They look back over the last 30, 60, or 90 days, find the baseline that has held steady, and recommend committing to some fraction of it. Because they can't see what happens next, they hedge — buying below the baseline and laddering purchases in small, continual increments rather than making one forecast-driven bet, and leaving the rest on-demand. The advice is remarkably consistent across the industry: don't commit to what you think you'll use; commit to what you've already proven you use.

Why the industry hedges — and when it's right

That caution exists for a good reason. A CUD can't be cancelled, sold, or exchanged; once you buy it, you owe it for the full one- or three-year term. If your workloads are spiky, autoscaling, or genuinely unpredictable, sizing to a conservative historical baseline and hedging the rest is exactly the right call. For that world, “don't trust the forecast” is sound advice.

But a signed contract isn't a guess

Plenty of demand isn't a guess, though. If you've signed a customer contract that obliges you to serve a certain capacity, you know that demand is coming. If you're part-way through a funded migration with a dated ramp, you know roughly what next quarter looks like. If you run a steady regulated baseline, it isn't going anywhere. For all of these, sizing commitments to last month's usage understateswhat you already know — and hedging against uncertainty you don't have is just money left on the table.

Forecast-driven planning: optimize for demand you already know

Forecast-driven planning flips the input. Instead of extrapolating history, you give the optimizer the demand you already know — per resource, month by month, net of the commitments you already own — and it finds the lowest-cost mix of 1- and 3-year CUDs to cover it. There's no hedge tax, because there's nothing to hedge: you're optimizing against demand you can already see. The problem is genuinely a mixed-integer program — coverage, utilization, and break-even interact across every month at once — which is exactly what the Solvicus CUD optimizer solves.

When your demand really is unpredictable

Forecast-driven doesn't mean betting the farm on a spreadsheet. A forecast can still be wrong, and a CUD you can't undo is unforgiving. That's what the editable what-if is for: take the plan Solvicus recommends, then stress-test it — how far can demand fall before a given commitment stops paying off? Where the answer makes you nervous, take a shorter term or leave that slice on-demand. Plan around what you know; hedge only the part you genuinely don't.