Blog
GCP Committed Use Discount Optimization: A Worked Example
Northline Analytics is a hypothetical company we made up to make this concrete — not a real Solvicus customer, and the numbers below are illustrative, not measured data.
Northline Analytics is a 250-employee SaaS company running a multi-tenant analytics platform on GCP, with 250 active customer contracts. Every contract is provisioned on one of three e2 machine sizes depending on tier, and every few months someone on the infra team has to decide: commit more spend to Committed Use Discounts, or keep paying on-demand rates? Below is exactly how Solvicus answers that question.
The setup
Northline's 250 contracts break down into three tiers, each pinned to an e2 size:
- Starter — 140 customers on
e2-standard-4, one instance each: 140 units/month. 12-month contracts. - Growth — 90 customers on
e2-standard-8, one instance each: 90 units/month. 24-month contracts. - Enterprise — 20 customers on
e2-standard-16, two instances each: 40 units/month. 24-month contracts.
Historically, about 75% of contracts renew at expiration — the rest churn and their capacity isn't needed again.
What's already committed
Northline isn't starting from zero. They already hold a 1-year CUD covering 60 units/month of e2-standard-4, with 4 months of coverage left, and a 1-year CUD covering 30 units/month of e2-standard-8, with 10 months left. Nothing is committed yet for e2-standard-16 — those 40 units/month are all on on-demand pricing today.
Feeding it to the model
This maps directly onto Solvicus's input, without inventing anything: each tier becomes one contracts entry — a resource-to-demand map (demands) over a start_t/end_tmonth range, rather than 250 individual contract objects (aggregating by cohort is the practical move; the model doesn't care whether one contract entry represents one customer or ninety). The two existing CUDs become two storages entries — each just a capacity and an end_t, since owned capacity has no start date to track.
The rest lives in config: a pricing_catalog with a 12- and 36-month term price plus an on-demand rate for each of the three machine sizes; is_integer: true, because you can't commit to 2.4 VMs; a 6-month investment_horizon (the purchases this decision covers); a 42-month effect_horizon (long enough to fully evaluate any 36-month commitment made near the end of that window); and a renewal_rate reflecting that 25% annual churn.
What comes back
Solvicus builds one independent linear or mixed-integer program per machine size — three in this case — and solves them concurrently. Each comes back with its own result: how many 12- or 36-month units to buy now for that resource, and the resulting month-by-month on-demand usage over the full 42-month horizon. A machine size where the existing CUD already outlasts declining demand might get no new purchase recommended at all — that's a normal, correct answer, not a failure.
Try it yourself
This is Solvicus's Google Cloud Committed Use Discount Optimization solver — available now, not a future use case. It's a mixed-integer program under the hood for exactly the reason above: whole-VM commitments are a yes/no, whole-unit decision, not a continuous one. Create a free account to run your own numbers.