Articles

We chose ECS over EKS — what we gained and what we gave up

16 October 2026 · 7 min read · Gaurav Tredia

This is not an argument that Kubernetes is unnecessary. We run EKS and GKE on other projects. But on this platform, once we did the arithmetic honestly, ECS was the right call — and that arithmetic is exactly what most teams skip before choosing.

What we gained

1. No control plane charge

ECS does not bill for orchestration. You pay for compute (EC2 or Fargate) and what surrounds it, not for the management layer. EKS charges per cluster: $0.10 per hour, about $73 a month for a single cluster.

That number looks trivial until you count clusters. A platform with development, QA and production is already three. Two regions? Six. And that is before a single instance runs your code:

• One cluster — about $73 a month
• Three environments — about $219 a month
• Six (three environments, two regions) — about $438 a month

Roughly $5,000 a year on orchestration alone, before workloads. At a large company that is noise. At a startup it is a part-time salary.

2. No constant upgrade pressure

Kubernetes versions leave standard support after roughly 14 months. Clusters that have not been upgraded move automatically to extended support, and the price jumps from $0.10 to $0.60 per cluster per hour — six times as much, about $438 a month per cluster. That transition is enabled by default, so the bill can rise without anyone making a decision.

ECS simply does not have that axis. There is no cluster version to chase, no quarterly maintenance window, and no CRD compatibility check before every upgrade.

3. Fewer components to secure

EKS means choosing a CNI, managing Kubernetes RBAC on top of IAM, maintaining admission controllers, and tracking whatever has been installed into the cluster. Each is reasonable on its own, and each is attack surface and one more thing to document. With ECS, permissions are IAM, and that is the whole list.

What we gave up

• Portability. ECS task definitions are AWS-specific. Moving to another cloud means rewriting, not copying.
• The ecosystem. No Helm, no operators, no Argo CD, no CRDs. Problems that have an off-the-shelf answer in Kubernetes need a local solution in ECS.
• Scheduling flexibility. The Kubernetes scheduler allows far finer rules than ECS placement constraints. If you need that, you will feel its absence.
• Hiring appeal. The job market speaks Kubernetes. ECS attracts fewer candidates, and that is a real long-term cost.

How to make the call

1. 1Count your clusters — environments times regions, then the annual control plane cost on its own.
2. 2Ask who upgrades — if nobody will genuinely upgrade twice a year, extended support is already heading your way.
3. 3Check what you need from the ecosystem — if the answer is Argo CD and operators, Kubernetes earns its cost.
4. 4Be honest about team knowledge — a cluster nobody understands deeply is a risk, not an asset.
5. 5Test the portability claim — will you really change cloud, or is it a theoretical assumption?

When EKS is the right answer

When you have many services and teams releasing in parallel; when you want GitOps with Argo CD; when you must run on more than one cloud; when the team already lives in Kubernetes; or when you run GPU and AI workloads that need precise scheduling. In those cases the fixed cost is the cheapest part.

The bottom line

The mistake is not choosing ECS, and it is not choosing EKS. The mistake is choosing without doing the arithmetic: what orchestration costs, who performs upgrades, and what you actually need from the ecosystem. Do that arithmetic against your own account, not against a slide.

A shorter version of this article first appearedon LinkedIn. Prices follow the AWS US pricing list at the time of writing.

Keep reading

• Kubernetes and GitOps — when Kubernetes is the right choice.
• Cloud cost optimization — where else money hides in the bill.
• AWS cloud services in Israel — design that starts from decisions like this.