AWS comparison
EKS vs ECS: How to Choose a Container Platform on AWS
Choose Amazon ECS when you want AWS to run the orchestrator for you and you do not need the Kubernetes API. Choose Amazon EKS when you need Kubernetes itself, its tooling such as Helm and operators, or a workload you may move off AWS later. The control plane fee is the smaller difference; the operating model is the bigger one.
By Muhammad Soliman, Founder at SeaGit
·
Key takeaways
- EKS charges per cluster per hour for the control plane, at $0.10 per cluster per hour on standard support. ECS charges no orchestration fee; you pay for the compute.
- EKS on older Kubernetes versions moves to extended support at $0.60 per cluster per hour, so keep clusters on a supported version.
- Fargate bills per vCPU and memory from image pull until the task or pod stops, with a one-minute minimum. That applies to both services.
- Pick EKS for the Kubernetes API and ecosystem. Pick ECS for AWS-native simplicity with fewer components to run.
What you pay, line by line
The EKS pricing page lists a per-cluster, per-hour fee that depends on the Kubernetes version. Standard support costs $0.10 per cluster per hour. Extended support costs $0.60 per cluster per hour. Over a 730-hour month, the standard fee is about $73 per cluster before any compute.
The ECS pricing page says there is no additional charge for ECS orchestration. You pay for the compute: Fargate by vCPU and memory, or EC2 instances and their storage and IP addresses. ECS Managed Instances add their own per-instance management fee.
| Cost item | EKS | ECS |
|---|---|---|
| Control plane | $0.10 per cluster per hour (standard support) | No orchestration fee |
| Fargate compute | Per vCPU and memory per pod, one-minute minimum | Per vCPU and memory per task, one-minute minimum |
| EC2 nodes | EC2, EBS and IPv4 billed by their own services | EC2, EBS and IPv4 billed by their own services |
The control plane fee is small next to a few EC2 nodes. The real cost is engineering time: an EKS cluster needs upgrades, add-ons, ingress and node management. ECS has fewer of those moving parts.
The operating model is the real difference
The EKS overview describes Amazon EKS as a managed Kubernetes control plane, with your workloads on worker nodes you run, Fargate or managed node groups. That means you use Kubernetes objects, controllers and the wider ecosystem. ECS has its own task definitions and services, and it is AWS-specific.
- Helm charts, Kubernetes operators, and tools that expect the Kubernetes API need EKS.
- A task definition and an ECS service cover most web workloads with less to learn.
- Portability: EKS manifests move between Kubernetes distributions with few changes. An ECS task definition is an AWS format.
# EKS: the cluster and its control plane are a separate resource
aws eks describe-cluster --name prod --query 'cluster.version'
# ECS: no cluster-level fee; list the services in a cluster
aws ecs list-services --cluster prodDecision rule
Choose ECS when
- The team has no Kubernetes experience and does not want to learn it now.
- The workload is a set of services that talk over load balancers, and AWS-native IAM and task roles cover your needs.
- You want the lowest number of components to patch.
Choose EKS when
- You already run Kubernetes elsewhere and want one set of manifests and tools.
- You need Helm charts, custom controllers, or an operator-based database.
- You may run on another cluster later, or on-premises with the same manifests.
Watch the version
On EKS, a cluster on an older Kubernetes version moves to extended support at $0.60 per cluster per hour. That is about $438 a month per cluster before compute. Upgrade on the AWS schedule, and check the version of every cluster in a fleet, not only the ones you touch.
Where SeaGit fits
SeaGit provisions a managed Kubernetes cluster on Amazon EKS in your own AWS account, so the EKS path is the one this site describes. The comparison above is AWS-only and does not cover other clouds.