AWS WAF Use Cases & Scenarios

AWS WAF protects five core scenarios extremely well: internet-facing web applications and APIs from OWASP Top 10 exploits, high-traffic endpoints from credential stuffing and bot abuse via rate-based rules and Bot Control, hybrid and on-premises origins through CloudFront edge filtering, multi-account enterprises through centralized Firewall Manager policies, and compliance-driven organizations that need detailed request logging for security operations and audit trails.

Key Takeaways

• Web application protection is the universal use case—deploy WAF on CloudFront, ALB, or API Gateway to block SQL injection, XSS, and OWASP Top 10 threats at layer 7
• Rate-based rules and Bot Control stop credential-stuffing, API abuse, and scraping by throttling or blocking IPs that exceed thresholds over five-minute windows
• CloudFront edge placement protects hybrid and on-premises origins by filtering malicious traffic at 450+ global locations before it consumes origin bandwidth or compute
• AWS Firewall Manager enables centralized policy enforcement across hundreds of AWS accounts and thousands of resources—critical for enterprise governance
• Logging to Kinesis Data Firehose, S3, or CloudWatch provides the telemetry security teams need for tuning, compliance, SIEM integration, and automated incident response
• Account takeover prevention combines rate-based rules on /login endpoints with managed Bot Control to detect and block credential-stuffing attacks
• Managed rule groups (OWASP, Known Bad Inputs, IP Reputation) give you continuous threat intelligence updates from AWS—start here, layer custom rules only when needed

Scenario 1: Protecting Internet-Facing Web Applications and APIs

The problem: Your web application or REST API is exposed to the internet. Attackers probe for SQL injection vulnerabilities, cross-site scripting flaws, remote code execution bugs, and known CVEs. A single successful exploit can result in data exfiltration, ransomware deployment, or full application takeover.

How AWS WAF solves it: Attach a Web ACL to your CloudFront distribution, Application Load Balancer, or API Gateway endpoint. Enable AWS Managed Rules—specifically the OWASP Core Rule Set and Known Bad Inputs rule group. These managed rules inspect every HTTP request for patterns that match common web exploits: SQL injection attempts in query parameters, XSS payloads in POST bodies, path traversal attempts in URIs, command injection in headers.

WAF evaluates requests in milliseconds. Malicious requests get blocked at the edge (CloudFront) or at the load balancer (ALB/API Gateway) before they ever reach your application code. Legitimate requests pass through with minimal latency overhead—typically 2–5ms for managed OWASP rules.

Real-world example: An e-commerce platform running on CloudFront and ALB faced automated scanners probing for vulnerabilities 24/7. Before WAF, these scanners triggered application errors, consumed database connections, and filled logs with garbage. After deploying the OWASP Core Rule Set, WAF blocked 98% of scanner traffic at the edge. Origin CPU usage dropped by 40%. Application logs became readable again. Security team could focus on legitimate threats instead of filtering scanner noise.

What you need:

• A Web ACL with CLOUDFRONT scope (for CloudFront) or REGIONAL scope (for ALB/API Gateway)
• AWS Managed Rules: OWASP Top 10, Known Bad Inputs, Amazon IP Reputation List
• Logging enabled (Kinesis Data Firehose or S3) to capture blocked requests
• CloudWatch metrics and alarms to alert on spikes in blocked traffic

Gotcha: Managed OWASP rules will trigger false positives on some applications—especially content management systems that accept JSON or XML in POST requests. Always deploy rules in Count mode first. Monitor logs for a week. Identify false positives. Create rule exceptions or scope-down statements. Then switch to Block.

Scenario 2: Stopping Credential Stuffing and Account Takeover

The problem: Attackers use stolen username/password pairs from data breaches to attempt logins on your application. They try thousands of credentials per minute, rotating through residential proxy IPs to evade simple IP blocking. Successful logins lead to account takeover, fraudulent transactions, and data theft.

How AWS WAF solves it: Create a rate-based rule targeting your login endpoint. Set a threshold—for example, 100 requests per 5 minutes per source IP on the /login URI path. When an IP exceeds the threshold, WAF blocks it for a configurable duration (10 minutes, 1 hour, 24 hours).

Layer Bot Control on top. Bot Control detects automated tools even when they rotate IPs or mimic browser user-agents. The free tier (common bot detection) identifies verified bots (Googlebot, Bingbot) and likely automated traffic. Targeted bot control (paid) adds granular categories, CAPTCHA challenges, and bot scoring.

Architecture pattern:

1. User (or bot) requests POST /login
2. CloudFront edge location receives request → WAF inspects
3. Rate-based rule checks: has this IP sent >100 requests to /login in the last 5 minutes?
4. Bot Control checks: does the request exhibit bot-like behavior (missing JavaScript execution, suspicious headers)?
5. If either rule matches → Block (403 response), log to Kinesis
6. If both pass → forward to origin ALB → application processes login

