Cargando...
Cargando...
Layer 7 protection that filters, monitors, and blocks malicious web traffic before it reaches your application
AWS WAF is a managed web application firewall that protects web applications and APIs against common web exploits, bot attacks, and application-layer DDoS by inspecting HTTP/HTTPS requests at Layer 7. It integrates natively with Amazon CloudFront, Application Load Balancer, API Gateway, AWS AppSync, Amazon Cognito, and AWS Verified Access, allowing rules to be enforced at the edge or within your VPC. WAF uses a combination of managed rule groups, custom rules, rate-based rules, and ML-powered bot control to provide defense-in-depth against evolving threats.
Protect web applications and APIs from OWASP Top 10 vulnerabilities, bot attacks, credential stuffing, account takeover, and application-layer DDoS using customizable and managed rule sets with real-time visibility.
Use When
Avoid When
Web ACLs (Web Access Control Lists)
Core construct — contains ordered rules and rule groups that inspect and act on HTTP/HTTPS requests
Managed Rule Groups (AWS Managed Rules)
Pre-built rule sets for OWASP Top 10, known bad inputs, Linux/Windows/PHP/SQL rules — updated automatically by AWS at no extra charge
AWS WAF Bot Control
ML-powered bot detection with two modes: Common (signature-based, cheaper) and Targeted (ML-powered, more expensive but detects sophisticated bots)
Account Takeover Prevention (ATP)
Managed rule group that detects credential stuffing on login endpoints by analyzing request patterns and comparing against compromised credential databases
Account Creation Fraud Prevention (ACFP)
Detects fraudulent account creation attempts on registration endpoints
Rate-Based Rules
Aggregate requests by IP, forwarded IP, HTTP method, query argument, URI path, or custom keys over a rolling 5-minute window
Geo Match Conditions
Allow or block requests based on country of origin using MaxMind GeoIP database — not a foolproof bot mitigation technique
IP Set Match
Match against custom IPv4/IPv6 allowlists or blocklists; supports CIDR notation
Regex Pattern Sets
Match request components against regular expressions; expensive in WCUs
Label Matching
Rules can match labels applied by earlier rules in the same Web ACL, enabling multi-stage evaluation logic
Custom Rules (Rule Builder)
Create rules with AND/OR/NOT logic across multiple conditions (URI, headers, body, query string, method, IP, country, etc.)
CAPTCHA and Challenge Actions
CAPTCHA presents a puzzle to the user; Challenge is a silent JavaScript browser challenge — both help distinguish humans from bots
Rule Actions: Allow, Block, Count, CAPTCHA, Challenge
Count mode is critical for testing new rules without blocking legitimate traffic
Override Rule Group Actions
You can override all rules in a managed rule group to Count mode for safe testing before enabling Block
AWS WAF Logging
Full request logs to Amazon Kinesis Data Firehose (then S3, Redshift, OpenSearch), CloudWatch Logs, or S3 directly; supports log redaction for sensitive fields
CloudWatch Metrics and Dashboards
Per-rule metrics for AllowedRequests, BlockedRequests, CountedRequests, PassedRequests, CaptchaRequests — essential for operational visibility
AWS Firewall Manager Integration
Centrally deploy and enforce WAF Web ACLs across multiple AWS accounts and resources in an AWS Organization
AWS Shield Advanced Integration
Shield Advanced can automatically create WAF rules during Layer 7 DDoS events — requires WAF to be enabled on the protected resource
Tokenization (Bot Control)
WAF issues encrypted tokens to verified browsers/clients; subsequent requests include the token, reducing re-verification overhead
Fraud Control - Intelligent Threat Integration
Combines ATP and ACFP with ML-based signals for advanced fraud detection
Scope-down Statements
Limit where rate-based rules or managed rules apply (e.g., only on /login path) to reduce WCU consumption and false positives
JSON Body Parsing
WAF can parse JSON request bodies and inspect specific JSON keys, not just raw body strings
Text Transformations
Normalize request components (URL decode, HTML entity decode, lowercase, etc.) before inspection to catch evasion attempts
Edge WAF for Global Applications
high freqAttach a WAF Web ACL to a CloudFront distribution to inspect and filter requests at AWS edge locations before they reach your origin. The Web ACL MUST be created in us-east-1 regardless of distribution region. This is the lowest-latency WAF deployment pattern and the most common architecture for public-facing applications.
Regional WAF for ALB-Backed Applications
high freqAttach WAF to an ALB to protect applications deployed in a specific AWS region. The Web ACL must be in the same region as the ALB. This pattern is used when CloudFront is not in the architecture or when you need WAF protection for internal ALBs.
API Protection with WAF
high freqAttach WAF to a REST API Gateway stage to protect APIs from SQLi, XSS, and rate-based abuse. WAF inspects all HTTP requests before they reach Lambda or backend integrations. Commonly combined with API Gateway usage plans for layered rate limiting.
Custom Rule Logic via Lambda
high freqUse Lambda to dynamically update WAF IP sets or rule conditions based on application events (e.g., too many failed logins triggers adding an IP to a block list). Lambda can also be invoked by CloudWatch Alarms or GuardDuty findings to automate WAF responses.
Layered DDoS Defense
high freqShield Advanced + WAF provides complementary protection: Shield handles Layers 3/4 volumetric attacks while WAF handles Layer 7 application attacks. Shield Advanced can automatically create WAF rate-based rules during detected Layer 7 events. This combination is the AWS-recommended architecture for DDoS-resilient applications.
Automated Threat Response
high freqGuardDuty findings (e.g., malicious IP, cryptocurrency mining, port scanning) trigger EventBridge rules that invoke Lambda to automatically add offending IPs to WAF IP sets. This creates an automated security feedback loop without human intervention.
Centralized Multi-Account WAF Governance
high freqFirewall Manager enforces WAF Web ACL policies across all accounts in an AWS Organization. New accounts and resources automatically inherit WAF policies. Security teams define baseline rules centrally while allowing account-level customization within guardrails.
WAF Log Analytics Pipeline
high freqStream WAF full request logs to Kinesis Firehose → S3 for long-term retention and forensic analysis, or to OpenSearch Service for real-time dashboards. Log group names must start with 'aws-waf-logs-' prefix when using CloudWatch Logs.
GraphQL API Protection
high freqAttach WAF to AWS AppSync to protect GraphQL APIs against query depth attacks, field-level injection, and rate abuse. WAF inspects GraphQL requests at the HTTP layer.
User Pool Protection
high freqAttach WAF to a Cognito User Pool to protect authentication endpoints from credential stuffing and brute-force attacks. Combined with ATP managed rule group for maximum protection of login flows.
Encrypted WAF Log Data
high freqWAF logs sent to S3 can be encrypted using SSE-KMS. KMS keys can enforce access policies ensuring only authorized security personnel can decrypt and read WAF log data, supporting compliance requirements.
CloudFront WAF Web ACLs MUST be created in us-east-1 (N. Virginia) — this is non-negotiable and one of the most tested WAF facts. All other resource types (ALB, API Gateway, AppSync, Cognito, Verified Access) use a regional Web ACL in the same region as the resource.
Web ACL Capacity Units (WCUs) are a hard limit at 5,000 per Web ACL and CANNOT be increased via support. If you exceed this, you must redesign your rule architecture — split rules across multiple Web ACLs or simplify conditions. Exam questions about 'WAF rule complexity limits' are testing WCU knowledge.
Rate-based rules alone are NOT sufficient bot protection. Sophisticated bots distribute requests across thousands of IPs, making per-IP rate limiting ineffective. The correct answer for advanced bot mitigation is WAF Bot Control (Targeted mode) with ML-powered detection, not just rate limiting or IP reputation lists.
WAF only inspects the first 8 KB of a request body by default. This is a known limitation and potential evasion vector. For scenarios requiring deeper inspection, configure the body inspection size limit (up to 64 KB for supported resource types). Exam questions about 'WAF missing injections in large payloads' are testing this.
Always use Count mode when deploying new WAF rules or enabling managed rule groups in production. Count mode logs matching requests without blocking them, allowing you to validate rules against real traffic and tune false positives before switching to Block. Skipping this step is an anti-pattern.
WAF does NOT protect against Layer 3/4 DDoS (volumetric attacks, SYN floods, UDP reflection). For those threats, AWS Shield is required. WAF + Shield Advanced is the complete layered defense — WAF handles Layer 7, Shield handles Layers 3/4. Exam questions presenting WAF as the solution for network-layer DDoS are traps.
CloudFront WAF Web ACLs MUST be created in us-east-1 — no exceptions. All other resources (ALB, API GW, AppSync, Cognito) use a regional Web ACL in the resource's region.
Rate-based rules, IP reputation lists, and geographic blocking are ALL insufficient for sophisticated distributed bot attacks. Only WAF Bot Control (Targeted mode) with ML-powered behavioral analysis provides effective protection against modern distributed bots.
WAF = Layer 7 only (HTTP/HTTPS). Shield = Layers 3/4. They are complementary, not substitutes. For complete DDoS protection, you need BOTH. Shield Advanced + WAF is the AWS-recommended architecture for DDoS-resilient applications.
AWS Managed Rules (Core Rule Set, Known Bad Inputs, SQL Database, Linux, Windows, PHP, WordPress rules) are FREE. Bot Control, ATP (Account Takeover Prevention), and ACFP (Account Creation Fraud Prevention) are AWS managed rule groups that have ADDITIONAL charges. Know which managed rules cost extra.
WAF rule evaluation is ordered — rules are evaluated in priority order (lower number = higher priority). The first matching rule's action is applied and evaluation stops (unless the action is Count). Rule groups are evaluated as a unit at their assigned priority. Understanding rule ordering is essential for exam scenarios.
Labels enable multi-stage WAF logic. Managed rule groups like Bot Control add labels to requests (e.g., 'awswaf:managed:aws:bot-control:bot:verified'). You can create custom rules that match these labels to take additional actions, creating sophisticated detection chains without complex rule conditions.
For detecting prompt injection attacks in AI/ML applications, WAF alone (even with regex rules) is NOT sufficient. Exam questions on AIF-C01 testing this: ML-based detection, semantic analysis, and application-layer guardrails are needed. WAF can catch known patterns but cannot perform semantic understanding of natural language attacks.
Scope-down statements in rate-based rules and managed rule groups are powerful for reducing false positives and WCU consumption. For example, apply ATP only to '/login' URI path, not all requests. Exam scenarios asking how to 'apply WAF rules only to specific endpoints' require scope-down statements.
Geographic blocking (Geo Match) does NOT effectively stop bot traffic. Modern botnets use residential proxies and compromised devices distributed across legitimate countries. Geo blocking only stops unsophisticated attackers. For bot mitigation, Bot Control (Targeted mode) with ML is required.
WAF log group names in CloudWatch Logs MUST start with the prefix 'aws-waf-logs-'. This is a hard requirement and a common implementation pitfall tested in developer-focused exams (DVA-C02, DOP-C02).
Common Mistake
Rate-based rules are sufficient to protect against bot attacks — if you set a low enough rate limit, bots will be blocked.
Correct
Rate-based rules only block high-volume requests from a SINGLE IP address over a 5-minute window. Sophisticated distributed bots operate across thousands of IPs (botnets, residential proxies), each sending requests well below any practical rate limit. Rate limiting catches only the most unsophisticated bots. AWS WAF Bot Control (Targeted mode) uses ML behavioral analysis to detect distributed bots regardless of per-IP request rate.
This is the #1 bot-related misconception on certification exams. Questions will present a scenario with distributed bot attacks and offer rate-based rules as a 'sufficient' solution — it is not. The correct answer always involves Bot Control Targeted mode for sophisticated, distributed bot mitigation.
Common Mistake
Enabling Geographic (Geo) blocking in WAF will stop bot traffic from foreign countries, providing effective bot protection.
Correct
Geo blocking is ineffective against modern bots because botnets use compromised residential devices and proxies distributed across all countries, including the countries you're trying to allow. Blocking entire countries causes significant false positives (blocking legitimate users) while barely inconveniencing sophisticated attackers who simply route through residential proxies in allowed countries.
Exam questions frequently offer Geo Match as a bot mitigation solution. It is an access control tool for compliance/licensing scenarios (e.g., blocking users from sanctioned countries), NOT a bot defense mechanism. Recognize the difference between geographic access control and bot mitigation.
Common Mistake
IP reputation lists and managed IP blocklists are sufficient to handle modern distributed bot attacks.
Correct
IP reputation lists are reactive — they block known-bad IPs that have already been identified as malicious. Modern sophisticated bots use fresh residential IPs that have no reputation history, rotate IPs frequently, and exploit legitimate cloud provider IP ranges. IP reputation lists catch commodity threats but fail against targeted, sophisticated attackers. ML-powered behavioral detection (Bot Control Targeted) is required to catch reputation-clean bots.
This misconception leads candidates to choose 'AWS Managed Rules - Amazon IP Reputation List' as the answer for bot protection scenarios. That rule group helps but is not sufficient alone. The exam specifically tests that ML-based detection is necessary for sophisticated distributed attacks.
Common Mistake
WAF protects against all DDoS attacks, so you don't need AWS Shield if you have WAF enabled.
Correct
WAF only operates at Layer 7 (HTTP/HTTPS application layer) and inspects individual HTTP requests. It cannot mitigate Layer 3/4 attacks like UDP floods, SYN floods, ICMP floods, or DNS amplification attacks. AWS Shield Standard (free, automatic) provides Layer 3/4 protection. Shield Advanced adds 24/7 DRT support, cost protection, and automatic WAF rule creation during Layer 7 events. WAF and Shield are complementary, not substitutes.
Exam questions testing layered security often present WAF as a complete DDoS solution. Recognize that WAF = Layer 7 only, Shield = Layers 3/4 (and assists with Layer 7 during DDoS events). The correct architecture for DDoS-resilient applications always includes both.
Common Mistake
WAF inspects the entire HTTP request body, so injections hidden in large request payloads will always be caught.
Correct
By default, WAF only inspects the first 8 KB of a request body. Content beyond 8 KB is not inspected. This means an attacker can prepend 8 KB of benign content before a malicious payload to evade WAF inspection. You can configure body inspection size up to 64 KB for supported resource types, but this increases WCU consumption and processing costs.
This is a critical security gap that appears in security-focused exam questions (SCS-C02). When a question describes WAF 'missing' injections in large payloads, the answer involves configuring the body inspection size limit. Also relevant for understanding why WAF is not a complete application security solution — defense-in-depth with input validation at the application layer is still required.
Common Mistake
Sentiment analysis and simple keyword matching in WAF rules is sufficient to detect prompt injection attacks against AI/ML applications.
Correct
Prompt injection attacks are semantically complex — they use natural language to manipulate AI model behavior, often through indirect instructions, role-playing scenarios, or obfuscated commands that bypass keyword filters. WAF regex and string match rules can catch known patterns but cannot perform semantic understanding. Effective prompt injection defense requires application-layer guardrails, dedicated LLM security tools (like Amazon Bedrock Guardrails), input/output validation, and least-privilege system prompts.
Critical for AIF-C01 and increasingly tested in SCS-C02. Exam questions present WAF as a solution for AI security — recognize that WAF is a useful first layer (blocking known malicious patterns) but semantic attacks require AI-aware security controls beyond WAF's capabilities.
Common Mistake
You can create a WAF Web ACL in any region and attach it to a CloudFront distribution.
Correct
WAF Web ACLs for CloudFront MUST be created in us-east-1 (N. Virginia), regardless of where your CloudFront distribution delivers content or where your origin is located. This is because CloudFront is a global service managed from us-east-1. Web ACLs for ALB, API Gateway, AppSync, Cognito, and Verified Access must be created in the same AWS region as the resource.
This is one of the most commonly tested WAF facts across all certification levels. A wrong-region Web ACL simply cannot be attached to a CloudFront distribution — it won't appear in the dropdown. Memorize: CloudFront WAF = us-east-1 always.
WAF CRAP: C=CloudFront needs us-east-1, R=Rate limits don't stop distributed bots, A=AWS Managed Rules are free (except Bot Control/ATP/ACFP), P=Payload body only 8KB inspected by default
WAF layers: WAF = Layer 7 (Web/HTTP), Shield = Layers 3+4 (Network). Think 'WAF protects Web, Shield protects the Wires'
WCU = 'Wicked Capacity Units' — 5,000 max, HARD limit, cannot increase. When you hit it, redesign don't escalate.
Bot Defense Ladder (weakest to strongest): IP Reputation → Geo Match → Rate Limiting → Bot Control Common → Bot Control Targeted (ML). Exam always wants the TOP of the ladder for sophisticated attacks.
Count before you Block — always deploy new WAF rules in Count mode first to avoid blocking legitimate traffic
CertAI Tutor · SAP-C02, SCS-C02, SAA-C03, DEA-C01, DOP-C02, AIF-C01, CLF-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns