Reserved vs on-demand vs spot capacity

The decision

A cloud provider sells the same server in three ways. On-demand capacity costs the most per hour and you can stop it at any time. Committed capacity (reserved instances or savings plans) costs less per hour. In return you promise to pay for a fixed amount for one or three years, whether you use it or not. Spot capacity is spare capacity at a large discount, and the provider can take it back with short notice. The forces are cost, risk of paying for unused capacity, and customer impact when capacity is taken back. Most real systems use all three.

Choose on-demand when

• The load is new or changing fast, so you cannot say what you will use next year.
• The load is spiky, and the peak lasts only a few hours a day.
• The service is critical and cannot lose capacity without notice.

Choose committed capacity when

• A steady base load runs all day, every day, and has done so for several months.
• The base will not shrink in the term, for example the service is core to the business.
• You can commit to a flexible plan that covers any instance type, which trades a smaller discount for freedom.

Choose spot when

• The work is stateless or can restart: batch jobs, build servers, video conversion, stream consumers that save their place.
• A delay of minutes or hours is fine, so a job can wait for capacity.
• You can spread across several instance types and zones.
• You have a fallback to on-demand when spot is not available.

The numbers that change the answer

Assumptions for the example: on-demand costs Rs 3 per vCPU-hour. A one-year commitment costs 70% of that (a 30% discount). A three-year commitment costs 50% (a 50% discount). Spot costs 35% (a 65% discount). A month has 730 hours. These discounts are our round numbers.

Cited facts: AWS says Compute Savings Plans reduce costs by up to 66% and EC2 Instance Savings Plans by up to 72%, for one or three years. It says Spot Instances cost up to 90% less than On-Demand (see Sources). Your discount depends on region and instance type.

The workload (assumptions). A web tier needs 100 vCPU all day. Each day it needs 200 more vCPU for 4 hours. A nightly batch job uses 100 vCPU for 6 hours. One month is 30.4 days.

• Base: 100 x 730 = 73,000 vCPU-hours.
• Peak: 200 x 4 x 30.4 = 24,320 vCPU-hours.
• Batch: 100 x 6 x 30.4 = 18,240 vCPU-hours.
• Total: 115,560 vCPU-hours.

Cost a month (calculation).

Break-even use. You pay for every hour you commit. A commitment at 70% of the price wins only if you use the capacity more than 70% of the hours. That is 0.7 x 730 = 511 hours a month. For a three-year term at 50%, the line is 365 hours. The peak runs 4 of 24 hours (17%), so never commit for the peak.

Regret (calculation). Assumption: in month 6 you move to a cheaper design and the base falls from 100 to 60 vCPU. We compare each commitment with staying on-demand for the base. The spot saving is separate.

• Per month while the base is 100 vCPU: on-demand costs 100 x 730 x 3 = Rs 219,000. A one-year commitment costs 100 x 730 x 2.1 = Rs 153,300. A three-year commitment costs 100 x 730 x 1.5 = Rs 109,500.
• After the fall, on-demand for 60 vCPU costs 60 x 730 x 3 = Rs 131,400 a month. The commitments cost the same as before.
• One-year commitment: 40 vCPU sit idle for 6 months, which wastes 40 x 730 x 6 x 2.1 = Rs 367,920. Net against on-demand: first 6 months save 6 x (219,000 - 153,300) = Rs 394,200. Last 6 months lose 6 x (153,300 - 131,400) = Rs 131,400. Net = Rs 262,800 saved.
• Three-year commitment: 40 vCPU idle for 30 months wastes 40 x 730 x 30 x 1.5 = Rs 1,314,000. Net: first 6 months save 6 x (219,000 - 109,500) = Rs 657,000. The next 30 months save 30 x (131,400 - 109,500) = Rs 657,000. Net = Rs 1,314,000 saved. It wins because 60% use is above its 50% break-even.
• A commitment loses when use falls below its break-even share: 70% for one year, 50% for three years. After a fall to 40 vCPU (40%), both would lose money each month.

Cited facts about spot. AWS gives a spot interruption notice two minutes before it stops or terminates the instance, on a best-effort basis. It says to design the application to be fault-tolerant. AWS lists stateless, fault-tolerant or flexible work as the fit (see Sources).

