Une entreprise de médias gère des milliers d'instances EC2 et utilise Slack ainsi qu'une boîte de réception e-mail partagée pour les communications d'équipe. Un ingénieur DevOps doit transmettre toutes les notifications de maintenance EC2 planifiées par AWS au canal Slack et à la boîte de réception partagée. Les notifications doivent inclure les balises Name et Owner des instances. Quelle approche répond à ces exigences ?

L'approche correcte utilise Amazon EventBridge pour capturer les événements de maintenance AWS Health, qui sont la source officielle des notifications de maintenance planifiée pour les instances EC2. EventBridge peut ensuite acheminer ces événements vers une rubrique Amazon SNS. Une fonction Lambda abonnée à cette rubrique SNS peut traiter les détails de l'événement, y compris les balises de l'instance (qui peuvent être récupérées via l'API EC2 si non incluses directement dans l'événement Health), et formater les messages pour Slack et la boîte de réception partagée. Les autres options sont incorrectes car : Intégrer Trusted Advisor avec AWS Config ne cible pas directement les événements de maintenance AWS Health et est une approche trop complexe et indirecte pour ce cas d'utilisation. Surveiller la santé des EC2 via les métriques CloudWatch et déclencher une Lambda à partir d'une alarme CloudWatch ne fournit pas les notifications de maintenance planifiée d'AWS Health, mais plutôt des alertes basées sur des métriques opérationnelles. Activer l'intégration d'AWS Support avec CloudTrail et créer un événement de recherche CloudTrail n'est pas la méthode standard pour recevoir les notifications de maintenance AWS Health. CloudTrail enregistre les appels d'API et les événements de gestion, mais ne génère pas directement les notifications de maintenance planifiée comme le fait AWS Health.