Most teams pick Kubernetes because it's the default answer in a Slack channel. That's a fine reason for a side project. For a company, it deserves more thought.
What you're actually choosing between
EKS is managed Kubernetes. AWS runs the control plane; you run the worker nodes (or use Fargate). ECS is AWS-native orchestration. Simpler primitives, deeper IAM integration, no upstream version to chase.
Pick ECS when
- You're on AWS now and likely to stay for the next 3 years.
- You have fewer than ~50 services to orchestrate.
- Your team is small and isn't already fluent in Kubernetes.
- Most of your services are stateless web/API workloads.
ECS with Fargate hits a sweet spot. You don't run nodes at all. Deployments are a CodeDeploy or GitHub Action away. The operational surface area is tiny—which is the point.
Pick EKS when
- You need to run the same orchestration on AWS, GCP, or on-prem.
- You depend on the Kubernetes ecosystem—Argo, Istio, Knative, Karpenter, custom operators.
- You're running 50+ services and ECS task definitions are getting unwieldy.
- You have, or are hiring, dedicated platform engineers.
The real cost of Kubernetes
EKS control plane is $73/month per cluster, which is nothing. The real cost is people. A correctly-run EKS cluster is a continuous engineering investment: upgrades every 4 months, IAM integration via IRSA, network policies, autoscaling tuning, secrets management. None of it is hard. All of it is constant.
ECS does the boring parts for you. The trade-off is less control and a thinner ecosystem.
Hybrid is fine
We've shipped stacks where the steady-state web tier runs on ECS Fargate and the data/ML platform runs on EKS because that's where the ecosystem lives. Don't feel obliged to pick one bucket for the whole company.