FinOps: Cloud Exchange - Safely Using Spot Instances in Kubernetes

Imagine getting the same computing power for 70% to 90% less cost. The catch? The cloud provider can take the server away from you at any time with just two minutes’ notice (AWS) or even just 30 seconds (Azure).

What is a nightmare for traditional servers is a huge opportunity for Kubernetes workloads. Since Kubernetes is fundamentally designed for pods to die and be reborn elsewhere, Spot Instances (or “Preemptible VMs”) are the perfect partner for a cost-effective cloud strategy in 2026.

The Principle: Clearance Rack of the Cloud Giants

Cloud providers like AWS, Google, and Azure maintain massive capacities to handle peak loads. These unused resources are auctioned off as Spot Instances on the “exchange.” Once a full-paying customer needs the capacity, the Spot Instance is terminated.

Which Workloads are Suitable for Spot?

Not every application should run on an instance that can suddenly disappear.

• Perfectly suitable: Stateless microservices, CI/CD runners, batch processing, AI training, rendering jobs.
• Conditionally suitable: Highly available web frontends (with sufficiently high replication).
• Not suitable: Databases (without replication), legacy monoliths with long startup times, single-node applications.

The Secret Weapon: Intelligent Orchestration with Karpenter

Managing Spot Instances used to be cumbersome. You had to install “Spot Termination Handlers” and hope the cluster reacted in time. Today, Karpenter (the modern node provisioner) takes over this task.

Karpenter understands the market:

1. Diversification: It doesn’t just choose one instance type but spreads across different sizes and families to minimize the risk of mass termination.
2. Proactive Action: It receives termination signals from the provider and immediately initiates the “draining” (controlled evacuation) of the node while simultaneously procuring replacements.
3. Cost Optimization: Karpenter calculates in real-time which combination of Spot Instances is currently the most cost-effective to host your current pods.

[Image showing Karpenter replacing a terminating Spot instance with a new one before the workload is affected]

Strategy: The “Mixed-Instance” Approach

For business-critical environments in the mid-market, we rarely recommend a pure Spot strategy. The safest way is the mix:

• Base Capacity (On-Demand): A small part of your cluster runs on stable On-Demand instances (possibly further discounted through Savings Plans or Reserved Instances). This is where the absolutely critical services reside.
• Burst Capacity (Spot): Everything beyond that or working asynchronously is offloaded to Spot Instances.

With Kubernetes features like Node Affinity and Taints/Tolerations, we can precisely control which app lands on which “grade” of hardware.

Conclusion: He Who Dares, Wins (in Margin)

Spot Instances are not a risk but an architectural decision. If your system is built “Cloud-Native”—meaning it has short startup times and operates statelessly—you are leaving money on the table every month if you don’t utilize Spot capacities. With modern tools like Karpenter, the risk is lower today than ever, while the financial leverage remains enormous.

Technical FAQ: Spot Instances

What happens if an entire instance class (e.g., all c5.large) is sold out in the data center? This is the biggest risk. In this case, the cluster can no longer scale on Spot Instances. A good provisioner (like Karpenter) then automatically switches to more expensive On-Demand instances (fallback) to save availability—and returns to Spot as soon as they are available again.

How does my monitoring software react to constant restarts? If you use many Spot Instances, your cluster becomes more dynamic. Your monitoring solution (e.g., Prometheus/Grafana) must be able to handle nodes coming and going. “Flapping Alerts” should be disabled or adjusted for Spot nodes.

Do I need to adjust my code for Spot Instances? Not directly, but the application must be able to handle a SIGTERM signal cleanly (graceful shutdown). It has only 30-120 seconds to complete ongoing transactions before the process is forcibly terminated.