AWS ECS vs EKS vs Fargate: Choose Your Container Path

Quick take: ECS is the easy AWS-native path. EKS is Kubernetes when you genuinely need it. Fargate removes nodes from both. The hard decision is not ECS vs EKS — it is whether you actually need Kubernetes, and separately, whether you want to own the servers.

A SaaS company adopted Amazon EKS because it was “the industry standard.” Six months later, three platform engineers spent their weeks managing node groups, the VPC CNI, an ingress controller, the cluster autoscaler and a sprawl of Helm charts — all to run a handful of stateless HTTP services that did nothing Kubernetes-specific. They migrated the web tier to ECS on Fargate and cut platform toil in half. The data platform, which leaned on the Spark Operator and custom controllers, stayed on EKS because Kubernetes was genuinely earning its keep there. That is the whole article in one anecdote: AWS gives you two orchestrators (ECS, EKS) crossed with two launch types (Fargate, EC2), and the cost of choosing wrong is measured in engineer-years, not dollars.

This is the decision guide I wish that team had read first. We treat the choice as two orthogonal axes, not one menu. Axis one — orchestrator — is ECS (AWS’s own scheduler, no control-plane fee, deep IAM/CloudWatch integration) versus EKS (conformant Kubernetes, portable, ecosystem-rich, but you operate add-ons and upgrades and pay $0.10/hr per cluster). Axis two — launch type — is Fargate (serverless: no nodes to patch, scale or right-size, billed per vCPU-second) versus EC2 (you own the instances: cheaper at steady state, Spot/Graviton/GPU available, daemonsets and privileged mode possible). Four corners: ECS+Fargate, ECS+EC2, EKS+Fargate, EKS+EC2 (and EKS+Karpenter, the modern node-provisioning answer). Each corner has a different operating model, a different bill, and a different set of 2 a.m. failure modes.

By the end you will stop choosing by brand recognition. You will know that an awsvpc task needs an ALB target group of target-type ip or it will never pass health checks; that a task stuck in PROVISIONING in a private subnet almost always means missing ECR/S3/logs VPC endpoints; that CannotPullContainerError is an execution-role problem, not a task-role one; that EKS Fargate quietly forbids DaemonSets and hostNetwork; and that the cheapest steady-state path is usually EC2 Spot on Graviton with Karpenter, while the cheapest operationally is Fargate. Because this is a reference you will return to mid-decision and mid-incident, the trade-offs, the limits, the task-definition fields and the failure modes are all laid out as scannable tables — read the prose once, then keep the tables open when the architecture review (or the pager) starts.

What problem this solves

Containers need an orchestrator: something to place them on hosts, restart them when they die, roll out new versions, wire them to load balancers, and scale them with demand. AWS does not give you one answer — it gives you a 2×2, and the marketing pages make all four corners sound equally good. They are not. The wrong corner is expensive in the way that hurts most: not a surprise invoice (though that too), but a permanent tax on every deploy, every patch cycle, every on-call rotation.

What breaks without a deliberate choice: a five-person startup stands up EKS “to be cloud-native,” then discovers that keeping the cluster alive — Kubernetes minor-version upgrades every ~14 months before support ends, VPC CNI / CoreDNS / kube-proxy add-on bumps, IP-exhaustion from the CNI’s per-pod ENI model, ingress-controller CVEs, Helm-chart drift — is now a full-time job that produces zero customer value. Conversely, a platform team standardizes on ECS for simplicity, then spends a year reinventing Helm-style templating, operators and CRDs in CloudFormation because they actually did need Kubernetes’ extensibility. Both teams chose on the wrong axis. The orchestrator axis is about extensibility and portability; the launch-type axis is about who owns the servers. Conflating them is the root mistake.

Who hits this: essentially every team that has outgrown a single EC2 box or a Lambda and wants to run long-lived containers. It bites hardest on teams that (a) adopt Kubernetes for resume-driven reasons, (b) run Fargate at high steady-state utilization and overpay versus EC2, © deploy into private subnets without the VPC endpoints awsvpc networking requires, or (d) confuse the execution role with the task role and then can’t pull an image or read a secret. The fix is almost never “switch orchestrators in a panic” — it’s “decide the two axes on their actual merits, then implement the networking and IAM correctly.”

To frame the whole field before the deep dive, here is the 2×2 with the one question each corner forces and the single fact that most often makes the decision:

Learning objectives

By the end of this article you can:

