Spot is the only discount in cloud that you earn rather than sign for. Every other instrument in this series is a purchasing decision made in a spreadsheet. Spot is a design decision made in your application, and that is why it is both the deepest discount available and the one most organisations quietly abandon after one bad afternoon.

I have watched that afternoon happen twice. Both times a team moved a workload to spot capacity because the savings figure was irresistible, both times the workload was a stateful job with a long startup and no checkpointing, and both times a single capacity reclaim in one availability zone wiped out six hours of processing. The conclusion drawn in the retrospective was that spot is unreliable. The correct conclusion was that the workload was never a spot candidate, and nobody had asked the question before the migration.

How spot capacity works

Every cloud provider builds more physical capacity than it sells at any given moment, because on demand customers expect a machine to appear the instant they ask for one. That unsold headroom is expensive to leave idle. Spot capacity is the provider selling it at a deep discount with one condition attached: when a full price customer wants the machine, you give it back.

The word for taking it back differs by vendor and the difference is only vocabulary. AWS calls it interruption, Azure calls it eviction, Google Cloud calls it preemption. All three mean the same thing: your instance stops, on someone else’s schedule, and you get a short warning first.

The concept that actually governs your experience is the capacity pool. AWS defines a spot capacity pool as the set of unused instances sharing one instance type in one availability zone, so an m5.large in us-east-1a is a different pool from an m5.large in us-east-1b. Spot availability is a property of individual pools, not of the market as a whole. When people say spot went away, what happened is that one pool drained while a dozen others sat half empty, and their configuration only knew how to ask for the one.

The interruption contract on each cloud

How much warning you get is the single most important design input, because it sets the upper bound on what your shutdown routine can accomplish. AWS is the most generous by a wide margin and the gap is not marginal, it is a factor of four.

Verified against AWS EC2, Microsoft Learn and Google Cloud Compute Engine documentation in July 2026. Discount ceilings are best case figures for specific machine families and regions, not the blended rate a mixed fleet will see.

Two details in that table are worth more attention than they usually get. The first is the AWS rebalance recommendation, which is a separate signal telling you an instance is at elevated risk of interruption, issued before the two minute notice where possible. AWS is careful to say it cannot always arrive first and may land alongside the interruption notice, so treat it as a bonus rather than a guarantee. Used well, it is the difference between draining a node calmly and draining it in a panic.

The second is Azure’s eviction policy, which quietly decides whether you keep paying. The default policy is Deallocate, which moves the machine to a stopped state so you can restart it later, and Microsoft is explicit that you continue to be charged for the disk storage while it sits there. The alternative policy, Delete, removes the machine and its disks together so the storage charge stops. Teams that pick the friendlier sounding default and then never restart the machines end up with a slow accumulation of orphaned disks, which is a genuinely common way to lose a chunk of your spot savings without noticing.

On Google Cloud the shutdown period is best effort and up to thirty seconds, which is short enough to be awkward for anything that has to flush state. Google’s own guidance is to raise the preemption notice duration, to 120 seconds for workloads that need longer than the default to shut down cleanly. If you are running anything on Google Cloud spot that has a meaningful shutdown routine, changing that setting is the highest value ten minutes of configuration work available to you.

Which workloads can take an interruption

AWS states the criteria plainly and the same test works on all three clouds: spot suits applications that are stateless, fault tolerant and flexible. It names big data, containerised workloads, continuous integration and delivery pipelines, stateless web servers, high performance computing and rendering as good fits.

The exclusion list matters more. AWS explicitly says spot is not suitable for workloads that are inflexible, stateful, fault intolerant, or tightly coupled between instance nodes. That last category catches people out, because a tightly coupled cluster job loses everything when one node vanishes, which means a fleet of a hundred nodes has a hundred chances to fail rather than one.

There is one more piece of AWS guidance that surprises almost everyone I show it to. AWS strongly discourages failing over to on demand instances when spot capacity runs short. The reasoning is that a rush to on demand in a constrained pool can drive further interruptions for your other spot instances, and once you have taken on demand capacity in a given type and zone combination, getting more of it can become difficult. The instinctive safety net makes the problem worse. The right response to a spot shortage is to wait, or to ask for a different shape of machine, not to buy your way out at list price.

