What break-even utilisation means and why it decides the purchase
A committed-use discount sells you instance-hours in advance. The provider drops the unit price; in exchange you agree to be billed for every hour of the term, used or not. That single asymmetry is the whole decision. On demand you pay for what you run. Under a commitment you pay for what you promised. So the commitment only saves money above the utilisation at which the fixed committed bill equals the variable on-demand bill.
Call that point u*. Above it, every extra hour you run is bought at the committed rate, which is cheaper. Below it, you have already paid for hours you are not using, and the effective price of the hours you did run climbs. At 50% utilisation a 40%-off commitment is not 40% off — it is 20% more expensive than on demand, because you paid the full committed bill for half the compute.
The number that makes this concrete is the effective hourly rate: total commitment cost divided by total committed hours. Once you have that, break-even utilisation is a single division, and it is exactly the complement of the effective discount. A commitment advertised at 37% off breaks even at 63% utilisation. Nothing else about the instance matters.
The same arithmetic covers every commercial form these products take. AWS Standard and Convertible Reserved Instances, Compute Savings Plans and EC2 Instance Savings Plans, Google Cloud committed use discounts, and Azure reserved VM instances all reduce to a fixed term commitment at a lower unit price. Only the flexibility differs — whether the commitment follows you across instance families or regions — and flexibility changes how likely you are to hit the utilisation, not the break-even itself.
The formula, and why the instance count cancels
Start with the two totals across the term. Let H be the hours in the term for one instance — months multiplied by billable hours per month, so 8,760 for a one-year term at 730 hours a month. Let N be the number of instances committed.
The committed path costs (upfront + r_c · H) · N. That figure does not move with usage. The on-demand path costs r_od · u · H · N, where u is the fraction of hours you actually run. Set the two equal and N and H both cancel, leaving
u* = (upfront/H + r_c) / r_od.
The numerator is the effective committed hourly rate: it folds any upfront payment back into an hourly figure by spreading it across the term. That is the single number to compare between a no-upfront, partial-upfront and all-upfront quote, and it is the only fair way to compare them, because all three buy the same hours.
Two consequences fall straight out. First, N cancelling means the break-even is identical whether you commit one instance or a thousand — scale changes the money at risk, not the decision rule. Second, because u* = 1 − discount, you can read the break-even off any vendor discount claim without touching a spreadsheet. If the quoted saving is 28%, you need 72% utilisation to see any of it.
This calculator ignores the time value of the upfront payment. Spreading a lump sum evenly across the term slightly flatters an all-upfront plan against a no-upfront one, because you have paid earlier. At a 10% cost of capital the effect on a one-year term is small; on a three-year all-upfront purchase it is worth checking with a discounted cash flow before signing.
Worked example: four instances, $0.192 on demand, $0.121 committed
You run four instances of a general-purpose type priced at $0.192 per hour on demand. A one-year, no-upfront commitment is offered at $0.121 per hour. Your last 90 days show the fleet busy about 78% of the time, and you bill 730 hours a month.
- Hours in the term, per instance. 12 months × 730 h = 8,760 h. Across four instances that is 35,040 committed hours.
- Committed cost. ($0 upfront + $0.121 × 8,760) × 4 = $1,059.96 × 4 = $4,239.84 for the year.
- Effective committed rate. $4,239.84 ÷ 35,040 h = $0.121 per hour. With no upfront payment it is simply the quoted rate.
- Break-even utilisation. 0.121 ÷ 0.192 = 0.630208, or 63.02%. The effective discount is the complement, 36.98%.
- On-demand cost at 78%. $0.192 × 0.78 × 35,040 = $0.14976 × 35,040 = $5,247.59.
- Saving. $5,247.59 − $4,239.84 = $1,007.75 for the year, which is 19.2% off the on-demand bill — about half the headline 36.98%, because you are only 15 points above break-even.
- Stranded value if usage falls 25%. Utilisation drops to 0.78 × 0.75 = 58.5%, below the 63.02% break-even. The compute you use is then worth $0.192 × 0.585 × 35,040 = $3,935.69 on demand, so $4,239.84 − $3,935.69 = $304.15 of the commitment buys nothing.
Step 6 is the number that changes conversations. The headline discount is 36.98%; the realised saving on this workload is 19.2%. Both are correct, and only one of them is your budget.
How to read the result before you sign
Compare the break-even against measured utilisation, not planned utilisation. Pull the last 90 days of hourly usage for the exact instance family and region, count the hours at least one instance was running, and divide by the hours in the window. Planning documents systematically overstate this because they describe the steady state, and commitments are bought before the steady state arrives.
Then judge the margin. If your measured utilisation clears the break-even by 20 points or more, the commitment is close to risk-free and the only question is term length. Between 5 and 20 points, the commitment is sound but the saving is materially smaller than the headline discount, and a fall in demand can erase it. Below the break-even the commitment is a loss on day one, and no amount of flexibility in the product fixes that.
Watch the asymmetry in the downside. Being 10 points above break-even earns you a small saving; being 10 points below costs you a slightly larger amount, because the committed bill is fixed while the on-demand bill you avoided shrinks with usage. That is why a laddered approach — commit to the floor of your usage, leave the peak on demand or on spot capacity — usually beats committing to the average. The floor is the part you can predict.
Finally, separate the pricing decision from the sizing decision. A commitment on an oversized instance locks in the waste for the whole term. Right-size first with a vCPU sizing check, then commit, and check what the same workload costs per business unit with the cost per transaction calculator so the saving shows up somewhere finance recognises.
Break-even utilisation for common discount levels
| Discount off on-demand | Effective committed rate ($/h) | Break-even utilisation | Hours per month at break-even |
|---|---|---|---|
| 20% | 0.15360 | 80.0% | 584.0 |
| 30% | 0.13440 | 70.0% | 511.0 |
| 37% | 0.12096 | 63.0% | 459.9 |
| 40% | 0.11520 | 60.0% | 438.0 |
| 50% | 0.09600 | 50.0% | 365.0 |
| 60% | 0.07680 | 40.0% | 292.0 |
| 72% | 0.05376 | 28.0% | 204.4 |
Read the last column as the minimum hours a month the committed capacity must be running. A 40%-off commitment needs 438 of 730 hours; below that you are paying more than on demand.
Mistakes that turn a discount into an overspend
- Committing to the average instead of the floor. Average utilisation includes the peaks you will not have next quarter. Commit to the level of usage that has never dropped below in 90 days, and buy the rest elastically.
- Comparing an all-upfront quote to a no-upfront quote on the sticker rate. They are not comparable until the upfront payment is divided by the hours in the term. That is what the effective committed rate does.
- Ignoring that the commitment survives the workload. Reservations do not cancel when a service is decommissioned. Every commitment should have a named owner and an expiry date in the same place the service does.
- Forgetting what the commitment is scoped to. A commitment tied to one instance family and region strands the moment you migrate; a flexible one costs more per hour but keeps its break-even reachable. Price the flexibility as the difference in break-even, not as a feature.
- Counting the discount before storage and transfer. Compute commitments do not touch egress or object storage, which on data-heavy services can be the larger half of the bill.
- Stacking commitments without a coverage report. Overlapping Savings Plans and Reserved Instances can leave you committed above your own baseline. Track coverage and utilisation as two separate metrics; a coverage figure alone hides idle commitment.
Utilisation and coverage are different numbers
Providers report both, and they answer different questions. Commitment utilisation is the share of what you bought that you used — it is the input to this calculator and the one that determines whether the purchase paid. Coverage is the share of your running hours that a commitment applied to. You can hold 100% utilisation with 20% coverage, which means the purchase was sound and too small. You can also hold 100% coverage with 60% utilisation, which means you bought too much. Read them as a pair.
Where commitments sit among the other levers
Commitments are the cheapest lever that requires no engineering work, which is why they are usually pulled first, and that ordering is a mistake. A commitment on a workload you have not right-sized locks in the oversizing for the term. The sequence that costs least is: delete what is idle, right-size what remains, move what is interruptible to spot, and only then commit to the stable floor that is left.
Against spot capacity, commitments trade a different risk. Spot is cheaper per hour and can be reclaimed; a commitment is dearer per hour and cannot be reclaimed, but it can be stranded by your own architecture changes. Batch and stateless work belongs on spot, and the spot savings calculator prices the interruptions. Long-lived stateful services belong on commitments.
Against a change of billing model altogether, the comparison is with per-invocation pricing. If the workload is spiky enough that utilisation cannot clear the break-even, the honest answer is often not a shorter commitment but a different runtime — the serverless versus container calculator finds the request volume where that flips. And when the whole platform decision is on the table, the commitment is one line in a larger migration payback case.