Firma obsługuje dwuwarstwową aplikację do przetwarzania obrazów. Aplikacja korzysta z dwóch stref dostępności (Availability Zones), z których każda ma jedną podsieć publiczną i jedną podsieć prywatną. Usługa Application Load Balancer (ALB) dla warstwy webowej korzysta z podsieci publicznych. Instancje Amazon EC2 dla warstwy aplikacyjnej korzystają z podsieci prywatnych. Użytkownicy zgłaszają, że aplikacja działa wolniej niż oczekiwano. Audyt bezpieczeństwa plików dziennika serwera webowego pokazuje, że aplikacja otrzymuje miliony nielegalnych żądań z niewielkiej liczby adresów IP. Architekt rozwiązań musi rozwiązać natychmiastowy problem z wydajnością, podczas gdy firma bada bardziej trwałe rozwiązanie. Co powinien zalecić architekt rozwiązań, aby spełnić ten wymóg?

Poprawna odpowiedź to modyfikacja listy kontroli dostępu do sieci (Network ACL) dla podsieci warstwy webowej. Network ACL działają na poziomie podsieci i są bezstanowe, co oznacza, że każda reguła jest oceniana niezależnie dla ruchu przychodzącego i wychodzącego. Dodanie reguły "deny" dla konkretnych adresów IP w Network ACL podsieci warstwy webowej (gdzie znajduje się ALB) skutecznie zablokuje złośliwy ruch zanim dotrze on do Application Load Balancer i instancji EC2, natychmiast poprawiając wydajność. Grupy bezpieczeństwa (Security Groups) działają na poziomie instancji i są stanowe, co oznacza, że zezwalają na ruch powrotny automatycznie. Chociaż można by dodać reguły "deny" do grupy bezpieczeństwa, Network ACL jest bardziej odpowiednie do blokowania ruchu na wczesnym etapie, zanim dotrze on do zasobów obliczeniowych, co jest kluczowe dla natychwatnego rozwiązania problemu wydajności. Modyfikowanie Network ACL lub Security Group dla warstwy aplikacyjnej nie rozwiąże problemu, ponieważ złośliwy ruch jest kierowany do warstwy webowej.