Cost

Run interruptible AKS workloads on Spot node pools

One capability across every AKS cluster: move the workloads that tolerate interruption, batch jobs, CI runners, dev and test, off pay-as-you-go nodes and onto Azure Spot node pools that buy spare capacity at a deep discount, without putting anything that cannot survive an eviction at risk.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

AKS Spot node pools: the basics

What does running interruptible work on full-price nodes actually cost you?

An AKS cluster runs its pods on node pools, and by default every pool is backed by regular pay-as-you-go virtual machines. That is the right choice for anything that must stay up: the system pool that runs cluster services, an API that serves live traffic, a stateful database. But a large share of what most clusters actually run does not need that guarantee. Batch jobs, nightly data processing, CI and build runners, machine-learning training, development and test environments: all of these can be restarted if a node disappears, and paying the full on-demand rate to run them is leaving money on the table.

A Spot node pool is a user node pool backed by an Azure Spot Virtual Machine Scale Set. It buys Azure's spare, unused capacity at a steep discount instead of the on-demand price. The trade is that the capacity is not guaranteed: when Azure needs it back, it evicts the nodes with thirty seconds of notice, and your pods are rescheduled elsewhere. For interruptible work that is a fine bargain. For a live API it is not. The whole capability is about drawing that line correctly, then moving everything on the right side of it onto Spot.

Azure Advisor surfaces this directly as a cost recommendation, 'Consider Spot nodes for workloads that can handle interruptions' (resource type microsoft.containerservice/managedclusters, recommendation ID 17f6ab99-c9b6-4800-bebd-7466699cec31). It fires when Advisor sees an AKS cluster whose pattern of work looks like it could tolerate eviction. The recommendation is the prompt; the work is deciding which of your workloads genuinely can be interrupted, adding a Spot pool with the right taints and tolerations, and scheduling that work onto it.

In this lesson you will learn how AKS expresses guaranteed versus interruptible capacity, how Spot node pools work and what an eviction actually does, how to find the workloads that can safely run on Spot, and how to add a Spot pool and schedule that work onto it without touching anything that must stay up. The Azure Advisor recommendation that prompts this is the starting point; the judgement about which workloads qualify is the real content.

Fun fact

The capacity nobody else booked

Spot pricing exists because cloud datacentres are never full. At any given moment a region has servers powered on and idle, capacity that has been bought and built but not yet rented. Rather than let it sit earning nothing, Azure offers it at a deep, variable discount on the understanding that it can be reclaimed the instant a paying, on-demand customer wants it. That is the whole bargain in one line: you run on the spare seats, and you give them up when the booked passenger arrives. For work that can simply catch the next train, batch jobs, build runners, test clusters, it is close to free money, which is exactly why Azure Advisor goes looking for AKS clusters that could be using it and are not.

Finding the interruptible work in a cluster

Priya runs the platform team at a company whose AKS bill has been climbing as more teams onboard. Azure Advisor has raised the Spot recommendation on two of their busiest clusters, and the monthly compute line is now large enough that leadership has asked what is driving it.

Rather than reach for Spot blindly, Priya starts by looking at what the cluster's node pools actually are today and what kind of work sits on them, so the interruptible workloads can be separated from anything that must stay up before a single node changes.

Start by listing the node pools on the cluster and their current priority. Everything on a Regular pool is paying the full on-demand rate.

$ az aks nodepool list --resource-group rg-prod --cluster-name aks-prod --query "[].{name:name, mode:mode, priority:scaleSetPriority, vmSize:vmSize, count:count}" -o table

Name Mode Priority VmSize Count

-------- ------ ---------- --------------- -------

system System Regular Standard_D4s_v5 3

apps User Regular Standard_D8s_v5 6

# 'apps' is one big Regular pool running live APIs AND nightly batch at full price.

# The batch jobs are interruptible. They are the candidate to move onto Spot.

When a Priority of Regular is shown next to a user pool that mixes live traffic with batch work, the interruptible share is paying full price for no reason. That is the spend a Spot pool reclaims.

How an AKS Spot node pool actually behavesdeep dive

A Spot node pool is a user node pool whose underlying Virtual Machine Scale Set has 'scaleSetPriority' set to 'Spot' rather than 'Regular'. It cannot be the default system pool, because the cluster's own services must run on guaranteed capacity. When you create it, AKS automatically applies two markers so that work does not land on it by accident: the label 'kubernetes.azure.com/scalesetpriority=spot', and the taint 'kubernetes.azure.com/scalesetpriority=spot:NoSchedule'. The taint repels every pod that does not explicitly tolerate it, which is why a Spot pool stays empty until you deliberately schedule work onto it. To run on Spot, a pod needs a matching toleration, and usually a node affinity so the scheduler prefers the Spot nodes.

