Toutes les instances EC2 d'un groupe Auto Scaling derrière un Application Load Balancer ont cessé de traiter le trafic et échouent aux vérifications de l'état de santé du groupe cible HTTP. Le processus de l'application ne s'exécute pas et les journaux système affichent de nombreuses erreurs de mémoire insuffisante. Pour améliorer la résilience contre une éventuelle fuite de mémoire et activer la surveillance/les alertes, quelle combinaison d'actions devriez-vous entreprendre ? (Choisissez-en deux.)

La modification du groupe Auto Scaling pour remplacer automatiquement les instances défaillantes est cruciale pour la résilience. Lorsque les instances échouent aux vérifications de l'état de santé de l'équilibreur de charge (en raison d'une fuite de mémoire, par exemple), Auto Scaling les terminera et lancera de nouvelles instances saines, rétablissant ainsi le service. L'installation de l'agent CloudWatch permet de collecter des métriques détaillées sur l'utilisation de la mémoire au niveau de l'OS, ce qui est essentiel pour détecter les fuites de mémoire avant qu'elles ne causent une panne complète. Une alarme CloudWatch basée sur ces métriques peut ensuite alerter les opérateurs via SNS, permettant une intervention proactive. Réduire le HealthCheckIntervalSeconds ne résout pas la cause du problème et peut même augmenter la charge. Changer la vérification de HTTP à TCP masquerait le problème de l'application au lieu de le détecter. La métrique de consommation de mémoire disponible dans la console CloudWatch est une métrique d'hôte fournie par le service EC2, mais elle ne fournit pas le niveau de détail nécessaire pour diagnostiquer une fuite de mémoire applicative et n'est pas disponible pour l'ensemble du groupe Auto Scaling sans configuration supplémentaire.