An ECS service on EC2 is set to a higher desired count, and the count does not rise. The service maximum percent is 100, and the cluster's container instances have no spare CPU or memory. What is the constraint?
Select an answer to reveal the explanation.
Short Explanation
The service wants more copies, but the container instances have no empty room, so ECS cannot place them. You need more cluster capacity or a smaller task reservation. DNS is not holding the desired count.
Full Explanation
ECS will not set desired count above what it can place. With the instances already full of CPU and memory, ECS cannot place the higher count at all. The constraint is cluster capacity. Maximum percent limits how many extra tasks may run during a deployment, so it is not what blocks a plain scale-out. Route 53 does not store ECS desired count. S3 versioning does not place tasks. A health-check grace period only delays failing a new task; it does not add CPU or memory. Caveat: if this is a rolling deploy, raising maximum percent above 100 lets new tasks start before old ones stop, but only after the cluster actually has room. Operational check: the service events should say the task could not be placed, and Container Insights or the instance view should show no remaining CPU or memory. Look at the service event for a placement failure that names insufficient CPU or memory. Either add container instances, raise the Auto Scaling group's capacity, or shrink the task's reservation if it is larger than it needs to be. Maximum percent of 100 only matters for deployments, where it stops a new copy starting before an old one stops; raise it only if the cluster has room for the overlap.