AWS DevOps Agent przyspiesza rozwiązywanie problemów z Network Firewall

AWS rozszerzył możliwości AWS DevOps Agent o obsługę dochodzeń dotyczących AWS Network Firewall. Nowa integracja pozwala agentowi autonomicznie analizować przyczyny utraty łączności sieciowej, korelować logi i konfigurację zapory z historią zmian w CloudTrail i prezentować gotowy plan naprawczy — bez konieczności ręcznego przeglądania wielu narzędzi jednocześnie.

Problem, który rozwiązuje integracja

Gdy administrator wprowadza zmianę reguły w AWS Network Firewall i łączność sieciowa zostaje zerwana, zidentyfikowanie przyczyny wymaga inspekcji wielu punktów na ścieżce ruchu jednocześnie: silników reguł bezstanowych i stanowych, reguł domenowych, tabel routingu i logów CloudTrail. Z perspektywy workloadu porzucony pakiet wygląda tak samo niezależnie od warstwy, na której nastąpił problem.

Ręczna korelacja alertów, logów przepływu i konfiguracji zapory z ostatnimi zmianami API pochłania czas, który przy incydencie produkcyjnym jest najcenniejszym zasobem. AWS DevOps Agent robi tę korelację automatycznie: gdy alarm CloudWatch się odpali, agent odczytuje konfigurację i logi zapory przez API AWS, wiąże porzucone pakiety z ostatnią aktywnością API i zwraca przyczynę źródłową wraz z planem naprawczym do zatwierdzenia przez inżyniera.

Jak działa potok alarmowy

Każde dochodzenie dotyczące Network Firewall przebiega tym samym torem:

1. Po wyzwoleniu alarmu CloudWatch powiadomienie trafia do Amazon SNS
2. Amazon SNS wywołuje funkcję Lambda
3. Lambda odczytuje adres URL webhooka i sekret podpisujący z AWS Secrets Manager, podpisuje payload alarmu i wysyła go do webhooka AWS DevOps Agent
4. Agent analizuje zebrane dane i identyfikuje przyczynę źródłową

Dwa sposoby wykrywania problemów z zaporą są dostępne od razu i można je łączyć w jednym potoku alarmowym:

Wbudowana metryka Network Firewall — DroppedPackets zsumowana dla strumieni stanowych, uruchamiana gdy liczba porzuconych pakietów przekroczy próg bazowy. Nie wymaga żadnej dodatkowej instrumentacji po stronie workloadu — działa na już wdrożonej zaporze. Wadą jest to, że wskazuje jedynie, że zapora porzuca pakiety, nie wskazując konketnej reguły.

Metryka kondycji aplikacji — niestandardowa metryka z cyklicznego sprawdzania łączności workloadu do konkretnego punktu końcowego. Daje alarm powiązany bezpośrednio z wpływem na użytkownika i pozwala odróżnić różne ścieżki ruchu od siebie. Niezbędna gdy problem — jak asymetryczny routing między strefami dostępności — jest niewidoczny dla licznika porzuconych pakietów zapory.

Trzy scenariusze dochodzeń

AWS opisał trzy typowe awarie, przez które przeszedł agent w środowisku laboratoryjnym. Każda dotyczy innej warstwy, więc każda prowadzi przez inną ścieżkę dochodzeniową.

Scenariusz 1: Lista odrzucanych domen blokuje zaufany punkt końcowy

Administrator dodaje regułę Suricata do grupy reguł domenowych, która blokuje połączenia TLS do konkretnej nazwy domenowej na podstawie wskaźnika SNI (Server Name Indication). Jeśli zablokowany punkt końcowy jest prawidłowym celem workloadu — łączność zrywa się natychmiast.

Agent bada problem równolegle na czterech frontach: koreluje skok metryki DroppedPackets ze spadkiem pakietów przekazanych, odczytuje log ALERT i identyfikuje regułę domenową (SID 2000002) blokującą połączenia TLS, porównuje stan bieżący z oknem bazowym potwierdzając że blokada jest nowa, i przeszukuje CloudTrail ujawniając wywołanie UpdateRuleGroup — użytkownika, rolę i znacznik czasu około minuty przed pojawieniem się porzuconych pakietów.

Wynik: wskazanie konkretnej reguły domenowej jako przyczyny, rekomendacja usunięcia wpisu blokującego lub dodania wyjątku zezwalającego, oraz zalecenie włączenia FirewallPolicyChangeProtection zapobiegającego nieautoryzowanym zmianom.

Scenariusz 2: Błędna kolejność priorytetów reguł bezstanowych

Reguły bezstanowe AWS Network Firewall oceniane są według numerów priorytetów — niższy numer ewaluowany jest pierwszy. Jeśli reguła DROP ma niższy priorytet niż reguła PASS dla tej samej klasy ruchu, porzucenie następuje zanim ruch dotrze do silnika stanowego. W logach ALERT nie pojawia się żaden wpis — bo silnik stanowy nie widzi pakietów, które porzucił silnik bezstanowy.

Agent zmienia strategię: zamiast szukać w logach ALERT, odczytuje stan grupy reguł bezstanowych i stwierdza że reguła DROP ma niższy numer priorytetu niż reguła PASS. Następnie analizuje logi przepływu — widzi że przekazane pakiety spadają do zera minutę po zmianie — i przeszukuje CloudTrail ujawniając wywołanie UpdateRuleGroup z inwersją priorytetów.

