ECS Task Placement: Binpack, Spread, and When Each Costs You

What placement strategies actually control

ECS placement strategies tell the scheduler where to start a new task within a cluster. They apply when a task launches — not continuously. If you change the strategy on a running service, existing tasks are not rebalanced. Only new task launches follow the updated strategy.

Three strategies are available: binpack, spread, and random. In practice, you choose between binpack and spread. Random is rarely the right answer.

Binpack: fewer instances, higher blast radius

Binpack packs tasks onto the fewest possible instances by maximizing utilization of a chosen resource (cpu or memory).

{
  "placementStrategy": [
    { "type": "binpack", "field": "memory" }
  ]
}

The benefit is cost: if your cluster runs 40 tasks that could fit on 4 instances instead of 8, you pay for 4. With EC2 pricing, that difference compounds across environments and AWS accounts.

The risk is blast radius. Fewer instances means more tasks per host. When a host terminates — scheduled replacement, capacity event, Spot interruption — more tasks die simultaneously. Recovery time for the service depends on how fast ECS can reschedule and how long each task takes to pass health checks.

Use binpack when:

• Workloads are batch or async (failures can retry, not user-facing)
• You run Spot instances and treat interruption as a normal event
• Cost is the primary constraint and the workload can tolerate brief disruption

Spread: higher cost, better fault tolerance

Spread distributes tasks as evenly as possible across a specified dimension. The most common dimensions are instanceId (spread across hosts) and attribute:ecs.availability-zone (spread across AZs).

{
  "placementStrategy": [
    { "type": "spread", "field": "attribute:ecs.availability-zone" },
    { "type": "spread", "field": "instanceId" }
  ]
}

Chaining spread strategies like this is the standard pattern for user-facing services: first spread across AZs, then spread instances within each AZ. A single host failure takes down only the tasks on that host. A single AZ failure takes down only the tasks in that AZ.

Use spread when:

• The service handles live user traffic
• You have an SLA that requires surviving single-AZ failures
• You run multiple environments (each env has its own instances, and spread within each matters)

Combining strategies with capacity providers

Real clusters often mix both approaches: On-Demand instances running spread for baseline capacity, Spot instances running binpack for burst workloads. ECS capacity providers enable this without managing two separate clusters.

{
  "capacityProviderStrategy": [
    { "capacityProvider": "FARGATE",      "weight": 1, "base": 2 },
    { "capacityProvider": "FARGATE_SPOT", "weight": 3, "base": 0 }
  ]
}

The base field reserves a minimum number of tasks on a specific provider — useful for ensuring at least some tasks run on On-Demand even during Spot shortages.

ResourceInUseException: The specified capacity provider is in use and cannot be removed.

resource "aws_ecs_cluster_capacity_providers" "main" {
  cluster_name = aws_ecs_cluster.main.name

  capacity_providers = ["FARGATE", "FARGATE_SPOT"]

  default_capacity_provider_strategy {
    base              = 2
    weight            = 1
    capacity_provider = "FARGATE"
  }
}

Placement constraints: the hard filter before the strategy

Constraints run before strategies. If no instance satisfies the constraint, the task fails to place regardless of which strategy you specified.

The two constraint types are:

• distinctInstance — each task must run on a different instance (useful for ensuring tasks do not co-locate)
• memberOf — filter by a cluster query language expression, such as instance type, AZ, or custom attribute

{
  "placementConstraints": [
    {
      "type": "memberOf",
      "expression": "attribute:ecs.availability-zone in [us-east-1a, us-east-1b]"
    }
  ]
}