Containers on EKS: Busting the Managed Kubernetes Cost Myth

Imagine you're a platform engineer at a mid-sized SaaS company. Your CEO just read an article claiming that managed Kubernetes is a budget killer, and now you're in a meeting defending your EKS bill. You've got a cluster running 30 nodes, and the finance team is asking why you're paying so much for "just a control plane." You know the answer isn't simple—it's about instance types, purchase options, and how you've architected for scale. But how do you explain that to someone who thinks containers should be free?

We've all been there. The container conversation inevitably turns to cost, and too often the default assumption is that managed Kubernetes is a luxury you can't afford. But that's a myth. The real cost of running containers on AWS isn't the EKS control plane fee—it's how you choose and pay for the underlying compute. Let's bust that myth and look at what actually moves the needle.

Is EKS really that expensive?

Let's start with the obvious: EKS itself has a management cost. But here's the thing—the EKS control plane fee is a fixed hourly charge per cluster, and it's not the dominant line item on your bill. The real money goes to the worker nodes. And those nodes have a pricing model that's far more nuanced than "pay per hour." You can run EKS on On-Demand instances, but that's the priciest way to go. If you commit to a Savings Plan, you can cut compute costs by up to 66% with Compute Savings Plans or up to 72% with EC2 Instance Savings Plans (AWS Documentation). That's a massive lever. So, when someone says "EKS is expensive," they're usually ignoring the fact that you can run the same Kubernetes workloads on the same EC2 instances at a fraction of the cost—if you're willing to commit.

But wait, there's more. The type of instance you choose matters just as much as the purchase model. AWS Graviton instances, for example, cost up to 20% less than comparable x86 instances (AWS Graviton). And Graviton isn't some niche, experimental chip anymore—Graviton5 has 192 cores and a 5x larger cache, making it a serious contender for production workloads, including AI inference (AWS Graviton). Switching your EKS nodes from x86 to Graviton could be the single biggest cost saver you haven't implemented yet.

Doesn't Fargate cost more than EC2?

This is another myth we hear constantly. The assumption is that Fargate, being serverless, must be more expensive. But that's not necessarily true. Fargate is a pay-as-you-go compute engine for containers that scales up to 16 vCPU and 120 GB of memory per task (AWS Fargate). It eliminates the need to manage servers, which means you also eliminate the overhead of patching, capacity planning, and idle nodes. When you run EKS on EC2, you're paying for a node 24/7, even if your pods only use 10% of its CPU. With Fargate, you pay only for the vCPU and memory your containers actually request, per second. For spiky or unpredictable workloads, Fargate can be significantly cheaper than running a fleet of underutilized EC2 nodes.

Now, I'm not saying Fargate is always the answer. For a steady, high-utilization workload, a well-architected EC2 node group with a Savings Plan will usually be cheaper. But the myth that "Fargate is always more expensive" is just wrong. It depends on your workload patterns. We've seen customers cut their compute bill by 30% just by moving from an always-on EC2 node group to Fargate for their dev and test environments, where utilization is low and unpredictable.

Can I use Spot Instances for containers?

Yes, and you absolutely should. Spot Instances use spare AWS capacity at up to a 90% discount compared to On-Demand (AWS EC2 Spot). That's a huge saving potential. The catch is that Spot can be interrupted with a two-minute warning, but Kubernetes is designed to handle that. You can run stateless workloads, CI/CD pipelines, and even web servers on Spot. The key is to use Spot for workloads that are fault-tolerant or can be restarted. With EKS, you can mix Spot and On-Demand nodes in the same cluster, using Spot for the bulk of your work and On-Demand for critical, stateful components.

Let's put some numbers on this. Say you're running a cluster of m5.large instances (2 vCPU, 8 GiB) in us-east-1. On-Demand, that's $0.096/hour each (AWS EC2 Price List API). If you use Spot, you might pay as little as $0.0096/hour—a 90% reduction. Even if you only get 70% savings on average, that's still a massive cut. For a batch processing job that runs for a few hours a day, Spot is a no-brainer. And with Kubernetes' native support for node selectors and pod disruption budgets, you can make Spot work without sacrificing reliability.

Is the free tier really free?

Ah, the classic trap. Everyone loves a free tier, but you need to read the fine print. AWS offers up to $200 in credits and access to over 90 services for up to 6 months, plus more than 30 services that are always free within monthly usage limits (AWS Free Tier). That's great for experimenting, but the moment you run a production workload, you'll blow through those limits. The trick is to use the free tier strategically—for dev/test, for learning, or for small personal projects. Don't try to run a production EKS cluster on the free tier; you'll get a surprise bill.

But here's a concrete example of how the free tier can be useful: you can run a t3.micro instance (2 vCPU, 1 GiB) for free for up to 750 hours per month, which is perfect for a small development environment. That's $0.0104/hour if you had to pay for it (AWS EC2 Price List API). Over a month, that's about $7.50 saved. Not huge, but it's enough to run a single-node Kubernetes cluster for testing. Just remember that the free tier is a tool, not a solution. When you're ready to scale, you need to move to a proper compute plan.

What's the real cost difference between Graviton and x86?

We touched on this earlier, but let's dig deeper. The myth is that ARM-based instances like Graviton are less performant or incompatible with your existing container images. That was true a few years ago, but now most images are multi-arch. The reality is that Graviton instances can save you up to 20% on compute costs (AWS Graviton) and use up to 60% less energy (AWS Graviton). For a large cluster, that 20% is significant. Let's compare apples to apples: m7g.large (Graviton3) costs $0.0816/hour, while m7i.large (x86) costs $0.1008/hour (AWS EC2 Price List API). That's a 19% savings right off the bat, with no performance penalty for most workloads.

And it's not just about the sticker price. Graviton instances also tend to have better price-performance for compute-intensive tasks. If you're running a high-throughput web service or a data processing job, you might find that Graviton can handle the same load with fewer instances, saving you even more. The bottom line: if you're not at least testing Graviton for your EKS nodes, you're leaving money on the table.

So, what's the single most important thing to remember? Containers on AWS are not inherently expensive—the cost is driven by the compute you choose and how you pay for it. Stop thinking of EKS as a premium service and start thinking of it as a way to run Kubernetes more efficiently. Use Savings Plans, mix in Spot, and seriously consider Graviton. That's how you keep your container bill under control.

Sources

• AWS Documentation - https://docs.aws.amazon.com/ec2/
• AWS EC2 Spot - https://aws.amazon.com/ec2/spot/
• AWS Graviton - https://aws.amazon.com/ec2/graviton/
• AWS EC2 Price List API - https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.json
• AWS Fargate - https://aws.amazon.com/fargate/
• AWS Free Tier - https://aws.amazon.com/free/