Cruxly › Cloud and DevOps › Cloud & DevOps: Cloud Cost Engineering
Reserved, Spot, and On-Demand: The Real Trade-off Behind Each Discount
advertised savings vs realistic savings, and commitment risk
Open the interactive lessonPrompt: a workload currently runs entirely on on-demand instances. Design a capacity mix across reserved, spot, and on-demand that captures real savings without either over-committing to reserved capacity the team might not need in a year, or naively assuming spot's advertised discount is the number to plan a budget against.
30 minutes first. The naive version either moves everything to the cheapest advertised option, or avoids spot/reserved entirely as "too risky" without quantifying what the actual risk and actual savings are.
Spot: a real discount, with a real, quantifiable interruption cost
A spot instance can be reclaimed whenever the provider needs the capacity back, and the notice is short: two minutes on AWS, and only about 30 seconds on GCP Spot VMs and Azure Spot VMs. AWS also sends an earlier, best-effort rebalance recommendation when an instance is at higher risk, which tools like Karpenter and the AWS Node Termination Handler use to start replacing the node before the two-minute notice arrives. Design around the shortest notice of the clouds you run on — this is the mechanism behind the steep discount, not an incidental limitation: the provider is selling genuinely spare, reclaimable capacity, and the discount is the price of that reclaimability, not a promotional rate.
The advertised discount (commonly up to 90% off on-demand) is a ceiling that assumes zero interruption cost, which no real workload actually achieves. Once a team accounts for the retries an interruption forces, the engineering time spent building genuine interruption tolerance (checkpointing, graceful handoff, workload types that can actually resume from where they left off), and the operational overhead of running spot fleets at all, the real saving is much smaller than the pricing page. Calculate it instead of quoting a typical percentage:
net saving ≈ (share of fleet on spot) × (average discount you get) − (re-run work + on-demand fallback + engineering, as a share of baseline cost)
For example, 70% of a fleet on spot at an average 65% discount is about 45% off before costs. Subtract 5% for re-run work and fallback capacity and the whole fleet is about 40% cheaper. That's a real saving, and it's the number to put in the budget.
How you request spot changes the interruption rate. Ask for many instance types and sizes across every zone, and use the price-capacity-optimized allocation strategy (or let Karpenter pick from a wide list). The provider then places you in the pools least likely to be reclaimed. Pinning one instance type in one zone puts all your nodes in the same pool, where a single capacity crunch reclaims all of them at once.
Spot is a strong fit specifically for interruption-tolerant workload shapes — batch processing, stateless horizontally-scaled services behind a load balancer that can lose one instance without dropping in-flight work, CI/CD build runners — and a poor fit for anything stateful that can't gracefully hand off or checkpoint its work inside that notice window (as short as 30 seconds on some clouds). Choosing spot for a workload shape that can't actually tolerate interruption converts an intended cost optimization into an intended reliability problem.
Reserved capacity: the risk is commitment, not the discount rate itself
A reserved instance or Savings Plan trades a lower hourly rate for a 1-3 year commitment to pay for that capacity regardless of whether it's actually used — the discount itself isn't the risky part; committing to a specific capacity number for a multi-year horizon, in a business where traffic patterns, service architectures, and instance-family preferences routinely change well inside that window, is.
The responsible sizing discipline: reserve only the portion of load that's genuinely steady and predictable, and leave bursty or uncertain capacity to on-demand or spot. A team that reserves capacity sized to peak load, rather than steady-state baseline, is paying the commitment premium on capacity it may only actually use during traffic spikes — exactly the portion of load reserved instances are the wrong tool for, since a spike is by definition not the steady, predictable demand a multi-year commitment is meant to underwrite.
Reservations need periodic review against actual usage, not a "buy once" decision made at a point in time and never revisited. A service that gets deprecated, migrated to a different instance family, or simply outgrows its original sizing leaves a reservation partially or fully unused for the remainder of its term — a cost that shows up as "we're still paying for capacity nothing uses" months after the architecture that justified the original purchase has already changed, which a scheduled utilization review catches before it compounds across the full commitment term instead of after.
Savings Plans vs RIs, and the order you do things in
Order matters: rightsize first, schedule second, commit last. A commitment locks in whatever you're running today. If half your instances are twice the size they need to be, a 3-year commitment locks that waste in at a discount. So the sequence is:
- Rightsize: shrink instances and container requests to what they actually use.
- Turn things off: shut down dev and staging outside working hours.
- Measure the floor: find the lowest steady usage over the past several weeks.
- Commit to part of that floor (often 70-80% of it) and leave room for further optimization.
On AWS, Savings Plans have mostly replaced Reserved Instances for compute. You commit to a dollar amount per hour of spend, not to specific instances:
- Compute Savings Plans apply across instance families, sizes, regions, and operating systems, and to Fargate and Lambda. They discount up to about 66%.
- EC2 Instance Savings Plans are tied to one instance family in one region and discount up to about 72%.
That flexibility is the main protection against the "we migrated families and the reservation went unused" problem. Since December 2025 Database Savings Plans cover RDS, Aurora, DynamoDB, ElastiCache and other managed databases, but only on a 1-year term, for up to about 35% off, and on ElastiCache only for Valkey. The list has since grown to include OpenSearch. So RIs still matter for 3-year terms, deeper discounts, ElastiCache for Redis OSS or Memcached, and services no Savings Plan covers, such as Redshift. Standard RIs can be resold on the RI Marketplace; Savings Plans can't be resold. GCP's committed-use discounts and Azure reservations and savings plans follow the same pattern.
Measure commitments with two numbers:
- Utilization: how much of what you bought you actually used. Below 100% means you're paying for capacity nothing uses.
- Coverage: how much of your eligible spend the commitments cover. Low coverage means steady load is still paying on-demand rates.
Stagger purchases over time (for example, a small one every quarter) rather than making one big buy, so commitments expire at different times and you can adjust as usage changes.
How to say it in the interview
"Spot's 90% discount is a ceiling, not a plan - once you account for the share of the fleet that can actually run on spot, re-running interrupted work, on-demand fallback, and the engineering to tolerate a reclaim at two minutes' notice (30 seconds on GCP and Azure), the net saving is a number you calculate for your workload, and it's usually far below 90%. Budgeting against the advertised number is how a cost-savings initiative quietly under-delivers against its own projection."
Checklist
- Calculated net spot savings (share on spot × discount − rework, fallback, engineering) instead of budgeting against the advertised ceiling
- Matched spot to genuinely interruption-tolerant workload shapes (batch, stateless horizontally-scaled, CI runners), designed for the shortest notice (30s on GCP/Azure)
- Diversified spot across many instance types and zones with a capacity-aware allocation strategy, and acted on rebalance recommendations
- Rightsized and scheduled non-prod off before buying commitments, then committed to part of the steady floor
- Preferred Compute Savings Plans for flexibility, tracked utilization and coverage, and staggered purchases
- Sized reserved capacity to steady-state baseline load, not peak, leaving bursty capacity to on-demand or spot
- Scheduled periodic review of reservation utilization against actual usage, not a one-time purchase decision