A company runs an application on EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). On startup, instances run user-data scripts to download critical application content from an S3 bucket. Instances launch but, after some time, are terminated with the message: “An instance was taken out of service in response to an ELB system health check failure.” Auto Scaling repeatedly launches and terminates instances in a loop. The only recent change was adding a large amount of critical content to the S3 bucket. The company does not want to modify user-data scripts in production. What should a solutions architect do so the production environment can deploy successfully?

The Auto Scaling group health check grace period is the time an instance is given to start up and pass health checks before Auto Scaling considers it unhealthy. Since the recent change involved adding a large amount of content to the S3 bucket, the user-data script now takes longer to download this content, causing the instance to exceed the default grace period and fail the health check. Increasing this grace period allows instances sufficient time to complete their startup tasks and become healthy. Increasing EC2 instance sizes might speed up downloads slightly but doesn't address the core timing issue with the health check. Increasing the ALB health check timeout value only affects the ALB's individual health checks, not the Auto Scaling group's initial evaluation during startup. Changing the ALB health check path doesn't resolve the extended startup time for content download.