A term commitment is billed for every hour of its term - how many run-hours a day does a workload need before it beats metered capacity?

middleshould knowfreq 50%

answer

compare monthly totals, not rates
the term bills while you sleep
break-even is a utilisation
committed fraction equals break-even fraction
count hours up, not hours busy

basics

~20 s

Break-even is a utilisation, not a number of hours you can memorise: if the committed rate is a given fraction of the metered rate, the workload must run at least that same fraction of the hours. Compare monthly totals, never the two hourly rates.

solid answer

~50 s

The committed rate is charged for all 24 hours of every day in the term, while metered capacity is charged only for the hours the workload actually runs. So the comparison is committedRate x 24 against meteredRate x runHours, and the break-even falls out as runHours = 24 x committedRate / meteredRate. If the committed rate were, say, 0.6 of the metered rate, break-even sits at about 14.4 hours a day - roughly 60% utilisation - and the useful shortcut is that the break-even utilisation equals the committed fraction. Below it, paying as you go is cheaper even though the sticker rate is higher. Two things move the line: a longer term usually buys a deeper rate and therefore a lower break-even, and paying some or all of the term up front is usually priced lower than paying monthly. Where the instrument is expressed as spend per hour that any matching usage draws down, break-even becomes a property of the whole fleet rather than of one workload.

The committed rate is charged for all 24 hours of every day in the term, while metered capacity is charged only for the hours the workload actually runs. So the comparison is `committedRate x 24` against `meteredRate x runHours`, and the break-even falls out as `runHours = 24 x committedRate / meteredRate`. If the committed rate were, say, 0.6 of the metered rate, break-even sits at about 14.4 hours a day - roughly 60% utilisation - and the useful shortcut is that **the break-even utilisation equals the committed fraction**. Below it, paying as you go is cheaper even though the sticker rate is higher. Two things move the line: a longer term usually buys a deeper rate and therefore a lower break-even, and paying some or all of the term up front is usually priced lower than paying monthly. Where the instrument is expressed as spend per hour that any matching usage draws down, break-even becomes a property of the whole fleet rather than of one workload.

code

pseudocode · 20 lines

pseudocode

// illustrative units, not any provider's price list
meteredRatePerHour   = 1.0    // billed only while the machine runs
committedRatePerHour = 0.6    // billed for every hour of the term
hoursInDay           = 24
daysInMonth          = 30

breakEvenHoursPerDay = (committedRatePerHour * hoursInDay) / meteredRatePerHour
// = 14.4 hours a day, i.e. utilisation of 0.6 - the committed fraction itself

function monthlyMetered(runHoursPerDay)
    return meteredRatePerHour * runHoursPerDay * daysInMonth

function monthlyCommitted()
    return committedRatePerHour * hoursInDay * daysInMonth   // 432

runHoursPerDay = 10
if runHoursPerDay > breakEvenHoursPerDay
    choose "term commitment"        // not taken: 10 is below 14.4
else
    choose "metered on-demand"      // taken: 300 < 432

go deeper

for a junior

Remember that a committed rate is charged for every hour of the term, whether or not the machine is running, so a lower rate is not automatically a lower bill.

for a middle

Derive the break-even yourself: committed rate times 24 against metered rate times run-hours, giving a break-even utilisation equal to the committed fraction of the metered rate.

for a senior

Insist on measured run-hours before signing, count the hours capacity exists rather than hours it is busy, and say how term length and payment option move the line.

for a principal

Treat break-even as the easy half. The judgment is how far ahead the fleet's shape is credible, and how much of the bill you are prepared to make non-cancellable on that view.

The comparison people get wrong

The usual mistake is to put the two hourly rates side by side, see that the committed one is lower, and conclude that committing saves money. That comparison is not valid, because the two rates are charged on different clocks:

Metered on-demand capacity is billed only for the hours the machine is running. Stop it and the meter stops.
A term commitment is billed for the committed level for every hour of the term, running or not. Weekends, nights, an outage, a workload you deleted - the commitment keeps billing.

So the only honest comparison is between monthly totals, and the input you need is not a rate but a utilisation: what share of the hours does this capacity actually exist?

