Azure Kubernetes Service Spot Node Pools: A Cost Guide

Last updated: June 2026

Written by Morten Andersen and reviewed by Fredrik Filipsson. Method: See, Cut, Lock, Run. We have optimized $420M+ in cloud spend across 500+ environments.

An AKS spot node pool is a standard Azure Kubernetes Service node pool whose nodes run on Azure Spot Virtual Machines instead of regular VMs, which means they use Azure's unused capacity and cost up to 90% less, at the price of being evictable with a 30-second warning. Adding spot capacity is one of the largest single levers on a Kubernetes bill, and it is a Cut step in our See, Cut, Lock, Run method. This article is part of our Azure cluster; start with the complete guide to Azure cost optimization, the pillar this piece links up to.

How much do AKS spot node pools save?

Spot nodes save up to 90% versus pay-as-you-go on the compute they replace. They run on Azure Spot Virtual Machines, which draw from Azure's spare capacity and are priced far below on-demand, per Microsoft's AKS spot node pool documentation. The exact discount is not fixed: it varies by region and VM size and moves with available capacity, so treat 90% as the ceiling rather than a guarantee and verify the live spot price for your instance family in the Azure Virtual Machines pricing before you size around it. Even at a more typical discount, moving the interruptible half of a cluster to spot meaningfully bends the bill.

What happens when a spot node is evicted?

Azure sends a 30-second eviction notice and then reclaims the node according to the eviction policy you set, either deallocating or deleting it. Kubernetes responds by rescheduling the evicted pods, ideally onto other spot nodes, or onto regular nodes if your configuration allows it. This is why spot is safe only for workloads that can absorb a sudden node loss: a batch job retries, a CI runner restarts, a stateless replica gets recreated elsewhere. A single-replica database does not survive this gracefully, which is the whole reason for keeping critical and stateful work off spot.

How to add and use AKS spot node pools

Follow these five steps to add spot capacity and route the right workloads to it without putting anything critical at risk.

1. Identify interruptible workloadsList the batch jobs, CI/CD runners, data pipelines, dev and test environments, and stateless services that can tolerate a 30-second eviction. These are the only workloads that belong on spot. Anything stateful, single-replica, or latency-critical stays on regular nodes.
2. Add a spot node poolCreate a new node pool with the spot scale set priority, set the eviction policy to Delete or Deallocate, and set a max price (or accept the current spot price). The result is a pool of discounted, evictable nodes attached to your existing cluster.
3. Apply taints, tolerations, and affinityAKS automatically taints the spot pool so general pods avoid it. Add a matching toleration and node affinity to the interruptible workloads so they schedule onto spot, and leave everything else to land on regular nodes. The result is precise control over what runs where.
4. Configure fallback to on-demandSet the cluster autoscaler so that when spot capacity is unavailable, evicted pods can reschedule onto regular nodes rather than sitting pending. The result is that the workload keeps running through an eviction, just at a higher rate until spot returns.
5. Monitor eviction rate and tuneTrack how often nodes are evicted and how much you are saving, then adjust the workload mix, the VM sizes, and the max price. As confidence grows, move more interruptible work onto spot. The result is a steadily larger share of the cluster running at the discounted rate.

Which workloads should and should not run on spot?

Run fault-tolerant, interruptible workloads on spot and keep everything critical off it. Good spot candidates are batch and data-processing jobs, CI/CD pipelines, machine learning training and experimentation, and dev or test environments, all of which can restart without consequence. Poor candidates are production databases, single-replica services, anything holding state in memory, and the AKS system node pool itself, which should always run on regular or reserved nodes. The discipline is simple: spot for work that can be interrupted, committed capacity for work that cannot. For the platform-choice context around this, compare it against serverless in Azure Container Apps vs AKS: a cost comparison.

How does spot fit with reservations on the same cluster?

Spot and reservations are complementary layers, not alternatives. The cheapest AKS clusters run a stable, committed base of reserved nodes for system components and steady production, then layer spot node pools on top for the interruptible, variable work. Reservations lock in a low rate on the capacity you always need; spot captures the deepest discount on the capacity you can afford to lose. Combining them on one cluster is how the lowest total compute cost is reached, and it is the same commitment-plus-variable pattern we apply across the Azure cost optimization program.

Spot discounts, the 30-second eviction notice, and eviction policy behavior reflect Azure as of June 2026. Verify current spot prices and behavior in the linked Azure documentation before planning capacity, because spot pricing and availability change continuously.

Frequently asked questions

The short version

AKS spot node pools cut compute up to 90% by running interruptible workloads on Azure spare capacity, in exchange for a 30-second eviction notice. Identify what can be interrupted, add a spot pool with an eviction policy and fallback, route only safe pods with taints and tolerations, and pair spot with reservations for the stable base. When you want the spot topology designed and the savings captured safely, that is exactly what our Azure cost optimization service delivers.