A water utility's Auto Scaling group replaces new instances before the application is listening. The group uses load balancer health checks, and the grace period is shorter than boot. What should they change?
Select an answer to reveal the explanation.
Short Explanation
The referee is blowing the whistle before the player has finished tying their shoes. You set the Auto Scaling health check grace period shorter than boot, so the group treats a still-starting instance as unhealthy and replaces it. Idle timeouts and drain delays do not give that instance time to start listening.
Full Explanation
With load balancer health checks, Auto Scaling replaces an instance once the load balancer reports it unhealthy and the grace period has ended. The grace period is the time after launch during which Auto Scaling does not act on that result. If the application is not listening when the grace period ends, the new instance is terminated and the group never settles. Lengthen the grace period so it covers boot and the time needed to pass the check. The load balancer idle timeout closes quiet client connections and does not change how launch health is judged. Desired capacity is how many instances the group wants, not how long each one may boot. Deregistration delay applies while a target is being removed, and it does not protect a new instance that has not yet passed. Caveat: a grace period that far outlasts a real boot also delays replacement of an instance that is truly broken, so base it on a measured start, not an open-ended wait. Operational check: launch one instance, time how long until the target is healthy, and set the grace period longer than that measurement.