• Separate the orchestrator decision (ECS vs EKS) from the launch-type decision (Fargate vs EC2) and reason about each on its own axis instead of as a single menu choice.
• State precisely when Kubernetes earns its complexity — existing Helm/CRDs/operators, portability/multi-cloud, advanced scheduling — and when it is pure overhead you should avoid.
• Choose between Fargate and EC2 using utilization, GPU/daemon needs, Spot tolerance and the per-vCPU cost premium, and back it with real numbers.
• Author a task definition (ECS) and a Pod/Deployment (EKS) and explain every field that bites: CPU/memory pairs, networkMode awsvpc, execution role vs task role, log driver, health check.
• Wire containers to an ALB correctly, including why awsvpc/Fargate tasks require target-type ip and how the health check must target the container port.
• Diagnose the canonical container failures — PROVISIONING hangs, CannotPullContainerError, ResourceInitializationError, OOM (exit 137), IP exhaustion, ALB 503s — to a specific root cause with the exact command to confirm it.
• Right-size and cost-model all four corners (Fargate vCPU-seconds, EC2/Spot/Graviton, the EKS control-plane fee, Savings Plans) in rough INR/USD and pick the cheapest appropriate path.
• Map each choice to the relevant certifications (SAP-C02, DVA-C02, DOP-C02) and the Kubernetes (CKA) mindset.

Prerequisites & where this fits

You should already be comfortable with the AWS container fundamentals: a container image lives in a registry (Amazon ECR or another OCI registry); a task (ECS) or Pod (Kubernetes) is one or more containers scheduled together; a service keeps N copies running and registers them with a load balancer. You should know how to run the AWS CLI and read JSON output, what a VPC, subnet, security group and route table are, and that IAM roles grant AWS permissions. Basic Kubernetes literacy (Deployment, Service, namespace) helps for the EKS sections but is not required to follow the decision logic.

This sits in the Compute → Containers track and is the decision upstream of all the hands-on container work. It assumes the compute landscape from AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose? (that article picks the category; this one picks within containers). It depends on the networking from AWS VPC, Subnets and Security Groups Explained — awsvpc task networking, VPC endpoints and SGs are where most container outages actually live — and on the load-balancer choice from AWS ALB vs NLB vs API Gateway Compared, because the ALB target-type detail below is the single most common ECS wiring bug. Identity grounding comes from AWS Organizations & IAM Foundations.

A quick map of who owns what during a container incident, so you page the right person fast:

Core concepts

Six mental models make every later decision and diagnosis obvious.

The choice is two axes, not one. Orchestrator (ECS vs EKS) decides the API and ecosystem you program against and operate. Launch type (Fargate vs EC2) decides who owns the servers. They are independent: you can run ECS on Fargate or EC2, and EKS on Fargate or EC2 (or both at once). Decide them separately. The orchestrator question is “do I need Kubernetes’ extensibility and portability?” The launch-type question is “do I want to patch, scale and right-size servers, in exchange for lower cost and more control?”

ECS is the AWS-native, no-cluster-fee orchestrator. Amazon ECS (Elastic Container Service) schedules tasks (defined by a task definition — a versioned JSON describing containers, CPU/memory, networking, roles, logging). A service maintains a desired count and integrates natively with ALB/NLB, CloudWatch, IAM, App Mesh and Service Connect. There is no charge for the ECS control plane — you pay only for the compute (Fargate or EC2). ECS concepts map cleanly onto AWS primitives, so there is little to learn beyond AWS itself. The trade: it is AWS-only and less extensible than Kubernetes.

EKS is conformant Kubernetes, with a control-plane fee and add-on operations. Amazon EKS (Elastic Kubernetes Service) runs an upstream-conformant Kubernetes control plane that AWS manages (highly available across AZs) for $0.10 per cluster-hour (~$73/month). You get the entire Kubernetes API: Deployments, CRDs, operators, Helm, the Horizontal/Vertical Pod Autoscaler, network policies, and portability across clouds. The cost is operational: you own the add-on lifecycle (VPC CNI, CoreDNS, kube-proxy), cluster version upgrades (a new minor roughly every ~4 months; ~14 months of standard support each), the ingress/load-balancer controller, IP planning for the CNI, and the broader Kubernetes blast radius. Power and portability in exchange for toil.

Fargate is serverless containers — no nodes, billed per vCPU-second. AWS Fargate runs your task/pod on AWS-managed capacity. You specify CPU and memory; AWS finds the host, attaches an ENI (awsvpc), pulls the image and runs the container. No EC2 to patch, scale, secure or right-size. You pay per vCPU-second and GB-second while the task runs (per-second, 1-minute minimum). The trade-offs: a per-vCPU premium over EC2 at steady state (~20–50% depending on Region/commitment), no DaemonSets/privileged/GPU, fixed CPU↔memory ratios, slower cold starts than a warm EC2 node, and ephemeral storage capped (20 GiB default, up to 200 GiB configurable).

