A developer who recently joined a company migrating from Heroku to AWS has laid out a common infrastructure dilemma: ECS or EKS for a team with no cloud experience. The question, posted to Hacker News, attracted a focused debate about operational complexity versus architectural flexibility.
The company runs almost entirely stateless web services, with some data pipeline work already shifted to Lambda. The development team of roughly 20 people has no background in cloud or infrastructure as code. The poster, the second DevOps hire on the team, argues for ECS. The consulting firm engaged before the poster arrived is pushing EKS.
The case for ECS
The poster's reasoning is straightforward. ECS maps cleanly to AWS primitives. A team learning cloud infrastructure for the first time does not need to also learn Kubernetes abstractions. Service discovery, load balancing, and task scheduling are handled by AWS services that behave consistently. There is no control plane to maintain, no etcd cluster to watch, no version skew between API server and node agents.
For stateless web services, ECS Fargate removes the node management layer entirely. You define a task, attach a load balancer, and AWS handles placement and scaling. The learning curve is the IAM policy, the task definition, and the service configuration. That is a weekend of reading for a team that already understands networking and deployment concepts from Heroku.
The consulting team's argument for EKS
The consultants argue that Kubernetes namespaces let developers work in isolated environments without needing separate AWS accounts or custom IAM permissioning per team. In their view, the increased operational burden on the cluster itself is offset by reduced work around multi-account governance and per-service permission scoping.
That argument has merit in organizations with many teams, strict compliance requirements, or complex service-to-service communication patterns. Kubernetes namespaces, network policies, and RBAC provide a rich isolation model that ECS does not match natively. If the company plans to grow significantly or split into multiple autonomous teams, the EKS approach front-loads some complexity that pays off later.
What the team's experience actually implies
The key constraint is the team. Twenty developers with no cloud experience will struggle with EKS not because Kubernetes is inherently worse, but because the failure modes are less familiar and the debugging surface is larger. When a pod fails to start, the team needs to understand image pulls, resource requests, node affinity, and the relationship between deployments and replica sets. When a task fails on ECS, the answer is usually in the CloudWatch log for that task definition.
The poster's instinct that abstractions should be minimal during a migration is well-founded. The team is already learning VPCs, security groups, IAM roles, and load balancers. Adding Kubernetes on top of that means learning a second infrastructure model simultaneously. ECS lets the team focus on one set of AWS concepts and get comfortable before introducing anything more complex.
The hidden cost of "just use namespaces"
The consulting team's suggestion to use namespaces instead of multiple AWS accounts sounds simple on paper. In practice, it creates coupling. All teams share the same cluster, the same node pool, and the same Kubernetes version. A bad deployment from one team can affect others through resource exhaustion or API server load. AWS accounts, by contrast, provide hard isolation boundaries with clear cost attribution and independent blast radius.
For a team that is new to cloud, the namespace approach also introduces Kubernetes-specific complexity that has nothing to do with running applications. The team will need to understand RBAC policies, network policies, and resource quotas to make namespaces work as an isolation mechanism. That is additional cognitive load with no corresponding benefit for stateless web services that could just as easily run in separate ECS services.
When EKS makes sense
EKS is the right choice when the team already knows Kubernetes, when the workload demands features like custom scheduling, persistent storage orchestration, or service mesh integration, or when the organization has a platform team that will own the cluster and abstract it away from application developers. None of those conditions appear to apply here.
The honest answer for this team is ECS, with a clear migration path to EKS if the company grows into a multi-team structure that needs the isolation model Kubernetes provides. The poster's plan to start with the simpler option, learn AWS properly, and revisit the decision later is the pragmatic choice. Infrastructure decisions made during a migration should optimize for the team that exists today, not the team that might exist in three years.