Teams are moving from self-run Kubernetes to ECS, mostly because nobody wants to own the cluster. How to tell whether you should, what maps to what, and a service-by-service migration that never needs a freeze.
Your clusters are on versions in extended support, or have been auto-upgraded, because nobody had time.
The person who set up the cluster left, and what is installed on it is partly a mystery.
Most of what runs there is ordinary web services and workers — nothing that needs an operator.
You pay for a platform team in everything but name: senior engineers losing days each quarter to upgrades and add-ons.
Signs it is not: you depend on operators for stateful systems, you run the same stack outside AWS, or you have a platform team that likes Kubernetes and keeps it current. Then the better move is usually EKS Auto Mode, not leaving.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Inventory every workload and sort it: stateless services first, workers and jobs next, anything stateful or operator-managed last — or never.
Build the ECS side in infrastructure as code: one cluster per environment, task definitions generated from the same image tags your Kubernetes manifests use.
For each service, run the ECS version alongside the Kubernetes one behind the same load balancer or DNS name with weighted routing, and shift traffic over a few days.
Move service-to-service calls to Service Connect or internal load balancers as their callers move.
When a cluster runs nothing, delete it — and its control-plane fee, add-ons and upgrade calendar with it.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
ECS or Kubernetes in 2026? Most Teams Are Choosing for the Wrong Reasons
ECS added blue/green and canary deployments, managed EC2 and one-call deploys; EKS made Kubernetes far easier to operate, but kept charging six times as much for clusters that fall behind. What actually decides it now, with the numbers.
Read
An EKS Reference Architecture for 2026, With Diagrams: The Small-Team Version and the Regulated Version
What a production EKS setup looks like in 2026, layer by layer: edge, entry, cluster, platform add-ons, data, security and observability. A lean version for a small team on Auto Mode, and a regulated version with separate node pools, network policies and audit logging, with the choices behind each box.
Read
As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.