EKS vs ECS vs Fargate for an SMB: the real cost/complexity comparison

“We’re going with Kubernetes, it’s the standard.” That’s the most common answer we hear on engagements when an SMB picks its container orchestrator — and it’s often the wrong answer. Not because EKS is a bad product, but because the question being asked is the wrong one. For a team of 5 to 30 engineers on AWS, the choice between ECS, EKS and Fargate isn’t about following the market standard: it’s a trade-off between a fixed cost of operational complexity and a monthly control-plane bill, weighed against what the team already knows how to run.

This article breaks down the real costs — control plane, Fargate compute, extended support — and lays out a decision tree that avoids the most common mistake: defaulting to EKS because “it looks good on a resume,” and discovering six months later that a full-time hire is now needed just to keep the cluster running.

Three products, two separate questions

The vocabulary invites confusion because ECS and EKS answer “who orchestrates my containers,” while Fargate answers an orthogonal question: “who manages the underlying infrastructure.”

• ECS (Elastic Container Service): AWS’s proprietary orchestrator, simpler, native integration with IAM, ALB, CloudWatch, Service Discovery — without the Kubernetes vocabulary (pods, deployments, CRDs).
• EKS (Elastic Kubernetes Service): a Kubernetes control plane managed by AWS. You inherit the full CNCF ecosystem (Helm, ArgoCD, Istio, third-party operators) and multi-cloud portability, at the cost of inherently higher complexity.
• Fargate: a serverless compute mode, usable with either ECS or EKS. You no longer provision EC2 instances — AWS bills the vCPU and memory consumed by each task/pod, per second.

The real decision point is therefore two-fold: ECS or EKS for orchestration, then Fargate or EC2 for compute. That’s four possible combinations, not two.

The real cost: the EKS control plane isn’t negotiable

This is the most underestimated point on engagements. ECS carries no control-plane fee at all — you only pay for compute (EC2 or Fargate). EKS, on the other hand, bills the control plane at $0.10 per cluster per hour, roughly $73/month per cluster, regardless of how many services run on it. An EKS cluster for three microservices costs the exact same control-plane flat fee as one running fifty.

The hidden trap: if the cluster isn’t upgraded to a supported Kubernetes version in time, AWS automatically switches it to extended support — the rate jumps to $0.60/hour, roughly $438/month, a 6x jump on the control-plane line alone. It’s a textbook case of an AWS bill exploding with no actual load increase: just a Kubernetes version that was left to drift.

On the Fargate compute layer itself, eu-west-3 (Paris) rates sit around €0.046/vCPU-hour and €0.005/GB-hour — roughly €41/month for a 1 vCPU / 2 GB task running 24/7. That rate is strictly identical whether the task runs under ECS or under EKS: Fargate doesn’t distinguish between the two. The billing gap comes entirely from the control plane and, for EKS on EC2, from Auto Mode.

EKS Auto Mode, launched to automate node provisioning and patching, adds a 10 to 12% surcharge on top of the underlying EC2 cost, billed per second with a one-minute minimum — on top of the control-plane fee. That’s a reasonable trade-off if the team has nobody dedicated to Kubernetes ops, but it isn’t free.

On a concrete case — three containerized services, 1 vCPU / 2 GB each, running continuously — the gap between ECS + Fargate (≈€123/month) and EKS + Fargate (≈€196/month) comes down entirely to the control plane. That’s not a dealbreaker at this scale, but it adds up fast once an SMB spins up separate clusters per environment (dev, staging, prod) without consolidating them.

The complexity that doesn’t show up on paper

The euro cost is often not the real blocker — team time is. Three blind spots that come up systematically in audits:

The learning curve isn’t linear. ECS can be picked up in a few days by a team that already knows IAM and Security Groups. EKS requires mastering Kubernetes objects, RBAC, CNI plugins (VPC CNI, Calico), Kubernetes-specific observability (metrics-server, kube-state-metrics) — a knowledge base that takes weeks to build for a team that’s never operated a cluster, and that needs continuous upkeep (Kubernetes versions ship roughly every 4 months).

Kubernetes upgrades are a recurring friction point. AWS deprecates old EKS versions on a regular cadence — unlike ECS, where there’s nothing to upgrade on the orchestrator side. An SMB with no documented upgrade process routinely drifts into extended support out of sheer neglect, with the 6x bill that comes with it.

The CNCF ecosystem has an integration cost. Helm, cert-manager, external-dns, ingress-nginx or the AWS Load Balancer Controller aren’t provided out of the box — each piece is a choice, a version to track, a source of vulnerabilities to patch. On ECS, the equivalent (ALB, Service Discovery, Secrets Manager) is natively integrated and maintained by AWS.

Conversely, EKS becomes the right call as soon as one of these is true: the team already operates Kubernetes elsewhere (on-prem, another cloud), there’s a genuine multi-cloud portability requirement, or there’s a dependency on a Kubernetes-specific tool (operators, service mesh, advanced GitOps) with no ECS equivalent.

Decision tree for an SMB

In summary, the method we apply on engagements to decide quickly:

1. Does the team already have in-house Kubernetes expertise? No → ECS, unless there’s a strong external constraint. Yes → EKS remains a valid option.
2. Is there a documented multi-cloud or hybrid portability requirement? No → ECS. Yes → EKS.
3. Does the volume justify paying the fixed control plane (minimum $73/month)? Three critical services in production → yes, the ratio quickly becomes negligible. A single internal service → no, ECS is plenty.
4. Fargate or EC2? Stable, predictable load, ready to fine-tune → EC2 (cheaper per vCPU, more ops). Variable load, small team, priority on not managing infra → Fargate, even at the premium.
5. Is a Kubernetes upgrade process in place? If the answer is no for EKS, that’s a warning sign — not a reason to drop EKS, but a workstream to budget for from day one, before the extended-support bill arrives.

In the large majority of audits we run for SMBs of 10 to 100 people with no dedicated Kubernetes team, ECS + Fargate remains the most cost-effective starting point: minimal startup cost, free control plane, native AWS integration, and an operational load compatible with a team that also has to ship product. EKS earns its place once the expertise already exists or portability is a genuine business requirement — not a technical aspiration.

Conclusion

The ECS vs EKS choice isn’t a maturity choice, despite what a lot of content on the topic implies. It’s an economic and organizational one: how much does the control plane cost relative to your scale, and how much does team time cost to maintain a Kubernetes cluster instead of shipping product. Fargate, for its part, is decided independently — it’s a compute-vs-ops trade-off, not an argument for or against Kubernetes.

If your current stack already mixes auto-scaled EC2 with poorly orchestrated containers, our article on what a Well-Architected Review actually finds covers how this kind of blind spot surfaces in an audit.

If you’re weighing ECS against EKS for a project still in scoping, that’s exactly the kind of trade-off we settle in a DevSecOps Audit — with real cost math run against your actual load, not a theoretical one.