ECS is underrated. Most teams picking EKS don’t need it. I’ve been saying this for years, and I’ll keep saying it until the industry stops treating Kubernetes as the default answer to every container question.

I watched a team — smart engineers, solid product — choose EKS for what was essentially a three-service CRUD application behind an ALB. They’d read the blog posts, watched the conference talks, and decided Kubernetes was the future. Three months later they were still stabilizing the cluster. Not building features. Not shipping value. Debugging Helm chart conflicts, fighting with the AWS VPC CNI plugin, and trying to understand why their pods kept getting evicted. The application itself worked fine. The orchestration layer was the problem.

They eventually got it running. But those three months cost them a release cycle, burned out two engineers, and the platform they built was more complex than anything the application demanded. When I helped them evaluate what they actually needed, we could’ve had the same workload running on ECS in a week. Maybe less.

That’s not an anti-Kubernetes take. I run EKS clusters in production. I’ve written about EKS cluster setup with private nodegroups and Kubernetes deployment strategies. Kubernetes is genuinely powerful when you need what it offers. The problem is that most teams don’t need what it offers, and they pay a steep tax for capabilities they’ll never use.

Architecture: Two Very Different Philosophies

ECS and EKS solve the same problem — run containers reliably at scale — but they come at it from opposite directions.

ECS is AWS-native. It’s a proprietary orchestrator built by AWS, deeply integrated with IAM, ALB, CloudWatch, Service Connect, and the rest of the ecosystem. You define task definitions (what to run) and services (how to run them). That’s roughly it. There’s no separate control plane to manage, no etcd cluster to worry about, no API server to secure. AWS handles all of that.

A minimal ECS service in Terraform looks like this:

resource "aws_ecs_service" "api" {
  name            = "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_subnets
    security_groups = [aws_security_group.api.id]
  }

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

That’s a production-ready service definition. Three tasks behind a load balancer, running on Fargate, in private subnets. You can deploy this in minutes.

EKS is Kubernetes on AWS. It’s the full Kubernetes API — pods, deployments, services, ingresses, namespaces, RBAC, CRDs, operators, the whole thing. AWS manages the control plane (the API server, etcd, scheduler), but you’re responsible for everything else: node groups or Fargate profiles, networking plugins, ingress controllers, service meshes, monitoring stacks, and the endless YAML that ties it all together.

The equivalent deployment in Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: 123456789.dkr.ecr.us-east-1.amazonaws.com/api:latest
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

And you still need an Ingress resource, an ingress controller (probably the AWS Load Balancer Controller), proper RBAC, a namespace, resource limits, and a dozen other things before this is production-ready. That’s not a criticism — it’s the reality of what Kubernetes requires.

Fargate vs EC2 Launch Types: The Compute Decision

Both ECS and EKS support Fargate and EC2-backed compute. But the experience is wildly different.

ECS on Fargate is the simplest path to running containers on AWS. No instances to patch, no AMIs to maintain, no capacity planning. You specify CPU and memory in your task definition, and AWS handles the rest. I’ve written about ECS task placement strategies for EC2-backed clusters, but honestly, Fargate has eliminated the need for most teams to think about placement at all.

# Register a Fargate task definition
aws ecs register-task-definition \
  --family api \
  --requires-compatibilities FARGATE \
  --network-mode awsvpc \
  --cpu 512 \
  --memory 1024 \
  --container-definitions '[{
    "name": "api",
    "image": "123456789.dkr.ecr.us-east-1.amazonaws.com/api:latest",
    "portMappings": [{"containerPort": 8080}],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/api",
        "awslogs-region": "us-east-1",
        "awslogs-stream-prefix": "ecs"
      }
    }
  }]'

EKS on Fargate works but feels bolted on. Each pod runs in its own Firecracker microVM, which means no DaemonSets, no privileged containers, and you need Fargate profiles to map namespaces and labels to Fargate. It’s fine for simple workloads, but you lose a lot of Kubernetes functionality. EKS Auto Mode, introduced in late 2024, has improved this story significantly — AWS manages the nodes, picks instance types, handles patching — but it’s still more moving parts than ECS Fargate.

EC2 launch type makes sense when you need GPU instances, have sustained high-utilization workloads where Reserved Instances or Savings Plans make Fargate look expensive, or need specific instance families. On ECS, you manage an Auto Scaling group and capacity providers handle the rest. On EKS, you’re managing node groups (or Karpenter, which I’d recommend over the Cluster Autoscaler at this point).

For most teams running standard web services and APIs? ECS on Fargate. Don’t overthink it.

Networking: Simple vs Flexible

Networking is where the complexity gap between ECS and EKS becomes really obvious.

ECS has one networking mode that matters in 2026: awsvpc. Every task gets its own ENI with a private IP in your VPC. Traffic flows through standard AWS networking — security groups, NACLs, VPC flow logs, all the stuff you already know. I covered the different modes in understanding ECS network modes, but awsvpc is the only one you should be using with Fargate, and it’s the right default for EC2 launch type too.

