ECS vs EKS: The Enterprise Decision Framework Beyond Buzzwords

Business Challenge

A retail e-commerce company migrated from VMs to containers two years ago. They chose EKS because the engineering blog posts they read were all about Kubernetes, and the senior architects wanted something "portable." Today they run 45 microservices on three EKS clusters. They have four platform engineers. Two of them spend most of their time on cluster operations: CoreDNS tuning, VPC CNI upgrades, kube-proxy compatibility, node group AMI patching, Cluster Autoscaler configuration drift.

The other team — a fintech startup — made the opposite call. They chose ECS with Fargate across 60 microservices. Their platform team of two handles task definition updates, service scaling policies, and ALB routing rules. When AWS releases a Fargate runtime update, they do nothing. Their two platform engineers ship product features.

Neither team made a wrong decision given their constraints at the time. But the retail team made a decision based on prestige and perceived portability, not operational fit. The fintech team made a decision based on what they actually needed to run.

Architecture

ECS and EKS solve the same problem — running containers at scale — but at different layers of the stack. ECS is an opinionated AWS-native orchestrator. EKS is managed Kubernetes: the control plane is AWS-managed, but the add-on layer, the node management, and the Kubernetes API surface are yours to operate.

ECS: what AWS owns versus what you own

EKS: what AWS owns versus what you own

EKS manages the Kubernetes control plane — the API server, etcd, controller manager, and scheduler. Everything else is yours: worker nodes, CNI plugin, CoreDNS, kube-proxy, Cluster Autoscaler or Karpenter, load balancer controller, metrics-server, Fluent Bit or Fluentd, storage classes, RBAC policies, and the upgrade path for all of it.

Why This Decision Framework Works

Operational complexity budget is finite

Every platform team has a fixed capacity for operational complexity. EKS consumes more of that budget than ECS. The question is whether the capabilities EKS provides — custom schedulers, DaemonSets, StatefulSets with persistent volumes, Kubernetes-native tooling (Helm, ArgoCD, Kyverno) — are worth the draw-down. For most web API workloads, they are not.

Portability is a real option cost

The most common justification for EKS is portability: "we might need to run on GCP or Azure later." This is worth interrogating. Moving from EKS to GKE requires rewriting your IAM roles (IRSA → Workload Identity), your load balancer annotations, your storage classes, your secrets integration, and your networking policies. The Kubernetes YAML is portable; the AWS-specific integrations are not. If multi-cloud is a real requirement in the next 18 months, EKS is the right call. If it is hypothetical, you are paying the complexity tax for an option you may never exercise.

ECS integrates natively with AWS services

ECS task roles give containers IAM credentials without any additional tooling — no IRSA configuration, no webhook, no service account annotation. ECS Service Connect gives you service-to-service observability without deploying a service mesh control plane. ECS integrates with CodeDeploy for blue/green deployments natively. These integrations exist in EKS, but they require additional components and configuration.

Key Design Decisions

Tradeoffs and Alternatives

Reference: ECS Service with Fargate and Service Connect

A minimal ECS service configuration using Fargate with Service Connect enabled for service-to-service discovery:

resource "aws_ecs_service" "api" {
  name            = "payments-api"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 3
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.api.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.api.arn
    container_name   = "payments-api"
    container_port   = 8080
  }

  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_http_namespace.main.arn

    service {
      port_name      = "http"
      discovery_name = "payments-api"
      client_alias {
        port     = 8080
        dns_name = "payments-api"
      }
    }
  }
}

With Service Connect enabled, other ECS services in the same namespace reach this service at http://payments-api:8080 — no service discovery client, no Route 53 lookup, no sidecar configuration required beyond the service definition.

Closing Thought

The ECS vs EKS decision is not a technical question with a universally correct answer. It is an organisational capacity question: how much operational complexity can your platform team absorb while still shipping product? ECS with Fargate is not a lesser version of EKS — it is a deliberate choice to let AWS own the orchestration layer so your team can own the product layer.

The teams that regret EKS adoptions are not the ones who needed Kubernetes capabilities. They are the ones who adopted it before they had the team size and operational maturity to benefit from those capabilities. The teams that regret ECS adoptions are the ones who hit a ceiling — DaemonSet requirements, complex scheduling, or a real multi-cloud requirement — that ECS genuinely cannot address.

The decision framework is simple: start with the four signals. If your operational complexity budget is low, workloads are standard web services, team is under four platform engineers, and multi-cloud is hypothetical — choose ECS. If two or more signals point the other way, choose EKS and invest in the platform team to operate it properly.

Official AWS Reference

AWS Documentation — Amazon ECS Developer Guide — covers task definitions, service configuration, capacity providers, Service Connect, and Fargate launch type constraints. The capacity provider strategy section is particularly useful for understanding the Fargate/EC2 mix pattern.