Une entreprise exécute une application sur des instances EC2 dans un groupe Auto Scaling derrière un Application Load Balancer (ALB). Au démarrage, les instances exécutent des scripts user-data pour télécharger le contenu critique de l'application depuis un compartiment S3. Les instances se lancent mais, après un certain temps, sont arrêtées avec le message : « An instance was taken out of service in response to an ELB system health check failure. » Auto Scaling lance et arrête les instances en boucle. Le seul changement récent a été l'ajout d'une grande quantité de contenu critique au compartiment S3. L'entreprise ne souhaite pas modifier les scripts user-data en production. Que doit faire un architecte de solutions pour que l'environnement de production puisse être déployé avec succès ?

L'erreur indique que les instances échouent aux vérifications de santé de l'ALB et sont terminées par Auto Scaling. Le problème survient après l'ajout d'une grande quantité de contenu à S3, ce qui suggère que le téléchargement des données prend plus de temps. Augmenter la période de grâce de la vérification de l'état du groupe Auto Scaling permet aux instances de disposer de plus de temps pour terminer le téléchargement du contenu et initialiser l'application avant que l'ALB ne commence à effectuer des vérifications de santé. Augmenter la taille des instances EC2 n'est pas la solution, car le problème est lié au temps de téléchargement et d'initialisation, pas à la capacité de traitement. Augmenter le délai d'expiration de la vérification de l'état de l'ALB ne résoudrait pas le problème si l'instance n'est pas prête à répondre dans le délai actuel, et pourrait même masquer le problème. Changer le chemin de la vérification de l'état de l'ALB ne résoudrait pas le problème d'initialisation.