flowchart TD
  A{Does the work survive losing one node} -->|No, nodes are tightly coupled| B[Keep on demand or committed capacity]
  A -->|Yes| C{Is there state on local disk}
  C -->|Yes, and it cannot be rebuilt| B
  C -->|No, or it checkpoints externally| D{Can it restart within the SLA}
  D -->|No, restart takes hours| E[Spot only for a small tail of capacity]
  D -->|Yes, minutes| F{Is it flexible across machine shapes}
  F -->|Pinned to one family| G[Widen the shape list first, then revisit]
  F -->|Flexible| H[Strong spot candidate, start at 30 percent]
  H --> I[Measure interruption rate for 30 days before raising the share]

Designing for capacity, not for instances

The mental shift that makes spot work is to stop asking for particular machines and start asking for an amount of compute. AWS puts it as thinking in aggregate capacity, in vCPUs, memory, storage or network throughput, rather than in individual instances. Once you think that way, an interruption stops being a failure and becomes a substitution.

Flexibility across shapes is the practical expression of that idea, and AWS gives a concrete rule of thumb: be flexible across at least ten instance types for each workload, and make sure every availability zone in your VPC is configured and selected. If a workload can scale vertically, include larger sizes. If it can only scale horizontally, deliberately include older generation families, because those are less in demand from on demand customers and therefore more available as spare capacity. That last point is the sort of thing that sounds like folklore until you look at your interruption rate by family and see it plainly.

The allocation strategy, meaning the rule the platform uses to pick which pool to draw from, is the other lever. AWS recommends the price capacity optimized strategy, which draws from the pools that have the most available capacity while also having the lowest price, and states plainly that sourcing from optimal capacity pools decreases the chance of reclaim. Choosing pure lowest price instead is the classic beginner error: it finds the cheapest pool, which is frequently the emptiest one, and hands you a higher interruption rate for a rounding error of savings.

Two further AWS features are worth knowing. Attribute based instance type selection lets you describe what you need in vCPUs, memory and storage and have the platform find matching instance types automatically, including newly released ones you have never heard of. Spot placement score returns a number from one to ten for a region or zone indicating how likely your requested spot capacity is to be fulfilled there, which is useful for deciding where to place a large batch run. AWS is careful to note it is a point in time recommendation and does not guarantee capacity or predict interruption risk, so use it to choose between options rather than to promise anything.

Kubernetes changes the arithmetic

If your workloads already run on Kubernetes, most of the hard work has been done for you, because the scheduler is built around the assumption that nodes come and go. On EKS, Karpenter consumes interruption notifications from an Amazon SQS queue and drains the affected node gracefully while provisioning a replacement, which is the exact behaviour you would otherwise be writing yourself.

Karpenter also does spot to spot consolidation, replacing running spot nodes with cheaper equivalent ones, a capability added in version 0.34.0. It requires a diversified configuration of at least fifteen instance types before it will act, precisely to stop the optimiser from herding you into a thin pool with a high interruption rate. That guard rail is a good summary of the whole discipline: the platform will not let you trade availability for a few cents unless you have given it room to choose. Pair it with pod disruption budgets on anything user facing so that consolidation and interruption cannot drain more replicas at once than you can afford to lose.

What spot actually saves once you add headroom

Headline discounts of 90 percent do not become 90 percent off your bill, and the gap is not small. Two things eat into it. Only part of your fleet is ever a spot candidate, and running spot reliably means over provisioning slightly so that a reclaim does not immediately reduce your effective capacity. That buffer is headroom, and ten percent is a reasonable planning figure for a diversified fleet.

Work it through on a hundred node fleet at roughly 0.50 USD per node hour, which is about 36,500 USD a month at on demand rates, with spot at a 70 percent discount.

