A lot of ECS vs Kubernetes articles come from vendors selling Kubernetes tooling. We run both in production for clients and have no preference between them, as long as the choice fits the team.
The short version: on AWS, ECS is the default. Kubernetes is the exception you opt into for specific reasons. Most teams under about 30 engineers who choose EKS carry ongoing operational work for capabilities they rarely use.
What you are actually choosing between#
Both run containers, restart them when they die, scale them, and route traffic to them. For a typical setup of stateless services behind a load balancer with a database, both do the job completely. The differences that matter are who operates the platform and what it costs them.
ECS is a proprietary AWS orchestrator. There is no control plane for you to manage, no version upgrades on a clock, and the integration with IAM, ALB, CloudWatch, and Service Connect is native. With Fargate, there are no hosts either. The trade is flexibility: you get the features AWS built, configured the way AWS allows.
Kubernetes (EKS) is an ecosystem. You get an enormous API surface, Helm charts for almost everything, operators, custom controllers, and portability in principle. The trade is that the cluster itself becomes a product your team maintains: version upgrades roughly every year whether you want them or not, add-on compatibility (CNI, CoreDNS, ingress controller, cert-manager, external-dns, autoscaler), and an ecosystem that moves fast and deprecates things.
What each one costs to run#
The EKS control plane fee, about $73 per cluster per month, is small next to engineer time, though it adds up with a cluster per environment. Most of the cost is people:
- Upgrades are mandatory. EKS versions leave standard support 14 months after release. After that, extended support keeps you running for another 12 months at six times the control plane price. Each upgrade means reading changelogs for the cluster and every add-on, testing deprecations, and rolling nodes. For a small team this is days of work, at least once a year. ECS has no equivalent. We have seen clusters running two-year-old Kubernetes versions because nobody had time, and catching up from there is closer to a migration than an upgrade.
- The cluster needs a stack of add-ons before it is useful. Ingress, DNS, certificates, autoscaling, monitoring agents. You can back most of them with the same managed AWS services ECS uses: ALB through the AWS Load Balancer Controller, Route 53 through external-dns, ACM certificates on the load balancer. EKS Auto Mode takes a few of those controllers off your hands. But then you have the same AWS lock-in as ECS, plus controllers in between that you still have to upgrade and debug. On ECS that integration is built in and there is nothing to install.
- Debugging depth. When ECS misbehaves, the surface area is small and the answer is usually in the event log or an IAM policy. When Kubernetes misbehaves, the answer can be anywhere from the app to the CNI plugin. Someone on the team has to be able to work through that stack, or platform incidents take a lot longer to resolve.
- Hiring and bus factor. “We run EKS” means you need to keep hiring people who know Kubernetes, or you concentrate the knowledge in one person. That person becoming the single point of failure is one of the most common findings in our audits.
None of this is an argument that Kubernetes is bad. It is an argument that Kubernetes is a workload of its own, and it belongs on the cost side of the comparison.
When Kubernetes earns it#
There are good reasons to run EKS:
- You need the ecosystem, not just the orchestrator. Argo Workflows, operators for stateful systems, GPU scheduling for ML workloads, service meshes you actually need. If your roadmap depends on these, ECS is the wrong fit.
- Multi-cloud or on-prem is a hard requirement. A contractual or regulatory requirement, or an existing on-prem footprint, rather than something you might want someday. Kubernetes is the only portable answer.
- Your vendors ship Kubernetes. If the software you must run is distributed as Helm charts and the vendor supports nothing else, that decides it for you.
- You already have solid Kubernetes competence. A team that has run it for years and is happy with it should keep it. The migration cost would exceed the ECS savings.
- Scale and density economics. Hundreds of services, bin-packing across large node fleets, custom scheduling. At that point the platform team pays for itself.
The reasons we hear most often are “we might grow”, “Kubernetes experience is good for the team’s CVs”, and “everyone uses it”. None of them are on the list above.
The matrix#
| Question | Points toward ECS | Points toward Kubernetes |
|---|---|---|
| Team size | Under ~30 engineers, no platform team | Dedicated platform team, or budget to build one |
| Where you run | AWS only | Multi-cloud or on-prem required |
| Workloads | Stateless services, workers, cron jobs | Operators, ML/GPU scheduling, vendor Helm charts |
| Existing skills | Little or no production k8s experience | Years of it, in-house, more than one person |
| Appetite for platform work | Want to ship product, not run a platform | Willing to staff upgrades and add-on maintenance permanently |
| Service count | A handful to a few dozen | Hundreds, with density economics that matter |
| Compliance/portability | No portability requirement | Contractual or regulatory portability requirement |
If you land mostly in the left column and still want EKS, what you have is a preference, which is fine, as long as you budget for it as one.
The middle path people forget#
Fargate on ECS removes host management entirely and is where we start most greenfield client setups. It costs more per vCPU than EC2-backed capacity, and for spiky or modest workloads the premium is smaller than the cost of managing instances. When the bill grows, moving hot services to EC2 capacity providers is a contained change.
And if you are a small team reading this with three containers and a database: you may not need an orchestrator at all yet. A boring setup that one person fully understands beats an impressive one that nobody does.
Where we land#
Default to ECS on AWS. Choose Kubernetes when a requirement on the list above forces your hand, and staff for it when you do. Both are fine technologies. The most common mistake we see is picking Kubernetes and budgeting for it as if it were ECS.
Deciding between them right now, or running an EKS cluster that has become nobody’s job? Get in touch. We have moved teams in both directions.