Spot vs On-Demand: Calculating Real Savings After Interruptions

The marketed Spot discount of “up to 70–90%” and a team’s realized savings are two different numbers. The first counts only the list price of compute. The second counts downtime, reruns, engineering time spent on graceful shutdown, and the risk of state loss.

Below is a simple TCO model showing when raw Spot is genuinely cheaper, when it costs more than On-Demand, and where microsrv falls on that spectrum.

In short: a Spot list-price discount and realized savings are two different things. For stateful workloads, raw Spot often costs more than On-Demand once downtime and engineering time are counted.

1. What the true cost includes

A minimal useful monthly formula:

TCO ≈ (hourly_price × hours_running)
    + downtime_cost
    + rerun_cost
    + eng_and_ops_overhead

Where:

hourly_price: On-Demand, Spot, or a platform rate;
downtime_cost: lost revenue, SLA penalties, and blocked human work;
rerun_cost: recomputing batch jobs, refetching data, rerunning CI;
eng/ops: time spent on eviction handlers, instance diversity, runbooks, and overnight incidents.

A list-price discount reduces only the first term. With raw Spot capacity, the other three usually grow.

2. Batch vs. stateful: two different cost models

Batch / fault-tolerant

Checkpointed training, rendering, scraping, and CI without a strict wall-clock SLA:

an interruption costs you the work completed since the last checkpoint;
with a short checkpoint interval, realized savings stay close to the list-price discount;
TCO often lands far below On-Demand.

Stateful / interactive services

APIs, databases, long-lived agents, developer SSH sessions:

an interruption means customer-visible downtime or lost in-memory state;
you need external storage, reconnection logic, sometimes a multi-AZ active-active architecture;
the engineering cost of adapting the workload can erase a year of vCPU “savings.”

This is where “Spot at 70% off vs. On-Demand” misleads: the two sides of the comparison assume different levels of reliability.

3. A rough example

Suppose On-Demand for the required VM size costs 100 units per month.

Scenario	Compute	Downtime / retries	Eng/ops	TCO	“Savings” vs OD
On-Demand	100	0	5	105	baseline
Raw Spot, batch + checkpoints	30	10	15	55	~48%
Raw Spot, stateful without a platform	30	40	50	120	worse than OD
Platform on top of Spot (≈ −25%)	75	~0–5	~5	~80–85	~20–25%

The numbers are illustrative, but the pattern is typical: for stateful workloads, raw Spot loses on everything except its list price. The Spot and preemptible overview covers eviction mechanics; live migration cuts downtime costs by avoiding cold restarts.

4. Hidden multipliers spreadsheets omit

Mass eviction. Correlated reclaim of many nodes during a provider-side demand peak hits the system harder than infrequent, isolated interruptions.
Response window. A 30-second eviction notice is not enough time to “reshuffle a StatefulSet and warm caches.”
Instance diversity. Chasing Spot availability often forces autoscalers across many instance families, which makes capacity planning harder.
Human time. Even if downtime is “free” under your SLA, overnight incident response costs more than the Spot capacity itself.

Any calculation without these multipliers is optimistic.

5. Where microsrv sits on the scale

microsrv deliberately does not promise “70% off, like raw Spot.” The platform runs on interruptible capacity and removes the main sources of hidden costs:

the orchestrator performs live migration before the host is shut down;
replicated volumes outlive compute;
eBPF networking preserves IPs and TCP sessions.

In return you get about 25% savings versus standard cloud rates, an operating model close to a conventional On-Demand VM, and no application rewrite for interruptible compute.

That figure is realized savings, counted after interruptions.

6. How to calculate it for your team

Classify the workload: batch or stateful.
Estimate the cost of one hour of downtime and one lost run.
Add the engineering overhead of Spot-specific support, even a rough person-days × rate estimate.
Compare three columns: On-Demand, raw Spot, and a stabilization platform.
Raw Spot often wins for batch workloads. Production services usually end up on On-Demand capacity or on Spot with an orchestration layer such as microsrv.

The recommendation is simple: optimize TCO and treat the price list as an input. A discount you cannot safely realize is worth nothing.

Sources and methodology

Public calculators used for the “about 25%” estimate: /go/cloud-a and /go/cloud-b — 3×(4 vCPU·8 GB·40 GB SSD), standard (non-Spot) rates on Aug 2026. microsrv runs on interruptible capacity and adds orchestration; the net price is the figure quoted, not a raw Spot list discount.
TCO inputs: hourly_price + downtime_cost + rerun_cost + eng_and_ops_overhead, the §1 formula. downtime_cost should include SLA penalties and blocked human work alongside compute.
For provider list prices alone, see Spot and preemptible overview.

Disclaimer: this is a cost model, not financial advice. Your realized savings depend on workload class (batch vs stateful), checkpoint interval, and the price of one hour of downtime for your product.

FAQ

When does raw Spot actually save money? Fault-tolerant batch with frequent checkpoints: TCO ≈ list price. Stateful services without a platform usually cost more than On-Demand once downtime + eng time are added (§2 table).

Why not claim “70–90% off”? That is a list-price discount on compute only. Realized savings after interruptions are lower, and microsrv quotes the latter.