Every few months I have the same conversation. A small team, three to eight engineers, is containerizing their app, and someone says “we should use Kubernetes, that’s the industry standard.” Six months later they’re maintaining a small distributed systems platform on the side, and the app they were supposed to ship is still competing for attention with CNI upgrades.
I’ve written before about the ECS decisions that waste six weeks. This post is the prequel: what ECS actually is, how it maps onto the Kubernetes concepts you already know, and what you stop carrying on your pager when you choose it. There are a few interactive diagrams below. Click around in them; they teach the model faster than prose does.
One thing before we start: this is not a “Kubernetes bad” post. EKS is the right choice for some teams, and I’ll tell you exactly which ones at the end. But I’ve watched too many three-person teams default to EKS because it felt like the serious choice, without anyone explaining what they were signing up to operate.
ECS is an orchestrator. That’s it.
Strip away the branding and every container orchestrator does the same job: you declare what should be running, and a control loop makes reality match the declaration. Kubernetes does this. Nomad does this. ECS does this.
ECS just exposes far fewer moving parts to you. Here’s the whole object model. Click each piece:
Click a component
Every box on the left has a direct Kubernetes equivalent. Click to see what it is and what it maps to.
If you know Kubernetes, the translation table is short enough to memorize over coffee:
| ECS | Kubernetes | What it is |
|---|---|---|
| Cluster | Cluster | Logical boundary for compute + workloads |
| Service | Deployment + ReplicaSet + Service | “Keep N running, behind this LB” |
| Task | Pod | Co-scheduled containers, shared network + identity |
| Task definition | Pod spec | Versioned blueprint for a task |
| Capacity provider | Node group / Karpenter | Where compute comes from |
| Fargate | — (closest: virtual kubelet) | Serverless compute, no nodes at all |
| Task IAM role | ServiceAccount + IRSA | Per-workload cloud credentials |
awsvpc mode | CNI | Every task gets its own ENI/IP — not a choice, a default |
That last column is where the story actually lives. In Kubernetes, “where compute comes from” and “how pods get IPs” and “how workloads get cloud credentials” are all decisions with an ecosystem of competing answers. In ECS they’re defaults. You don’t pick a CNI. You don’t install an IRSA webhook. There’s one way, it’s boring, and it works.
The reconciliation loop — same idea, fewer layers
The core idea both systems share: you declare desired state, a control loop enforces it. This is the part I find people understand instantly once they watch it instead of reading about it.
Below is an ECS service with desired count: 4. Click a task to kill it, then watch the scheduler notice and replace it. Then hit deploy and watch a rolling deployment do exactly what a Kubernetes Deployment rollout does: bring up new tasks, drain old ones, never drop below healthy.
That’s a Deployment rollout and a ReplicaSet self-heal, except nobody installed anything to get it. There’s no controller manager to version. You get all of this the moment you create a service.
When I help teams ship on ECS, this is where it clicks: you already understand ECS. If you can reason about desired state and reconciliation, the orchestration knowledge transfers completely. What doesn’t transfer is the operational surface area, and that’s the actual argument.
What you stop operating
This is the comparison that matters for a small team, and it’s the one nobody draws. The question isn’t which scheduler is smarter. They’re both fine. The question is whose pager each layer lands on.
Toggle ECS between Fargate and EC2 to see the middle ground:
Look at the EKS column. Six of the seven layers are yours. None of them are your product.
The upgrade treadmill deserves special attention because it’s the one that quietly eats small teams. Kubernetes ships about three releases a year, and EKS standard support for each lands around 14 months. That means a recurring, unskippable project roughly once a year, forever: test the control plane upgrade, upgrade the add-ons in the right order, chase whatever deprecated APIs your manifests use, then roll the nodes. Skip it and AWS moves you to extended support at six times the control plane price. For a platform team of 15, that’s Tuesday. For a team of four, it’s a sprint per year spent running to stand still. And there’s a quieter cost on top: you have to stay the kind of team that can do this safely.
ECS doesn’t have a version. I want to make sure that lands. There is no upgrade, no deprecation cycle, no “v1.29 removes the API your ALB controller depends on.” The control plane changed under you a hundred times last year and you never noticed. I have ECS services from 2021 that have never needed a maintenance commit. Infrastructure that doesn’t generate homework is worth more to a small team than anything on the Kubernetes feature list. It’s the same reason I tell teams to pick boring options everywhere else in the stack: boring means you debug your app, not your platform.
On raw cost, the EKS control plane is about $73 a month per cluster and ECS’s is free, and that’s the least interesting line in the comparison. Run the numbers on engineering time instead. One sprint of one engineer’s time per year on cluster maintenance is $10-20k. The biggest AWS savings I’ve ever found came from deleting complexity, not from rightsizing it.
What you give up
If this were one-sided, EKS wouldn’t exist. Here’s what you actually lose.
The big one is the operator ecosystem. Kubernetes has operators for Postgres, Kafka, cert-manager, external-dns, ArgoCD, all debugged by thousands of teams over a decade. ECS has no CRDs and no operator pattern. The AWS answer is “use the managed service”: RDS instead of a Postgres operator, MSK instead of Strimzi. That works right up until you need something AWS doesn’t sell.
Tooling in general follows the same line. Vendors ship a Helm chart, not a task definition. Kustomize, the CNCF landscape, none of it targets ECS. And your deployment layer is AWS-native, so a future move off AWS means rewriting it. Your containers move unchanged, but the wiring around them doesn’t.
There’s also the hiring thing, and I won’t pretend it isn’t real. Engineers want Kubernetes on their CV. ECS knowledge is real orchestration knowledge and the concepts transfer completely, as the diagrams above show, but nobody’s career was ever advanced by the phrase “task definition.”
And ECS has a control ceiling. Custom schedulers, topology spread, network policy, the more exotic probe and init semantics: Kubernetes gives you knobs ECS simply doesn’t have. Most web products never touch them. If yours genuinely does, you’ll feel the ceiling and you’ll resent it.
So when is EKS the right call?
EKS earns its keep when at least one of these is true:
- Someone owns the platform. You have, or are hiring, people whose actual job is cluster operations, so the pager layers above land on a team that exists.
- You’re running stateful infrastructure on-cluster that AWS doesn’t offer as a managed service, and you need the operator ecosystem for it.
- Multi-cloud or on-prem is a real requirement: contractual, regulatory, or your customers deploy your software into their clusters.
- Your team is already fluent. K8s veterans ship faster on EKS than they would learning anything else. The tax is only a tax if you haven’t already paid it.
If none of those describe you, and for most sub-ten-engineer teams shipping a web product none do, then Kubernetes isn’t buying you capability. It’s buying you a second job.
The takeaway
ECS is not “Kubernetes for beginners.” It’s the same control loop idea with a deliberately smaller operational surface. Same desired state, same reconciliation, same rolling deploys, minus the version treadmill, the add-on stack, and the node fleet. You’ve seen the whole object model in this post. There is no part two where the hidden complexity lives.
Small teams don’t lose because they picked the wrong orchestrator. They lose because their best engineers spent the year operating infrastructure the product didn’t need. Pick the tool that generates the least homework, ship, and revisit when you have the head count to afford opinions.
If you’re starting an ECS build-out, the companion post on the 5 ECS decisions that waste 6 weeks covers the concrete choices: Fargate vs EC2, service discovery, CI/CD, secrets, and monitoring.
If this post saved you a meeting, it did its job. I write about AWS, DevOps, and building things from scratch. Subscribe via RSS, or find me on Twitter.