Containers Are Not Cheaper: How to Stop Overpaying for EKS and Fargate

Why is my container bill so high?

You're paying for the control plane, the nodes, and the premium for managed services. Amazon EKS cluster management is free (Azure AKS is too), but you still pay for the worker nodes and any add-ons. And if you're using Fargate, you're paying a premium for serverless convenience—Fargate pricing is per vCPU and memory, and it's not cheap. The real cost driver is usually over-provisioning: spinning up beefy instances 'just in case' and leaving them running 24/7. We've all done it. But the fix isn't to abandon containers—it's to get smart about what you run where.

Is Fargate actually cost-effective?

Fargate is great for bursty, unpredictable workloads—you pay per second and scale to zero. But for steady-state services, it's usually more expensive than running EC2 instances. Compare: a t3.micro On-Demand costs $0.0104/hour (AWS EC2 Price List API). Fargate's smallest configuration (0.25 vCPU, 0.5 GB) costs roughly $0.011 per hour plus memory—so you're paying more for less compute. And if you need 16 vCPU and 120 GB per task (Fargate's max), you're paying a hefty premium. The catch is that Fargate pricing is per-second, which is great for spiky workloads, but for a web server running 24/7, EC2 wins. We recommend Fargate only for truly event-driven, short-lived tasks—otherwise, use EC2 and eat the management overhead.

Should I run Kubernetes at all?

Kubernetes is a tool, not a goal. If you have a handful of services, EKS is overkill—you're paying for control plane management (even though the API server is free, the nodes aren't) and adding operational complexity. But if you're running dozens of microservices, Kubernetes gives you auto-scaling, self-healing, and portability. The key is to use managed Kubernetes (EKS or AKS) and not run your own control plane—you'll save hours of toil. But don't think managed = cheap. You still pay for nodes, and you need to right-size them. EKS cluster management may be free (AWS EKS), but the nodes are on your dime. So use Kubernetes when you need it, not because it's trendy.

What's the biggest cost myth about containers?

That containers are inherently cheaper than VMs. They're not. Containers are just isolated processes—they share the host kernel, so you can pack more onto a single VM, but you still pay for the VM. The savings come from density: if you can fit 10 containers on one m5.large instead of 10 separate VMs, you win. But if you run one container per VM, you're paying the same as VM pricing. And if you use Fargate, you're paying a premium for the convenience. The real myth is that serverless containers are cheap—they're not. The only way to save is to use Spot instances for fault-tolerant workloads. Spot can be up to 90% off On-Demand (AWS EC2 Spot). That's where the money is.

How do I right-size container nodes?

Start with metrics. Use CloudWatch or Prometheus to see actual CPU and memory utilization. If your nodes are pegged at 5% CPU, you're over-provisioned. Downsize. For general-purpose workloads, Graviton instances are a no-brainer: they cost up to 20% less than comparable x86 instances (AWS Graviton) and use up to 60% less energy. For example, m7g.large (Graviton3) is $0.0816/hour vs m7i.large (x86) at $0.1008/hour (AWS EC2 Price List API). That's a 19% savings on every node. And if you have bursty CPU, use T3 instances—they accumulate CPU credits when idle (AWS EC2 T3). But don't use them for sustained high CPU. The key is to pick the right instance family for your workload, not just the cheapest.

• Use Spot for stateless, fault-tolerant container workloads—big data, CI/CD, web servers (AWS EC2 Spot).
• Use Savings Plans for steady-state nodes—you can save up to 66% with Compute Savings Plans (AWS Documentation).
• Use On-Demand only for unpredictable, critical workloads—it's the most expensive (AWS Documentation).

Should I use Spot for containers?

Absolutely, but design for it. Spot instances can be interrupted with a two-minute warning (AWS Documentation), so your containers must handle eviction gracefully. That's easier with Kubernetes—use PodDisruptionBudgets and node selectors to spread workloads. For CI/CD, big data, and stateless web servers, Spot is perfect. You can save up to 90% (AWS EC2 Spot). But for stateful databases, don't even think about it. The trick is to mix: run critical pods on On-Demand or Savings Plans, and run the rest on Spot. Tools like Karpenter or cluster-autoscaler can manage this automatically. We've seen teams cut their container costs by 70% just by moving to Spot and right-sizing.

Is there a free tier for containers?

Yes, but it's limited. AWS Free Tier gives you 750 hours of t3.micro per month for 12 months (AWS Free Tier). That's enough for a small test cluster. Azure Container Apps has an always-free tier of 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests per month (Azure Free Account). And Google Cloud Functions gives you 2 million invocations free (Google Cloud Functions Pricing). But these free tiers are for serverless functions, not containers. For containers, you're on your own. So if you're prototyping, use the free tiers, but for production, budget for the real costs.

Sources

• 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
• AWS Graviton - https://aws.amazon.com/ec2/graviton/
• AWS Fargate - https://aws.amazon.com/fargate/
• Azure Free Account - https://azure.microsoft.com/en-us/free/