AutoSpotting vs Karpenter for Spot on Kubernetes

Different layers, different jobs

Karpenter is an open-source Kubernetes node provisioner. It watches for pending pods and launches right-sized nodes to fit them, it can request Spot capacity directly, and it consolidates nodes as workloads change. If you want a Kubernetes-native provisioner and you are moving off Cluster Autoscaler, Karpenter is a strong, widely used choice.

AutoSpotting works one layer down, at the EC2 AutoScaling group. It converts the capacity of groups you already run to Spot, diversifies across compatible instance types, and falls back to on-demand automatically when Spot runs short. It is not a Kubernetes provisioner; it works with any service backed by an AutoScaling group. That includes EKS managed node groups and self-managed Kubernetes node pools, and also ECS, Elastic Beanstalk, and plain AutoScaling groups. So the comparison is not really either-or: the two operate at different layers and often suit different parts of the same estate.

Where Karpenter fits

Karpenter is the right tool when you want a Kubernetes-native provisioner in charge of your nodes. It shines when you are replacing Cluster Autoscaler, when you want nodes sized and consolidated in response to pending pods, and when your team is ready to define and operate NodePools as part of how the cluster runs. It requests Spot directly, and you can mix Spot and on-demand through NodePool configuration. If Kubernetes is your whole world and you want provisioning to live inside the cluster, Karpenter is a natural home for that.

Where AutoSpotting fits

AutoSpotting is the right tool when you do not want to replace your node provisioner. If your EKS or self-managed clusters run on managed node groups or self-managed AutoScaling groups that you are happy with, AutoSpotting brings Spot to that existing capacity with automatic on-demand fallback, by adding a tag. There is no new provisioning model to adopt and operate.

It also fits when Kubernetes is only part of the picture. Because it works at the AutoScaling group layer, the same tag on the same kind of group also covers ECS, Elastic Beanstalk, and plain AutoScaling groups. One team can use one approach for Spot across Kubernetes and non-Kubernetes workloads alike, instead of one tool for clusters and something else for everything else. Everything runs inside your own AWS account, with no SaaS backend and no cross-account access.

A note on reduced capacity

One behavior worth understanding across all of these options is what happens when Spot runs out. EKS managed node groups running Spot, and the native Auto Scaling group Spot integration in general, do not fall back to on-demand once Spot is exhausted across all configured instance types. They launch fewer nodes, so the cluster silently drops to reduced capacity until Spot frees up, often during high-demand periods such as the end-of-year holiday season. AutoSpotting fails over to on-demand automatically at the AutoScaling group layer, so the group keeps full capacity. With Karpenter, on-demand fallback depends on how you configure your NodePools and weights, so it is a setting to get right rather than an automatic default.

Using both

These are not mutually exclusive. Karpenter can run the clusters where you want a native provisioner, while AutoSpotting brings Spot with automatic on-demand fallback to the AutoScaling groups behind your other clusters and your non-Kubernetes services. Pick per workload rather than treating it as a single all-or-nothing decision. For a deeper look at Spot on containers, including ECS draining, see our guide to running Spot on Kubernetes and ECS.