ECS or EKS? The Right Choice Depends on the Problem

There is no single best choice between Amazon ECS and Amazon EKS. Both can run containers in production. The right choice depends on the problem you need to solve and on the team that will support the platform after it goes live. In this post I share how I made this decision for one request, the costs I look at, and the questions I use.

The request

I got a request to deploy some services quickly. The request was basically: “we need a way to deploy these services fast, can you prepare something?” There were not many details yet. I did not know how many services there would be, or which connections they would need. I also did not know which backing services they would depend on, like databases, Redis or message queues.

My first thought was Kubernetes. Then I asked myself: what if we only need to deploy two or three services? Is Kubernetes worth the effort for that? To be honest, setting up either ECS or EKS would have been quick. The harder question was: do we have the capacity to support another Kubernetes cluster over time?

Our team already supports other clusters. Those clusters were not available for these services, so the practical choice was between creating a new EKS cluster and using ECS. We did not have the capacity to support another Kubernetes cluster, so for us the answer was no. The rest of this post explains why that question matters so much.

What is different between ECS and EKS

	Amazon ECS	Amazon EKS
Control plane cost	No charge, you pay for Fargate or EC2	$0.10 per cluster per hour (about $73 per month)
Cost if you fall behind on versions	Not applicable, ECS has no cluster version	$0.60 per cluster per hour in extended support (about $438 per month)
Upgrades	No cluster version to upgrade. On Fargate, AWS patches the infrastructure. On EC2, you update the AMIs and the ECS agent.	A new Kubernetes minor version about every four months. You start each upgrade, one minor version at a time, and you also upgrade nodes and add-ons.
AWS integrations	Load balancers, IAM roles, secrets and logs are set in the service and task definitions	Many integrations need add-ons or controllers
Ecosystem	AWS services	Kubernetes tools like Helm charts, operators and CRDs
Portability	Service and task definitions are AWS-specific	Kubernetes workloads can move to other clusters, with changes for the AWS-specific parts
Concepts to learn	Clusters, services, task definitions	Pods, Deployments, Services, Ingress, RBAC, CRDs and more

Prices are for the standard EKS control plane as of September 2026. ECS Managed Instances and ECS Anywhere have their own fees, and EKS has optional larger control plane tiers. Check the pricing pages for your case.

The control plane fee is the easiest number to see, but it is small compared with the cost of engineering time. The extended support price is more important. On EKS, each Kubernetes version gets 14 months of standard support. After that, the cluster moves to extended support, which is enabled by default and costs six times more. After 12 more months, EKS upgrades the cluster automatically. If nobody owns upgrades, you pay more first, and then you get an upgrade you did not plan.

Running Kubernetes is more than the cluster

An EKS cluster on its own is not ready for most applications. To make it work, you install and maintain add-ons and other tools. A typical cluster uses:

Networking and DNS: Amazon VPC CNI, kube-proxy and CoreDNS (installed by default)
Load balancing: AWS Load Balancer Controller, to create ALBs and NLBs
Node autoscaling: Karpenter or Cluster Autoscaler
AWS permissions for pods: EKS Pod Identity Agent, or IAM roles for service accounts
Storage: Amazon EBS CSI driver, if you need persistent volumes
Secrets: Secrets Store CSI Driver with the AWS provider, or External Secrets Operator
Metrics and logs: Metrics Server, plus the CloudWatch Observability agent or another monitoring stack

Each of these has its own version, configuration and compatibility rules. Several of them run as DaemonSets, so they use CPU and memory on every node. On small nodes, this overhead is a bigger part of what you pay for.

On ECS, most of this is part of the service. You set the load balancer target group in the service definition, give the task an IAM role, reference secrets from Secrets Manager or Parameter Store in the task definition, and send logs to CloudWatch with the awslogs driver. There is no controller to install or upgrade for these.

EKS Auto Mode removes a lot of this work. AWS manages compute autoscaling, networking, load balancing, DNS, block storage and node patching. It adds a fee per instance on top of the EC2 price, plus the normal cluster fee. In AWS’s own pricing example, that fee is about 12% of the On-Demand instance price. With Auto Mode you still start Kubernetes version upgrades, test your applications, and maintain any other add-ons you install.

