Aplikacja w VPC używa bramy NAT do wychodzącego dostępu do internetu. Inżynier sieciowy obserwuje dużą ilość podejrzanego ruchu wychodzącego z VPC do adresów IP znajdujących się na liście zablokowanych. Inżynier musi określić, które zasoby AWS generują ten ruch, jednocześnie utrzymując niskie koszty i nakład administracyjny. Które podejście spełnia te wymagania?

Poprawna odpowiedź to włączenie VPC Flow Logs i publikowanie ich w Amazon CloudWatch Logs, a następnie użycie CloudWatch Logs Insights do analizy. VPC Flow Logs rejestrują metadane ruchu IP (źródło, cel, porty, protokół, akcja) dla interfejsów sieciowych, co pozwala zidentyfikować, które zasoby AWS (np. instancje EC2) generują ruch wychodzący. Publikowanie logów bezpośrednio do CloudWatch Logs i użycie Logs Insights to natywne, w pełni zarządzane rozwiązanie AWS, które jest efektywne kosztowo i wymaga minimalnego nakładu administracyjnego. Umożliwia ono szybkie i elastyczne zapytania bez konieczności wdrażania dodatkowych serwerów czy złożonych potoków danych. Pozostałe opcje są mniej optymalne: Traffic Mirroring jest droższe i bardziej złożone, wymaga instancji EC2 do analizy i nie jest idealne do identyfikacji źródła ruchu z bramy NAT. Wdrożenie SIEM w VPC wiąże się z wysokimi kosztami i dużym nakładem administracyjnym na utrzymanie dodatkowych zasobów. Strumieniowanie do Kinesis, Firehose i S3 z Athena jest bardziej złożonym i potencjalnie droższym rozwiązaniem, odpowiednim dla bardzo dużych wolumenów danych lub długoterminowej analizy, ale nie dla szybkiej, kosztowo efektywnej identyfikacji.