2026-07-09 · 8 min read
EKS vs ECS vs Fargate: Choosing AWS Container Compute
A decision guide for running containers on AWS, when to pick ECS, EKS, or Fargate, the real trade-offs on control, cost, and operational burden, and how to avoid over-engineering.

EKS vs ECS vs Fargate: Choosing AWS Container Compute
"Should we use EKS?" is one of the most over-answered-with-yes questions in AWS. Kubernetes is powerful, but it's not free, in money or operational effort. Here's how I actually decide between ECS, EKS, and Fargate.
First, separate two questions
These are different choices people conflate:
- Orchestrator: ECS or EKS (Kubernetes)?
- Compute mode: EC2 (you manage nodes) or Fargate (serverless, AWS manages nodes)?
You pick one from each. "Fargate" isn't an alternative to EKS, you can run EKS on Fargate or ECS on Fargate.
ECS: the pragmatic default
Amazon ECS is AWS's own orchestrator. It's simpler, deeply integrated, and has no control-plane cost.
Choose ECS when:
- You want to run containers without learning Kubernetes.
- Your team is small and values low operational overhead.
- You're all-in on AWS and don't need portability.
Trade-off: less ecosystem (no Helm, no Operators, fewer third-party tools) and it's AWS-only.
EKS: when you need Kubernetes specifically
Amazon EKS is managed Kubernetes. You get the entire K8s ecosystem, Helm, ArgoCD, Operators, service meshes, and portability across clouds.
Choose EKS when:
- You already have Kubernetes expertise or need its ecosystem (GitOps, Operators, mesh).
- You want workload portability across clouds/on-prem.
- You're running enough services that the platform investment pays off.
Trade-off: real operational weight (upgrades, add-ons, RBAC, networking) and a control-plane cost. Don't adopt EKS for three services, that's over-engineering.
EC2 vs Fargate (the compute mode)
- Fargate (serverless): no nodes to patch, scale, or capacity-plan. Pay per task's CPU/memory. Best for variable, bursty, or low-ops workloads. Slightly higher per-unit cost; cold-ish starts.
- EC2: you manage the nodes, but get cheaper steady-state cost, GPUs, DaemonSets, and full control. Best for high, steady load or special requirements.
A common sweet spot: Fargate for spiky/low-volume services, EC2 node groups for the steady base.
A decision shortcut
Need the Kubernetes ecosystem or multi-cloud portability?
├─ Yes → EKS
│ ├─ Small/variable workloads → EKS on Fargate
│ └─ Steady/large or special (GPU, DaemonSets) → EKS on EC2
└─ No → ECS
├─ Low ops / variable → ECS on Fargate
└─ Cost-sensitive steady load → ECS on EC2
Cost reality
- Control plane: ECS is free; EKS charges per cluster-hour.
- Compute: EC2 is cheaper per unit at steady load; Fargate wins when things are idle/bursty (no paying for empty nodes).
- Hidden cost: EKS's biggest cost is often engineering time, not the invoice. Factor it in.
The honest recommendation
- Most teams under ~20 services, AWS-only: start with ECS on Fargate. It's boring, cheap to operate, and ships fast.
- Teams that need K8s' ecosystem or run at real scale: EKS, with Fargate for variable workloads and EC2 for the steady base.
- Don't pick EKS because it's on your CV. Pick it because you need what it offers. (My Enterprise Kubernetes case study is where EKS did earn its place, 50+ services, GitOps, mesh.)
The best architecture is the simplest one that meets the requirement. Often that's ECS, and that's a feature, not a compromise.
Weighing container platforms on AWS? That's exactly the kind of call I help teams make, see my services or reach out.