AWS ECS vs EKS

AWS gives you two container orchestrators. They solve the same problem and the choice between them is mostly about team and ecosystem rather than capability. Both will run your containers reliably at scale.

The honest summary: ECS is simpler and cheaper; EKS is portable and has a far larger ecosystem.

The comparison that matters

Choose ECS when

• You are AWS-only and expect to stay that way.
• The team has no Kubernetes experience and no appetite for acquiring it.
• You want the lowest operational overhead. There is genuinely very little to run.
• Cost matters and you would be running several small clusters.

ECS is frequently the right answer and frequently dismissed for the wrong reason, which is that Kubernetes is what people have heard of. A team of four running a dozen services does not need Kubernetes, and will spend real time on it.

Choose EKS when

• You need portability, or run workloads across clouds or on-premises.
• You want the Kubernetes ecosystem. Helm charts, operators, ArgoCD, Istio, Prometheus.
• The team already knows Kubernetes.
• You are large enough to have a platform function that can own a cluster properly.

The ecosystem argument is the strongest one. Almost every infrastructure tool ships a Helm chart; far fewer ship an ECS task definition.

Core concepts side by side

An ECS task definition

{
  "family": "payments-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::111122223333:role/paymentsTaskRole",
  "containerDefinitions": [{
    "name": "api",
    "image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/payments-api:1.4.2",
    "portMappings": [{ "containerPort": 8080 }],
    "secrets": [{
      "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:eu-west-1:111122223333:secret:prod/db-AbCdEf:password::"
    }],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/payments-api",
        "awslogs-region": "eu-west-1",
        "awslogs-stream-prefix": "ecs"
      }
    }
  }]
}

The two IAM roles are the thing people get wrong. The task execution role is used by the ECS agent to pull the image from ECR and write logs to CloudWatch. The task role is what your application code uses to call AWS. Putting your application's S3 permissions on the execution role does not work, and the symptom, image pulls and logging succeed while your code gets AccessDenied, is confusing until you know the split.

Fargate: no servers either way

Both ECS and EKS can run on Fargate, which removes node management entirely. You specify CPU and memory per task or pod; AWS provisions the compute.

Fargate's constraints are real. No DaemonSets means most observability agents cannot run as designed, which catches teams out on EKS. You need a sidecar or a different collection approach. No privileged containers means no Docker-in-Docker builds.

The pricing crossover is roughly this: bursty, intermittent or low-volume workloads are cheaper on Fargate because you pay nothing between tasks. Steady 24/7 load is cheaper on reserved or Spot EC2 capacity.

What EKS actually costs

The $0.10/hour control plane charge is per cluster, which shapes architecture. A cluster per team per environment adds up quickly. Six clusters is around $440/month before a single pod runs.

Add worker nodes, a NAT gateway, load balancers and cross-AZ transfer, and a modest production EKS setup typically lands around $300 to 500/month. ECS has no equivalent baseline.

That difference matters most at small scale. At large scale it disappears into the compute bill.

What you actually operate

This is the part that decides how much time the choice costs you.

ECS: task definitions, services, capacity providers. Upgrades are AWS's problem. There is genuinely not much else.

EKS: everything above, plus Kubernetes version upgrades roughly annually before support expires, the CNI and its IP address arithmetic, an ingress controller, cluster autoscaling with Karpenter or Cluster Autoscaler, RBAC and access entries, add-on lifecycle, and a steady stream of ecosystem components to keep current.

None of that is hard individually. Together it is a part-time job, and it needs an owner.

The third option

App Runner deploys a container or a repository directly to a managed URL with automatic scaling and TLS. No cluster, no task definitions, no load balancer configuration.

For a straightforward HTTP service it is dramatically less work than either ECS or EKS, and it is worth ruling out deliberately before reaching for an orchestrator. The limits are real. Less control over networking, fewer configuration options, per-request pricing that suits variable traffic, but a great many web services fit inside them.

A decision in one paragraph

If a single containerised web service is all you need, try App Runner. If you are AWS-only and want minimal operational load, use ECS with Fargate. If you need portability or the Kubernetes ecosystem and have someone to own a cluster, use EKS. Do not choose EKS because Kubernetes is on job adverts. Choose it because you need what it does.

Go deeper in this section

Quick reference

---

Key takeaways

• ECS is simpler and has no control plane cost; EKS is portable with a far larger ecosystem.
• The EKS control plane is ~$73/month per cluster, which makes a cluster-per-team-per-environment pattern expensive.
• ECS has two IAM roles. Task execution role for the agent, task role for your code. They are not interchangeable.
• Fargate removes node management but supports no DaemonSets and no privileged containers.
• Fargate is cheaper for spiky load, EC2 cheaper for steady load.
• EKS adds real operational work: version upgrades, CNI, ingress, autoscaling, add-ons.
• Consider App Runner first for a single HTTP service.

---

Check your understanding

---

Frequently Asked Questions

Should I use ECS or EKS?

Use ECS if you are AWS-only, want minimal operational overhead, and the team has no Kubernetes experience. It is simpler, has no control plane charge, and there is genuinely little to run. Use EKS if you need portability across clouds, want the Kubernetes ecosystem of Helm charts, operators and tooling, or already have Kubernetes expertise. Both run containers reliably at scale; the decision is about team and ecosystem rather than capability.

How much does EKS cost compared to ECS?

The EKS control plane is about $0.10 per hour per cluster, roughly $73 a month, before any compute. ECS has no control plane charge at all. Both then charge for the underlying compute, whether EC2 or Fargate, plus load balancers, NAT gateways and data transfer. The difference matters most for small deployments and for organisations running many clusters. Six EKS clusters cost around $440 a month in control plane fees alone. At large scale the gap disappears into the compute bill.

What is the difference between the ECS task role and task execution role?

The task execution role is assumed by the ECS agent to pull container images from ECR and write logs to CloudWatch. It is infrastructure-level. The task role is assumed by the code inside your container to call AWS APIs. If image pulls and logging work but your application gets AccessDenied, the permissions were added to the execution role and belong on the task role. This is the single most common ECS configuration mistake.

Should I use Fargate or EC2 for my containers?

Fargate when you want no node management and your workload is spiky, intermittent or low-volume, since you pay nothing between tasks. EC2 when load is steady around the clock, where reserved or Spot instances are meaningfully cheaper, or when you need something Fargate does not support. DaemonSets, privileged containers, GPU workloads, or very large instance sizes. Many teams run a mix, with Fargate for bursty jobs and EC2 for the steady baseline.

Can I migrate from ECS to EKS later?

Yes, but it is a rewrite of your deployment layer rather than a lift and shift. The containers themselves are unchanged, the same image runs on both, but task definitions become Kubernetes manifests, ECS services become Deployments and Services, and your CI/CD, service discovery, secrets injection and monitoring all need reworking. Plan it as a project. If portability is a genuine near-term requirement, starting on EKS is cheaper than migrating to it.

Is there a simpler option than either?

AWS App Runner deploys a container image or a source repository directly to a managed HTTPS endpoint with automatic scaling, no cluster, no task definitions and no load balancer to configure. For a single web service it is dramatically less work than either orchestrator. The trade-offs are less networking control, fewer configuration options and per-request pricing, but a great many straightforward web applications fit comfortably within them. It is worth ruling out deliberately before choosing an orchestrator.