Containers: Stop Overprovisioning, Start Saving with Spot and Serverless

Imagine you're running a containerized microservices app on Kubernetes. Your cluster hums along at 20% CPU utilization, but you're paying for a fleet of always-on VMs because you're afraid of evictions. That fear is costing you real money. The cloud is a marketplace of discounts and trade-offs, and containers are the perfect vehicle to ride them. The truth is, most teams overprovision and overpay. It's time to stop treating every workload like a pet and start treating them like cattle.

Is Kubernetes really the standard for containers?

Yes, and the data backs it up. The CNCF's 2025 survey found that 82% of container users run Kubernetes in production, up from 66% in 2023 (CNCF Annual Cloud Native Survey). That's a massive jump. If you're not on Kubernetes yet, you're in the minority. But running Kubernetes doesn't have to mean running a bunch of always-on nodes. Managed services like Amazon EKS or AKS handle the control plane, and you can use Fargate or virtual nodes to avoid managing the data plane entirely. The key is to stop thinking of Kubernetes as a cluster of VMs and start thinking of it as a scheduling layer for whatever compute you want to use.

What's the cheapest way to run containers?

Spot Instances, hands down. On AWS, Spot Instances give you up to 90% off On-Demand prices for spare capacity (AWS EC2 Spot). Azure Spot VMs offer similar savings, and Google Cloud Spot VMs are up to 91% cheaper with a guaranteed 60% minimum discount (Google Cloud Spot VMs). That's not a typo. If you have fault-tolerant, stateless workloads—and most containerized apps are—you're leaving money on the table by not using Spot. For example, a t3.micro On-Demand costs $0.0104/hour (AWS EC2 Price List API). At 90% off, that's a tenth of a cent per hour. Run a hundred of those for a month and you've saved hundreds of dollars. The catch? They can be interrupted with a two-minute warning on AWS (AWS Documentation) and 30 seconds on Azure (Azure Spot VMs). But that's fine if your containers are designed to die gracefully and restart elsewhere.

Isn't Spot too risky for production?

That's the myth. Spot is not for batch jobs only. It's perfect for production if you design for it. Use a mix of Spot and On-Demand, or Spot and Savings Plans. Kubernetes can handle evictions gracefully—that's what pod disruption budgets are for. The CNCF survey shows 82% of container users run Kubernetes in production, and many of them use Spot for a significant portion of their cluster. The risk is manageable. You just need to spread your Spot instances across multiple availability zones and have a fallback. AWS even recommends Spot for containerized workloads, CI/CD, and web servers (AWS EC2 Spot). So, don't be afraid. Start with a small percentage of your cluster on Spot and scale up as you gain confidence.

Is serverless the future of containers?

For some workloads, yes. AWS Fargate is a serverless compute engine for containers that removes the need to manage servers (AWS Fargate). You define your task, and Fargate runs it, scaling up to 16 vCPU and 120 GB of memory per task (AWS Fargate). No nodes, no patching, no cluster management. You pay per second. For spiky or unpredictable workloads, Fargate can be cheaper than running a cluster that sits idle. But for steady, predictable loads, a Savings Plan or Reserved Instance can be cheaper. It's not either/or. You can run a mixed cluster with Fargate for the spiky stuff and regular EC2 for the baseline. The point is to match the compute to the workload, not the other way around.

How do I stop overpaying for underutilized resources?

Stop guessing and start measuring. AWS Compute Optimizer analyzes your usage and recommends rightsizing, detects idle resources, and even identifies workloads that would benefit from Graviton (AWS Compute Optimizer). Graviton instances cost up to 20% less than comparable x86 instances (AWS Graviton). That's a no-brainer if you're running x86 today. Also, look at your utilization. If your CPU is below 10% for most of the day, you're overprovisioned. Use a tool like Compute Optimizer or just look at your metrics. Then, downsize or move to burstable instances like T3 (AWS EC2 T3) or Azure B-series (Azure B-series CPU Credit Model). These are designed for low baseline CPU with occasional bursts. They're cheap and perfect for many containerized services. You don't need a c7i.48xlarge to run a webhook.

What about Committed Use Discounts and Savings Plans?

They're worth it if you have steady, predictable workloads. AWS Savings Plans offer up to 72% off On-Demand (AWS Savings Plans). Azure Savings Plan is similar, with a 1-year or 3-year commitment (Azure Savings Plan). Google Cloud Committed Use Discounts let you commit to vCPUs and memory for 1 or 3 years (Google Cloud Committed Use Discounts). These are great for your baseline load. But don't buy a Savings Plan for workloads that are spiky or temporary. Combine them with Spot for the rest. For example, if you have a baseline of 10 m5.large instances running 24/7, a Savings Plan will cut your bill dramatically. The m5.large On-Demand is $0.096/hour (AWS EC2 Price List API). At 72% off, that's $0.027/hour. Over a year, that's a big saving. Just be careful: Savings Plans are commitments, and if you don't use them, you lose the money.

How do I choose between ECS and EKS?

It depends on your team's skills. ECS is simpler and fully managed—you don't have to manage a control plane (AWS ECS). EKS is managed Kubernetes, but you still have to deal with the Kubernetes ecosystem (AWS EKS). If you're already using Kubernetes, stick with EKS. If you're starting fresh and don't need Kubernetes' portability, ECS is easier. But remember, Kubernetes is the de facto standard (CNCF Annual Cloud Native Survey). If you might want to move to another cloud or on-premises, EKS is safer. And with EKS, you can use Fargate to run pods without managing nodes. That's a sweet spot. But don't let the tooling dictate your architecture. Start with what you know and grow.

Quick tip: Use Spot Instances for stateless, fault-tolerant workloads, and always have a fallback. Test your application's behavior under eviction before you rely on Spot in production.

Takeaway

Containers give you the flexibility to mix and match compute options. Stop paying full price for everything. Use Spot for the flexible, interruptible parts of your workload. Use Savings Plans or Reserved Instances for the baseline. Use serverless for the spiky bits. And always rightsize. The cloud is not a one-size-fits-all. It's a menu of discounts, and you should order accordingly.

Sources

• 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/
• AWS EC2 Spot - https://aws.amazon.com/ec2/spot/
• Google Cloud Spot VMs - https://cloud.google.com/compute/docs/instances/spot
• AWS EC2 Price List API - https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.json
• AWS Compute Optimizer - https://aws.amazon.com/compute-optimizer/
• AWS Savings Plans - https://aws.amazon.com/savingsplans/