Firma potrzebuje natywnego rozwiązania AWS do alertowania o powtarzających się nieudanych logowaniach do swoich hostów bastionowych: wyzwolenie powiadomienia, gdy w ciągu 5 minut nastąpi 5 nieudanych prób uwierzytelnienia, i wysłanie alertu tylko do administratora systemu odpowiedzialnego za dany host. Które podejście spełnia te wymagania?

Poprawne podejście wykorzystuje agenta CloudWatch do zbierania logów systemu operacyjnego, co jest standardową metodą. Następnie tworzy alarm CloudWatch oparty na filtrze metryk, aby wykryć 5 nieudanych logowań w ciągu 5 minut. Po przekroczeniu progu alarm publikuje wiadomość w temacie SNS. Kluczowe jest użycie filtrowania wiadomości SNS, które pozwala na precyzyjne kierowanie powiadomień tylko do administratora odpowiedzialnego za dany host, spełniając wymóg wysyłania alertów do konkretnego administratora. Pozostałe opcje są mniej odpowiednie: Opcja 1 błędnie sugeruje użycie EventBridge do tworzenia alarmu opartego na filtrze metryk (to jest funkcja CloudWatch Alarms) oraz użycie tagów instancji EC2 do decydowania o tematach SNS, co nie jest natywnym mechanizmem filtrowania wiadomości SNS. Opcja 2 i 4 wprowadzają niepotrzebne złożoności z AWS Systems Manager Agent i Run Command do konfiguracji CloudWatch, podczas gdy agent CloudWatch jest bezpośrednim rozwiązaniem. Dodatkowo, opcja 4 ponownie błędnie sugeruje użycie tagów instancji EC2 do filtrowania tematów SNS.