Containers: Should You Run Them on VMs, Fargate, or Kubernetes?

What's the best way to run containers in the cloud? You've got VMs, Fargate, Kubernetes, and a dozen other options. Here's the short version: for most teams, a managed serverless container service like AWS Fargate is the right default. Reach for Kubernetes only when you've outgrown it. And stop running containers on raw VMs unless you have a specific reason.

I once watched a startup burn $14,000 in a month on a Kubernetes cluster that was running three services. They had maybe 200 daily active users. They didn't need Kubernetes; they needed to ship features. That's the trap: we pick tools for the resume, not the workload.

What's the difference between containers on VMs, Fargate, and Kubernetes?

They're three points on a spectrum of control versus convenience. On VMs, you manage everything: the OS, the container runtime, scaling, patching. Fargate is serverless compute for containers—you define CPU and memory, and AWS handles the rest. It scales up to 16 vCPU and 120 GB of memory per task and runs with Amazon ECS or Amazon EKS (AWS Fargate). Kubernetes, via Amazon EKS, gives you a managed control plane but leaves node management to you (AWS EKS).

Think of it this way: VMs are like owning a house—you fix the plumbing. Fargate is a hotel—you show up, everything works. Kubernetes is a co-op—you get shared infrastructure but still have to manage the building.

Is Kubernetes overkill for most container workloads?

Often, yes. Kubernetes is powerful, but it's not free. You pay for the control plane and the nodes, and you pay in operational complexity. The CNCF 2025 Annual Cloud Native Survey found that 82% of container users run Kubernetes in production, up from 66% in 2023. That's a huge jump, but adoption doesn't mean it's the right first step.

If you're running a handful of services, ECS with Fargate will get you to production faster. Kubernetes shines when you need portability across clouds, a rich ecosystem of operators, or you're already standardized on it.

And here's a number that might surprise you: a single EKS cluster with three m5.large nodes costs about $450 a month on-demand—before you add the control plane fee, data transfer, or the engineer you'll need to manage it. That same workload on Fargate might cost $200 and zero management time.

Can I just run containers on EC2 instances and save money?

You can, but the savings are usually an illusion. Yes, the raw compute is cheaper. But you're now responsible for patching, scaling, and capacity planning. And you'll likely overprovision.

The better move: use Spot Instances for stateless container workloads. They're up to 90% off On-Demand (AWS EC2 Spot). Combine that with a managed orchestrator like ECS, and you get low cost without the VM babysitting. But if you're running steady-state workloads, Savings Plans can cut compute costs by up to 72% (AWS Savings Plans)—often a better fit than Spot for predictable services.

One caveat: Spot Instances can be reclaimed with two minutes' notice. If your container can't handle a sudden shutdown, you'll need to architect for it—or stick with Savings Plans.

Which is cheaper: Fargate or Kubernetes on EC2?

It depends on utilization. Fargate pricing is per-second for the vCPU and memory you request, with no upfront commitment. Kubernetes on EC2 means you pay for nodes, whether they're full or not.

For spiky or low-utilization workloads, Fargate wins because you only pay for what you use. For high, steady utilization, EC2 with Savings Plans or Spot can be cheaper. Here's a quick comparison:

Don't forget the free tiers. AWS Free Plan gives you $200 in credits and access to over 90 services for up to 6 months (AWS Free Tier). Azure's free account includes $200 credit for 30 days plus 65+ always-free services (Azure Free Account). Google gives new customers $300 in credits for 90 days (Google Cloud Functions Pricing). Use these to test before you commit.

What's the biggest myth about containers?

That containers are inherently cheaper than VMs. They're not. Containers are a packaging and isolation mechanism, not a cost-saving one. The cost savings come from density and orchestration efficiency—if you use them well. A poorly configured Kubernetes cluster can easily cost more than a few well-utilized VMs.

And here's another one: people think you don't need capacity planning with containers. Not true. You still have to set CPU and memory requests and limits, and you still pay for what you reserve. Kubernetes isn't automatically more scalable either—ECS with Fargate scales just fine. Serverless containers aren't just for toy apps; Fargate supports up to 16 vCPU and 120 GB per task, which is plenty for many production services.

The real win is operational: faster deploys, better resource utilization, and portability. But you have to manage it.

What's the one thing to remember?

Match the tool to the workload. Start with a managed serverless container service like Fargate. Move to Kubernetes when you have a clear need—multi-cloud, complex scheduling, or a large team already fluent in it. And always optimize with Spot or Savings Plans once your usage is predictable. That's the straight path to cost-effective containers.

Sources

• AWS Fargate - https://aws.amazon.com/fargate/
• AWS EKS - https://aws.amazon.com/eks/
• 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/
• AWS Savings Plans - https://aws.amazon.com/savingsplans/
• AWS Free Tier - https://aws.amazon.com/free/
• Azure Free Account - https://azure.microsoft.com/en-us/free/
• Google Cloud Functions Pricing - https://www.srvrlss.io/provider/google-cloud-functions/