The question nobody asks correctly
When engineers ask "which is cheapest — EC2, ECS, or EKS?", they're usually only thinking about the AWS bill. That's the wrong frame. The real cost has three parts:
- Infrastructure cost — what AWS charges
- Operational cost — the engineering hours to run it
- Opportunity cost — the features you don't build while managing infrastructure
EKS looks expensive on the AWS bill. EC2 looks cheap. But once you factor in engineering hours, the ranking often flips. Here's the honest breakdown.
What each one actually is
EC2 — raw virtual machines. You provision instances, SSH in, install software, manage everything yourself. Maximum control, maximum responsibility.
ECS (Elastic Container Service) — AWS-managed container orchestrator. You define tasks (containers) and services (how many replicas, how to update them). Two launch modes: EC2 (you manage the nodes) and Fargate (AWS manages the nodes).
EKS (Elastic Kubernetes Service) — AWS-managed Kubernetes control plane. You run standard Kubernetes on top of EC2 or Fargate. Full Kubernetes API, maximum portability, steepest learning curve.
Infrastructure cost breakdown
Let's compare running a typical production workload: 3 services, ~10 replicas each, in us-east-1.
EC2 (self-managed)
You'd provision a few instances and run your services directly or with Docker Compose:
| Resource | Spec | Monthly |
|---|---|---|
| 3× m5.xlarge (4 vCPU, 16 GB) | On-demand | $414 |
| Application Load Balancer | 1 ALB | $22 |
| Data transfer | ~100 GB | $9 |
| Total | ~$445/month |
With Reserved Instances (1-year, no upfront), the same setup costs around $280/month.
ECS on Fargate
Fargate bills per vCPU-hour and GB-hour of memory consumed by your tasks. No node management.
Assume 30 tasks total (10 per service), each at 0.5 vCPU and 1 GB:
| Resource | Calculation | Monthly |
|---|---|---|
| Compute (15 vCPU × 730 hr) | $0.04048/vCPU-hr | $443 |
| Memory (30 GB × 730 hr) | $0.004445/GB-hr | $97 |
| Application Load Balancer | 1 ALB | $22 |
| Total | ~$562/month |
No control plane charge. ECS itself is free.
ECS on EC2 (self-managed nodes)
Same as Fargate but you manage the EC2 nodes. You recover the Fargate markup (~30%) by over-provisioning less carefully:
| Resource | Monthly |
|---|---|
| 2× m5.xlarge nodes (with ~70% utilization) | $276 |
| ALB | $22 |
| Total | ~$298/month |
EKS
EKS charges $0.10/hour per cluster — that's $73/month just for the control plane, regardless of what runs on it. Nodes are standard EC2:
| Resource | Monthly |
|---|---|
| EKS control plane | $73 |
| 3× m5.large nodes (Karpenter-managed) | $207 |
| ALB (via AWS Load Balancer Controller) | $22 |
| Total | ~$302/month |
With Karpenter and Spot instances, the node cost drops to roughly $70–90, bringing EKS total to around $160–180/month — cheaper than anything else.
Side-by-side summary
| Option | Baseline monthly | With savings (Reserved/Spot) |
|---|---|---|
| EC2 (raw) | $445 | $280 |
| ECS Fargate | $562 | $420 (Savings Plans) |
| ECS on EC2 | $298 | $190 |
| EKS + Spot (Karpenter) | $302 | $160 |
On infrastructure cost alone, EKS with Karpenter and Spot wins. But this ignores everything else.
The hidden cost: engineering hours
This is where the real difference lies. Assume a senior engineer costs $150/hour fully loaded.
EC2 (bare)
Running production services on raw EC2 means you own: OS patching, disk management, process supervision (systemd, Docker), log rotation, health checks, rolling deploys, and capacity planning. A single engineer spending 10 hours/month on this is $1,500 in operational cost — more than the entire AWS bill.
Operational overhead: High. Suitable only if your team has deep Linux ops experience and low deployment frequency.
ECS
ECS removes the "how do I run containers reliably" problem. AWS handles scheduling, health checks, and rolling updates. With Fargate, you also eliminate node management entirely.
The main overhead is ECS-specific knowledge: task definitions, service configuration, IAM task roles, and service discovery. It's AWS-specific — skills that don't transfer to other environments.
Operational overhead: Low–Medium. Fargate is the lowest overhead AWS option for teams that don't need Kubernetes.
EKS
EKS has the highest learning curve. You need engineers who understand Kubernetes — pods, deployments, services, ingress, RBAC, namespaces, PVCs. Getting to production takes longer upfront.
But once the platform is built, it pays dividends: self-service deployments, Helm charts, GitOps with ArgoCD, HPA, Karpenter autoscaling. A well-built EKS platform reduces per-deployment engineering time to near zero.
Operational overhead: High upfront, low long-term. The crossover point is typically around 5–8 services.
Which should you choose?
Choose EC2 if:
- You have 1–2 services and a very small team
- Your workload doesn't containerize well (legacy app, specific OS dependencies)
- You want maximum control over the environment
- You're running stateful workloads like databases (use RDS instead, but if you must)
Choose ECS (Fargate) if:
- You want the simplest possible path to running containers on AWS
- Your team is small (2–5 engineers) and doesn't want to learn Kubernetes
- You have 2–8 services with predictable traffic
- You're already deep in the AWS ecosystem and don't need cloud portability
Choose EKS if:
- You have 5+ services or expect to
- You want GitOps, Helm, and the broader Kubernetes ecosystem
- Your team already knows Kubernetes or you're willing to invest in learning it
- Cost efficiency at scale matters (Karpenter + Spot can halve your compute bill)
- You might need to run on GKE or AKS in the future (portability matters)
The real answer
For a team of 1–3 engineers with fewer than 5 services: ECS Fargate. Zero node management, AWS handles everything, simple mental model.
For a team of 4+ engineers with 5+ services: EKS. The upfront investment pays off quickly in operational efficiency and cost savings. Karpenter + Spot on EKS is routinely 40–60% cheaper than equivalent Fargate at the same scale.
EC2 bare metal: rarely the right answer for application workloads in 2026. You're trading engineering hours for a slightly lower AWS bill. The math rarely works out.
The cheapest option isn't the one with the lowest AWS bill — it's the one that best matches your team's skills and scale, minimises operational overhead, and doesn't require you to rebuild your platform in 18 months.