EC2 launch type means you own the nodes — cheaper and more flexible, but yours to operate. With the EC2 launch type, tasks/pods run on EC2 instances you provision (an ECS capacity provider / Auto Scaling Group, or on EKS a managed node group or Karpenter). You choose instance families (Graviton/arm64 for ~20–40% better price-performance, GPU for ML, memory-optimized for caches), use Spot for up to ~90% savings on interruptible work, bring custom AMIs, run DaemonSets/privileged containers, and bin-pack many tasks per instance. The cost: you patch AMIs, manage scaling and capacity, and carry the security of the host OS.

awsvpc networking gives each task its own ENI — and its own failure modes. On Fargate (always) and increasingly on EC2, ECS/EKS use the awsvpc network mode: each task/pod gets its own Elastic Network Interface with a VPC IP, its own security group, and first-class VPC routing. This is clean (per-task SGs, no port conflicts) but introduces three classics: IP exhaustion (each task burns a subnet IP; the EKS CNI burns several), the ALB target-type ip requirement (the LB targets the task’s ENI IP, not a host), and VPC-endpoint dependence in private subnets (pulling from ECR and writing to CloudWatch need a route to AWS — a NAT Gateway or interface/gateway endpoints).

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary repeats these for lookup; this table is the mental model side by side:

Axis 1 — ECS or EKS? Deciding whether you need Kubernetes

This is the consequential decision, and it is not about which is “better” — it is about whether your workload needs Kubernetes’ extensibility and portability enough to pay for operating it. Default to ECS. Reach for EKS only when you can name a concrete Kubernetes capability you depend on.

What ECS gives you (and what it doesn’t)

ECS is the path of least resistance on AWS. Everything is an AWS primitive you already understand; there is no second API to learn, no add-on fleet to keep current, and no control-plane bill.

What EKS gives you (and what it costs)

EKS is Kubernetes — the full API, the ecosystem, the portability. The price is a control-plane fee plus a permanent operational surface.

The decision table — does this workload need Kubernetes?

Run each “yes” signal against the list. One genuine yes can justify EKS; all no means ECS, full stop.

Operating-toil comparison (the part the bill doesn’t show)

The control-plane fee is the visible cost. The invisible one is recurring engineering time. This is where most “we should have used ECS” regret originates.

Axis 2 — Fargate or EC2? Deciding who owns the servers

Independent of the orchestrator, decide whether you want to operate nodes. Fargate trades money for the elimination of node operations; EC2 trades operations for lower cost and more capability. Both work under ECS and EKS.

Fargate — the no-nodes model

EC2 launch type — own the nodes

Fargate-vs-EC2 decision table

The four corners, side by side

ECS deep dive — the task definition, every field that bites

On ECS you deploy task definitions. A task definition is immutable and versioned (family:revision); you register a new revision and update the service to it. The fields below are where real incidents originate.

Task-level settings

Fargate CPU↔memory valid combinations

Fargate does not let you pick arbitrary CPU/memory. Pick a row.

Container-level settings (inside containerDefinitions)

Create an ECS Fargate service (CLI)

# 1) Register the task definition (JSON in file)
aws ecs register-task-definition --cli-input-json file://taskdef.json

# 2) Create a target group of TYPE IP (awsvpc requires this!)
aws elbv2 create-target-group --name web-tg \
  --protocol HTTP --port 8080 --vpc-id vpc-0abc \
  --target-type ip --health-check-path /healthz

# 3) Create the service on Fargate, wired to the ALB
aws ecs create-service --cluster prod --service-name web \
  --task-definition web:7 --desired-count 3 --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-1,subnet-2],securityGroups=[sg-web],assignPublicIp=DISABLED}' \
  --load-balancers 'targetGroupArn=arn:...:targetgroup/web-tg/...,containerName=web,containerPort=8080'

The same in Terraform

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

  network_configuration {
    subnets          = var.private_subnets
    security_groups  = [aws_security_group.web.id]
    assign_public_ip = false
  }
  load_balancer {
    target_group_arn = aws_lb_target_group.web.arn # target_type = "ip"
    container_name   = "web"
    container_port   = 8080
  }
}

ECS capacity providers — how Fargate/EC2/Spot mix is set

EKS deep dive — clusters, node options, and the add-ons you own

