Reserved vs on-demand: a decision framework, not a guess

Quick answer

Commit when a resource will run enough of the term that the discount beats on-demand including idle time — roughly above ~60-70% utilization for a 1-year term. Calculate break-even (on-demand cost for expected hours vs commitment cost for the term), ladder 3-year for the rock-solid core and 1-year for the probable, and never commit to capacity you might strand. Spot covers the variable remainder.

"Should we buy reserved?" is one of the highest-leverage cost questions and one of the most guessed-at. It doesn't need to be a guess — it's a break-even calculation plus a judgment about how confident you are the workload will stick around. Here's the framework.

The core trade

On-demand charges full rate but only for what you run — zero waste, no commitment. Reserved/committed pricing discounts the rate (40-72% depending on cloud and term) but you pay for the commitment whether you use it or not. The decision is whether your expected usage clears the point where the discounted-but-committed cost beats full-rate-but-flexible.

The break-even rule of thumb

1-year, ~40% off: breaks even around ~60% utilization of the term. Run the resource more than that and committing wins.
3-year, ~60% off: breaks even at lower utilization but locks you in for three years — only worth it if you're confident the workload lives that long.

Do the actual arithmetic: total on-demand cost for your expected running hours versus the commitment cost for the full term. If expected utilization clears break-even with margin, commit; if it's marginal, stay on-demand.

Ladder your commitments

It's not all-or-nothing. A common, robust structure:

3-year on the rock-solid baseline you'd bet the company on.
1-year on the probable steady workloads.
On-demand for unpredictable steady-ish demand.
Spot for the interruptible, fault-tolerant remainder (AWS, Azure, GCP).

Avoid stranding

The failure mode is over-committing — paying for reserved capacity you abandoned after a resize, migration, or shutdown. Commit only to the baseline you're confident about, prefer flexible commitment types where the discount difference is small (see Reserved Instances vs Savings Plans and the Azure equivalent), and revisit as the workload evolves.

FAQ

When should I buy reserved capacity instead of paying on-demand?

When you'll run the resource for enough of the commitment term that the discounted rate beats on-demand even accounting for idle time. A rough rule: if a resource will run more than ~60-70% of a 1-year term, a 1-year commitment usually pays off. Below that, on-demand (or Spot) is cheaper because you don't pay for capacity you don't use.

How do I calculate the break-even for a reservation?

Compare total on-demand cost for your expected running hours against the commitment cost for the full term. A 1-year commitment at ~40% off breaks even around 60% utilization; a 3-year at ~60% off breaks even lower but locks you in longer. If expected utilization clears the break-even with margin, commit.

Should I choose 1-year or 3-year commitments?

1-year for workloads you're fairly sure about; 3-year only for truly stable, long-lived baseline you'd bet on. 3-year gives a deeper discount but the risk of stranding it (re-architecture, shutdown, migration) is higher. Many teams ladder: 3-year for the rock-solid core, 1-year for the probable, on-demand/Spot for the rest.

What's the risk of over-committing?

Stranded commitment — paying for reserved capacity you no longer use because you resized, migrated, or shut the workload down. That erases the discount and can cost more than on-demand would have. The defense is committing only to the baseline you're confident about, and using flexible commitment types where possible.

How does Spot fit into this decision?

Spot is the third option for the variable, fault-tolerant portion of your workload. The full picture is a layered strategy: commitments for the steady baseline, on-demand for unpredictable steady-ish demand, and Spot for interruptible bursts. They're complementary, not either/or.

How does C3X help with this decision?

C3X prices your resources at on-demand rates from your Terraform, giving you the baseline cost and running-hours picture to run the break-even math and decide what to commit. It turns the reserved-vs-on-demand call into a number rather than a guess.

What to do next

The framework needs one input: your real baseline cost and running hours. C3X prices your resources at on-demand rates from your Terraform, so you can run the break-even math on actual numbers and commit deliberately. The quickstart runs it in minutes.