A team on AWS is choosing between Amazon ECS and Amazon EKS to run a new containerized service. What would make EKS the right choice, and what do you take on by picking it?
answer
- same compute, different orchestrator
- ecosystem versus operational simplicity
- who pays for the upgrade cadence
- ECS control plane costs nothing
basics
~20 sChoose EKS when you need conformant Kubernetes — its ecosystem of Helm charts, operators and CRDs, portability off AWS, or existing Kubernetes skills. The price is a per-cluster fee plus a permanent upgrade and add-on treadmill that ECS does not impose.
solid answer
~50 sBoth run containers on the same underlying compute, EC2 or Fargate, so the decision is about the orchestrator, not the workload. ECS is AWS's own scheduler: no control-plane charge, a small surface area — task definitions, services, capacity providers — and native wiring to IAM, ALB target groups, CloudWatch and Auto Scaling. EKS gives you upstream-conformant Kubernetes, which is what you want when the workload already depends on Helm charts, operators or custom resources, when the team has Kubernetes experience or runs clusters elsewhere, or when portability off AWS is a stated requirement. What you take on is real: a flat hourly charge per cluster, a Kubernetes minor version to upgrade on AWS's support cadence, add-ons like the VPC CNI and CoreDNS to keep compatible, and enough platform expertise on staff that the cluster is not one person's hobby. For a handful of straightforward services with no Kubernetes dependency, ECS is the cheaper and quieter answer.
go deeper
Know that both services run the same containers on EC2 or Fargate, that ECS is AWS's own simpler orchestrator with no control-plane charge, and that EKS means real Kubernetes.
Explain the concrete tradeoff: the Helm and operator ecosystem and portability on one side; the cluster fee, version upgrades and add-on compatibility on the other. Name a workload that clearly belongs on each.
Demonstrate that you have paid the EKS bill in time as well as dollars — upgrade sequencing, removed API versions breaking third-party charts, add-on skew — and be willing to recommend ECS when the Kubernetes case is speculative.
Own the organisational version of the choice: how many clusters, whether the company can staff a platform team, whether portability is a real constraint or a slogan, and what the standard becomes for every team that follows.
## The decision is about the orchestrator, not the containers Amazon ECS and Amazon EKS both schedule containers onto the same two kinds of AWS capacity: EC2 instances you manage, or Fargate, where AWS runs the underlying host. The image is the same image. So the question an interviewer is really asking is: what does the *scheduler and its ecosystem* buy you, and what does it cost? ## What ECS gives you ECS is AWS's proprietary orchestrator, and its defining property is that there is nothing underneath it to learn. You describe containers in a task definition, run them as a service behind a load balancer, and pick a capacity provider for the compute. Everything is expressed in AWS's own vocabulary: an IAM task role gives the containers permissions directly, the `awslogs` driver ships stdout to CloudWatch Logs, service auto scaling is Application Auto Scaling, and the service registers itself with an ALB target group. There is no control-plane charge. A single engineer can hold the whole model in their head. The ceiling is the flip side of that: you get exactly the primitives AWS provides. There is no equivalent of a custom controller reconciling your own resource type, no third-party operator you can install to run a database or a service mesh, and no way to take the deployment description to another cloud. ## What EKS gives you EKS runs upstream-conformant Kubernetes with an AWS-operated control plane. Four reasons genuinely justify it: 1. **Ecosystem dependency.** The workload already ships as a Helm chart, or it needs an operator — Prometheus, cert-manager, a database operator, Argo CD, a service mesh. These exist for Kubernetes and not for ECS. This is the most common honest reason. 2. **Existing skills and tooling.** A team that already writes Kubernetes manifests, or a company that runs clusters on-premises or on another cloud, gets one operating model instead of two. 3. **Portability as a requirement.** Not a slogan — an actual constraint, such as shipping the same platform to a customer's own cluster. 4. **Extension.** You need to model your own resource types and reconcile them with a controller, which is Kubernetes' core extensibility story. ## What EKS costs you **The cluster fee.** A flat hourly charge per cluster, independent of workload. Multiplied by environments and teams, this alone can dwarf a small platform's compute bill. **The upgrade treadmill.** Kubernetes minor versions arrive several times a year and each one gets a limited standard-support window on EKS; after it, the cluster moves to extended support at a higher rate. Upgrading is a sequence — control plane, then add-ons, then node groups — plus checking whether any removed API version is still in use by your manifests or your third-party charts. ECS has no equivalent obligation; AWS evolves it under you. **Add-on ownership.** The VPC CNI, CoreDNS, kube-proxy, CSI drivers, an ingress controller, and whatever operators you installed all have their own version compatibility matrices, and they are yours. **Headcount.** EKS assumes someone owns the platform. Rule of thumb: if no one on the team can explain what a controller does when it reconciles, EKS is a liability rather than an asset. ## Things that are *not* a reason to pick EKS - "We want AWS to manage the nodes." Both offer Fargate; ECS on Fargate involves fewer moving parts than EKS Fargate profiles. - "We need autoscaling." Both scale on CloudWatch metrics. - "We need IAM permissions per workload." ECS task roles do this natively and simply; on EKS you configure IRSA or EKS Pod Identity first. - "Kubernetes is the standard." A preference, not a requirement — say what it buys *this* workload. ## How to answer it out loud Name the axis first: ecosystem and portability versus operational simplicity and cost. Then commit. "Three stateless services, a small team, no Kubernetes dependency, everything else already on AWS: ECS on Fargate, and I would revisit if we start wanting operators." "A platform team running twenty services with Helm-packaged dependencies and an existing on-prem cluster: EKS, and I budget for the upgrade cadence." Interviewers are testing whether you can decide, not whether you can list features.
- If the team ends up on EKS, does choosing Fargate for the pods remove most of the operational burden?It removes node patching and capacity management, not the Kubernetes burden. You still upgrade the cluster version, keep add-ons compatible, and run whatever controllers you installed. EKS Fargate profiles also come with constraints — no DaemonSets, limited ephemeral storage, and no EKS Pod Identity — so the observability and logging agents most clusters run as DaemonSets need a different arrangement.
- How would you migrate a service from ECS to EKS later if the ecosystem argument only shows up in a year?The container image and its configuration surface carry over unchanged; what you rewrite is the deployment description — task definition to Deployment, service to Service plus ingress, task role to a role bound through IRSA or Pod Identity. That is usually days of work, not months, which is a fair argument for starting on ECS when the Kubernetes case is speculative.
- Does running Kubernetes on EKS actually give you portability off AWS?Partially. The workload manifests port cleanly; the seams do not. IAM-based pod identity, ALB ingress, EBS and EFS storage classes, and Route 53 integration are all AWS-specific and have to be re-implemented on another platform. Claiming portability means committing to keep those seams thin, which is a design discipline rather than a property of Kubernetes.
saying these in an interview costs you the question
- Picks EKS because Kubernetes is the industry standard, with no workload reason
- Thinks ECS cannot use Fargate or cannot autoscale
- Ignores the per-cluster charge and the recurring upgrade obligation
- Claims EKS is portable while depending on ALB ingress and IAM pod identity
- Assumes EKS is required for per-workload IAM permissions