Een bedrijf draait een applicatie op EC2-instances in een Auto Scaling-groep achter een Application Load Balancer (ALB). Bij het opstarten voeren de instances user-data scripts uit om cruciale applicatiecontent te downloaden van een S3-bucket. Instances starten, maar worden na enige tijd beëindigd met de melding: “An instance was taken out of service in response to an an ELB system health check failure.” Auto Scaling start en beëindigt instances herhaaldelijk in een lus. De enige recente wijziging was het toevoegen van een grote hoeveelheid cruciale content aan de S3-bucket. Het bedrijf wil de user-data scripts in productie niet wijzigen. Wat moet een solutions architect doen zodat de productieomgeving succesvol kan worden geïmplementeerd?

De Auto Scaling group health check grace period is de tijd die Auto Scaling wacht nadat een instance is opgestart voordat de health checks beginnen. De nieuwe, grote hoeveelheid content in de S3-bucket verlengt de downloadtijd via het user-data script, waardoor de instance langer nodig heeft om volledig operationeel te zijn. De ALB health checks falen voordat de applicatie klaar is, wat leidt tot beëindiging van de instance en de herhaaldelijke lus. Door de grace period te verhogen, krijgt de instance voldoende tijd om de content te downloaden en de applicatie te starten voordat de health checks beginnen. Het vergroten van de EC2-instancegroottes helpt niet direct met de downloadtijd. Het wijzigen van het ALB health check pad lost het onderliggende probleem van de opstarttijd niet op. Het verhogen van de ALB health check timeout waarde kan helpen, maar de grace period is specifieker voor opstartproblemen.