Scheduling vs Reserved Instances: Which Workload Gets Which

Scheduling and reserved capacity are both described as cost savings, but they work on different variables. Scheduling reduces the number of hours a resource runs: the machine is stopped (or deallocated, or scaled to zero) when nobody needs it, and on-demand billing stops with it. A reservation (or savings plan, or committed use discount) reduces the price of each hour in exchange for paying for every hour of a one- or three-year term. One attacks quantity, the other attacks rate. That is why the question is never “which is better” but “which workload gets which”.

Why the two collide on the same machine

A commitment is billed whether or not the capacity runs. AWS bills No Upfront Reserved Instances “for every hour within the term, regardless of whether the Reserved Instance is being used.” Azure calls its reservation discount “use-it-or-lose-it”: an hour with no matching resource is lost and cannot be carried forward. Google bills resource-based CUDs monthly to the end of the term “regardless of whether or not you use those resources.”

So if you reserve a development server and then stop it every night, you pay for the reservation all night and the stop saves nothing. Scheduling committed capacity only lowers its utilisation. The reverse mistake is just as costly: reserving capacity for a part-time environment locks in a charge for hours it was never going to run.

The break-even arithmetic

For a single machine, a commitment beats on-demand only when the machine runs more of the term than the commitment’s price ratio. Write the committed hourly rate as a fraction of the on-demand rate. If that fraction is r, the commitment pays off only if the machine runs more than r of all hours.

A worked example with an illustrative discount (check your own rates, they vary by instance, term and payment option):

• Suppose a one-year commitment costs 60% of the on-demand rate for every hour of the year.
• The machine must then run more than 60% of all hours for the commitment to win.
• A development box on a 10-hour, 5-day schedule runs 50 hours of a 168-hour week, about 30% of hours, which is roughly 217 of the 730 hours in an average month.
• At 30% utilisation the scheduled on-demand box costs about half of what the always-billed commitment would. On-demand plus scheduling wins by a wide margin.

The same box running all month (730 of 730 hours) flips the answer: the commitment is cheaper for every hour it covers.

The order that makes both work

1. Classify. Anything that should not run around the clock, such as dev, test, QA, demo, training and batch windows, is a scheduling candidate. Production services that serve traffic every hour are commitment candidates.
2. Schedule first. Put the part-time estate on start/stop schedules. This removes hours you would otherwise have been tempted to commit to.
3. Measure the floor. After a few normal weeks, the capacity or hourly spend that never drops is your always-on baseline.
4. Commit to the baseline, not the peak. Buy reservations, savings plans or CUDs for that floor. Everything above it stays on-demand, where scheduling keeps working.
5. Re-check utilisation. When a scheduled environment grows or a production service shrinks, the floor moves. Utilisation reports show when a commitment has become oversized.

When neither is the answer

Some capacity is neither part-time nor steady: interruptible batch work may be better on spot capacity, and a machine that is simply too large should be rightsized before you commit to its current size.

How ZopNight handles the overlap

ZopNight’s commitment suggestions are built to avoid the collision described above. They are advisory only, price a commitment against the instance’s measured uptime rather than assuming 24/7, cap the projected run cost at what the instance actually runs, and suppress the suggestion unless that run cost exceeds the commitment cost by a 10% margin. With no measured uptime the saving is reported as unknown, and capacity already covered by a reservation or savings plan does not produce a new suggestion. Schedule recommendations are generated separately from the last 21 days of metrics, so a part-time machine can receive a schedule recommendation while the break-even gate keeps its low uptime from producing a commitment one.