Un site web s'exécute sur quatre instances EC2 derrière un ALB. Lorsque l'ALB marque une instance comme non saine, une alarme CloudWatch passe à l'état ALARM et un opérateur ajoute manuellement une instance de remplacement. L'entreprise souhaite une solution hautement disponible qui remplace automatiquement les instances EC2 défaillantes tout en minimisant les temps d'arrêt pendant la migration vers la nouvelle conception. Quelle séquence d'étapes l'architecte de solutions doit-il utiliser ?

La bonne approche consiste à créer un groupe Auto Scaling (ASG) avec un nouveau modèle de lancement, puis à l'attacher à l'ALB existant. Ensuite, les instances EC2 existantes peuvent être ajoutées à l'ASG. Cette méthode permet une transition en douceur sans temps d'arrêt, car l'ALB continue de servir le trafic via les instances existantes pendant que l'ASG est configuré. L'ASG prendra en charge le remplacement automatique des instances défaillantes, améliorant ainsi la haute disponibilité. Les autres options impliquent la suppression de l'ALB ou des instances existantes, ce qui entraînerait des temps d'arrêt. L'option qui attend que l'ALB enregistre les instances auprès de l'ASG est incorrecte car c'est l'ASG qui gère les instances, pas l'ALB qui les enregistre auprès de l'ASG.