On EKS you deploy standard Kubernetes objects (Deployment, Service, Ingress). The differences from a generic cluster are where the nodes come from, how pods get IPs, and which add-ons you keep current.

EKS compute options

The add-ons you must keep current (the toil, enumerated)

Fargate profiles (EKS) — and their hard limits

A Fargate profile declares which pods (by namespace + labels) run on Fargate instead of nodes. The limits below decide whether your workload even fits.

IRSA vs Pod Identity — granting AWS permissions to pods

Minimal EKS on Fargate, then a Deployment

# Cluster + a Fargate profile for the "apps" namespace (eksctl)
eksctl create cluster --name prod --region ap-south-1 --fargate

# Install the AWS Load Balancer Controller (Helm) so Ingress provisions an ALB
helm repo add eks https://aws.github.io/eks-charts
helm install aws-lb-controller eks/aws-load-balancer-controller \
  -n kube-system --set clusterName=prod

apiVersion: apps/v1
kind: Deployment
metadata: { name: web, namespace: apps }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      serviceAccountName: web-sa   # IRSA-annotated for the app's AWS perms
      containers:
        - name: web
          image: 1234.dkr.ecr.ap-south-1.amazonaws.com/web:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            requests: { cpu: "250m", memory: "512Mi" }
            limits:   { cpu: "500m", memory: "1Gi" }

Networking — awsvpc, ALB target types, and the VPC endpoints you forget

This section is where the most outages live. awsvpc networking is clean but unforgiving, and the ALB/endpoint requirements are non-negotiable.

Network modes (ECS)

ALB target-type — the #1 ECS wiring bug

If your service is Fargate or awsvpc and you created an instance target group, registration fails or the ALB has no healthy targets → clients get 503. Recreate the target group with --target-type ip and point its health check at the container port.

VPC endpoints private tasks need (or a NAT Gateway)

A task in a private subnet with assignPublicIp=DISABLED must reach AWS APIs to pull the image and ship logs. Either route via a NAT Gateway or add these endpoints (cheaper at scale, and required if you have no NAT):

Forgetting the S3 gateway endpoint is the classic: ecr.api/ecr.dkr resolve, auth succeeds, but the layer download (which goes to S3) hangs → task stuck in PROVISIONING or CannotPullContainerError.

EKS VPC CNI — IP exhaustion math

The EKS VPC CNI gives each pod a real VPC IP, pre-allocating a warm pool per node. Without prefix delegation, a node’s pod density is capped by its ENI/IP limits, and large clusters exhaust /24s fast.

Deployments & rollouts — keeping the service alive during change

ECS deployment controllers

Deployment-tuning knobs (ECS)

Kubernetes rollout knobs (EKS)

Architecture at a glance

Trace one HTTPS request and you can see the whole 2×2 in a single path. A client hits an Application Load Balancer on :443 (TLS terminates here). Because the containers run with awsvpc networking, the ALB’s target group must be target-type ip — it sends traffic to the task’s own ENI IP, not to a host. From there the request enters the control plane you chose: ECS (AWS-native, no cluster fee) or EKS (the Kubernetes API at $0.10/hr). That orchestrator schedules the work onto the data plane you chose: Fargate (serverless, 0.25–16 vCPU, nothing to patch) or EC2 nodes (you own the AMI; Graviton, Spot and GPU live here). Whichever combination, the actual workload is the same container — an image pulled from ECR over :443, running as a task or pod under a task role (ECS) or IRSA (EKS). Finally every task leans on shared platform dependencies: CloudWatch for logs and metrics, and IAM split into an execution role (pull the image, write logs, read secrets) and a task role (the app’s own AWS calls).

The numbered badges mark the five places this architecture most often goes wrong or forces a decision. (1) is the ALB target-type trap — awsvpc demands ip, and an instance target group gives you a 503 with no healthy targets. (2) is the orchestrator fork itself: pay the EKS control-plane fee and add-on toil only for genuine Kubernetes needs. (3) is the Fargate-vs-EC2 trade — serverless simplicity versus steady-state cost, GPU and daemons. (4) is the dreaded PROVISIONING hang: an ENI that can’t attach because the subnet is out of IPs or the private subnet lacks ECR/S3/logs endpoints. (5) is the IAM split — mixing the execution and task roles is why images won’t pull or secrets won’t resolve. Read the diagram left to right and the badges become your pre-flight checklist.

Real-world scenario

