Une application s'exécute sur des instances EC2 derrière un Application Load Balancer (ALB). L'administrateur SysOps doit créer une vérification de l'état de santé personnalisée pour les instances. Quelle est la méthode la plus simple sur le plan opérationnel pour implémenter cela ?

La configuration de la vérification de l'état de santé de l'ALB avec un chemin de vérification de l'état de santé (Health Check Path) correct est la méthode la plus simple et la plus opérationnelle. L'ALB est conçu pour effectuer des vérifications de l'état de santé des instances enregistrées dans ses groupes cibles. En spécifiant un chemin personnalisé, l'application sur l'instance peut exposer une URL qui renvoie un code de succès (par exemple, 200 OK) si l'application est saine, et un code d'erreur dans le cas contraire, permettant à l'ALB de gérer automatiquement le routage du trafic. Les autres options sont moins efficaces : Écrire l'état dans un objet S3 partagé ajoute une complexité inutile et n'est pas le mécanisme prévu pour les vérifications de l'état de santé de l'ALB. Utiliser Amazon ElastiCache pour maintenir l'état de santé est une utilisation inappropriée de ce service et ne s'intègre pas directement avec les vérifications de l'état de santé de l'ALB. Utiliser API Gateway pour exécuter des vérifications de l'état de santé introduit une couche de complexité et de coût supplémentaire sans offrir les avantages inhérents aux vérifications de l'état de santé de l'ALB.