Skip to content
intermediate Phase 18 · AWS Containers

ECS & Fargate

Deploy containers with ECS and Fargate for serverless container management.

1h 15m
0 problems
Topic Progress 0%

Task, Service, Cluster

Task, Service, Cluster

ECS has three layers. A task definition is the blueprint: image, CPU/memory, ports, environment, and IAM roles. A service maintains desired count, integrates load balancers, and restarts unhealthy tasks. A cluster is the logical grouping of capacity.

Two launch types answer "where does it run": EC2 you manage instance capacity via capacity providers/ASGs — good for steady workloads, bin-packing efficiency, and GPUs; Fargate bills per running task with no instances to size — good for bursty or ops-light services. All Fargate tasks use awsvpc networking, giving each task its own ENI and IP — which makes subnet IP capacity and security-group design first-class concerns.

Task Definition and Deploy

Task Definition and Deploy

{
  "executionRoleArn": "arn:aws:iam::...:role/ecsTaskExecution",
  "taskRoleArn": "arn:aws:iam::...:role/appTask",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "containerDefinitions": [{
    "name": "api", "image": "123.dkr.ecr.../api:abc123",
    "portMappings": [{"containerPort": 8080}],
    "dependsOn": [{"container": "migrator", "condition": "SUCCESS"}]
  }]
}

The execution role pulls the image and writes logs; the task role is what the application itself uses for AWS API calls — conflating them is the top IAM mistake. Deploy with aws ecs update-service --force-new-deployment after pushing an image, and set health-check grace period so the ALB does not kill a slow-warming app.

Scaling and Troubleshooting

Scaling and Troubleshooting

Services scale on the right metric: target tracking on ALB requests per target or on CPU/memory; scale the service, not the cluster (capacity providers handle EC2 supply). Set ALB deregistration delay so in-flight requests finish while tasks drain.

Common failures, in order to check: stuck deployments → target group health (wrong path/port), "no container instances" → ENI/IP exhaustion on awsvpc instances or Fargate subnet capacity, AccessDenied on pull → execution role missing ECR/logs permissions, and app cannot reach RDS → task security group not allowed on the DB SG. Read ECS events on the service — they name the failing condition.

Interview: explain why awsvpc per-task ENIs make security groups behave like instance firewalls.

Quiz

1. What is the task role used for?

Question 1 options

2. Which statement about Fargate is true?

Question 2 options

3. A deployment hangs reporting "healthy: 0". First place to look?

Question 3 options

Flashcards

Question

Execution vs task role

Answer

Execution: pull images + logs. Task: AWS permissions for the app at runtime.

Question

Launch types

Answer

EC2 = your instances, capacity providers; Fargate = per-task billing, no instances.

Question

awsvpc networking

Answer

One ENI/IP per task; SGs apply per task; subnets need spare IPs.

Question

Service vs task

Answer

Service keeps desired count + LB integration; task definition is the blueprint.

Question

Force new deployment

Answer

Rolling update that re-pulls the tag — needed when the tag was mutated in place.

Revision Notes

Key Takeaways

  • 1. Task definition = blueprint, service = desired state, cluster = capacity
  • 2. Keep execution and task roles distinct — it is the classic ECS IAM bug
  • 3. Troubleshoot via service events and target health before restarting anything

Interview Tips

  • • Walk a deployment failure top-down: events → target health → ENI/IP → IAM
  • • Explain why per-task ENIs change security-group thinking versus bridge mode

Cheat Sheet

ECS: task def = blueprint → service (count+ALB) → cluster (capacity). EC2 vs Fargate; awsvpc = ENI/IP per task. Execution role pulls/logs; task role = app AWS perms. Debug: events, health, SGs, IPs.

Continue Learning

Before You Start

  • No prerequisites listed.

Next Topics