W konfiguracji obejmującej wiele kont, firma kieruje cały ruch wychodzący przez Transit Gateway do konta operacji sieciowych. Tam ruch jest sprawdzany przez urządzenie firewall, zanim dotrze do bramy internetowej. Firewall zapisuje logi do CloudWatch Logs i klasyfikuje zdarzenia jako CRITICAL, HIGH, MEDIUM, LOW i INFO. Zespół bezpieczeństwa musi być powiadamiany za każdym razem, gdy pojawią się zdarzenia CRITICAL. Co powinien zaimplementować inżynier DevOps, aby spełnić ten wymóg?

Poprawna odpowiedź to utworzenie filtru metryk CloudWatch Logs, który wyszukuje zdarzenia "CRITICAL" w logach firewalla i emituje niestandardową metrykę. Następnie należy skonfigurować alarm CloudWatch, który monitoruje tę metrykę i publikuje powiadomienia do tematu SNS, do którego subskrybowany jest adres e-mail zespołu bezpieczeństwa. Jest to najbardziej bezpośrednie i efektywne rozwiązanie, ponieważ firewall już zapisuje logi do CloudWatch Logs, a filtry metryk są przeznaczone do wyodrębniania konkretnych wzorców z logów. Nieprawidłowe opcje: Canary CloudWatch Synthetics służy do monitorowania dostępności i wydajności aplikacji, a nie do analizy logów firewalla pod kątem konkretnych zdarzeń. Amazon GuardDuty skupia się na wykrywaniu zagrożeń bezpieczeństwa na podstawie logów przepływu i innych źródeł danych AWS, a nie na analizie logów z urządzeń firewall pod kątem zdefiniowanych przez użytkownika poziomów krytyczności. AWS Firewall Manager służy do centralnego zarządzania regułami firewalla, a nie do monitorowania logów z konkretnych urządzeń firewall pod kątem zdarzeń "CRITICAL" w sposób opisany w scenariuszu.