ECS Tasks Stuck in PENDING Because the Instance Ran Out of ENIs
A service scaled to six tasks on a two-instance cluster. Four started, two sat in PENDING while the cluster reported plenty of free CPU and memory. The service events pointed at network interface capacity, which is not where I was looking.
In awsvpc network mode, every task gets its own elastic network interface. The instance has a hard cap on those, and the primary interface counts toward it. A c5.large allows three, so you can attach two, so you can run two tasks. Free memory is irrelevant.
Turn on trunking
ECS can attach a trunk interface and carry many branch interfaces on it. On a c5.large that raises the limit from three to twelve, which means ten tasks instead of two.
aws ecs put-account-setting-default --name awsvpcTrunking --value enabledThen replace your instances. This is the part that wasted an afternoon for me: only instances launched after the setting is enabled get the trunk interface. Existing ones never pick it up, no matter how many times you drain and restart the agent. Roll the Auto Scaling group.
Two more ways it silently doesn’t apply
put-account-setting without -default applies to the IAM identity you called it with, and nothing else. If you enable it as your admin user but your instances launch under a different instance profile, nothing changes. The console shows the setting as on, because it’s showing it for you.
The instance also needs container agent 1.28.1 or later, plus ecs-init 1.28.1-2 or later on the ECS-optimized AMI, and a supported instance type. A recent AMI covers this, an AMI you pinned two years ago might not.
Or skip the whole problem
Fargate tasks always get a dedicated interface and no instance limit applies. If the cluster exists mainly to pack small tasks together, the ENI ceiling is a decent argument for not managing instances at all.
Before scaling a service, work out how many interfaces each instance type gives you. It’s a smaller number than the memory suggests, and it’s the limit you hit first.