Service-to-service communication? ECS Service Connect handles it natively. It gives you service discovery with automatic DNS and optional traffic management, all configured in your service definition. No sidecars to manage, no mesh to deploy.

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

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

    service {
      port_name      = "http"
      client_alias {
        port     = 80
        dns_name = "api"
      }
    }
  }

  network_configuration {
    subnets         = var.private_subnets
    security_groups = [aws_security_group.api.id]
  }
}

EKS networking is a different beast. The AWS VPC CNI plugin assigns pod IPs from your VPC subnets, which is great for integration with other AWS services but means you need to plan your IP address space carefully. I’ve seen teams run out of IPs in their subnets because they didn’t account for the pod density. You can enable prefix delegation to mitigate this, but it’s another thing to configure.

Then there’s the service mesh question. Kubernetes gives you Services and Ingress natively, but for anything beyond basic load balancing you’re looking at an ingress controller (AWS Load Balancer Controller, Nginx, Traefik), possibly a service mesh (Istio, Linkerd), network policies for microsegmentation, and custom DNS configurations. Each layer adds power and complexity in equal measure.

If your networking needs are “services talk to each other and sit behind a load balancer,” ECS gives you that out of the box. If you need fine-grained traffic splitting, canary routing at the network level, or multi-cluster service mesh — that’s where Kubernetes earns its keep.

IAM: Night and Day

IAM integration is one of ECS’s strongest advantages, and it’s rarely discussed.

In ECS, every task can assume its own IAM role. You define a task_role_arn in your task definition, and that’s it. The task gets temporary credentials scoped to exactly what it needs. No shared node roles, no ambient credentials floating around. It works exactly like you’d expect AWS IAM to work.

