ECS vs EKS, in depth: the concept map, networking, identity, upgrade burden and real cost, with a decision procedure and a migration path

What is actually different

Strip away the compute and three differences remain. API and ecosystem: ECS resources (clusters, task definitions, services) are AWS API objects managed with the console, CLI, CloudFormation, CDK or Terraform. EKS exposes the Kubernetes API, so you use kubectl, Helm, operators, custom resources and the whole CNCF tool ecosystem, and your manifests are portable to other Kubernetes clusters. Operating model: ECS has no control-plane version for you to upgrade. EKS runs Kubernetes minor versions that each receive 14 months of standard support, then 12 months of extended support at a higher price, so upgrading every cluster regularly is a permanent job. Price of the control plane: ECS charges nothing for it. EKS charges per cluster-hour: $0.10 in standard support and $0.60 in extended support.

Everything else, including the instances, Fargate, load balancers, CloudWatch and VPCs, is shared. So the question is not which one runs containers better. It is which control plane and operating model fit your team and workloads.

Concept map

Compute choices under each

Both schedulers can place work on EC2 instances you manage, on Fargate, where each task or pod gets its own isolated micro-VM and you never see a host, or on instances AWS manages for you inside your account. For ECS that last option is ECS Managed Instances, launched in September 2025: you state vCPU, memory and architecture needs and ECS provisions and patches the EC2 instances, charging a management fee on top of the EC2 price. For EKS it is EKS Auto Mode, generally available since December 2024, which runs compute autoscaling, pod networking, load balancing and storage components for you, also for a per-node management fee on top of EC2.

Fargate removes host management on both but brings limits, such as no DaemonSets on EKS Fargate and no GPU tasks, and per-vCPU pricing that is higher than well-packed EC2. EC2 capacity is cheapest when you pack it well and use Spot, but you own the AMIs, the patching and the bin-packing. The compute decision is largely independent of the ECS-versus-EKS decision, and both give you the same three levels of host ownership.

Networking

On ECS, tasks in awsvpc mode (required on Fargate and the usual choice on EC2) each get their own elastic network interface, with a private IP from the subnet and their own security groups. The limit to watch on EC2 is ENIs per instance; ENI trunking raises it on supported instance types. On EKS, the default Amazon VPC CNI gives every pod an IP address from the VPC subnet, attached as secondary addresses on the node's ENIs. Pods are first-class VPC citizens, which is simple for routing and security groups, but a large cluster consumes subnet addresses fast. Prefix delegation, which assigns whole /28 prefixes to ENIs, raises pod density per node, and large estates plan dedicated subnets or secondary CIDR ranges for pods.

In practice ECS networking has fewer moving parts: there is no CNI add-on to version or upgrade, and security groups attach naturally per task. EKS networking is more flexible, since you can replace the CNI, use network policies and run a service mesh, but every one of those is a component you run and upgrade.

Identity

An ECS task definition names two roles: the execution role the ECS agent uses to pull images and write logs, and the task role whose credentials the application receives. On EKS two layers are involved. Humans and pipelines get into the cluster through access entries that map IAM principals to Kubernetes permissions, and pods get AWS credentials through EKS Pod Identity, which associates an IAM role with a Kubernetes service account, or the older IRSA mechanism based on OIDC federation. The EKS model is more powerful, since Kubernetes RBAC governs everything inside the cluster, but it means two permission systems to audit instead of one.

# ECS: the role is part of the task definition
"taskRoleArn": "arn:aws:iam::111122223333:role/orders-api",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecution"

# EKS: bind the role to a service account with Pod Identity
aws eks create-pod-identity-association \
  --cluster-name prod --namespace orders \
  --service-account orders-api \
  --role-arn arn:aws:iam::111122223333:role/orders-api

The same service, defined both ways

An HTTP API with three replicas, 0.5 vCPU and 1 GiB each, behind a load balancer. On ECS, a task definition and a service:

{
  "family": "orders-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512", "memory": "1024",
  "taskRoleArn": "arn:aws:iam::111122223333:role/orders-api",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecution",
  "containerDefinitions": [{
    "name": "api",
    "image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders-api:1.42.0",
    "portMappings": [{"containerPort": 8080}],
    "healthCheck": {"command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"]}
  }]
}

aws ecs create-service --cluster prod --service-name orders-api \
  --task-definition orders-api --desired-count 3 --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-a,subnet-b],securityGroups=[sg-orders]}" \
  --load-balancers "targetGroupArn=<tg-arn>,containerName=api,containerPort=8080"

On EKS, a Deployment and a Service; an Ingress handled by the AWS Load Balancer Controller would add the ALB:

apiVersion: apps/v1
kind: Deployment
metadata: {name: orders-api, namespace: orders}
spec:
  replicas: 3
  selector: {matchLabels: {app: orders-api}}
  template:
    metadata: {labels: {app: orders-api}}
    spec:
      serviceAccountName: orders-api        # Pod Identity association
      containers:
      - name: api
        image: 111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders-api:1.42.0
        ports: [{containerPort: 8080}]
        resources:
          requests: {cpu: 500m, memory: 1Gi}
          limits: {memory: 1Gi}
        readinessProbe: {httpGet: {path: /health, port: 8080}}
