Committed Use Discounts: Are You Leaving 30% on the Table?
If you're running a steady baseline of compute on-demand, you're paying the tourist price. Commitments trade flexibility for a big discount, but only after you've right-sized, not before.
By The FeckBills team
Committed Use Discounts: Are You Leaving 30% on the Table?
There are two ways to pay less for cloud compute: use less (right-sizing) and commit to what you use (discounts). Most teams obsess over the first and ignore the second, leaving 20-55% sitting on the table for the baseline capacity they were always going to run anyway.
But there's a right order to do this in, and getting it backwards is expensive.
What a commitment actually is
A Committed Use Discount (CUD) on GCP (and Savings Plans / Reserved Instances on AWS) is a deal: promise to keep spending at a certain level for 1 or 3 years, get a steep discount in return. Spend-based CUDs are flexible across machine types; resource-based ones lock you to specific shapes for an even deeper cut.
The discount is large precisely because you're taking on the risk. If your usage drops, you keep paying for the commitment. So the whole game is committing to the floor you're certain about, and leaving the variable part on-demand (or spot).
The cardinal rule: right-size FIRST
Here's the mistake that turns a discount into a trap: buying a commitment for waste. If you commit to 100 vCPU and then right-size your workloads down to 60, you've locked yourself into paying for 40 vCPU of nothing for up to three years. You've discounted your waste and made it permanent.
The correct sequence:
- Right-size every workload (requests vs P95 usage).
- Clean up the orphans and zombies.
- Observe your stable baseline for a few weeks once the fat is gone.
- Then commit to that lean, true floor.
Discount the right number, not the bloated one.
How much to commit
- Look at your minimum steady-state usage over the trailing months, the level you never drop below.
- Commit to roughly 70-85% of that floor, not 100%. Leave a margin so a modest dip doesn't strand commitment.
- Layer it: a 3-year commit on the rock-solid base, 1-year on the probably-stable middle, on-demand/spot on the variable top.
Don't forget coverage drift
Commitments expire. Usage shifts. A commitment that was perfect a year ago can quietly become 60% utilised as workloads move. Review coverage quarterly, both under-coverage (on-demand spend you could be discounting) and over-coverage (committed capacity going unused).
How FeckBills helps
FeckBills focuses on steps 1 and 2: finding the waste so you commit to a clean baseline, not a bloated one. Cut the over-provisioning and orphans first, watch where your usage settles, and you'll buy a commitment that actually saves money instead of locking in three years of fat. (Coverage-gap detection is on our roadmap; right-sizing comes first for a reason.)