L'application HTTP d'une entreprise est derrière un Network Load Balancer (NLB). Le groupe cible du NLB utilise un groupe Amazon EC2 Auto Scaling avec plusieurs instances EC2 exécutant le service web. Le NLB ne détecte pas les erreurs HTTP, ce qui nécessite des redémarrages manuels des instances EC2 du service web. L'entreprise souhaite améliorer la disponibilité sans écrire de scripts ou de code personnalisés. Que doit faire un architecte de solutions ?

Un Application Load Balancer (ALB) est le choix approprié car il opère au niveau de la couche 7 (HTTP/HTTPS) et peut effectuer des vérifications de l'état de santé HTTP détaillées, y compris la vérification des codes de statut HTTP spécifiques de l'application. Le Network Load Balancer (NLB) opère au niveau de la couche 4 (TCP/UDP) et ne peut pas interpréter les erreurs HTTP, ce qui explique le problème actuel. En remplaçant le NLB par un ALB et en configurant des vérifications de l'état de santé HTTP, l'ALB détectera automatiquement les instances défectueuses. Couplé à une action Auto Scaling pour remplacer ces instances, cela améliore la disponibilité sans script personnalisé. Activer les vérifications de l'état de santé HTTP sur le NLB est incorrect car le NLB ne prend pas en charge les vérifications de l'état de santé HTTP au niveau de l'application. Ajouter une tâche cron est incorrect car cela implique des scripts personnalisés, ce que l'entreprise souhaite éviter. Créer une alarme CloudWatch pour UnhealthyHostCount est incorrect car le NLB ne peut pas détecter les erreurs HTTP de l'application, donc la métrique ne refléterait pas les problèmes d'application.