Real-world example: A SaaS company saw 200,000 login attempts per hour during a credential-stuffing attack. Origin instances scaled to 80+ EC2 instances to handle the load. After deploying a rate-based rule (50 requests per 5 minutes on /api/auth/login) and Bot Control, WAF blocked 99.5% of the attack at the CloudFront edge. Origin instances dropped to 12. The attack continued for three days. The origin never noticed.

What you need:

• Rate-based rule scoped to login endpoints (/login, /api/auth, /signin)
• Threshold tuned to your legitimate user patterns (monitor for a week, set threshold at 150–200% of 95th percentile)
• AWS Managed Rules Bot Control (free tier or targeted)
• Logging to track blocked IPs and bot categories

Tuning tip: Legitimate users occasionally trigger rate limits—someone frantically retrying a forgotten password, a mobile app with a buggy retry loop. Set your initial threshold high (500 requests per 5 minutes), run in Count mode, review logs, tune down to the lowest threshold that doesn’t block real users.

Scenario 3: Protecting Hybrid and On-Premises Origins

The problem: Your application runs on-premises or in a colocation facility. You expose it to the internet via a public IP. Attackers can reach your origin directly. Your on-premises firewall and IDS handle network-layer attacks, but they don’t inspect HTTP payloads deeply. Web exploits slip through. Your internet circuit bandwidth is expensive, and malicious traffic consumes it.

How AWS WAF solves it: Place CloudFront in front of your on-premises origin. Point the CloudFront distribution to your origin’s public IP or hostname (or use AWS Direct Connect for private connectivity). Attach a WAF Web ACL to the CloudFront distribution. Enable managed OWASP rules, IP reputation lists, and rate-based rules.

Now all internet traffic hits CloudFront’s edge locations first. WAF inspects every request at the edge—milliseconds after it arrives at the nearest CloudFront point of presence. Malicious requests get blocked there. Clean requests are forwarded to your on-premises origin over a persistent connection (or Direct Connect private link). Your origin sees only legitimate, WAF-approved traffic.

Benefits:

• Origin load reduction: Blocked requests never consume origin CPU, memory, or bandwidth
• Bandwidth cost savings: Your ISP charges for inbound and outbound traffic; WAF blocks malicious inbound traffic at CloudFront’s edge, not at your data center
• Reduced attack surface: Attackers cannot bypass CloudFront to hit your origin directly if you restrict origin firewall rules to accept traffic only from CloudFront IP ranges
• Edge caching: CloudFront caches static content (images, CSS, JS) at the edge, further reducing origin load

Real-world example: A manufacturing company ran a legacy web portal on-premises. Internet bandwidth was capped at 100 Mbps. During a layer 7 DDoS attack—50,000 HTTP requests per second—the circuit saturated. Legitimate customers couldn’t access the portal. After deploying CloudFront + WAF, the next attack was absorbed at CloudFront’s edge. Origin bandwidth usage stayed under 10 Mbps. The portal remained available throughout.

What you need:

• CloudFront distribution with on-prem origin (public IP or Direct Connect)
• Web ACL (CLOUDFRONT scope) with managed OWASP rules and rate-based rules
• Origin firewall rules that accept traffic only from CloudFront IP prefixes (published by AWS)
• Logging and CloudWatch alarms to monitor blocked traffic and origin health

Security hardening: Lock down your origin firewall to allow traffic only from CloudFront. AWS publishes the list of CloudFront IP ranges as a managed prefix list and via an API endpoint. Update your firewall rules to accept traffic from those IPs only. Now attackers cannot bypass CloudFront and hit your origin directly.

Scenario 4: Multi-Account Enterprise Governance with Firewall Manager

The problem: You manage 50+ AWS accounts under AWS Organizations. Each account has multiple CloudFront distributions, ALBs, and API Gateways. You need to enforce a baseline security policy—every public endpoint must have WAF protection with OWASP rules and rate limiting. Manual deployment is error-prone. Developers sometimes deploy new resources without attaching WAF. You lack visibility into which resources are protected.

How AWS WAF solves it: Use AWS Firewall Manager to create and enforce WAF policies across all accounts and resources. Define a policy: a Web ACL template with managed OWASP rules, IP reputation, and a rate-based rule. Apply the policy to an organizational unit (OU) or to all accounts. Tag resources that require protection.

Firewall Manager automatically associates the Web ACL with matching CloudFront distributions, ALBs, and API Gateways across all accounts. When a developer deploys a new ALB in any account, Firewall Manager detects it (if it matches the policy scope or tags) and attaches the baseline Web ACL within minutes. You get centralized visibility—Firewall Manager dashboard shows which resources are protected, which are out of compliance, and which Web ACLs are attached where.

Governance model:

• Security team defines the baseline Web ACL policy in Firewall Manager
• Policy is applied to all accounts in the organization (or specific OUs)
• Application teams can layer additional custom rules on top of the baseline but cannot remove baseline protections
• Firewall Manager continuously monitors for new resources and enforces the policy
• Security team receives alerts when resources are out of compliance

Real-world example: A financial services company with 120 AWS accounts struggled to enforce WAF policies. Audits routinely found unprotected ALBs and API Gateways. After deploying Firewall Manager, the security team created a policy with OWASP rules and tagged all internet-facing resources with Tier:Public. Firewall Manager attached the baseline Web ACL to 300+ resources across all accounts within two hours. New deployments got protection automatically. Compliance violations dropped to zero within a month.

What you need:

• AWS Organizations with multiple member accounts
• AWS Firewall Manager (runs in the organization’s management account or a delegated admin account)
• A baseline Web ACL template (OWASP rules, IP reputation, rate-based rules)
• Resource tagging strategy or scope rules (apply to all resources, or only tagged resources)
• IAM permissions for Firewall Manager to attach Web ACLs across accounts

Cost consideration: Firewall Manager itself has no additional charge beyond the Web ACL and rule costs in each account. However, you pay for Web ACLs, rules, and requests across all protected resources. Budget accordingly—300 resources × $5 per Web ACL per month = $1,500/month baseline cost before request charges.

Scenario 5: Security Operations, Compliance, and Logging

The problem: Your security team needs detailed telemetry for every web request—allowed, blocked, and counted. Compliance frameworks (PCI DSS, SOC 2, HIPAA) require evidence of security controls and audit trails. You need to integrate WAF logs with your SIEM, run automated threat-hunting queries, and provide audit reports to external assessors.

How AWS WAF solves it: Enable logging on every Web ACL. Configure Kinesis Data Firehose as the log destination (recommended for high-volume environments) or send logs to S3 or CloudWatch Logs. Each log entry includes:

• timestamp: when the request was received
• httpRequest: client IP, headers, URI, method, query string, request body sample
• action: ALLOW, BLOCK, COUNT, CAPTCHA
• terminatingRuleId: which rule matched and triggered the action
• ruleGroupList: which managed rule groups were evaluated
• Web ACL ID, distribution ID (CloudFront), load balancer ARN (ALB)

Forward Kinesis logs to your SIEM (Splunk, Elastic, Chronicle). Set up automated queries: alert when BlockedRequests for a specific rule exceeds threshold, flag IPs with high block rates, detect patterns indicating zero-day exploit attempts.

For compliance, export logs to S3 with versioning and object lock. Retain for the required period (7 years for some frameworks). Generate reports: total requests inspected, breakdown by action (allowed/blocked/counted), top blocked IPs, most-triggered rules.

Audit workflow:

1. Assessor asks: “Prove your web applications are protected from SQL injection.”
2. You show: Web ACL configuration with OWASP SQLi rule enabled
3. You query logs: SELECT COUNT(*) FROM waf_logs WHERE terminatingRuleId LIKE '%SQLi%' AND action='BLOCK'
4. Result: 45,000 SQL injection attempts blocked in the last quarter
5. Assessor satisfied: control is active and effective

Real-world example: A healthcare SaaS platform needed SOC 2 Type II certification. Auditors required evidence of active web application firewall controls and detailed logs. The platform enabled WAF logging to S3, integrated logs with their Splunk SIEM, and created dashboards showing blocked attack attempts, rule effectiveness, and compliance metrics. During the audit, they provided Splunk reports and S3 log exports. Auditors verified the controls were active and effective. Certification granted.

What you need:

• Logging enabled on all Web ACLs
• Kinesis Data Firehose delivery stream → S3, OpenSearch, or CloudWatch Logs
• S3 bucket lifecycle policies for retention and cost management
• SIEM integration (Splunk, Elastic, AWS Security Lake)
• CloudWatch dashboards and alarms for real-time monitoring
• Automated reports and queries for compliance evidence

Cost warning: High-traffic applications generate massive log volumes. A CloudFront distribution serving 100 million requests per day writes 100 million log entries. At ~1 KB per entry, that’s 100 GB of logs per day = 3 TB per month. Kinesis Data Firehose charges ~$0.029 per GB ingested = $87/month. S3 storage adds ~$70/month (standard tier). Budget for logging costs upfront.

Scenario 6: API Abuse and Scraping Prevention

