Kubernetes is the default answer to "how do we run containers," and on AWS that usually means EKS. For a large platform team running dozens of services with complex orchestration needs, it is a fine choice. For most teams, it is a heavy, expensive way to run a handful of containers that AWS could run for you with far less machinery.
What EKS Actually Costs You
EKS is not just a control-plane fee. It is the ongoing human cost: cluster upgrades, node group management, networking plugins, IAM-to-Kubernetes-RBAC mapping, ingress controllers, and a steady stream of CVEs to patch. You are now operating a distributed system in order to operate your distributed system.
For a team of five shipping a product, that is a second full-time job nobody signed up for.
What AWS Gives You Instead
ECS on Fargate runs containers with no cluster to manage and no nodes to patch. You hand it a task definition and it runs:
{ "family": "api", "cpu": "512", "memory": "1024", "containerDefinitions": [ { "name": "api", "image": "myrepo/api:latest", "portMappings": [{ "containerPort": 8080 }] } ] }
For simpler workloads, App Runner goes further — point it at a container image or repo and it handles deploy, scaling, and HTTPS. And for event-driven work, plain Lambda removes containers from the picture entirely.
The Portability Argument
The usual defense of Kubernetes is portability: "we won't be locked into AWS." In practice most teams never leave, and they pay the full complexity cost the whole time for an escape hatch they never use. Optimize for the reality you are in, not a migration that probably will not happen.
Where I Land
Reach for EKS when you genuinely have Kubernetes-shaped problems: many teams sharing infrastructure, complex multi-service orchestration, or an existing investment in the Kubernetes ecosystem. For everything else, start with Fargate or App Runner. You can always graduate to Kubernetes later — but most teams never need to, and the ones that start there spend months operating a cluster instead of shipping.