Stop Overprovisioning: Why Your Containers Need Spot, Not On-Demand

The contrarian take: On-Demand is the wrong default for containers

Every cloud provider's marketing pushes On-Demand as the safe, simple choice. For containerized workloads, that's backwards. The vast majority of container jobs—stateless APIs, batch processors, CI runners, queue consumers—are already designed to be killed and restarted. That's literally what an orchestrator does. So why are we paying full price for a guarantee we don't need?

My recommendation: default your container compute to Spot VMs, and treat On-Demand as the exception you justify, not the baseline. The savings are too large to ignore, and the operational cost of handling interruptions is smaller than most teams assume—if you architect for it from day one.

Let's be precise about what we're deciding. The question isn't "are containers good?" It's: For a stateless container workload with a Kubernetes or ECS control plane, what purchase option should you choose by default, and when should you deviate? That's the narrow question. Here's how we actually reason through it.

What you're actually buying when you pick a purchase option

Cloud compute pricing is a menu of commitments. On-Demand bills per second or hour with no upfront commitment—most flexible, most expensive for steady workloads (AWS Documentation). Savings Plans commit to a dollar amount of compute for 1 or 3 years; Compute Savings Plans offer up to 66% off, EC2 Instance Savings Plans up to 72% (AWS Documentation). Reserved Instances commit to a specific instance type and region for up to 75% savings, or up to 54% with Convertible RIs (AWS Documentation).

Then there's Spot. AWS Spot Instances use spare capacity at up to 90% off On-Demand but can be interrupted with a two-minute warning (AWS Documentation). Azure Spot VMs offer significant savings but no SLA and can be evicted with 30 seconds' notice (Azure Spot VMs). Google Cloud Spot VMs are up to 91% cheaper than standard on-demand with a guaranteed minimum 60% discount and a 30-second preemption notice (Google Cloud Spot VMs).

Notice the pattern: the bigger the discount, the shorter the eviction warning and the less control you have. That's the trade. For containers, it's usually a trade worth making.

The break-even math that changes the decision

Here's the calculation that should drive your default. Suppose you run a stateless API on 10 m5.large instances. On-Demand, that's $0.096/hour each, or $0.96/hour total (AWS EC2 Price List API). If Spot cuts that by even 70%, you're at roughly $0.29/hour. Over a month, that's real money—and for a workload that can lose an instance and recover in seconds, you've given up almost nothing.

Now the nuance: not all Spot is equal. Azure Spot VMs let you set a max price in USD with up to five decimal places (for example $0.98765 per hour); setting it to -1 prevents price-based eviction, and eviction policies are Deallocate (default) or Delete. B-series sizes are not supported for Spot (Azure Spot VMs). Google's Spot VMs have no maximum runtime, unlike legacy preemptible VMs that ran at most 24 hours (Google Cloud Spot VMs). That matters for long-running batch jobs.

If your workload can't tolerate interruption at all—think a stateful database primary or a latency-sensitive trading system—then Spot is wrong and you should use Savings Plans or Reserved Instances. But that's a minority of container workloads. The CNCF 2025 Annual Cloud Native Survey found that 82% of container users run Kubernetes in production, up from 66% in 2023, and 56% of organizations now use containers for most or all production applications (CNCF Annual Cloud Native Survey). That's a lot of workloads, and most of them are not stateful databases.

Comparison: purchase options for container compute

The table makes the case bluntly: if your container workload is stateless and fault-tolerant, Spot wins on cost by an order of magnitude. The only question is whether you've built for interruption.

How to actually run containers on Spot without pain

The operational playbook is not complicated, but it requires discipline. First, never run a single replica. Spread your pods across multiple instance types and Availability Zones. AWS EC2 Auto Scaling can combine purchase options and instance types to optimize performance and cost, and it automatically replaces unhealthy instances (AWS EC2 Auto Scaling). That's your safety net.

Second, handle the termination notice. On AWS you get two minutes; on Azure and GCP, 30 seconds. That's enough time to drain connections and checkpoint if you've written the handler. Kubernetes has had graceful node shutdown for years; use it.

Third, use the right instance families. For general-purpose container hosts, Graviton-based instances like m7g.large are $0.0816/hour versus $0.1008/hour for the x86 m7i.large—about 19% cheaper at list price (AWS EC2 Price List API). Combine that with Spot and you're stacking discounts. AWS Graviton-based instances cost up to 20% less than comparable x86 instances and use up to 60% less energy for the same performance (AWS Graviton). If your container images are multi-arch, this is free money.

Fourth, don't forget the control plane. Amazon EKS automates Kubernetes cluster infrastructure management (AWS EKS), and Azure Kubernetes Service cluster management is free—you only pay for the compute resources consumed by the AKS nodes (Azure Free Account). The control plane cost is either small or zero; your savings come from the worker nodes.

The exceptions where On-Demand still wins

We're not absolutists. There are container workloads where Spot is a bad idea:

• Stateful databases in containers. If you're running Postgres or Cassandra in Kubernetes (and some teams do), interruption means data unavailability. Use On-Demand or Reserved.
• Latency-critical services with tight SLOs. A 30-second eviction notice is an eternity when your p99 latency budget is 50ms. Pay for the guarantee.
• Workloads with licensing tied to specific hardware. If you're running server-bound software licenses, a Dedicated Host purchased On-Demand or via Savings Plans may be the only compliant option (AWS EC2 Pricing).

But notice how narrow those exceptions are. Most containerized applications—web frontends, API gateways, queue workers, CI/CD runners—fall outside them. The CNCF survey found that 66% of organizations running generative AI workloads use Kubernetes to manage inference workloads (CNCF Annual Cloud Native Survey). Inference is often stateless and can be retried; much of it is a Spot candidate.

Takeaway

Default your container compute to Spot, build for interruption from the first commit, and use Savings Plans only for the steady-state baseline you're confident you'll run 24/7. On-Demand should be a deliberate exception for stateful or latency-critical services, not the lazy default. The discount—up to 90% on AWS, up to 91% on Google Cloud—is too large to leave on the table for workloads that were designed to be killed and restarted. If your orchestrator can't handle a node disappearing, that's a bug in your architecture, not a reason to pay full price.

Sources

• AWS Documentation - https://docs.aws.amazon.com/ec2/
• AWS EC2 Spot - https://aws.amazon.com/ec2/spot/
• AWS EC2 Price List API - https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.json
• Azure Spot VMs - https://learn.microsoft.com/en-us/azure/virtual-machines/spot-vms
• Google Cloud Spot VMs - https://cloud.google.com/compute/docs/instances/spot
• CNCF Annual Cloud Native Survey - https://www.cncf.io/announcements/2026/01/20/kubernetes-established-as-the-de-facto-operating-system-for-ai-as-production-use-hits-82-in-2025-cncf-annual-cloud-native-survey/