Pricing is governed by 'spotMaxPrice'. A value of -1 means 'accept the current Spot price up to, but never above, the on-demand price', which is the common choice: you always pay the Spot rate and are only ever evicted for capacity, never for price. You can instead set a specific maximum in US dollars, in which case a node is also evicted if the Spot price rises above your cap. The eviction policy decides what happens to an evicted node: 'Delete' (the default) removes it, and the autoscaler can create a fresh one when capacity returns; 'Deallocate' stops it in place, but it still counts against your scale set quota.

Eviction is the behaviour that defines the whole capability. When Azure needs the capacity back, it gives the node thirty seconds of notice and then reclaims it. Kubernetes sees the node go and reschedules its pods. For a stateless batch job or a build runner that means a restart; for a job that writes checkpoints it means resuming from the last one. This is why placement is everything: pair a Spot pool with the cluster autoscaler so evicted capacity is replaced when it returns, keep the system pool and any latency-sensitive or stateful workload on a Regular pool, and only tolerate the Spot taint from the workloads you have decided can survive being interrupted.

What is the impact of running interruptible work on full-price nodes?

The direct impact is pure overspend. Every node-hour that a batch job, build runner or test environment spends on a Regular pool is paying the on-demand rate for capacity that Azure would have sold you at a steep discount. Because this work is often bursty and runs at scale, machine-learning training, large nightly jobs, parallel CI, the full-price node-hours add up fast, and they are some of the easiest hours in the whole estate to discount because the work does not care which physical capacity it runs on.

The second-order impact is that the cluster's cost stops reflecting its actual reliability needs. When everything runs on guaranteed capacity, the bill treats a throwaway test pod and a customer-facing API as if they have the same requirement, which they plainly do not. That makes the compute line harder to reason about and hides the fact that a large slice of it is discretionary. Splitting interruptible work onto Spot makes the bill tell the truth: guaranteed capacity for what needs it, discounted spare capacity for what does not.

The reason this is worth doing rather than just nice to have is the asymmetry. The saving is large, recurring and a direct discount on a rate you already pay. The cost to capture it is a one-off piece of engineering plus modest resilience work, and the only ongoing risk, an eviction, is fully contained by only placing interruptible work on Spot. Azure Advisor flags the clusters where this gap exists precisely because it is one of the most reliable cost wins available in Kubernetes.

How do you move interruptible work onto Spot safely?

Work this as a deliberate split, not a blanket switch. The order matters: decide what can tolerate an eviction before you add any Spot capacity, so nothing that must stay up ever lands on a node that can disappear.

1. Classify every workload as guaranteed or interruptible

Go through the cluster's workloads and mark each one. The system pool, live APIs, stateful services and anything latency-sensitive stay on guaranteed Regular capacity. Batch jobs, CI and build runners, machine-learning training, and development and test environments are the interruptible candidates. When in doubt, leave it on Regular: this capability is about moving the clear wins, not forcing every workload onto Spot.

2. Add a Spot user node pool with the autoscaler

Create a user node pool with priority Spot, an eviction policy of Delete, and a max price of -1 so you pay the Spot rate and are only ever evicted for capacity. Enable the cluster autoscaler with a sensible min and max so the pool grows when there is interruptible work and shrinks, ideally toward zero, when there is not. AKS automatically taints the pool so nothing schedules onto it by accident.

3. Schedule the interruptible work onto it

Add a toleration for the Spot taint, and a node affinity for the Spot label, to each workload you classified as interruptible. The toleration lets the pod past the taint; the affinity tells the scheduler to prefer the Spot nodes. Keep replicas, retries and, for long jobs, checkpointing in place so a thirty-second eviction notice results in a clean reschedule rather than lost work.

4. Make the split the default and review it

Once it is working, make 'interruptible work runs on Spot' the team default rather than a one-off, and revisit the classification as workloads change. Track the share of cluster compute still running interruptible work on Regular pools as the signal of discount left on the table, and keep production firmly on guaranteed capacity.

# 1. Add a Spot user node pool to an existing AKS cluster.
#    --priority Spot is required; --spot-max-price -1 pays the Spot rate up to
#    the on-demand price, so you are only ever evicted for capacity, not price.
az aks nodepool add \
  --resource-group rg-prod \
  --cluster-name aks-prod \
  --name spot \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-vm-size Standard_D8s_v5 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 10

