Firma migrowała kontenery do Amazon EKS i potrzebuje zautomatyzowanych powiadomień e-mail dla każdego komponentu EKS. Plan zakłada użycie tematów SNS i funkcji Lambda, która analizuje zdarzenia logów i publikuje je w odpowiednim temacie SNS. Które podejście do logowania wspiera ten projekt?

Poprawna odpowiedź to włączenie Amazon CloudWatch Logs dla komponentów EKS i utworzenie filtru subskrypcji CloudWatch Logs dla każdego komponentu z Lambda jako miejscem docelowym. CloudWatch Logs to naturalny wybór do centralizacji logów z EKS. Filtry subskrypcji CloudWatch Logs umożliwiają przekazywanie strumieni logów w czasie rzeczywistym do funkcji Lambda, która może następnie przetwarzać zdarzenia i publikować je w odpowiednich tematach SNS. Pozostałe opcje są mniej odpowiednie: Używanie zapytań CloudWatch Logs Insights z EventBridge jest możliwe, ale filtry subskrypcji są bardziej bezpośrednim i wydajnym sposobem na reagowanie na strumienie logów w czasie rzeczywistym. Logowanie do Amazon S3 jest przeznaczone głównie do archiwizacji i analizy wsadowej, a nie do powiadomień w czasie rzeczywistym. Filtry subskrypcji CloudWatch Logs nie działają bezpośrednio na logach S3. Powiadomienia o zdarzeniach S3 PUT Object również nie są przeznaczone do analizy logów w czasie rzeczywistym z komponentów EKS.