🚨 AWS Error: 'unable to place a task because no container instance met all of its requirements' — Cause, Fix, and Troubleshooting Guide

Overview

On the ECS EC2 launch type, the scheduler must find a registered container instance with enough CPU, memory, free host ports, and matching attributes to run a task. When no instance satisfies every requirement, the service event log reports it couldn’t place the task and names the closest miss (CPU, memory, ports, or a constraint). Tasks stay PENDING and the service never reaches its desired count.

You will see it in the service’s events:

service app-svc was unable to place a task because no container instance met all of its requirements. The closest matching container-instance i-0abc123REDACTED has insufficient CPU units available. For more information, see the Troubleshooting section.

Other variants cite memory, ports, or attributes:

...has insufficient memory available.
...is already using a port required by your task.
...doesn't have the agent connected / didn't satisfy placement constraints.

It occurs when the cluster lacks free capacity, a host port is taken, or a placement constraint can’t be met.

Symptoms

• The ECS service can’t reach desired count; tasks stay PENDING.
• Service events repeat “unable to place a task … insufficient CPU/memory” or “port required.”
• A deploy stalls after a task-definition change that raised CPU/memory or added a host port.
• Scaling out does nothing because the ASG is at max capacity.

Common Root Causes

1. Insufficient CPU or memory on the cluster

The sum of running task reservations leaves no instance with enough free CPU units or memory for the new task.

2. Host port already in use

A task using host/bridge networking needs a fixed host port that another task already holds (one task per host port).

3. Placement constraints or attributes not met

A memberOf/distinctInstance constraint or a required custom attribute/instance type isn’t satisfied by any instance.

4. No registered / connected container instances

The ASG scaled to zero, instances failed to register, or the ECS agent is disconnected.

5. awsvpc ENI limit reached

With awsvpc networking, each task needs an ENI; the instance type’s ENI limit caps how many tasks fit.

How to diagnose

Step 1: Read the service events

aws ecs describe-services --cluster prod --services app-svc \
  --query 'services[0].events[0:5].message' --output table

The “closest matching” message names the exact shortfall (CPU, memory, port, constraint).

Step 2: Check remaining resources per instance

aws ecs list-container-instances --cluster prod --query 'containerInstanceArns' --output text \
| xargs -n1 aws ecs describe-container-instances --cluster prod --container-instances \
  --query 'containerInstances[].[ec2InstanceId,remainingResources[?name==`CPU`].integerValue|[0],remainingResources[?name==`MEMORY`].integerValue|[0],agentConnected]' \
  --output table

Compare the remaining CPU/MEMORY against the task definition’s reservations.

Step 3: Check the task definition’s requirements

aws ecs describe-task-definition --task-definition app-svc \
  --query 'taskDefinition.[cpu,memory,containerDefinitions[].[cpu,memory,portMappings]]' --output json

Fixes

Add cluster capacity

Scale the ASG (or capacity provider) so more/larger instances register:

aws autoscaling set-desired-capacity --auto-scaling-group-name ecs-prod-asg \
  --desired-capacity 4

Enabling a capacity provider with managed scaling lets ECS add capacity automatically.

Right-size the task reservation

Lower the task/container cpu/memory in the task definition if it over-reserves relative to real usage, so it fits existing instances.

Use dynamic host ports

For bridge networking, set the container’s host port to 0 so ECS assigns an ephemeral port (with an ALB target group), eliminating fixed-port collisions.

Relax constraints or switch to Fargate

Remove overly strict placement constraints, or move the service to the FARGATE launch type so AWS provisions right-sized capacity per task and placement stops depending on your fleet.

What to watch out for

• The “closest matching container-instance” line tells you the exact bottleneck — read it before assuming it’s always CPU.
• ECS reserves against declared CPU/memory, not live usage; an over-reserved task blocks placement even on an idle host.
• With host/static bridge ports, only one task per port per instance — dynamic ports or awsvpc avoid this.
• On awsvpc, the instance type’s ENI limit (not just CPU/memory) caps task density — pick larger types or enable ENI trunking.

Related

• AWS Error: ‘CannotPullContainerError’ on ECS — a task that places but can’t pull its image.
• AWS Error: ECS ‘ResourceInitializationError’ fetching secrets — a task that places but fails to start.
• AWS Error: ‘Task failed ELB health checks’ — the next failure once tasks do get placed.