Northwind Stream (fictional) is a 40-engineer media-analytics SaaS on AWS. Two years ago a newly hired platform lead stood up a single large EKS cluster “to be cloud-native,” and everything went on it: the customer-facing web/API tier (a dozen stateless Go and Node services), a set of scheduled batch jobs, and the data platform (Spark on the Spark Operator, plus a couple of bespoke controllers). It worked — until operating it became the team’s main job.

The symptoms were classic misallocation. The platform group had grown to three full-time engineers whose week was Kubernetes upkeep: a minor-version upgrade every cycle (with the obligatory VPC CNI / CoreDNS compatibility testing), recurring IP-exhaustion alerts as the CNI burned through a /23 (prefix delegation hadn’t been enabled), AWS Load Balancer Controller CVEs to patch, Helm-chart drift, and a painful incident where a bad CoreDNS bump broke service discovery for twenty minutes. None of this produced customer value. Meanwhile the web tier — pure stateless HTTP behind an ALB — used nothing Kubernetes-specific. It was paying the full cluster tax for zero benefit.

The architecture review split the workloads along the two axes honestly:

They migrated the web tier to ECS Fargate behind the existing ALBs (recreating the target groups as target-type ip), moved the batch jobs to ECS Fargate Spot triggered by EventBridge Scheduler, and kept the data platform on EKS — but moved its nodes to Karpenter on Graviton Spot, and finally enabled prefix delegation to kill the IP-exhaustion alerts. The numbers afterward: the platform team shrank from three engineers to one; the EKS cluster’s blast radius dropped (only the data platform now depends on it); the batch tier’s compute bill fell sharply because it scaled to zero between runs; and the Spark/ML workloads got cheaper on Karpenter+Graviton+Spot while gaining the JIT bin-packing they’d lacked. The lesson the lead wrote in the post-mortem: “Kubernetes was the right tool for the 20% of our workload that needed it, and an expensive mistake for the 80% that didn’t. We chose on the wrong axis — we picked an orchestrator before asking whether each workload needed one.”

Advantages and disadvantages

In prose: ECS wins when the workload is “just containers + a load balancer” and you value shipping over operating — which is most workloads, most of the time. EKS wins precisely when you can name the Kubernetes capability you depend on (an operator, CRDs, a mesh, portability) — and when that value clears the bar of the control-plane fee plus the permanent add-on/upgrade surface. On the other axis, Fargate wins on spiky utilization, small teams, and anything you’d rather not babysit; its premium is real but often dwarfed by the salary cost of node operations at small scale. EC2 wins on steady, high-utilization fleets where bin-packing plus Savings Plans/Spot/Graviton make it dramatically cheaper, and on the hard requirements Fargate simply can’t meet (GPU, DaemonSets, custom kernels). The corners are not ranked; they are matched to a workload’s shape.

Hands-on lab

This lab deploys a tiny HTTP container on ECS Fargate behind an ALB, hits it, then tears everything down. It is free-tier-adjacent (Fargate and ALB are not free, but a few minutes costs cents). Run in a Region like ap-south-1 (Mumbai). Replace IDs with yours.

Step 0 — prerequisites

aws sts get-caller-identity            # confirm you're authenticated
aws ec2 describe-vpcs --query 'Vpcs[0].VpcId' --output text   # note a VPC id

Step 1 — create a cluster

aws ecs create-cluster --cluster-name lab --capacity-providers FARGATE FARGATE_SPOT

Expected: JSON with "status": "ACTIVE".

Step 2 — an execution role (pull image + write logs)

aws iam create-role --role-name lab-exec \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name lab-exec \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

Step 3 — register a task definition (taskdef.json)

{
  "family": "lab-web",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "256", "memory": "512",
  "executionRoleArn": "arn:aws:iam::<acct>:role/lab-exec",
  "containerDefinitions": [{
    "name": "web",
    "image": "public.ecr.aws/nginx/nginx:latest",
    "portMappings": [{ "containerPort": 80 }],
    "essential": true,
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/lab-web",
        "awslogs-region": "ap-south-1",
        "awslogs-stream-prefix": "web",
        "awslogs-create-group": "true"
      }
    }
  }]
}

aws ecs register-task-definition --cli-input-json file://taskdef.json

Step 4 — an ALB + a TARGET-TYPE IP target group (the lab’s whole point)

aws elbv2 create-load-balancer --name lab-alb --type application \
  --subnets subnet-1 subnet-2 --security-groups sg-alb
aws elbv2 create-target-group --name lab-tg --protocol HTTP --port 80 \
  --vpc-id vpc-0abc --target-type ip --health-check-path /
