Right‑Sizing ECS Tasks Before Autoscaling to Avoid CPU Saturation

The post details a production go‑live scenario where an ECS service was running at 99.8% CPU on a 0.5 vCPU task, causing request queuing and high latency. The author explains that adding more tasks does not help when each task is already saturated; instead the CPU allocation must be increased. The solution was to double the CPU from 512 to 1024 units, which brought the task utilization to around 50% and provided headroom for bursts. The autoscaling policy was then set to target 70% CPU, with a minimum of 9 tasks, a maximum of 20, a 60‑second scale‑out cooldown, and a 300‑second scale‑in cooldown. A second service that was 92% at peak was also right‑sized from 1 vCPU to 2 vCPU. The author notes that the ALBRequestCountPerTarget metric could not be used due to cross‑account registration constraints, so CPU tracking was chosen. The article emphasizes the importance of right‑sizing before configuring autoscaling, as scaling on a saturated task would simply add more undersized units.

Key takeaways include the need to observe real traffic for at least 24 hours, the value of a structured post‑launch data review, and the fact that right‑sizing can resolve both CPU saturation and scaling policy issues in a single change.