# AKS applies these automatically to the new pool:
#   label: kubernetes.azure.com/scalesetpriority=spot
#   taint: kubernetes.azure.com/scalesetpriority=spot:NoSchedule
# so nothing schedules onto Spot until a workload tolerates the taint.

# 2. Tolerate the taint and prefer Spot nodes on an interruptible workload.
#    Apply this to batch jobs, CI runners, ML training, dev/test, never to
#    the system pool or a live, stateful or latency-sensitive service.
cat <<'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nightly-etl
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nightly-etl
  template:
    metadata:
      labels:
        app: nightly-etl
    spec:
      tolerations:
        - key: kubernetes.azure.com/scalesetpriority
          operator: Equal
          value: spot
          effect: NoSchedule
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              preference:
                matchExpressions:
                  - key: kubernetes.azure.com/scalesetpriority
                    operator: In
                    values:
                      - spot
      containers:
        - name: etl
          image: myregistry.azurecr.io/nightly-etl:latest
EOF

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider Spot nodes for workloads that can handle interruptions' on an AKS cluster. What is the right way to act on it?

Keep learning

Go deeper on how AKS Spot node pools work and where they fit in a wider cost-optimisation picture.

You can now treat AKS compute as two categories rather than one: guaranteed capacity for what must stay up, and discounted Spot capacity for the interruptible work that can simply restart. Classify each workload, add a Spot user node pool with the autoscaler, tolerate its taint only from the work that can survive an eviction, and make 'interruptible runs on Spot' the default. The Azure Advisor recommendation that started this is just the prompt; the saving comes from acting on it deliberately.

Back to the library

AKS Spot node pools: the savings view

A configuration change that cuts the compute bill for interruptible work to a fraction of on-demand

Spot is one of the highest-leverage cost levers in the whole Azure compute story, because the saving is a direct discount on the rate you already pay. Microsoft documents Spot pricing as variable spare capacity offered at a significant discount, commonly cited up to around 90 percent off the pay-as-you-go price, with the exact figure depending on the VM size, region and current demand. Moving a workload from a regular pool to a Spot pool does not buy anything new; it buys the same compute cheaper. The spend that was going to full-price nodes for batch and test work simply falls.

The cost to capture it is engineering time, not new Azure spend. There is no licence, no add-on, no reserved commitment required: you add a node pool, label the work that can tolerate interruption, and let the cluster autoscaler scale the Spot pool up and down. The only real cost is the engineering judgement to decide which workloads qualify, plus a modest amount of resilience work, retries and checkpointing, for the jobs that need to survive an eviction cleanly.

Frame this as savings with a known boundary rather than a risk. The downside of a Spot eviction is a rescheduled job, not lost data, provided you only place interruptible work there. So the question for finance is not 'is this safe?' but 'how much of our cluster compute is currently interruptible work paying the full rate, and what is the payback on moving it?' For most clusters that runs batch, CI and non-production, the answer is a large recurring saving for a one-off piece of work.

This lesson is for the finance partner who sees an AKS line growing on the Azure bill and an Advisor recommendation to consider Spot, and wants to know what the saving really is, what it costs to capture, and where the boundary of safe sits. It covers why the discount is a direct rate cut, why the cost to capture is engineering time rather than new spend, and how to size the payback before approving the work.

Fun fact

The capacity nobody else booked

How a finance partner sizes the Spot opportunity

Priya is the finance partner working with the platform team on the AKS line that has grown each of the last four months. The Advisor recommendation to consider Spot has landed on two clusters, and the instinct is not to ask 'is Spot risky?' but to ask 'how much of what we run is interruptible, and what is the rate difference?' The platform team breaks the 'apps' pool down: the live APIs and the system pool must stay on guaranteed capacity, but the nightly ETL, the CI build runners and three non-production environments are all interruptible work currently paying the on-demand rate.

Priya turns that into a payback. The interruptible workloads are a defined slice of the pool's node-hours, and Spot prices that same compute at a steep, variable discount, commonly cited up to around 90 percent off pay-as-you-go depending on VM size and region. Even taking a conservative discount and allowing headroom for evictions sending work briefly back to on-demand, the recurring saving on that slice dwarfs the one-off engineering cost of adding a Spot pool and tolerating it in the manifests. The finance pack reads: 'Roughly a third of cluster compute is interruptible work on full-price nodes; moving it to Spot is a one-off engineering task with a recurring discount; the only ongoing cost is a little resilience work so the jobs survive an eviction cleanly.'