# create a listener on :80 forwarding to lab-tg (ARNs from the two commands above)
aws elbv2 create-listener --load-balancer-arn <alb-arn> --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=<tg-arn>

Step 5 — run the service

aws ecs create-service --cluster lab --service-name web \
  --task-definition lab-web --desired-count 2 --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-1,subnet-2],securityGroups=[sg-web],assignPublicIp=ENABLED}' \
  --load-balancers 'targetGroupArn=<tg-arn>,containerName=web,containerPort=80'

Note: assignPublicIp=ENABLED lets the lab pull the public ECR image without VPC endpoints. In production you’d use private subnets + the endpoints in the table above.

Step 6 — verify

aws ecs describe-services --cluster lab --services web \
  --query 'services[0].deployments[0].runningCount'      # → 2 when ready
aws elbv2 describe-target-health --target-group-arn <tg-arn> \
  --query 'TargetHealthDescriptions[].TargetHealth.State' # → ["healthy","healthy"]
curl http://<alb-dns-name>/                               # → nginx welcome HTML

Step 7 — teardown (avoid charges)

aws ecs update-service --cluster lab --service web --desired-count 0
aws ecs delete-service --cluster lab --service web --force
aws elbv2 delete-listener --listener-arn <listener-arn>
aws elbv2 delete-load-balancer --load-balancer-arn <alb-arn>
aws elbv2 delete-target-group --target-group-arn <tg-arn>
aws ecs delete-cluster --cluster lab
aws logs delete-log-group --log-group-name /ecs/lab-web

Common mistakes & troubleshooting

This is the differentiator. Containers fail in a small set of recurring ways with a specific root cause and an exact confirm step. Use this as a playbook: match the symptom, confirm the cause, apply the fix.

A few reading notes that save the most time:

• Always read stoppedReason first. aws ecs describe-tasks --cluster <c> --tasks <id> --query 'tasks[0].stoppedReason' tells the truth for almost every Fargate failure (pull, secrets, ENI, OOM). On EKS, the equivalent is kubectl describe pod events.
• Execution role vs task role is the most common IAM confusion. Execution role = the platform pulling your image, writing your logs, reading your secrets before/around your code. Task role = your code’s AWS identity. If the image won’t pull or a secret won’t resolve, it’s the execution role. If your app gets AccessDenied calling AWS, it’s the task role.
• target-type ip is mandatory for awsvpc/Fargate. This single setting causes more “ALB returns 503” tickets than anything else.

Best practices

• Default to ECS; adopt EKS only with a named Kubernetes requirement. Write the requirement down (operator X, CRD Y, portability to Z). If you can’t, you don’t need EKS.
• Default to Fargate; move to EC2 when the bill or a hard requirement says so. Start serverless; switch steady, high-utilization or GPU/daemon workloads to EC2 with data.
• Always use target-type ip target groups for awsvpc/Fargate, and health-check the container port — not a host port.
• Split IAM correctly: execution role for pull/logs/secrets, task role for the app. Keep both least-privilege; never reuse one for both jobs.
• In private subnets, add the ECR(api+dkr) + S3 gateway + logs endpoints (and secretsmanager/sts/ssm as needed) — or you’ll chase PROVISIONING hangs.
• Turn on the ECS deployment circuit breaker with rollback so a bad task definition auto-reverts instead of taking the service down.
• Pin image digests/tags; never :latest in production. Reproducible deploys and clean rollbacks depend on it.
• Run an on-demand base + Spot burst (capacity-provider strategy on ECS; Karpenter Spot with on-demand fallback on EKS) for cost without fragility.
• On EKS, enable VPC CNI prefix delegation early and plan CIDRs generously — IP exhaustion is painful to fix after the fact.
• On EKS, keep add-ons current and test upgrades on a non-prod cluster (or use blue/green clusters). CNI/CoreDNS/kube-proxy must match the control-plane version.
• Right-size with Container Insights / metrics, then commit (Savings Plans for Fargate+EC2) once usage is steady.
• Prefer Graviton (arm64) for both Fargate and EC2 where your stack supports it; build multi-arch images so you’re not locked to x86.

Security notes