What breaks with each choice

On-demand.

• You overpay all year for steady load. Here Rs 346,680 against Rs 245,412 a month is 101,268 x 12 = about Rs 1.2 million a year more.
• In a regional shortage you may not get capacity when you need it. Fallback: a capacity reservation for the critical base, if your provider offers one. A price commitment alone may not reserve capacity, so read the terms.

Committed.

• The base shrinks, or you change instance type, and you pay for idle capacity (Rs 367,920 in the example). Fallback: commit to about 60% of the lowest steady use, not 100%, and prefer flexible plans.

Spot.

• All your spot capacity can go at once in one zone or one type. Fallback: spread across zones and types, and fall back to on-demand.
• A job without checkpoints loses everything. Fallback: save progress every few minutes.

What it costs

• People: Assumption: 2 to 3 engineer-weeks for the first spot setup.
• Reversible-first path. Start with all on-demand and tag every cost. After three months of data, commit one year to about 60% of the lowest steady base (here 60 vCPU), using a flexible plan. Move the safe batch work to spot with an on-demand fallback. Raise the commitment each quarter while the use of the commitment stays above 95% (our trigger, an assumption). Choose three years only for a base that you would keep even if the design changed.
• Changing your mind: you cannot cancel most commitments. You can sell or exchange some, depending on the provider, so read the terms. Spot to on-demand is a setting change.

How each level answers

The question is: "Cut the cloud bill of a service with a steady base and a daily peak."

SDE-1: Committed servers are cheaper but need a long promise. Spot servers are cheap but can be taken away.

SDE-2: I reserve the steady base, use on-demand with autoscaling for the peak, and put batch jobs on spot.

Senior: The base uses 100 vCPU all month, so a commitment at 70% of the price pays back above 511 hours of use. The peak runs 4 hours a day, so I never commit it. Committing the base and putting the batch on spot cuts the bill from Rs 346,680 to Rs 245,412 a month. I commit to 60 vCPU first. Spot jobs save progress, because the notice is only two minutes.

Staff: A commitment is a financial promise, so I decide with finance. I compare the saving on the base (Rs 65,700 a month) with the idle cost if the design changes (Rs 367,920). I make the platform team own coverage and a monthly report. I measure coverage, use of commitments, spot interruption rate and cost per request. I ask for a review before any three-year term, and I revisit when the base changes by more than 20% (our trigger, an assumption).

Say it in the interview

I would commit to the steady base, since it is above the break-even use of 70% of hours. I would keep the daily peak on on-demand and move the nightly batch to spot with checkpoints. That cuts the example bill by about 29%. I would commit to only 60% of the lowest steady use at first, and grow it each quarter.

Common mistakes

• Committing the peak. It runs 17% of the time, far below the 70% break-even.
• Committing 100% of today's base. If you improve the design next quarter, you pay for idle servers.
• Putting a database on spot. A two-minute notice is not enough to move state.
• Reading "up to 72%" as your discount. The figure is the best case. Check your own price.

Sources

• AWS, Savings Plans: a commitment to a consistent usage amount for a 1 or 3 year term; Compute Savings Plans reduce costs by up to 66% and EC2 Instance Savings Plans by up to 72%. https://aws.amazon.com/savingsplans/compute-pricing/ (opens in a new tab) (checked 26 Oct 2026)
• AWS, EC2 Spot Instances: up to a 90% discount compared with On-Demand prices; suited to stateless, fault-tolerant or flexible applications. https://aws.amazon.com/ec2/spot/ (opens in a new tab) (checked 26 Oct 2026)
• AWS, Spot Instance interruption notices: a warning issued two minutes before the instance is stopped or terminated, on a best-effort basis. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html (opens in a new tab) (checked 26 Oct 2026)
• The prices, the 30%, 50% and 65% discounts, workload sizes, the drop in the base, the 60% starting share and the 95% and 20% triggers are our assumptions. The costs, the 19%, 29% and 42% savings, the break-even hours and the regret figures are our calculations, shown above. The up-to discounts and the two-minute notice are cited AWS facts.