---
apiVersion: v1
kind: Service
metadata: {name: orders-api, namespace: orders}
spec:
  selector: {app: orders-api}
  ports: [{port: 80, targetPort: 8080}]

The container image is identical. What changes is the surrounding description, and on EKS the set of cluster components (the load balancer controller, DNS, the CNI) that must already be installed and kept current.

The upgrade cycle and the real cost

Direct control-plane cost is easy to compute. At about 730 hours per month, one EKS cluster in standard support costs about $73 a month. An estate of three environments in two regions is six clusters, about $438 a month, which is rarely decisive. If those clusters slip into extended support, the rate becomes $0.60 an hour, about $438 a month per cluster and about $2,628 for the six. That penalty exists to make you upgrade.

The real cost is people. Kubernetes releases minor versions a few times a year, so with 14 months of standard support each cluster needs roughly one or two upgrades a year. Each upgrade means reading deprecations, updating manifests and Helm charts, upgrading add-ons (VPC CNI, CoreDNS, kube-proxy, the load balancer controller, Karpenter or cluster autoscaler) in a compatible order, and rolling the nodes. Assume, for illustration, three engineer-days per cluster upgrade plus a platform team's steady-state time for controllers and policies. On six clusters that is several engineer-weeks a year, dwarfing the $438 fee. ECS has no equivalent control-plane upgrade; its recurring work is AMI and agent updates on EC2 capacity, which Fargate and Managed Instances take over.

A decision procedure

Ask the questions in order; the first decisive answer usually settles it.

def choose(team):
    # 1. Hard requirements that only Kubernetes meets
    if team.needs_k8s_api or team.uses_operators_or_crds or team.multi_cloud_portability:
        return "EKS"
    # 2. Existing investment
    if team.has_platform_team and team.runs_kubernetes_elsewhere:
        return "EKS"
    # 3. Capacity to run it: someone must own upgrades and add-ons
    if team.platform_engineers < 2:
        return "ECS"
    # 4. Workload shape
    if team.mostly_stateless_http_and_workers and team.all_in_on_aws:
        return "ECS"
    return "EKS" if team.wants_cncf_ecosystem else "ECS"

In words: choose EKS when you need the Kubernetes API itself, meaning operators, custom resources, Helm-distributed third-party software, portability or an existing Kubernetes skill base. Choose ECS when the workloads are ordinary services and workers on AWS, the team is small, and nobody's job is to run a platform. Running both is legitimate: many organisations run ECS for simple services and EKS for the platforms that need Kubernetes, such as data and ML tooling.

Worked example: moving a service between them

A team runs 40 services on ECS and has decided, because it is adopting operator-based data platforms, to consolidate on EKS. Services move one at a time, and the load balancer does the cutover. For each service, deploy it to EKS with a Pod Identity role equivalent to its ECS task role, register its pods in a second target group through the load balancer controller, and put both target groups behind the existing ALB listener rule with weights. Shift traffic 1%, 10%, 50% and then 100% while watching error rates and latency, and keep ECS capacity at full size until the service has been stable for a few days.

The traps are predictable. IAM permissions differ subtly between the task role and the pod's role. Security-group rules for pods need the security-groups-for-pods feature or node-level groups. Health checks move from task definitions to readiness probes. Log routing changes from awslogs or FireLens to a cluster log agent. The reverse move, from EKS to ECS, follows the same weighted pattern and is common when a small team finds the upgrade burden outweighs what it uses from Kubernetes.

Failure modes and trade-offs

• Kubernetes without a platform owner. Clusters fall behind, drift into extended support at six times the price, and upgrades become risky big-bang events.
• ECS for platform-shaped problems. Teams rebuild operators and CRDs with Lambda functions and step functions; if you need extensibility, EKS is cheaper in the end.
• Pod IP exhaustion. EKS clusters in small subnets stop scheduling pods. Plan CIDRs and prefix delegation up front.
• ENI limits on ECS EC2 capacity. Without trunking, awsvpc tasks per instance are capped by ENIs, not CPU.
• Comparing only compute prices. The compute is the same; the difference is people and the control plane.

What to do next

1. List your workloads and mark any that need the Kubernetes API, operators or portability.
2. Count the engineers who would own cluster upgrades and add-ons; if the answer is under two, default to ECS.
3. Price the estate: clusters times $73 a month, plus your estimate of upgrade effort per cluster per year.
4. Pick the compute level separately: EC2, Fargate, or ECS Managed Instances or EKS Auto Mode.
5. Plan networking (task ENIs or pod CIDRs) and IAM (task roles or Pod Identity) before the first deployment.
6. If you are migrating, use weighted ALB target groups and move one service at a time.
7. Keep learning: ECS in depth, EKS in depth, Fargate, VPC design and IAM.