• Least-privilege task roles. Scope the task role to exactly the AWS APIs the app calls; never grant *. On EKS, use IRSA or Pod Identity so each ServiceAccount maps to a minimal role — not node-wide instance-profile permissions.
• Don’t put secrets in environment. Inject from Secrets Manager/SSM Parameter Store via the task definition secrets block (or External Secrets/CSI on EKS); the execution role reads them, and they never appear in the task-def history or logs.
• Private subnets + endpoints, no public IPs. Run tasks with assignPublicIp=DISABLED in private subnets and reach AWS via VPC endpoints, keeping image pulls and log shipping off the public internet.
• Per-task security groups (awsvpc) let you micro-segment: the ALB SG → app SG on the container port only; app SG → database SG on the DB port only. On EKS, add network policies for pod-to-pod controls.
• Image provenance. Scan images in ECR (enhanced scanning / Inspector), pin digests, and ideally enforce signed images. A vulnerable base image is a vulnerable fleet.
• EKS RBAC + IAM together. Lock down Access Entries / aws-auth so only the right principals reach the API server, and use Kubernetes RBAC for in-cluster authorization. Restrict the public API endpoint or make it private.
• No privileged unless required. On Fargate it’s impossible (a security feature). On EC2/EKS, drop Linux capabilities you don’t need and avoid privileged: true.

Cost & sizing

What drives the bill differs sharply by corner. Roughly (us-east-1-class on-demand list; INR at ~₹84/USD; verify current pricing):

Right-sizing guidance

Free-tier-ish notes

• ECS itself is free (you pay only compute) — there is no orchestrator charge.
• EKS has no free tier: the $0.10/hr control-plane fee starts immediately, so don’t leave idle clusters running.
• Fargate/ALB are not free but a few minutes of the lab above costs only cents — just remember to tear down.

Interview & exam questions

Q1. ECS vs EKS in one sentence — when each? ECS is AWS’s native orchestrator with no control-plane fee and the lowest operational surface — use it for straightforward containerized services. EKS is conformant Kubernetes ($0.10/hr/cluster) — use it when you need the Kubernetes ecosystem (operators, CRDs, Helm), portability, or advanced scheduling. (SAP-C02)

Q2. Fargate vs EC2 launch type — the trade-off? Fargate is serverless (no nodes to patch/scale/right-size, per-second billing) at a per-vCPU premium and without GPU/DaemonSet/privileged support. EC2 is cheaper at steady high utilization and supports Spot, Graviton, GPU, daemons and custom AMIs, but you own host operations. (DVA-C02 / SAP-C02)

Q3. Your Fargate service behind an ALB returns 503 with no healthy targets. Why? Almost certainly the target group is target-type instance while Fargate uses awsvpc, so targets register the wrong way. Recreate the target group with --target-type ip and point the health check at the container port. (DVA-C02)

Q4. A Fargate task is stuck in PROVISIONING in a private subnet. First two suspects? No free IPs in the subnet for the task ENI, or missing VPC endpoints (ECR api+dkr, the S3 gateway endpoint for layers, and logs). Confirm via stoppedReason and subnet free-IP count. (SAP-C02)

Q5. Difference between the ECS execution role and task role? The execution role lets the ECS agent pull the image, write logs and read secrets (platform-side). The task role is the application’s own AWS identity for its API calls (S3, DynamoDB, etc.). CannotPullContainerError → execution role; app AccessDenied → task role. (DVA-C02)

Q6. When is EKS genuinely the right call over ECS? When you depend on Kubernetes-specific capabilities: existing Helm charts/operators/CRDs, a service mesh, advanced scheduling, multi-cloud portability, or workloads like Spark/Flink/ML that run on Kubernetes operators. Brand recognition is not a reason. (SAP-C02)

Q7. What can’t you run on EKS Fargate? DaemonSets, GPU workloads, privileged containers and hostNetwork/hostPort pods. Node-level agents (logging/security) must be sidecars; GPU/daemon needs require EC2 node groups. (CKA mindset / SAP-C02)

Q8. How do you give an EKS pod AWS permissions securely? Use IRSA (IAM Roles for Service Accounts via OIDC) or EKS Pod Identity to bind a least-privilege role to a ServiceAccount — not the node instance profile, which would over-grant every pod on the node. (DOP-C02)

Q9. Container exits with code 137 — what happened and how do you confirm? It was OOM-killed for exceeding its memory limit. Confirm via stoppedReason: OutOfMemoryError (ECS) or the pod’s OOMKilled reason (EKS) and Container Insights memory metrics; fix by raising memory or fixing the leak. (DVA-C02)

Q10. How do you cut container compute cost without sacrificing availability? Run an on-demand base plus Spot burst (capacity-provider strategy on ECS; Karpenter Spot with on-demand fallback on EKS), adopt Graviton/arm64, right-size from metrics, and commit Savings Plans once usage is steady. (SAP-C02)