Why Spot is one of the cleanest savings on the bill

The cost model here is unusually favourable. The saving is not a rebate you have to claim or a commitment you have to forecast; it is a lower hourly rate for the same work, applied the moment the workload moves onto a Spot pool. Microsoft prices Spot as spare capacity at a significant, variable discount, commonly cited up to around 90 percent off pay-as-you-go depending on VM size, region and demand, so the recurring saving on a meaningful slice of cluster compute is large.

The cost to capture it is a one-off: add a Spot pool, add tolerations to the interruptible workloads, and do a little resilience work, retries and checkpointing, so an eviction is a clean restart rather than a failed job. There is no licence and no reserved commitment. The finance role is to size the interruptible slice in node-hours, apply a conservative discount, and present the payback, which for most clusters carrying batch, CI and non-production work is a short one. The metric that belongs on the cost review is the share of cluster compute that is interruptible work still running on Regular pools, because that is the discount left unclaimed.

What finance can do about the Spot gap

Finance cannot add a node pool, but it owns the framing that turns an Advisor recommendation into a sized, approved piece of work with a clear recurring return and a one-off cost. Three levers.

1. Size the interruptible slice before approving anything

Ask the platform team which workloads are genuinely interruptible and what share of cluster node-hours they represent. That slice, priced at the Spot discount rather than the on-demand rate, is the recurring saving. Make the number concrete: 'this many node-hours a month move from full price to a steep, variable discount.' Without that slice sized, Spot is a vague good idea; with it sized, it is a payback you can approve.

2. Treat the discount as recurring and the cost as one-off

The saving repeats every month for as long as the work runs on Spot; the cost, adding the pool, tolerating the taint, a little resilience work, is paid once. Present it that way so nobody mistakes the capture cost for an ongoing expense. There is no licence and no reserved commitment to model, which makes the payback unusually short and the decision unusually clean.

3. Track the share of interruptible work still on Regular pools

The metric that belongs on the cost review is not the Spot saving already captured but the discount still unclaimed: the proportion of interruptible workloads still running on full-price nodes. That number turns Spot from a one-time project into a standing target, and it is the honest measure of how much of the cluster's discretionary compute is still paying more than it needs to.

Quick quiz

Question 1 of 5

As the finance partner, what is the saving from moving interruptible work to a Spot node pool actually made of?

Keep learning

Go deeper on how AKS Spot node pools work and where they fit in a wider cost-optimisation picture.

You have finished the finance view of AKS Spot. You know the saving is a direct discount on a rate you already pay, the cost to capture it is a one-off engineering task with no licence or commitment, and the only ongoing risk is fenced off by placing nothing but interruptible work on Spot. Next time an AKS line grows and Advisor raises the Spot prompt, you will size the interruptible slice, present the recurring saving against the one-off cost, and track the share still on full-price nodes as the discount left unclaimed.

Back to the library

AKS Spot node pools: the headline

Whether the estate pays full price for compute that does not need to

Kubernetes clusters quietly accumulate cost. Build runners, nightly jobs, model training and a stack of dev and test environments all run on the same full-price nodes as production, and nobody questions the rate because it is the default. Spot node pools are the lever that separates 'compute that must stay up' from 'compute that can be restarted', and pays a fraction of the price for the second category.

The leadership question is not technical. It is: what proportion of our container compute is interruptible work paying the on-demand rate, and have we deliberately decided to keep it there? Azure Advisor is already pointing at the clusters where the answer is probably 'no, we just never moved it.' The defensible end state is that production runs on guaranteed capacity, interruptible work runs on Spot, and the split is a recorded decision rather than an accident of which pool a workload happened to land on.

This is a savings decision with a small, bounded engineering cost and a clear payback. The risk of a Spot eviction is contained entirely by placing only the right workloads there, which is exactly why it is a fast call to approve: the upside is a recurring discount, and the downside is fenced off by design.

A short read for the leader who needs to know why a cluster pays full price for interruptible work by default, why moving it to Spot is a bounded savings decision rather than a reliability gamble, and what a defensible split between guaranteed and interruptible capacity looks like across the estate.

Fun fact

The capacity nobody else booked

What it looks like when interruptible work stops paying full price