The engineering cost

A significant cost of Kubernetes may not appear directly on the AWS bill: it is the engineering time required to operate the platform safely. With standard EKS, teams must:

Follow the Kubernetes release cycle and upgrade one minor version at a time
Check for deprecated APIs and test applications before each upgrade
Upgrade nodes and add-ons, and confirm they work with the new version
Patch nodes or roll out new AMIs
Monitor the cluster and respond to issues when they happen
Keep enough Kubernetes knowledge in the team, so the work does not depend on one person

This work repeats for every cluster, and it continues after the project that created the cluster is finished. AWS’s decision guide also describes organizations that run Kubernetes as teams that invest in strong SRE practices and handle frequent cluster upgrades. When you compare ECS and EKS, count these hours, not only the control plane price.

The questions I ask

I use four questions, in this order. The first one with a clear answer usually decides.

1. What is the rest of the solution built on?

If the platform already uses AWS services like ALB, RDS, SQS, Secrets Manager and CloudWatch, ECS fits in with the same IAM setup, the same infrastructure code and the same logging. EKS works with all of these too, but usually through add-ons. If your organization already runs Kubernetes and has the capacity to support one more cluster, the answer can change. In that case, another EKS cluster may be a smaller step than adding ECS as a new platform.

2. Which one can we ship sooner, and support after that?

Look at the time to get working software to users, and also at who will support it after it goes live. A team with Kubernetes experience and time for one more cluster can ship quickly on EKS and support it well. A team without that capacity will usually do better with ECS.

3. Is there a requirement that only Kubernetes covers?

Sometimes the decision is clear. For example:

Software that is only shipped as Helm charts or Kubernetes operators
Workloads that depend on custom resources (CRDs) and controllers
Multi-tenant clusters with namespaces, RBAC and quotas for each team
A service mesh with more features than ECS Service Connect, like Istio
The same Kubernetes API across AWS, on-premises and other clouds

Most of these are about the Kubernetes ecosystem, not about running containers.

4. If it is still a tie, choose the simpler option

When the first three questions do not decide it, I choose the option with fewer parts to run. Fewer parts means fewer things to upgrade, fewer things that can fail, and less for new team members to learn.

If your team is not ready to support Kubernetes

This is common, and it is not a problem by itself. It is a limit to plan around. Some options:

Start with ECS on Fargate. There is no cluster version to upgrade, and AWS patches the infrastructure. You can move to Kubernetes later if a real requirement appears.
If you need Kubernetes, reduce the work. EKS Auto Mode manages nodes, autoscaling, load balancing and storage. Managed EKS add-ons and managed node groups also help.
Make ownership clear. Decide who owns upgrades and add-ons before the cluster goes live.
Write an upgrade runbook and test upgrades first. AWS recommends testing upgrades in a non-production environment. EKS cluster insights can show deprecated APIs and other issues before you upgrade.
Plan time for learning. Give the team time to learn Kubernetes with non-critical workloads before moving important services.
Add clusters only when you need them. Every cluster adds upgrades, add-ons and monitoring work.

How it worked out in my case

Going back to the request, this is how the four questions looked:

The rest of the solution: the backing services were not defined yet, and ECS connects to AWS services without extra add-ons.
Ship and support: both options could be set up quickly, but we did not have the capacity to support another Kubernetes cluster.
Kubernetes-only requirements: nothing in the request needed Kubernetes-specific features.
Simpler option: ECS was also the option with fewer parts to run.

We went with ECS on Fargate. It gave us a way to deploy the services quickly, with no cluster versions or nodes to maintain. If the requirements grow and a real need for Kubernetes appears, we can review the decision. Container images run on both platforms, so changing later is possible, although it takes some migration work.

Conclusion

ECS is not better than EKS, and EKS is not better than ECS. For this request, with little information and limited capacity for more Kubernetes work, ECS was the right choice. For a team with Kubernetes experience and time to support another cluster, or for a workload that needs the Kubernetes ecosystem, EKS can be the right choice. AWS’s own guidance says the same thing: choose the container service that fits your application requirements and operational preferences. Start from the problem and the team, and then choose the service.