Q11. Why does the EKS control plane cost matter for cluster strategy? Each cluster is $0.10/hr (~$73/mo). Spinning up a cluster per team/app multiplies that fee and the add-on toil. Consolidate with namespaces and RBAC instead, reserving separate clusters for genuine isolation needs. (SAP-C02)

Q12. What is Karpenter and why prefer it over the Cluster Autoscaler? Karpenter is a just-in-time node provisioner for EKS that watches pending pods and launches right-sized, cheapest-fit nodes (Spot-native, bin-packing) in seconds, then consolidates. It’s faster and more cost-efficient than ASG-based Cluster Autoscaler’s fixed node groups. (DOP-C02)

Quick check

1. You have a dozen stateless HTTP services, a five-person team, and no Kubernetes experience. Which corner of the 2×2 do you pick, and why?
2. Your Fargate service behind an ALB shows “no healthy targets” and clients get 503. What is the single most likely misconfiguration?
3. Name two VPC endpoints (besides logs) a private-subnet Fargate task needs to pull an image, and the easy one to forget.
4. The app logs AccessDenied calling DynamoDB. Execution role or task role — which do you fix?
5. Give one workload that genuinely justifies EKS over ECS and one that genuinely justifies EC2 over Fargate.

Answers

1. ECS + Fargate. Stateless containers + ALB use nothing Kubernetes-specific, and Fargate removes node ops — the lowest total operational surface for a small team. EKS would add a control-plane fee and an add-on/upgrade burden for zero benefit.
2. The target group is target-type instance instead of ip. awsvpc/Fargate tasks must be targeted by ENI IP; recreate the target group with --target-type ip and health-check the container port.
3. ecr.api and ecr.dkr (interface endpoints) — plus the easy-to-forget S3 gateway endpoint, because ECR image layers are stored in S3 and the download stalls without it.
4. The task role. The app’s own AWS calls use the task role; the execution role only covers image pull, log writes and secret reads.
5. EKS-justifying: Spark/ML on the Spark Operator (or anything needing CRDs/operators, a mesh, or multi-cloud portability). EC2-justifying: a GPU inference service (Fargate has no GPU) or a steady 24×7 fleet where Spot+Graviton+bin-packing is far cheaper.

Glossary

• Amazon ECS — AWS’s native container orchestrator; schedules tasks, integrates with ALB/IAM/CloudWatch; no control-plane fee.
• Amazon EKS — AWS-managed, conformant Kubernetes; full k8s API and ecosystem; $0.10/hr per cluster.
• AWS Fargate — Serverless compute for containers; runs tasks/pods with no nodes to manage; billed per vCPU/GB-second.
• EC2 launch type — Running tasks/pods on EC2 instances you provision; cheaper at steady state; supports Spot/Graviton/GPU/daemons.
• Task definition — Immutable, versioned JSON describing an ECS task’s containers, CPU/memory, roles, networking and logging.
• Execution role — IAM role the ECS agent uses to pull the image, write logs and read secrets (platform-side).
• Task role — IAM role that is the application’s own AWS identity for its API calls.
• awsvpc — Network mode giving each task/pod its own ENI, IP and security group; required by Fargate.
• Target-type ip — ALB target-group mode that registers task/pod ENI IPs; required for awsvpc/Fargate services.
• Capacity provider — ECS construct mapping a service to Fargate/Fargate-Spot/EC2 capacity (with weighted strategies).
• Managed node group — AWS-managed EC2 Auto Scaling Group of EKS worker nodes with lifecycle handling.
• Karpenter — EKS just-in-time node provisioner that launches right-sized, cheapest-fit (Spot) nodes and consolidates.
• VPC CNI — EKS networking plugin that assigns each pod a real VPC IP; tuned via prefix delegation/custom networking.
• IRSA — IAM Roles for Service Accounts; binds a least-privilege IAM role to a Kubernetes ServiceAccount via OIDC.
• Fargate profile — EKS construct selecting which pods (namespace + labels) run on Fargate instead of nodes.
• Graviton (arm64) — AWS Arm-based processors offering ~20–40% better price-performance; needs multi-arch images.

Next steps

• Go deep on the launch-type cost mechanics in AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose?.
• Get the load-balancer choice right (the target-type detail lives here) in AWS ALB vs NLB vs API Gateway Compared.
• Master the awsvpc/endpoint/SG networking your tasks depend on in AWS VPC, Subnets and Security Groups Explained.
• Lock down the execution/task roles and account guardrails via AWS Organizations & IAM Foundations.
• Pair containers with event-driven glue (EventBridge-triggered batch tasks) using AWS Lambda Event-Driven Patterns.