resource "aws_iam_role" "api_task" {
  name = "api-task-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "ecs-tasks.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "api_dynamodb" {
  role       = aws_iam_role.api_task.name
  policy_arn = aws_iam_policy.dynamodb_read.arn
}

EKS uses IAM Roles for Service Accounts (IRSA) or the newer EKS Pod Identity to achieve the same thing. Both work, but they’re additional layers you have to set up. IRSA requires an OIDC provider, annotated service accounts, and trust policies that reference the OIDC issuer URL. Pod Identity is simpler but still requires creating associations between Kubernetes service accounts and IAM roles.

Neither is hard once you understand it. But ECS task roles are zero-configuration IAM — it just works the way every other AWS service works. That matters when you’re onboarding new team members or debugging permission issues at 2am.

Cost: The Math Most Teams Get Wrong

Here’s where the conversation gets interesting, because the sticker price comparison is misleading.

EKS control plane: $0.10/hour for standard support ($73/month per cluster). Extended support bumps that to $0.60/hour. That’s just the control plane — you still pay for compute.

ECS control plane: Free. Zero. You pay only for the compute your tasks consume.

That $73/month sounds trivial until you’re running multiple clusters across environments. Three clusters (dev, staging, prod) is $219/month before a single container runs. With extended support, that’s $1,314/month just for API servers.

But compute cost is where the real money is, and this is where teams get confused.

Fargate pricing is the same whether you’re on ECS or EKS. You pay per vCPU-hour and per GB-hour. As of writing, that’s roughly $0.04048 per vCPU-hour and $0.004445 per GB-hour in us-east-1 for Linux/x86. Graviton (ARM) instances are about 20% cheaper, and you should be using them unless you have a specific reason not to.

EC2 pricing is also the same underlying cost, but EKS has hidden overhead. The kube-system pods (CoreDNS, kube-proxy, VPC CNI) consume resources on your nodes. On a small cluster, that overhead is a meaningful percentage of your total capacity. ECS doesn’t have this — every bit of compute you pay for runs your workloads.

Here’s a rough comparison for a modest workload — six services, each running three tasks at 0.5 vCPU / 1GB memory:

ECS Fargate EKS Fargate EKS EC2 (managed nodes)
Control plane $0 $73/mo $73/mo
Compute (18 tasks) ~$265/mo ~$265/mo ~$180/mo (t3.medium x3)
System overhead None ~$30/mo Included but consumes capacity
Total ~$265/mo ~$368/mo ~$253/mo

EKS on EC2 can be cheaper at scale because you can bin-pack more efficiently and use Reserved Instances. But for small-to-medium workloads, ECS Fargate wins on total cost when you factor in the control plane fee and operational overhead.

And that table doesn’t account for the biggest cost of all: engineering time. If your team spends 20% of their time managing Kubernetes instead of building product, that’s the real expense. I’ve seen this pattern repeatedly when designing scalable systems in AWS — the orchestration layer shouldn’t be where your engineers spend their days.

Operational Overhead: Where Teams Actually Struggle

Running ECS in production means managing task definitions, services, and deployments. That’s a short list. ECS handles rolling deployments natively, including the new built-in blue/green deployments with bake times and automatic rollback. Health checks integrate directly with ALB target groups. Logging goes to CloudWatch. Monitoring uses Container Insights. It’s all… there.

Running EKS in production means managing all of the above plus: Kubernetes version upgrades (control plane and node groups separately), add-on compatibility matrices, ingress controller versions, cert-manager, external-dns, metrics-server, cluster autoscaler or Karpenter, RBAC policies, network policies, pod security standards, and whatever CRDs your team has installed. Every component has its own release cycle and its own breaking changes.

Kubernetes upgrades alone are a recurring tax. AWS drops support for older versions, and upgrading isn’t always smooth. You test in dev, find that one of your Helm charts uses a deprecated API, fix it, test again, then do staging, then prod. Multiply by however many clusters you run. I’ve seen teams dedicate an entire sprint to a minor version bump.

ECS doesn’t have this problem. There’s no orchestrator version to upgrade. AWS evolves the platform underneath you.

When ECS Wins

Pick ECS when:

  • Your team doesn’t have Kubernetes experience and you’d rather ship features than learn an orchestrator. ECS has a learning curve measured in days, not months.
  • You’re running a straightforward service architecture — APIs, workers, scheduled tasks behind load balancers. ECS handles this beautifully with minimal configuration.
  • You want the simplest possible IAM story. Task roles just work. No OIDC providers, no service account annotations.
  • You’re cost-sensitive at small scale. No control plane fee, no system pod overhead, and Fargate pricing is identical.
  • You’re an AWS-only shop. If you’re not running workloads on other clouds or on-prem, the portability argument for Kubernetes doesn’t apply to you.
  • You value operational simplicity. No cluster upgrades, no add-on compatibility matrices, no YAML sprawl.

I’d estimate 70% of the container workloads I’ve seen in production would be better served by ECS. That’s not a scientific number — it’s pattern recognition from years of consulting.

When EKS Wins

Pick EKS when:

  • Your team already knows Kubernetes. If you’ve got experienced K8s engineers, the operational overhead drops dramatically. Don’t make Kubernetes people learn a proprietary system when they’re already productive.
  • You need the Kubernetes ecosystem. Custom operators, CRDs, service meshes, advanced scheduling constraints, pod disruption budgets, topology-aware routing — this stuff doesn’t exist in ECS.
  • Multi-cloud or hybrid is real, not theoretical. If you’re genuinely running workloads across AWS, GCP, and on-prem, Kubernetes gives you a consistent API. But be honest about whether this is a current requirement or a “maybe someday.”
  • You need advanced deployment patterns. Argo Rollouts, Flagger, progressive delivery with traffic splitting — the Kubernetes ecosystem for deployment sophistication is unmatched. I covered some of these in K8s deployment strategies.
  • You’re running complex stateful workloads. Databases, message queues, ML training jobs with specific GPU scheduling — Kubernetes operators handle these patterns well.
  • You’re at serious scale. Hundreds of services, multiple teams, namespace-level isolation, resource quotas per team — Kubernetes multi-tenancy features start to matter.

The Decision Framework

Here’s how I walk teams through this decision:

Start with your team. If nobody on the team has run Kubernetes in production, that’s a 3-6 month investment before you’re comfortable. Is that investment worth it for your use case? Usually not.

Then look at your workload. Count your services. Map the communication patterns. If it’s fewer than 20 services with straightforward HTTP/gRPC communication, ECS handles it. If you’re building a platform that dozens of teams deploy to with complex scheduling requirements, EKS starts to make sense.

Then check your constraints. Multi-cloud mandate from leadership? EKS. Regulatory requirement for specific network isolation patterns? Evaluate both. Need to run the same orchestrator on-prem and in AWS? EKS (or EKS Anywhere).

Finally, be honest about portability. The “we might move to another cloud” argument has justified more EKS deployments than actual cloud migrations. Your Terraform modules, your CI/CD pipelines, your monitoring stack, your IAM policies — none of that is portable regardless of which orchestrator you pick. Kubernetes gives you portable workload definitions, but the infrastructure around them is always cloud-specific.

My Recommendation

If you’re starting a new project today and you don’t have a specific reason to choose Kubernetes, start with ECS on Fargate. You can have a production-ready deployment pipeline in a day. Your team can focus on the application instead of the platform.

If you outgrow ECS — and you’ll know when you do, because you’ll hit real limitations, not theoretical ones — migrating to EKS is straightforward. Your containers don’t change. Your Docker images don’t change. Your CI pipeline barely changes. You’re mostly rewriting deployment configuration, which is the easy part.

The reverse migration, from EKS to ECS, is equally doable but rarely happens because teams build dependencies on Kubernetes-specific features. That’s fine if you need those features. Just make sure you actually need them before you take on the complexity.

The best orchestrator is the one that disappears into the background and lets your team ship. For most teams, that’s ECS.