To scenariusz pokazujący dlaczego monitorowanie kondycji aplikacji jest niezbędnym uzupełnieniem metryk samej zapory: problem bezstanowy jest niewidoczny dla DroppedPackets jeśli reguła DROP należy do grupy bezstanowej.

Scenariusz 3: Asymetryczny routing między strefami dostępności

AWS Network Firewall jest inspekcją stanową — wymaga żeby obie strony połączenia (egress i powrót) przechodziły przez ten sam punkt końcowy zapory w tej samej strefie dostępności. Jeśli egress wychodzi przez punkt końcowy w us-east-1a, a powrót zostaje skierowany do punktu końcowego w us-east-1b — żaden z nich nie widzi pełnego przepływu, uzgadnianie połączenia kończy się niepowodzeniem i łączność zostaje zerwana.

Ten typ awarii jest szczególnie trudny do wykrycia: licznik DroppedPackets pozostaje na zerze, bo zapora nie odrzuca pakietów — po prostu nigdy ich nie widzi w całości. Przepływ ginie przez asymetrię routingu. Alarm kondycji aplikacji wyzwala się, ale alarm oparty wyłącznie na metrykach zapory milczy.

Agent koreluje logi przepływu (ruch jednokierunkowy, brak przepływów w stanie established), odczytuje metryki zapory (pakiety przesunęły się z jednej strefy do drugiej w momencie zmiany), wywołuje DescribeRouteTables i stwierdza że trasa egress wskazuje na inny punkt końcowy niż trasa powrotu, oraz przeszukuje CloudTrail ujawniając wywołania ReplaceRoute i CreateRoute przez tego samego użytkownika chwilę przed alarmami.

Gdy dwa alarmy wyzwalają się w tym samym czasie, agent rozpoznaje je jako powiązane i scala w jedno dochodzenie — zamiast produkować dwa osobne raporty o tej samej przyczynie.

Proaktywne zapobieganie incydentom

Agent nie tylko diagnozuje istniejące problemy. Po zakończeniu dochodzenia analizuje wzorce z przeszłych zdarzeń i dostarcza rekomendacje zapobiegające podobnym incydentom w przyszłości — w tym rekomendacje zabezpieczeń dla pipeline'u CI/CD oparte na klasach błędów konfiguracji, które agent już rozwiązał.

Dla zmian reguł Network Firewall oznacza to konkretne wskazówki jak zbudować guardrails w pipeline'ach wdrożeniowych zapobiegające błędnej kolejności priorytetów lub nieautoryzowanym zmianom grup reguł. Rekomendacje dostępne są w zakładce Improvements panelu operatora AWS DevOps Agent.

Integracja z IaC i repozytoriami kodu

Gdy agent ma dostęp do repozytoriów kodu i pipeline'ów CI/CD — GitHub, GitHub Enterprise Server, GitLab Self-Managed, CloudFormation, CDK, Terraform — może korelować awarię z wdrożeniem, które ją wprowadziło, i rekomendować naprawę zgodną z zamierzonym projektem infrastruktury.

Dla środowisk z wieloma strefami dostępności oznacza to na przykład rekomendowanie konkretnego punktu końcowego zapory w tej samej strefie co workload — zamiast ogólnego zalecenia przywrócenia symetrii routingu bez wskazania właściwego celu.

Środowisko laboratoryjne do testów

AWS udostępnił gotowe środowisko CDK pozwalające odtworzyć wszystkie trzy scenariusze we własnym koncie. Wdrożenie całego stosu to jedna komenda:

git clone https://github.com/aws-samples/sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent.git
cd sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent
bash scripts/deploy.sh

Stos wdraża instancję EC2 w chronionym podsieci sprawdzającą łączność w pętli, Network Firewall z dwoma punktami końcowymi w dwóch strefach dostępności, potok alarmowy przez CloudWatch, SNS i Lambda do webhooka DevOps Agent oraz stronę statusu pokazującą w czasie rzeczywistym stan każdego scenariusza.

Po zakończeniu testów usunięcie wszystkich zasobów — jedna komenda:

bash scripts/destroy.sh

Wzorzec wykracza poza Network Firewall

Ten sam potok alarmowy — CloudWatch alarm → SNS → Lambda → webhook DevOps Agent — działa dla każdej usługi emitującej metryki i logi do CloudWatch: AWS WAF, grupy bezpieczeństwa EC2, sieciowe listy kontroli dostępu (NACL). Agent stosuje tę samą metodologię dochodzeniową: odczytuje konfigurację przez API, koreluje z logami przepływu i historią zmian CloudTrail, wskazuje przyczynę i rekomenduje naprawę.

Podsumowanie

Integracja AWS DevOps Agent z Network Firewall to praktyczna odpowiedź na jeden z trudniejszych problemów operacyjnych w środowiskach AWS: diagnozowanie utraty łączności sieciowej, gdy ta sama symptomatologia może mieć przyczynę w regule domenowej, kolejności priorytetów reguł bezstanowych lub asymetrycznym routingu między strefami dostępności.

Trzy różne warstwy problemu — trzy różne ścieżki dochodzeniowe — jeden potok alarmowy i jeden agent który robi korelację automatycznie. Agent prezentuje plan naprawczy do zatwierdzenia przez inżyniera, nie wykonuje zmian autonomicznie — co jest właściwym podejściem dla środowisk produkcyjnych.