How Many Instances to Reserve: The Break-Even Method

“Reserve the baseline” is the standard advice for cloud commitments, but it doesn’t tell you what the baseline is. The minimum instance count is too cautious, the average reserves too much, and the peak wastes money. A better answer uses your hourly usage and one number: the break-even utilisation.

The one number that matters

A reservation costs the same every hour of its term, whether or not you use it. On-demand costs nothing when the instance is off. So a reservation is only worth it if the instance runs at least this share of the time:

break-even utilisation = effective reserved hourly rate ÷ on-demand hourly rate

The effective rate includes the upfront payment spread over every hour of the term. With an on-demand price of 0.096/hour, and a reservation of 280 upfront plus 0.032/hour for one year:

effective rate = 0.032 + 280 ÷ (730 × 12) = 0.064 / hour
break-even     = 0.064 ÷ 0.096          = 66.7 %

Below 66.7% utilisation, that instance is cheaper on demand. The reserved instance break-even calculator works this out from your own prices for any plan type and term. It also shows the month in which the upfront payment is paid back.

Slice the fleet into layers

An autoscaled fleet doesn’t run “N instances”. It runs 4 at night, 10 at peak and something in between most of the time. Think of it as layers: the 1st instance, the 2nd and so on. For each layer, ask: in what share of the hours were at least this many instances running?

You can get this from hourly usage data: AWS Cost Explorer’s hourly granularity, a CUR export, or a metric like your Auto Scaling group’s GroupInServiceInstances. Here is an example service over 30 days:

Layer	Hours with at least this many running
1st–4th	100 %
5th	90 %
6th	70 %
7th	50 %
8th	25 %
9th–10th	10 %

The first four layers never turn off. The 8th only runs during weekday peaks.

Reserve every layer above break-even

Compare each layer with the 66.7% break-even. The monthly saving from reserving a layer is its on-demand cost minus the reservation’s fixed cost (0.064 × 730 = 46.72 per month):

Layer	Utilisation	On-demand cost/month	Reserved cost/month	Saving
1st–4th	100 %	70.08 each	46.72 each	+93.44 total
5th	90 %	63.07	46.72	+16.35
6th	70 %	49.06	46.72	+2.34
7th	50 %	35.04	46.72	−11.68
8th	25 %	17.52	46.72	−29.20

Reserving six instances saves 112.13 per month. Reserving a seventh brings that down to 100.45, because the 7th layer costs more to reserve than to run on demand.

Note that the average fleet size here is about 6.6 instances. “Reserve the average” would round up to seven and lose money on the last one.

Leave margin on the marginal layer

The 6th layer saves only 2.34 a month, and only if its usage stays at 70% for the whole term. If you move part of the service to a different instance family, or traffic drops, it becomes a loss. Layers that only just clear the break-even point are usually worth skipping:

Reserve layers clearly above break-even, say 10 percentage points or more. Here that is layers 1–5.
Leave the marginal layers on demand, or cover them with a more flexible commitment, such as Compute Savings Plans on AWS, which follow usage across instance types.
Re-check every quarter. If the 6th layer’s utilisation has gone up, reserve it then.

Run your own numbers

Export hourly usage for the last 30–60 days and calculate the utilisation of each layer.
Enter your on-demand price, upfront payment and reserved rate in the break-even calculator to get the break-even utilisation, effective rate and payback month.
Reserve the layers well above break-even and keep the rest on demand.

Plans with no upfront payment have the same break-even logic but a lower discount. A 3-year term lowers the break-even point but adds three years of risk. Run each option through the same calculation before you commit.