ECS vs Kubernetes

Most ECS vs Kubernetes content falls into one of two camps. Camp one: Kubernetes is the industry standard and ECS is Amazon's proprietary answer to a problem they didn't fully understand — migrate immediately. Camp two: Kubernetes is overengineered nonsense and anyone who chooses it is showing off.

Both are wrong. And both are unhelpful if you're actually trying to make a good decision for your team.

Here's an honest take, built from running production systems on both.

Where ECS Genuinely Wins

If you're already deep in the AWS ecosystem, ECS is the path of least resistance — and that's not a criticism. Native IAM integration, seamless ALB routing, Fargate for serverless container execution, CloudWatch for observability. Everything talks to everything without ceremony.

Operational overhead is low. The learning curve is shallow enough that a small team can own it without a dedicated platform engineer. There's no control plane to manage, no cluster upgrade path to navigate, and no CNI debugging at 2am.

For startups, scale-ups, and teams without a platform specialism, ECS frequently delivers 90% of what Kubernetes offers at 30% of the complexity cost. It won't make you look as impressive at a conference, but for a large number of production workloads it is more than enough — and it will cost you significantly less in engineering time, tooling overhead, and operational complexity.

Where Kubernetes Genuinely Wins

At scale, the primitives matter. Custom resource definitions, advanced scheduling, multi-tenancy, complex networking policies, the breadth of the CNCF ecosystem — these are real advantages when your requirements justify them.

If you're running a large engineering organisation, building an internal developer platform, or operating across multiple cloud providers, Kubernetes earns its complexity. The operator ecosystem alone — for stateful workloads, database management, and specialised controllers — is something ECS simply can't match.

Kubernetes is also the right answer when you're building a platform for other engineers to build on. The abstractions it exposes — pods, services, custom resources — give platform teams the building blocks to create self-service experiences that would require significant custom work on ECS.

The Hidden Cost Nobody Puts in the Spreadsheet

When teams evaluate Kubernetes adoption, they usually look at the obvious costs: cluster compute, managed control plane fees, tooling, training. These are real costs. They're also the smallest part of what Kubernetes actually costs most organisations.

Engineering time. Not just the initial migration — the ongoing, permanent allocation of engineering attention to platform concerns. Cluster upgrades. Node management. Debugging networking issues that wouldn't exist on a simpler stack. For a small team, this can quietly consume 20–30% of senior engineering capacity.

Cognitive load. Every engineer on your team now needs a working mental model of Kubernetes to be effective. For engineers whose primary job is building product, this is a tax on every decision they make. It slows down debugging, makes incidents more stressful, and raises the floor of expertise required to contribute meaningfully to the platform.

Hiring pressure. Once you're running Kubernetes in production, you need engineers who can work with it. That narrows your hiring pool and raises salary expectations. When your one engineer who really understands the cluster leaves, you have a problem.

None of this means Kubernetes is the wrong choice. For the right organisation, these costs are justified many times over. But go in with an honest accounting of what you're signing up for.

Three Questions to Ask Before You Decide

When a team asks me whether they should use Kubernetes, I don't answer straight away. I ask three questions first. The answers almost always point clearly in one direction.

What problem are you actually trying to solve? Not what you want the platform to do eventually — what's the specific pain you're feeling right now? If the answer is "deployments are unreliable" or "we need to scale more efficiently", those are solvable problems. The question is whether Kubernetes is the right solution, or whether it introduces ten new problems while solving one. If the answer is "everyone else seems to be doing it" — that's pressure, not a problem.

Who is going to own this long-term? Kubernetes requires ongoing, expert ownership through staff turnover, cluster upgrades, and 2am incidents. If you have a team built for that, great. If you're a five-person startup where the backend engineers are also doing platform work alongside product development, be honest about what you're signing them up for.

What does "good" look like in 18 months? If good means a reliable, low-maintenance platform that lets your product team move fast, the simplest thing that achieves that is usually the right answer. If good means a mature internal developer platform serving multiple teams with complex, differentiated needs — you might be building toward Kubernetes whether you start there or not.

The Question That Actually Matters

It's not "which is better?" It's "which is better for us, right now, given what we're trying to build?"

That answer changes as your organisation grows. ECS today doesn't mean Kubernetes never. It means you're not paying complexity tax on problems you don't have yet. The best platform decision isn't always the most interesting one — sometimes it's just the one that lets you get on with the work.

Start with the requirements. Let the tool follow.

Watch the Talk

Neil presented Do You Really Need Kubernetes? at PlatformCon 2026, covering production-ready Docker hosting on AWS ECS and a direct comparison with Kubernetes across three critical layers: compute orchestration, ingress routing, and persistent storage.