Kubernetes Cost Optimisation With Spot Instances: How a DevOps Engineer Reduces Your Cloud Bill by 60 to 80%

Step 1: Workload Classification

Before any Spot configuration, a DevOps engineer classifies every workload in the cluster into two categories. Spot-eligible: stateless API services, background job workers, batch processing pods, development and staging workloads, non-critical data processing. On-demand only: databases (if running in cluster), stateful services with local storage, ingress controllers, monitoring stack (Prometheus, Grafana), and any pod where a 2-minute interruption creates a user-visible outage.

This classification is the most important step. Everything that follows flows from this list.

Step 2: Separate Node Groups (On-Demand and Spot)

Two managed node groups are created in EKS: an on-demand node group (minimum 2 nodes across 2 AZs for critical workloads) and a Spot node group (multiple instance types configured across multiple AZs for cost efficiency and interruption resilience). The Spot node group specifies 4 to 6 instance types of similar size so AWS can find available Spot capacity across multiple instance families when one is unavailable.

Step 3: Pod Tolerations and Node Affinity

Kubernetes tolerations and node affinity rules route pods to the correct node group. Spot-eligible pods get a toleration for the Spot node group taint. Critical pods get a node affinity rule that prevents them from being scheduled on Spot nodes. This separation ensures that a Spot interruption only affects the pods intentionally placed on Spot nodes.

Step 4: Pod Disruption Budgets (PDBs)

Pod Disruption Budgets define the minimum number of pods that must remain available during a disruption, including Spot interruptions. A DevOps engineer creates a PDB for each critical service: minAvailable: 1 ensures at least 1 replica of each service is always running. When AWS sends a 2-minute Spot termination notice, the node drains gracefully, rescheduling pods to other nodes before the instance is reclaimed.

Step 5: Karpenter or Cluster Autoscaler Configuration

Karpenter (recommended for new setups) or Cluster Autoscaler manages node-level provisioning. For Spot, Karpenter is configured with a NodePool that specifies on-demand as the fallback when Spot capacity is unavailable. Karpenter automatically provisions the cheapest available Spot Instance type that fits pending pod requirements, and falls back to on-demand if Spot is unavailable.

Step 6: Spot Interruption Handler

When AWS reclaims a Spot Instance, it sends a 2-minute termination notice. The AWS Node Termination Handler (NTH) daemon set watches for these notices and begins graceful pod draining immediately, ensuring in-flight requests complete and pods reschedule before the node is terminated. Without NTH, pods may be abruptly terminated rather than gracefully drained.

Node configuration

On-demand monthly cost

Spot monthly cost (70% saving)

1x m5.large (2 vCPU, 8GB RAM)

$69/month

$21 to $28/month

1x m5.xlarge (4 vCPU, 16GB RAM)

$138/month

$41 to $55/month

1x m5.2xlarge (8 vCPU, 32GB RAM)

$277/month

$83 to $111/month

Cluster: 3x m5.large on-demand + 3x m5.large Spot

$207 + $63 to $84 = $270 to $291/month

vs $414/month all on-demand = save $123 to $144/month

Cluster: 2x m5.large on-demand + 4x m5.large Spot

$138 + $84 to $112 = $222 to $250/month

vs $414/month all on-demand = save $164 to $192/month

Cluster: 2x m5.large on-demand + 6x m5.large Spot

$138 + $126 to $168 = $264 to $306/month

vs $552/month all on-demand = save $246 to $288/month

Cluster Autoscaler

Works with pre-defined managed node groups. Spot configuration requires setting up separate Spot node groups in EKS. Scale decisions happen at the node group level. When a Spot Instance is reclaimed, Cluster Autoscaler requests a replacement from the same node group. Simpler to configure. Works well with EKS Managed Node Groups.

Best for: teams already running Cluster Autoscaler who want to add Spot without migrating to a new autoscaler.

Karpenter

Provisions individual EC2 instances rather than scaling node groups. Karpenter selects the cheapest available instance type from a configured list that fits the pending pod requirements. Automatically tries multiple instance types and AZs when one Spot pool is unavailable. Significantly faster provisioning (30 to 60 seconds vs 2 to 3 minutes for Cluster Autoscaler).

Best for: new EKS setups and teams who want maximum Spot savings with the fastest interruption recovery.