When the AKS line crossed a threshold that put it on the monthly review, the question from the top was simple: why is this number what it is, and is any of it avoidable? The honest first answer was that the cluster had grown organically, every workload had landed on full-price nodes because that was the default, and nobody had ever separated the work that must stay up from the work that could be restarted.

The team's response was to stop treating the cluster as one undifferentiated pool of compute. They listed every workload, marked which ones could tolerate an eviction, added a Spot node pool, and moved the batch jobs, build runners and non-production environments onto it with the right tolerations, leaving production untouched on guaranteed capacity. The next review told a different story: the same workloads, the same throughput, a materially smaller compute line, and a one-line policy that interruptible work runs on Spot by default. The shift, from paying the on-demand rate for everything because it was easier to paying it only for what genuinely needs the guarantee, is the recurring saving this capability delivers, and it costs a one-off piece of engineering to reach.

Why this is an easy savings call

Most cost decisions involve a real trade: cheaper but slower, cheaper but less resilient. Spot is one of the few where the trade is fully contained. The discount is large and recurring, and the only downside, an eviction, touches nothing if you only place interruptible work on Spot. Production stays exactly as resilient as it was, on guaranteed capacity, while the discretionary work that was quietly paying full price moves to spare capacity at a fraction of the cost.

That makes it the kind of saving leadership should be quickest to approve: a clear recurring return, a one-off bounded cost to capture it, and a risk that is fenced off by design rather than managed by hope. Azure Advisor is already pointing at the clusters where the opportunity sits unclaimed, which turns the decision into a simple instruction: move the interruptible work, leave production alone, and record the split.

The leadership move on Spot

The executive handle is not to approve each workload individually; it is to require that interruptible work runs on discounted capacity by default and that the split between guaranteed and interruptible is a recorded decision.

1. Set the default, then make production the exception

Ask for a simple standing rule: interruptible work runs on Spot, production runs on guaranteed capacity, and any interruptible workload kept on full-price nodes needs a reason. A default that points the right way turns Spot from a project that has to be re-justified each time into the cheaper path the team takes automatically.

2. Ask for the payback, not the technology

The case to approve is not 'we will use Spot.' It is 'this share of cluster compute is interruptible work paying full price, moving it to Spot saves this much recurring, and the cost to capture it is this one-off engineering task.' Require the saving and the capture cost as numbers, with the Advisor recommendation as the prompt, and the decision becomes a quick yes.

3. Keep the risk fenced off, on the record

The only downside of Spot is an eviction, and it is contained entirely by placing only interruptible work there. The leadership requirement is that production and stateful services are never given the toleration, so an eviction can only reschedule discretionary work, and that this boundary is documented rather than held in one engineer's head. The goal is not maximum Spot; it is maximum discount with production untouched.

Quick quiz

Question 1 of 5

At a cost review you ask why the AKS line is what it is. What end state should you be steering towards?

Keep learning

Go deeper on how AKS Spot node pools work and where they fit in a wider cost-optimisation picture.

Two takeaways. Spot is one of the cleanest savings on the Azure bill because the discount is large and recurring while the only downside, an eviction, is contained entirely by what you place there. And the defensible end state is not 'we use Spot somewhere'; it is a recorded split where production runs on guaranteed capacity, interruptible work runs on Spot by default, and any exception carries a reason.

Back to the library

Part of the learning path Right-size your Azure compute

Run interruptible AKS workloads on Spot node pools

AKS Spot node pools: the basics

The capacity nobody else booked

Finding the interruptible work in a cluster

How an AKS Spot node pool actually behavesdeep dive

What is the impact of running interruptible work on full-price nodes?

How do you move interruptible work onto Spot safely?

1. Classify every workload as guaranteed or interruptible

2. Add a Spot user node pool with the autoscaler

3. Schedule the interruptible work onto it

4. Make the split the default and review it

Quick quiz

Keep learning

AKS Spot node pools: the savings view

The capacity nobody else booked

How a finance partner sizes the Spot opportunity

Why Spot is one of the cleanest savings on the bill

What finance can do about the Spot gap

1. Size the interruptible slice before approving anything

2. Treat the discount as recurring and the cost as one-off

3. Track the share of interruptible work still on Regular pools

Quick quiz

Keep learning

AKS Spot node pools: the headline

The capacity nobody else booked

What it looks like when interruptible work stops paying full price

Why this is an easy savings call

The leadership move on Spot

1. Set the default, then make production the exception

2. Ask for the payback, not the technology

3. Keep the risk fenced off, on the record

Quick quiz

Keep learning

Related cost lessons