Arithmetic from the stated assumptions: 100 nodes, 730 hours, 0.50 USD per node hour at on demand, a 70 percent spot discount, and 10 percent extra spot nodes provisioned as replacement headroom. Not a quote from any price list.

The shape of that final column is the finding. The first half of the journey is nearly free in engineering terms, because the easiest workloads go first and each 25 point step is worth about 17 points of saving. Past 50 percent the returns fall and the difficulty rises at the same time, since what is left is the work you were least comfortable interrupting. Getting from 70 to 90 percent buys 13 points and costs you the workloads you actually worry about. For most organisations that is the wrong trade, and the honest stopping point is somewhere between 50 and 70 percent.

Where spot goes wrong

Most spot failures trace back to one of four things, and none of them is bad luck. The first is pool concentration, asking for a single instance type in a single zone and then being surprised when that one pool empties. The second is an untested shutdown path, where the drain routine has never been run under time pressure and turns out to take ninety seconds in a thirty second window.

The third is silent state. A workload that looked stateless turns out to keep a cache, a scratch directory or a partially written output file on the local disk, and losing it costs more than the node. The fourth is measuring the wrong thing: teams track the spot discount rate and never track interruption rate or the cost of redone work, so a configuration that is quietly wasting thirty percent of its compute on retries still looks excellent on the cost dashboard.

The fix for all four is the same and it is unglamorous: rehearse the interruption. Every cloud gives you a way to force one, and running that exercise deliberately in a lower environment tells you more in an hour than a month of reading. Time the drain, watch what the scheduler does, and check whether anything was lost. If your team cannot say what your interruption rate was last month, you are not running spot, you are hoping.

sequenceDiagram
  participant P as Cloud provider
  participant N as Node
  participant S as Scheduler
  participant W as Workload
  P-->>N: Elevated risk signal, where available
  S-->>S: Start provisioning a replacement early
  P-->>N: Interruption notice, 30 to 120 seconds
  N-->>W: Stop accepting new work
  W-->>W: Write a checkpoint to durable storage
  N-->>S: Mark node unschedulable and drain pods
  S-->>W: Reschedule onto the replacement node
  P-->>N: Reclaim the machine

Start at 30 percent spot on one batch workload

Here is the recommendation for this part, without hedging. Pick your largest batch or continuous integration workload, the one that already tolerates a restart, and move 30 percent of its capacity to spot with at least ten eligible instance types across every availability zone, using the price capacity optimized allocation strategy or its equivalent on your cloud. Instrument the interruption rate and the cost of redone work from day one. Run it for thirty days before touching anything else.

If the interruption rate is boring and nothing was lost, raise the share to 50 or 70 percent on that workload and only then look for the second candidate. Do not go looking for 90 percent, and do not put anything user facing on spot until you have a platform that drains nodes automatically and a disruption budget protecting the replicas. The teams that get spot working are the ones that treated it as a capability to build rather than a discount to claim.

Part 14 turns to storage and data transfer costs, which is where the money hides once compute has been dealt with, and where the fixes are structural rather than contractual. The commitment position that spot sits above was set in Part 12, the rightsizing that should precede both was in Part 11, and every part so far is indexed on the Cloud FinOps guide.

One thing to do this week: force an interruption on a spot node in a non production environment and time how long your workload actually takes to shut down cleanly. If the answer is longer than the notice window you get, you have found the work before it finds you.

References

• Best practices for Amazon EC2 Spot, Amazon EC2 User Guide
• Spot Instance interruption notices, Amazon EC2 User Guide
• EC2 instance rebalance recommendations, Amazon EC2 User Guide
• About Azure Spot Virtual Machines, Microsoft Learn
• Spot VMs, Google Cloud Compute Engine documentation
• Applying spot to spot consolidation best practices with Karpenter, AWS Compute Blog

Notice windows, discount ceilings, eviction policies and allocation strategy names were verified against AWS, Microsoft and Google documentation in July 2026 and change over time. Monetary figures in the tables are arithmetic from stated assumptions rather than quotes from a live price list.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts