ECS or EKS? A decision rule for teams under 15 engineers.
The short answer for most startups: ECS on Fargate, until you have a specific reason for Kubernetes that you can write in one sentence. Here's the cost maths and the reasoning behind that.
Prices checked: 19 Oct 2026, us-east-1
The short answer.
Pick ECS on Fargate if you run a handful of web services and workers, have no one whose job is the platform, and want deploys that don't need a specialist.
Pick EKS if you need something only Kubernetes gives you: a tool that ships as a Helm chart and nothing else, a customer who runs your software in their own Kubernetes, many teams sharing one platform, or GPU scheduling beyond what ECS handles. And someone who'll own the upgrades.
What three environments cost before any workload runs.
| Item, per month | ECS | EKS, standard | EKS, extended support |
|---|---|---|---|
| Control plane, per cluster | $0 | $73 | $438 |
| Three clusters (dev, staging, prod) | $0 | $219 | $1,314 |
| Add-ons you'll install (ingress, DNS, metrics, autoscaler) | built in | your time | your time |
Compute costs the same on both if you use Fargate. The difference is the fixed overhead and, mostly, people. Extended support kicks in when a cluster falls behind on Kubernetes versions, which is exactly what happens on teams without a platform engineer.
Fargate list prices, us-east-1, Linux/x86: $0.04048 per vCPU-hour, $0.004445 per GB-hour.
A seed-stage app, priced both ways.
Two services (an API and a worker), two tasks each for availability, 0.5 vCPU and 1 GB per task, running all month. That's a very ordinary shape for a team of six.
- One task, a month$18.02
- Four tasks, one environment$72.08
- Three environments, compute only$216.24
- Add three EKS control planes+ $219.00
- Or, on extended support+ $1,314.00
At this size the Kubernetes control planes cost about as much as everything they run. That ratio flips as the workload grows, which is why the answer changes at 30 engineers and rarely at 6.
Ops time per month, the part nobody prices.
Kubernetes asks for a version upgrade roughly three times a year, and each one touches the add-ons too. Realistically, a small EKS setup takes a few days a month of someone's attention: upgrades, add-on updates, chasing why a pod won't schedule. ECS asks for close to none of that.
At a startup that time comes out of product work. Price it at your engineers' cost, and the control plane fee becomes the small number in the comparison.
App Runner, plain Fargate tasks, or Lambda for very small teams.
If you have one web app and a database, ECS might already be more than you need. App Runner or a single Fargate service behind a load balancer is fine for a long time, and Lambda suits spiky, event-driven work. Moving up to ECS later is a small step; moving down from Kubernetes rarely happens.
Migration paths, both ways.
ECS to EKS is straightforward if your services are already containers with configuration in environment variables: the images don't change, only how they're scheduled. EKS to ECS is also doable, and worth considering if a cluster was set up by someone who has since left and nobody wants to upgrade it.
Either way, the move is easier with the infrastructure in Terraform. Leaving Heroku? Our Heroku to AWS page uses ECS for the same reasons. Want help deciding for your setup? That's a typical first month on a fractional DevOps plan.