Skip to main content
Containers

ECS Fargate vs EKS on EC2: The Container Bill Nobody Warns You About

The common advice to default to Kubernetes for every container workload is wrong. Here's how ECS Fargate and EKS on EC2 really compare on cost, control, and ops overhead.

You have been told that Kubernetes is the default answer for containers, that anything less is amateur hour. That advice is wrong, and it costs teams real money every month. According to the CNCF 2025 Annual Cloud Native Survey, 82% of container users now run Kubernetes in production, which sounds like proof the crowd is right. It is not. That number tells you Kubernetes won the orchestration war, not that it is the correct tool for your twelve-service API. The real decision is narrower: do you pay a control-plane tax in engineering time, or a per-task tax in dollars? Let's compare the two paths that actually matter on AWS.

The contenders: ECS Fargate and EKS on EC2

First, the honest framing. Amazon ECS is a fully managed container service for building, managing, and running containerized applications at any scale, and ECS Anywhere even extends that same experience to your own on-premises or edge infrastructure. Amazon EKS is a managed Kubernetes service for building, running, and scaling production-ready Kubernetes apps across cloud, on-premises, and edge, with cluster infrastructure management automated. Both can run on Fargate, the serverless pay-as-you-go engine that scales to 16 vCPU and 120 GB of memory per task. The split I care about is ECS Fargate versus EKS where you manage the EC2 nodes underneath. That is where the bill diverges.

If you want a blunt rule: pick ECS Fargate unless you have a specific, named reason to need Kubernetes. "We might need it later" is not a reason. "Our platform team already runs three EKS clusters and has the tooling" is.

Cost: per-task pricing versus node math

Fargate is priced per task based on vCPU and memory, so your bill tracks your workload almost exactly. No idle nodes, no capacity planning, no paying for a 16-vCPU node that runs at 20% utilization because someone was afraid of a traffic spike. The trade is that Fargate's per-unit rates are higher than raw EC2, and you lose access to the discount machinery that makes EC2 cheap at scale.

That machinery is substantial. Spot Instances use spare AWS capacity at up to 90% off On-Demand and explicitly suit stateless, fault-tolerant, and flexible workloads including containerized workloads and CI/CD. Compute Savings Plans cut up to 66%, and EC2 Instance Savings Plans up to 72%, and Savings Plans apply automatically across instance family, Region, operating system, and tenancy. Graviton is the quieter win: Graviton-based instances cost up to 20% less than comparable x86 instances for the same performance and use up to 60% less energy.

Concrete example. Say you run a steady 40 vCPU of containerized API across a month. On m7g.large (2 vCPU, 8 GiB), the official us-east-1 Linux On-Demand rate is $0.0816/hour versus $0.1008/hour for the x86 m7i.large, a 19% gap before any commitment discount. Twenty of those Graviton nodes costs roughly $0.0816 × 20 × 730 = about $1,191/month On-Demand. Stack a 1-year Compute Savings Plan at even a 40% effective discount and you are near $715/month for the same CPU. Fargate at its per-task rates will not touch that. But here is the catch: that EC2 number assumes you actually keep 40 vCPU busy. If your real average is 15 vCPU with spikes, you are paying for 40 anyway, and Fargate's pay-per-task model wins outright.

CriteriaECS FargateEKS on EC2
Pricing modelPer-task vCPU/memory, pay-as-you-goPer-instance, second-billed; discounts available
Max discount leversNone beyond task rightsizingSpot up to 90% off, Savings Plans up to 72%
Ops overheadNo servers, no node patchingYou own node groups, upgrades, scaling
Best fitSmall teams, spiky or modest workloadsPlatform teams, steady scale, GPU or batch jobs

Control and operations: what you actually give up

Fargate's ceiling is real. Each task tops out at 16 vCPU and 120 GB of memory. That is plenty for a web service and nowhere near enough for a model-training job or a memory-hungry data pipeline. EKS on EC2 has no such ceiling: you can attach GPU instances, run DaemonSets for observability agents, mount specialized storage, and tune the kernel. If you need P5 instances with NVIDIA H100 GPUs for training, or G6 instances with fractional L4 GPUs for inference, Fargate is not the venue.

The cost of that control is operational. On EKS you own node upgrades, AMI rotation, cluster autoscaler tuning, and the security patching treadmill. That is a permanent tax paid in engineer hours, and it is the tax most teams underestimate. The CNCF survey found that 66% of organizations running generative AI workloads use Kubernetes to manage inference, which makes sense when you need GPU scheduling and custom runtimes. It makes no sense for a CRUD app.

A few things tilt the decision faster than any benchmark:

  • If your workload needs GPUs, specialized networking, or more than 16 vCPU per unit, EKS on EC2 is the only door.
  • If your team has no dedicated platform engineer, Fargate removes a job you cannot staff.
  • If your utilization is high and steady, EC2 plus Savings Plans beats Fargate on raw dollars.

One more lever worth knowing: AWS Compute Optimizer analyzes resource usage to recommend rightsizing, flag idle resources, and identify workloads that would benefit most from moving to Graviton. Run it on your ECS services and your EKS node groups before you argue about which platform is cheaper.

What I'd actually do

Start on ECS Fargate. Ship your services, measure real utilization for a quarter, and let the bill tell you the truth. If average CPU utilization across your tasks sits under roughly 40%, stay on Fargate forever and spend your engineering time on the product instead of on node groups. If utilization is consistently high, your tasks are hitting the 16 vCPU ceiling, or you need GPUs, migrate those specific workloads to EKS on EC2 and buy a Compute Savings Plan on day one, not month nine. Run Graviton where the toolchain allows, because a 20% instance discount for identical performance is the easiest money in cloud compute.

Do not adopt Kubernetes because it is popular. Adopt it because you have a workload that needs it and a team that can carry the operational load. Everything else is paying for complexity you will never use.

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 Fargate - https://aws.amazon.com/fargate/
  • AWS EC2 Spot - https://aws.amazon.com/ec2/spot/
  • AWS Savings Plans - https://aws.amazon.com/savingsplans/
  • 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

Share this article:

Comments (0)

No comments yet. Be the first to comment!