An Auto Scaling group uses target tracking on ALBRequestCountPerTarget. Desired capacity never changes, and no targets are registered in the load balancer. The application is not receiving traffic. Why is the policy idle?
Select an answer to reveal the explanation.
Short Explanation
The policy is watching requests per target, and there are no targets, so the number never arrives. You register targets, or you fix why the tasks are not registering, before the policy can see load. Deleting the load balancer removes the metric's source.
Full Explanation
ALBRequestCountPerTarget is emitted for a target group that has registered targets. With none registered, the series the policy tracks is missing, so target tracking does not change desired capacity. The idle policy is a consequence of the empty target group, not the cause of the outage. S3 versioning, deleting the load balancer, and a warm pool do not gate this metric. Caveat: once targets exist, a broken health check can leave them unused and the request count still low; fix registration and health together. Operational check: the target group should show healthy targets, the request-count metric should have datapoints, and only then should target tracking be expected to move desired capacity. The policy's metric is requests per target for a specific target group. With zero registered targets, CloudWatch has no series for the policy to track, so desired capacity stays where it is. Register the tasks or instances and make them healthy. A warm pool does not suppress the metric once targets exist. After datapoints appear, a test load should move desired capacity. Until then, editing the target value has nothing to track.