beginnerintermediateadvanced

AWS · ECS — Containerized Applications

ECS — Containerized Applications

Task definitions, EC2 vs Fargate capacity, task vs execution roles, and rolling deployments

Cluster → service → task → task definitionthe four-layer vocabulary
EC2 or Fargatesame task definitions, different capacity layer
Task role ≠ execution roleapp permissions vs ECS startup permissions
Rolling deploymentsminimumHealthyPercent / maximumPercent bound the replace

1.ECS Core Vocabulary

A task definition is the blueprint for a container app. A task is one running instance of that blueprint. A service keeps a desired number of tasks running long-term, replacing any that die. A cluster is the logical grouping all of this runs inside. A capacity provider decides what infrastructure (EC2 or Fargate) actually runs the tasks.

Key features

Task definition: the versioned blueprint — container image, CPU/memory, ports, environment, roles
Task: one running instance of a task definition; a batch job runs a task once and stops
Service: keeps a desired count of tasks running long-term, replacing failed or stopped tasks
Cluster: the logical grouping of infrastructure and services/tasks
Capacity provider: determines whether tasks run on EC2 instances or serverless Fargate
Service discovery (via AWS Cloud Map) lets tasks find each other by DNS name instead of hardcoded IPs

ECS vocabulary, top to bottom

Cluster

the logical grouping everything runs inside

Service

keeps N tasks running, replaces failures

Task

one running instance of a task definition

Task definition

the versioned blueprint — image, CPU/memory, roles

Signature

cluster → service → task → task definition

Task definition = blueprint. Task = one running instance. Service = keeps N tasks running, replaces failures. Cluster = the logical grouping. Capacity provider = EC2 or Fargate.

2.ECS on EC2 vs Fargate

Both run the same task definitions on the same ECS control plane — the difference is only in the capacity layer underneath. With EC2, you choose the instance type, count, and manage the capacity. With Fargate, AWS provisions compute per task automatically and you never see or manage an instance.

Key features

EC2 capacity: you choose instance type, count, and patch/manage the instances yourself
Fargate: serverless, pay-as-you-go — AWS provisions and scales compute per task, no capacity planning
Fargate removes instance-level isolation concerns; EC2 containers can share a kernel with co-located tasks
EC2 capacity is usually cheaper at steady, high utilization; Fargate avoids idle/undersized capacity
Both use identical task definitions, services, and clusters — the launch type is a per-service or per-task choice

Choosing EC2 vs Fargate capacity

Choosing EC2 vs Fargate capacity
Situation	Choice
Steady, high, predictable utilization	EC2 (often cheaper at scale)
Spiky or unpredictable workloads	Fargate (no idle capacity to pay for)
Need GPU instances or specialized instance types	EC2
Want zero instance patching/management	Fargate
Strict per-task isolation required	Fargate (dedicated kernel per task)

Same task definitions, different capacity layer

ECS on EC2

You choose instance type and count
You patch and manage the instances
Often cheaper at steady, high utilization

ECS on Fargate

AWS provisions compute per task
No instances to see or manage
Avoids paying for idle/undersized capacity

Command

text

EC2 capacity: you manage instances, register them to the cluster
Fargate: --launch-type FARGATE, AWS provisions compute per task, no instances to see

EC2 capacity: you manage instances, cheaper at steady high utilization. Fargate: serverless, pay-per-task, zero instance management — same task definitions and services either way.

3.Task Role vs Execution Role

The task role is what your application code inside the container can do — call S3, DynamoDB, and so on. The execution role is what ECS itself needs before the container even starts — pull the image, fetch secrets, write logs. They are separate roles with separate permissions, and one never substitutes for the other.

Key features

taskRoleArn: permissions vended to the application code running inside the container
executionRoleArn: permissions ECS/Fargate needs to pull the image and start the task
Execution role commonly needs ECR pull permissions and Secrets Manager/SSM read access
Task role is required whenever app code calls other AWS services directly (e.g. S3, DynamoDB)
A task role must trust ecs-tasks.amazonaws.com in its trust policy to be assumable by ECS

Which role grants which permission

Which role grants which permission
Need	Role
App code reads/writes an S3 bucket	Task role
Pull a private image from Amazon ECR	Execution role
Inject a secret from Secrets Manager into the container	Execution role
App code calls DynamoDB using the AWS SDK	Task role
Write container logs to CloudWatch Logs	Execution role

The caterer's badge vs the chef's badge

Execution role

Used by ECS/Fargate itself, before app code runs
Pulls the image from ECR
Fetches secrets, writes logs

Task role

Vended to the running application code
Calls S3, DynamoDB, other AWS APIs
Never used to start the task itself

Command

json

{ "taskRoleArn": "...", "executionRoleArn": "..." }  // both are optional but distinct fields on a task definition

Task role = what the app code inside the container can do (S3, DynamoDB calls). Execution role = what ECS/Fargate needs before the container starts (pull image, fetch secrets, write logs).

4.ECS Rolling Deployments

minimumHealthyPercent and maximumPercent, applied to the desired task count, decide how a rolling deployment replaces tasks — whether it starts new ones before stopping old ones, or has to stop first to free capacity. The deployment circuit breaker can automatically roll back a deployment whose tasks keep failing to start.

Key features

minimumHealthyPercent: lower bound on healthy tasks during a deploy, rounded up
maximumPercent: upper bound on total tasks during a deploy, rounded down
The deployment circuit breaker stops and rolls back a deployment when tasks repeatedly fail to start
CloudWatch alarms can also trigger an automatic rollback, based on application metrics rather than task start failures
Secrets are injected via the execution role from Secrets Manager or SSM Parameter Store, not baked into the image

Command

json

{ "deploymentConfiguration": { "minimumHealthyPercent": 100, "maximumPercent": 200 } }

minimumHealthyPercent bounds how low healthy task count can drop during a deploy; maximumPercent bounds how high total task count can climb. The deployment circuit breaker auto-rolls-back a deployment whose tasks keep failing to start.

5.When to Choose ECS

ECS fits when the workload is already containerized and the team wants managed orchestration without taking on Kubernetes's operational surface. It is AWS's own opinionated orchestrator, trading some of Kubernetes's portability for a simpler operational model on AWS specifically.

Key features

ECS fits when the application is already containerized and the team wants orchestration without Kubernetes's operational surface
ECS integrates natively with IAM (task roles), ALB/NLB, CloudWatch Logs, and Fargate — less glue code than an equivalent EKS setup
Choose EKS instead when Kubernetes portability, its ecosystem (Helm charts, operators), or multi-cloud consistency matters
Neither is required — a single EC2 instance or Lambda can be simpler when orchestration itself is not the actual need

Command

text

Containerized app + want managed orchestration + prefer AWS-native simplicity over Kubernetes portability → ECS

ECS: simpler, AWS-native orchestration for containers, no Kubernetes operational overhead. Choose EKS instead when Kubernetes portability or its ecosystem specifically matters.

Spotted a mistake on this page? Tell us.

Read Sheet