The arithmetic

Let the metered rate be m per machine-hour and the committed rate c per machine-hour, with c < m. Over a day:

committed cost is c x 24, because the commitment does not care whether the machine runs;
metered cost is m x h, where h is the hours the machine runs.

Setting them equal gives h = 24 x c / m. Dividing both sides by 24, the break-even utilisation is simply c / m.

That is the result worth remembering: the break-even utilisation equals the committed fraction of the metered rate. Using illustrative units - metered rate 1.0, committed rate 0.6 - break-even is 0.6, or about 14.4 hours a day. At 20 hours a day the month costs 1.0 x 20 x 30 = 600 metered against 0.6 x 24 x 30 = 432 committed, so committing wins. At 10 hours a day it is 300 metered against the same 432, and paying as you go wins comfortably even though its rate is higher.

Run-hours a day	Metered (30 days)	Committed (30 days)	Cheaper
24	720	432	Committed
20	600	432	Committed
about 14.4	432	432	Break-even
10	300	432	Metered

The numbers above are invented units chosen to make the arithmetic visible; the shape of the result is what transfers, not the figures.

What moves the line

Term length. A longer term normally buys a deeper rate, which lowers c / m and therefore lowers the break-even utilisation. It also lengthens the period over which you are exposed if the workload changes, so a lower break-even is not automatically a better deal.
Payment option. Providers usually price paying some or all of the term up front below paying monthly. That again deepens the discount and lowers break-even, at the cost of cash committed earlier.
How the instrument is expressed. Some commitments are tied to a specific machine shape; others are expressed as an amount of spend per hour that any matching usage draws down. Providers differ, and the second form changes the question: break-even stops being a property of one workload and becomes a property of the fleet, because usage from anywhere can consume the commitment.
What you count as run-hours. Use the hours the capacity exists, not the hours it is busy. A machine idling at low utilisation is still billing at the metered rate, so it counts as a run-hour. Conflating busy-hours with run-hours is what produces a break-even calculation that says commit when it should say the opposite.

Applying it to a real workload

For a reporting service with a flat weekday base, the base machines exist 24 hours a day, seven days a week - utilisation of the capacity, in this sense, is 100%, and committing is straightforwardly cheaper. For a batch tier that only runs overnight for six hours, utilisation is 25%, below any realistic break-even, and it stays metered. For a development environment shut down outside office hours - say ten hours a weekday, nothing at weekends - utilisation is around 30% of the hours in a week, and the correct answer is usually to keep it metered and shut it down harder, not to commit.

The discipline this imposes is worth stating plainly: before you can answer a break-even question at all, you need the run-hours, and that number comes from measurement rather than from the workload's description. A team that cannot say what share of the hours its fleet is up cannot responsibly sign a multi-year commitment for it.

Finally, be honest about which direction the risk runs. A break-even calculation tells you what happens if today's shape holds for the whole term. It says nothing about the shape changing, and the term is usually longer than the architecture's half-life.

