ECS Fargate: Task Placement and Availability

Amazon ECS (Elastic Container Service) with Fargate launch type allows you to run containers without managing servers. However, even with Fargate, AWS must decide where to place each task — which underlying compute resources (e.g., CPU, memory) are allocated. Task placement is the process by which the ECS scheduler determines the infrastructure (host) for a task. For Fargate, this is abstracted, but the scheduler still applies placement constraints and strategies to meet availability and capacity requirements.

When you run multiple tasks of a service, you want them distributed across Availability Zones (AZs) to tolerate an AZ failure. Without proper placement, all tasks could end up in one AZ, creating a single point of failure. Task placement strategies control this distribution.

ECS supports three types of task placement strategies:

In addition to strategies, you can define placement constraints using Amazon ECS attributes or custom attributes.

Fargate abstracts the host, but the ECS scheduler still uses placement strategies to decide which AZ and which underlying infrastructure (the Fargate platform) gets the task. The scheduler considers:

You can set placement strategy in the ECS service definition using the AWS CLI, SDK, or console. Example CLI command to create a service with spread strategy across AZs:

aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task:1 \
    --desired-count 3 \
    --network-configuration "awsvpcConfiguration={subnets=[subnet-abc,subnet-def],securityGroups=[sg-123]}" \
    --placement-strategy type=spread,field=attribute:ecs.availability-zone

To verify placement, use:

aws ecs describe-tasks --cluster my-cluster --tasks arn:aws:ecs:...

This returns the availabilityZone for each task.

To achieve high availability:

If you use binpack, tasks may be placed in fewer AZs, reducing resilience. The exam often tests the trade-off between cost (binpack) and availability (spread).

{
  "serviceName": "web-app",
  "taskDefinition": "web-app:1",
  "desiredCount": 4,
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "subnets": ["subnet-a", "subnet-b", "subnet-c"],
      "securityGroups": ["sg-123"]
    }
  },
  "placementStrategy": [
    {
      "type": "spread",
      "field": "attribute:ecs.availability-zone"
    }
  ]
}

This ensures tasks are spread across three AZs as evenly as possible.

A large e-commerce platform runs its product catalog, cart, and checkout as separate ECS services on Fargate. They operate in three AZs (us-east-1a, 1b, 1c). Each service has a desired count of 6 tasks. They use spread across AZs to ensure that if one AZ fails, each service still has 4 tasks running in the other two AZs. This is configured with the placement strategy shown earlier. The ALB is configured with cross-zone load balancing enabled to distribute traffic evenly across all healthy tasks. Performance is monitored via CloudWatch metrics for CPU and memory; if utilization exceeds 80%, Service Auto Scaling adds tasks, which are spread automatically.

A financial analytics company runs batch jobs on Fargate. They have a single service that processes large datasets. They want to minimize cost, so they use binpack strategy with field: memory to pack tasks onto as few hosts as possible. However, they still run in two AZs for basic availability. They set desiredCount to 2, one per AZ, but binpack might place both in the same AZ if memory is more available there. To force distribution, they use a custom attribute per AZ and a memberOf constraint. This scenario shows that binpack is not ideal for availability; the exam tests this trade-off.

A developer creates a service with subnets from only one AZ but uses spread strategy across AZs. All tasks end up in that single AZ because there is no other AZ to spread to. The service appears healthy until that AZ fails, causing complete outage. The exam loves this trap: the strategy does not override the subnet list; it only spreads across the AZs that are available via the subnets. Always ensure subnets span multiple AZs.