The problem: Your public API provides product data, pricing, or search functionality. Competitors scrape your API to build competing services. Abusive clients send millions of requests per day, consuming your infrastructure and degrading service for legitimate users. Standard API keys are easily leaked or shared.

How AWS WAF solves it: Deploy rate-based rules at the API route level. Create separate rate limits for different endpoints:

• /api/search: 1,000 requests per 5 minutes per IP
• /api/product/{id}: 500 requests per 5 minutes per IP
• /api/pricing: 100 requests per 5 minutes per IP (sensitive pricing data)

Add Bot Control to detect and block automated scrapers. Combine with custom rules: block requests missing required headers (API version header, custom signature), block known scraper user-agents, enforce geographic restrictions (block traffic from countries where you don’t operate).

Real-world example: A travel API provider faced scraping from hundreds of IPs rotating every few minutes. Rate-based rules alone weren’t enough—scrapers stayed under per-IP thresholds by distributing requests. Bot Control detected the automation patterns (missing JavaScript execution, suspicious request timing). Combining rate-based rules and Bot Control blocked 95% of scraping traffic. Legitimate API usage from customers’ mobile apps remained unaffected.

What you need:

• Rate-based rules scoped to specific API paths
• Bot Control (targeted tier recommended for API protection)
• Custom rules for header validation, user-agent filtering, geo-blocking
• Logging to identify scraping patterns and adjust rules

When NOT to Use AWS WAF

AWS WAF is not a universal solution. Here’s when to choose alternatives:

• Non-HTTP(S) traffic: WAF only inspects HTTP and HTTPS. For SSH, RDP, DNS, database protocols, or custom TCP/UDP applications, use AWS Network Firewall, security groups, or NACLs.
• Volumetric layer 3/4 DDoS: WAF operates at layer 7. It won’t stop a 100 Gbps SYN flood or UDP amplification attack. Use AWS Shield (Standard is free and automatic; Advanced adds DDoS Response Team support).
• Internal-only, low-latency services: If your application runs entirely within a VPC and never touches the internet, WAF adds unnecessary latency and cost. Use VPC security groups and NACLs instead.
• Advanced bot management beyond AWS capabilities: If you need specialized bot detection with device fingerprinting, behavioral analysis across sessions, and multi-CDN support, evaluate third-party bot management platforms (Cloudflare Bot Management, Akamai Bot Manager, DataDome).

Frequently Asked Questions

Can I use WAF to block traffic from specific countries?

Yes. Create a geo-match rule that inspects the request’s source country (based on IP geolocation). Set the action to Block for countries you want to exclude. This is useful for compliance (GDPR, data sovereignty) or reducing attack surface (block traffic from regions where you don’t operate).

How do I protect against zero-day vulnerabilities?

Use AWS Managed Rules—specifically the Known Bad Inputs rule group. AWS updates this rule group within hours when new CVEs or exploits become public. You benefit from AWS threat intelligence and rapid signature deployment without manual intervention. Layer virtual patching: if a CVE affects your application, create a custom rule to block the exploit pattern while you deploy the real patch.

What’s the difference between AWS WAF and third-party Marketplace WAFs?

AWS WAF is a managed service—no instances to run, tight AWS integration, pay-per-request pricing. Marketplace WAFs (Barracuda, Fortinet, Imperva) offer richer features: machine-learning-based detection, data loss prevention, vendor-managed rulesets, 24/7 SOC support. Trade-offs: Marketplace WAFs cost more (licensing + infrastructure), add operational overhead, and require separate management consoles. Start with AWS WAF. Evaluate Marketplace options if you need features AWS WAF doesn’t provide.

Can I automate WAF rule deployment with infrastructure-as-code?

Yes. AWS WAF supports CloudFormation, Terraform, and the AWS CLI. Define your Web ACL, rules, and rule groups as code. Deploy via CI/CD pipelines. Test rule changes in staging environments before promoting to production. This is the recommended approach for large-scale, multi-account deployments.

Conclusion

We explored six core scenarios where AWS WAF delivers measurable protection: blocking OWASP Top 10 exploits on internet-facing web applications and APIs, stopping credential-stuffing and account takeover with rate-based rules and Bot Control, protecting hybrid and on-premises origins through CloudFront edge filtering, enforcing enterprise-wide baseline policies across hundreds of AWS accounts via Firewall Manager, providing detailed request logs for security operations and compliance audits, and preventing API abuse and scraping with granular rate limits and bot detection. In each scenario, the pattern is consistent—deploy managed rules as your baseline, enable logging from day one, use Count mode to validate rules before blocking, tune for your application’s traffic patterns, and integrate with CloudWatch and your SIEM for real-time visibility. Start with the scenario that matches your immediate pain point, prove the value, then expand WAF coverage across your entire AWS footprint.