AWS WAF to jedna z tych usług, które szybko zaczynają mieć znaczenie, gdy ruch do aplikacji przestaje być „zwykły”: pojawiają się boty, skany podatności, próby credential stuffing i podejrzane żądania do API. W tym artykule pokazuję, jak działa web application firewall od Amazon Web Services, gdzie ma sens, ile kosztuje i jakie ma ograniczenia. To praktyczny przewodnik dla osób, które chcą dołożyć ochronę warstwy HTTP(S), ale nie chcą kupować bezpieczeństwa w ciemno.
Najważniejsze rzeczy, które warto wiedzieć od razu
- To filtr dla ruchu HTTP(S) na poziomie warstwy aplikacyjnej, a nie zamiennik całego systemu bezpieczeństwa.
- Najczęściej chroni CloudFront, API Gateway, ALB, AppSync, Cognito, App Runner, Verified Access i Amplify.
- Najlepiej sprawdza się przy SQLi, XSS, botach, nadużyciach logowania i limitowaniu tempa requestów.
- Start w trybie Count i na gotowych regułach zwykle daje mniej fałszywych blokad niż agresywne wdrożenie od razu na produkcji.
- Koszt rośnie wraz z liczbą ACL, reguł, requestów i dodatków takich jak Bot Control czy Fraud Control.
Czym jest AWS WAF i gdzie pasuje w architekturze
Najprościej patrzę na AWS WAF jak na kontroler dostępu ustawiony przed aplikacją albo API. Nie siedzi w kodzie aplikacji, tylko analizuje ruch HTTP(S) i decyduje, czy żądanie ma przejść dalej, zostać odrzucone czy tylko policzone.
Usługa ma sens przede wszystkim tam, gdzie na wejściu stoją publiczne zasoby webowe lub API. To właśnie w tym punkcie najlepiej odsiać śmieciowy ruch zanim dotrze do droższego backendu.
| Zasób | Najczęstsze zastosowanie | Dlaczego to działa |
|---|---|---|
| Amazon CloudFront | Strony publiczne, aplikacje edge, ruch globalny | Filtrowanie u źródła, zanim request dojdzie do originu |
| Application Load Balancer | Aplikacje webowe, backendy na EC2 lub ECS | Porządkuje ruch zanim trafi do usług za load balancerem |
| Amazon API Gateway | REST API i endpointy publiczne | Pomaga ograniczać nadużycia API, skany i gwałtowne wzrosty ruchu |
| AWS AppSync | GraphQL API | Daje dodatkową warstwę dla zapytań do danych i mutacji |
| Amazon Cognito | Logowanie i rejestracja | Przydaje się przy atakach na formularze i endpointy uwierzytelniania |
| AWS App Runner | Proste usługi webowe i API | Chroni aplikację bez dokładania własnej infrastruktury edge |
| AWS Verified Access | Dostęp do wewnętrznych aplikacji webowych | Pomaga kontrolować, co może wejść do środowiska firmowego |
| AWS Amplify | Frontend i hosting aplikacji | Przydaje się, gdy chcesz dołożyć kontrolę do warstwy publikacji frontendu |
W praktyce najczęściej wpinam tę warstwę tam, gdzie kończy się CDN albo load balancer, bo to właśnie tam opłaca się odsiać ruch zanim wejdzie w aplikację. Przy zasobach regionalnych pamiętaj tylko, że web ACL i chroniony zasób muszą być zgodne regionalnie; CloudFront i Amplify mają tu własne zasady rozmieszczenia. Gdy to już jest jasne, warto zobaczyć, jak usługa podejmuje decyzję o pojedynczym żądaniu.
Jak ruch przechodzi przez reguły i web ACL
W centrum jest web ACL, czyli zestaw reguł przypięty do zasobu. Każda reguła sprawdza wybrane cechy żądania i na tej podstawie może je przepuścić, zablokować, policzyć albo wystawić na CAPTCHA lub Challenge.
Jakie akcje ma do dyspozycji
| Akcja | Po co jej używam | Kiedy jest rozsądna |
|---|---|---|
| Allow | Przepuszczam zaufany ruch | Dla partnerów, health checków, zaufanych zakresów IP lub wyjątków |
| Block | Odrzucam oczywiście złośliwe żądania | Gdy wzorzec jest jednoznaczny i ryzyko false positive jest niskie |
| Count | Licząc, obserwuję ruch bez blokowania | Na etapie testów i strojenia reguł przed wdrożeniem na produkcję |
| CAPTCHA | Sprawdzam, czy po drugiej stronie jest człowiek | Przy podejrzanym ruchu z przeglądarki i tam, gdzie blokada byłaby zbyt agresywna |
| Challenge | Wykonuję cichą weryfikację przeglądarki | Gdy chcę utrudnić życie botom bez zatrzymywania całego ruchu |
Przeczytaj również: Jak połączyć komputer z telewizorem bezprzewodowo i cieszyć się komfortem
Skąd biorą się reguły
Ja zwykle zaczynam od managed rule groups, bo dają sensowny baseline bez ręcznego pisania wszystkiego od zera. Do kontroli skoków ruchu przydają się też rate-based rules, czyli reguły, które limitują żądania przekraczające ustalony próg w oknie czasu. Własne reguły dokładam dopiero wtedy, gdy widzę konkretną ścieżkę ataku albo niestandardowy wzorzec ruchu.
CAPTCHA i Challenge są wygodne przy podejrzanym ruchu z przeglądarki, ale działają tylko w bezpiecznym kontekście HTTPS i nie są rozwiązaniem dla każdego typu klienta. To prowadzi prosto do pytania, co WAF naprawdę umie zablokować, a czego nie powinien udawać.
Co chroni dobrze, a gdzie wymaga wsparcia innych narzędzi
Najwięcej sensu widzę tam, gdzie atak próbuje nadużyć samego żądania: SQL injection, XSS, bot scraping, credential stuffing, zbyt szybkie odpytywanie endpointów albo masowe próby tworzenia kont. W takich scenariuszach WAF potrafi odciąć spory procent szumu, zanim trafi do aplikacji.
| Scenariusz | Jak pomaga AWS WAF | Na co uważać |
|---|---|---|
| SQL injection i XSS | Może wykrywać i blokować typowe wzorce ataków na poziomie żądań | To nie zwalnia z walidacji wejścia i bezpiecznego kodu po stronie aplikacji |
| Boty, scrapery i skanery | Bot Control i własne reguły pomagają ograniczać automatyczny ruch | Nie każdy bot jest zły; część ruchu trzeba świadomie dopuścić |
| Credential stuffing i fake account creation | Fraud Control jest zbudowany właśnie pod logowanie i rejestrację | To może być kosztowne, jeśli ruch na formularzach jest duży |
| Przeciążanie endpointów | Rate-based rules pozwalają przyciąć nadmierny wolumen requestów | Trzeba dobrze dobrać próg, żeby nie ucinać legalnych użytkowników |
| Duże payloady i złożone body | Da się analizować body, ale tylko do określonego limitu | Powyżej limitu WAF widzi wyłącznie część danych |
| Volumetryczny DDoS | Może pomóc na warstwie aplikacyjnej, ale to nie jego pełna domena | Do większych ataków potrzebujesz warstwowej ochrony, często z Shield |
Granice są równie ważne jak możliwości. Body inspection nie obejmuje nieskończenie dużych payloadów: dla CloudFront, API Gateway, Cognito, App Runner i Verified Access domyślny limit to 16 KB i można go zwiększyć do 64 KB, a dla Application Load Balancer i AppSync limit jest stały i wynosi 8 KB. Jeśli request przekroczy limit, WAF widzi tylko część danych, więc nie warto zakładać, że obejrzy wszystko.
Nie traktuję go też jako zamiennika dobrego kodu, autoryzacji, walidacji wejścia czy ochrony przed volumetrycznym DDoS. Do tego dochodzi warstwa infrastruktury i ewentualnie Shield Advanced, jeśli skala zagrożenia jest większa. Następna sekcja pokazuje, jak wdrożyć WAF tak, żeby nie zablokować własnych użytkowników.
Jak wdrożyć go bez zaskoczeń na produkcji
Wdrożenie najczęściej psuje się nie przez samą usługę, tylko przez zbyt szybkie przejście do blokowania. Dlatego przydatne jest podejście etapowe.
- Podłącz WAF do właściwego zasobu wejściowego. Dla ruchu publicznego najczęściej będzie to CloudFront, ALB albo API Gateway.
- Zacznij od gotowych managed rule groups. Dają bazową ochronę bez ręcznego wymyślania wszystkiego od nowa.
- Włącz tryb Count dla reguł, które mogą generować false positive. To najbezpieczniejszy sposób, by zobaczyć wpływ bez wycinania ruchu.
- Analizuj logi i próbki ruchu. Logowanie możesz wysyłać do CloudWatch Logs, S3 albo Firehose, więc łatwo sprawdzisz, co naprawdę trafia w reguły.
- Dodaj wyjątki i scope-down statements. To zawężenie działania reguły do konkretnych ścieżek, metod lub wzorców ruchu.
- Przejdź na Block tylko tam, gdzie masz pewność. Najczęściej dotyczy to prostych wzorców ataku, a nie całego ruchu od razu.
- Strojenie rób osobno dla loginu, rejestracji i endpointów API. Te części aplikacji zwykle zachowują się inaczej i mają inny profil ryzyka.
Na etapie testów logowanie robi największą robotę: możesz szybko zobaczyć, które reguły generują najwięcej trafień i gdzie zaczyna się fałszywy alarm. Jeśli ruch jest prosty, porządek wychodzi niemal od razu; jeśli nie, logi pokażą problem zanim zrobi to produkcja. Stąd już tylko krok do kosztów, które potrafią zaskoczyć bardziej niż sama konfiguracja.
Ile kosztuje ochrona na AWS i co podbija rachunek
Model rozliczeń jest prosty na poziomie idei, ale łatwo go przeszacować, jeśli dorzucisz zbyt wiele dodatków. Bazowo płacisz za sam web ACL, reguły i liczbę requestów, a dodatkowe funkcje naliczają się osobno. Ceny mogą się różnić regionalnie, więc poniżej traktuję to jako praktyczny punkt odniesienia, a nie jedyny możliwy wariant.
| Element | Stawka | Co to oznacza w praktyce |
|---|---|---|
| Web ACL | 5,00 USD miesięcznie za sztukę | Każdy chroniony front door kosztuje osobno |
| Reguła lub rule group | 1,00 USD miesięcznie za każdą dodaną regułę lub grupę reguł | Im bardziej rozbudowany zestaw ochrony, tym szybciej rośnie koszt stały |
| Requesty | 0,60 USD za milion requestów | To zwykle główna część rachunku przy większym ruchu |
| Dodatkowe 500 WCU ponad 1500 | 0,20 USD za milion requestów | Wzrasta przy bardziej złożonych regułach i większej pojemności ACL |
| Dodatkowe 16 KB analizy body | 0,30 USD za milion requestów za każdy kolejny blok 16 KB | Wyższy limit inspekcji ma sens tylko wtedy, gdy naprawdę go potrzebujesz |
| CAPTCHA | 0,40 USD za 1000 prób | Przy dużym ruchu z przeglądarek może szybko urosnąć |
| Bot Control Common | Pierwsze 10 mln requestów miesięcznie bez opłat | Daje sensowny próg startowy dla mniej agresywnego ruchu botów |
| Bot Control Targeted | Pierwszy 1 mln requestów miesięcznie bez opłat | Przy mocniejszej ochronie warto szczególnie pilnować wolumenu |
| Fraud Control | 10,00 USD miesięcznie za web ACL, plus opłaty za analizę | Najbardziej opłaca się na logowaniu i rejestracji, nie na całym ruchu |
| Logowanie | 500 MB na 1 mln requestów wliczone w cenę | Dalej płacisz już według zasad CloudWatch, S3 lub Firehose |
| Managed rule groups z Marketplace | Cena ustalana przez sprzedawcę | To osobna pozycja, którą trzeba doliczyć do bazowego WAF |
Najprostszy rachunek dla jednego web ACL, pięciu reguł i 10 milionów requestów miesięcznie to około 16 USD, zanim doliczysz Bot Control, Fraud Control czy bardziej agresywne CAPTCHA. I właśnie dlatego lubię zaczynać od małej liczby reguł, a dopiero potem rozszerzać ochronę tam, gdzie daje realną wartość. Następna sekcja porządkuje jeszcze jedno pytanie, które pada niemal zawsze: czy to ma zastąpić Shield?
AWS WAF czy AWS Shield w praktyce
Jeśli masz publiczną aplikację w AWS, najzdrowiej myśleć o nich jako o warstwach, nie o zamiennikach. WAF tnie ruch na poziomie żądań, a Shield broni dostępności pod naporem ataku.
| Cecha | AWS WAF | AWS Shield |
|---|---|---|
| Poziom ochrony | Warstwa aplikacyjna, L7, ruch HTTP(S) | Warstwy sieci, transportu i aplikacji, L3/L4/L7 |
| Główna rola | Filtrowanie i kontrola requestów, botów i ataków na endpointy | Mitigacja DDoS i ochrona dostępności zasobów |
| Zakres konfiguracji | Duża elastyczność, własne reguły i managed rule groups | Standard jest włączony domyślnie, Advanced daje więcej automatyzacji i wsparcia |
| Model użycia | Wymaga jawnego skonfigurowania web ACL | Shield Standard jest dostępny dla kont AWS, Advanced to opcja płatna |
| Kiedy wygrywa | Gdy problemem są złośliwe requesty, boty, nadużycia logowania i API abuse | Gdy problemem są duże fale DDoS i chcesz szerszej ochrony dostępności |
W praktyce często używam obu narzędzi razem. Jeśli ruch atakuje konkretną aplikację, WAF robi pierwszą linię selekcji. Jeśli atak ma charakter masowy i próbuje zdusić usługę, Shield przejmuje ciężar obrony dostępności. To właśnie ta kombinacja daje najspójniejszy efekt w środowisku produkcyjnym. Została jeszcze jedna rzecz, którą lubię sprawdzić przed startem, bo oszczędza najwięcej czasu i nerwów.
Trzy ustawienia, które najszybciej poprawiają bezpieczeństwo bez chaosu
- Zacznij od Count, nie od Block. Dzięki temu zobaczysz realny wpływ reguł bez ryzyka, że odetniesz własnych użytkowników.
- Włącz logowanie od pierwszego dnia. CloudWatch Logs, S3 albo Firehose dadzą Ci obraz ruchu, a nie tylko intuicję.
- Sprawdź limit body inspection i charakter endpointów. Jeśli aplikacja wysyła większe payloady, limity 16 KB, 32 KB, 48 KB i 64 KB albo stałe 8 KB dla części usług mają bezpośredni wpływ na skuteczność ochrony.
- Rozdziel ochronę logowania, rejestracji i publicznego contentu. Jedna polityka dla wszystkiego zwykle kończy się zbyt agresywnym filtrowaniem albo zbyt luźnym ruchem.
Jeżeli miałbym zostawić jedną praktyczną radę, to tę: AWS WAF najlepiej działa wtedy, gdy jest częścią spokojnie testowanego procesu, a nie jednorazowego „włącz i zapomnij”. Najpierw obserwacja, potem selektywne blokowanie, a dopiero na końcu kosztowniejsze dodatki. Wtedy ta warstwa naprawdę odciąża aplikację i porządkuje ruch, zamiast generować nowe problemy.