## The comparison people get wrong The usual mistake is to put the two hourly rates side by side, see that the committed one is lower, and conclude that committing saves money. That comparison is not valid, because the two rates are charged on different clocks: - **Metered on-demand capacity** is billed only for the hours the machine is running. Stop it and the meter stops. - **A term commitment** is billed for the committed level for every hour of the term, running or not. Weekends, nights, an outage, a workload you deleted - the commitment keeps billing. So the only honest comparison is between **monthly totals**, and the input you need is not a rate but a **utilisation**: what share of the hours does this capacity actually exist? ## The arithmetic Let the metered rate be `m` per machine-hour and the committed rate `c` per machine-hour, with `c < m`. Over a day: - committed cost is `c x 24`, because the commitment does not care whether the machine runs; - metered cost is `m x h`, where `h` is the hours the machine runs. Setting them equal gives `h = 24 x c / m`. Dividing both sides by 24, the break-even **utilisation** is simply `c / m`. That is the result worth remembering: **the break-even utilisation equals the committed fraction of the metered rate.** Using illustrative units - metered rate 1.0, committed rate 0.6 - break-even is 0.6, or about 14.4 hours a day. At 20 hours a day the month costs 1.0 x 20 x 30 = 600 metered against 0.6 x 24 x 30 = 432 committed, so committing wins. At 10 hours a day it is 300 metered against the same 432, and paying as you go wins comfortably even though its rate is higher. | Run-hours a day | Metered (30 days) | Committed (30 days) | Cheaper | |---|---|---|---| | 24 | 720 | 432 | Committed | | 20 | 600 | 432 | Committed | | about 14.4 | 432 | 432 | Break-even | | 10 | 300 | 432 | Metered | The numbers above are invented units chosen to make the arithmetic visible; the *shape* of the result is what transfers, not the figures. ## What moves the line 1. **Term length.** A longer term normally buys a deeper rate, which lowers `c / m` and therefore lowers the break-even utilisation. It also lengthens the period over which you are exposed if the workload changes, so a lower break-even is not automatically a better deal. 2. **Payment option.** Providers usually price paying some or all of the term up front below paying monthly. That again deepens the discount and lowers break-even, at the cost of cash committed earlier. 3. **How the instrument is expressed.** Some commitments are tied to a specific machine shape; others are expressed as an amount of spend per hour that any matching usage draws down. Providers differ, and the second form changes the question: break-even stops being a property of one workload and becomes a property of the fleet, because usage from anywhere can consume the commitment. 4. **What you count as run-hours.** Use the hours the capacity **exists**, not the hours it is busy. A machine idling at low utilisation is still billing at the metered rate, so it counts as a run-hour. Conflating busy-hours with run-hours is what produces a break-even calculation that says commit when it should say the opposite. ## Applying it to a real workload For a reporting service with a flat weekday base, the base machines exist 24 hours a day, seven days a week - utilisation of the *capacity*, in this sense, is 100%, and committing is straightforwardly cheaper. For a batch tier that only runs overnight for six hours, utilisation is 25%, below any realistic break-even, and it stays metered. For a development environment shut down outside office hours - say ten hours a weekday, nothing at weekends - utilisation is around 30% of the hours in a week, and the correct answer is usually to keep it metered and shut it down harder, not to commit. The discipline this imposes is worth stating plainly: before you can answer a break-even question at all, you need the run-hours, and that number comes from measurement rather than from the workload's description. A team that cannot say what share of the hours its fleet is up cannot responsibly sign a multi-year commitment for it. Finally, be honest about which direction the risk runs. A break-even calculation tells you what happens if today's shape holds for the whole term. It says nothing about the shape changing, and the term is usually longer than the architecture's half-life.

Does a longer term always lower the break-even utilisation, and is that always good?
A longer term normally buys a deeper rate, so `c / m` falls and break-even utilisation falls with it. That is good arithmetic and bad risk: the same term that makes the maths easier is the one you are stuck inside if the workload shrinks or is re-platformed. Choose the term against how far ahead you can honestly see, not against the discount curve.
A machine is up 24 hours a day but averages 8% processor utilisation. What is its break-even utilisation?
100%, because break-even counts the hours the capacity **exists**, and this capacity exists every hour. Committing is cheaper than paying metered for the same machine. The 8% is a right-sizing problem - the machine is probably too big - and it is a separate decision from how its hours are bought.

A yearly gym membership beats paying per visit only above a certain number of visits, and the membership keeps charging in the months you never go. The committed compute rate works the same way, except the term is years and the workload cannot decide to visit.

saying these in an interview costs you the question

Comparing the two hourly rates and stopping there
Forgetting the commitment bills for hours the workload is stopped
Treating a cheaper rate as a saving at any utilisation
Using the workload's busy hours rather than its running hours
Assuming one-year and multi-year terms break even at the same point

A term commitment is billed for every hour of its term - how many run-hours a day does a workload need before it beats metered capacity?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The comparison people get wrong

The arithmetic

What moves the line

Applying it to a real workload

▾common follow-ups2 questions

▾analogy~20 s

▾red flags5 flags

The comparison people get wrong

The arithmetic

What moves the line

Applying it to a real workload

answer

go deeper