Une entreprise observe des tentatives de connexion inhabituelles sur plusieurs comptes AWS. Un sujet SNS existe déjà et l'équipe de sécurité y est abonnée. Quelle approche nécessite le moins d'effort opérationnel pour notifier l'équipe de sécurité lorsque plusieurs tentatives de connexion à la console échouent ?

L'option correcte est la plus efficace car elle utilise CloudTrail pour capturer les événements de gestion (qui incluent les tentatives de connexion à la console), les envoie directement à CloudWatch Logs, où un filtre de métriques peut facilement identifier les échecs de connexion. Une alarme CloudWatch est ensuite déclenchée par cette métrique et publie sur le sujet SNS existant, minimisant ainsi l'effort opérationnel. Les autres options sont moins optimales : L'utilisation d'Athena avec S3 implique une complexité et un coût plus élevés pour les requêtes régulières. Les événements de données CloudTrail ne sont pas pertinents ici ; les tentatives de connexion sont des événements de gestion. L'envoi d'événements de données à S3 avec des notifications d'événements S3 est incorrect car les tentatives de connexion sont des événements de gestion, et cette approche est plus complexe pour le filtrage et la notification en temps réel que CloudWatch Logs et les alarmes.