Amazon WAF is a managed web application firewall that protects your web applications and APIs from common exploits like SQL injection, cross-site scripting, and bot attacks. It works by inspecting HTTP(S) requests against configurable rules before they reach your origin servers, filtering malicious traffic at Amazon CloudFront edges, Application Load Balancers, or API Gateways.
Key Takeaways
- AWS WAF protects web applications from OWASP Top 10 threats, malicious bots, and layer 7 DDoS attacks by inspecting HTTP(S) requests at the application layer
- You can deploy WAF at CloudFront (edge/global), Application Load Balancer, or API Gateway depending on where you need protection
- Web ACLs, rules, and rule groups are the core building blocks—start with AWS-managed rule groups, then add custom rules as needed
- Always test new rules in count mode first and review CloudWatch logs before switching to block mode to avoid false positives
- Rate-based rules and bot control features help you throttle abusive traffic and mitigate automated attacks
- Placing WAF at CloudFront edges blocks threats before they reach your origin, reducing load and improving performance
What AWS WAF Does
AWS WAF sits between your users and your application, inspecting every HTTP or HTTPS request. Think of it as a bouncer at the door who checks ID before anyone gets in.
The service evaluates requests against rules you define in Web Access Control Lists (Web ACLs). Each rule looks at specific parts of the request—IP address, headers, URI path, query strings, or the request body. When a request matches a rule, WAF takes action: allow it through, block it, count it for monitoring, or challenge the user with a CAPTCHA.
Here’s what makes it useful: WAF handles the threats that traditional network firewalls miss. A network firewall can block port 80 traffic, but it won’t catch a SQL injection hidden in a form submission. WAF works at layer 7, understanding the application protocol itself.
Where You Can Deploy It
You attach AWS WAF to three types of resources:
- Amazon CloudFront — Your CDN distributions. This is the edge deployment option, filtering traffic at AWS edge locations closest to your users globally.
- Application Load Balancer — Regional deployment. Protects applications behind your ALBs in a specific AWS region.
- API Gateway — Also regional. Secures your REST APIs and HTTP APIs.
The choice matters. Deploy at CloudFront when you want global, low-latency protection that stops attacks before they consume your origin bandwidth. Deploy at ALB or API Gateway when you need region-specific controls or don’t use CloudFront.
Gotcha: You can only associate one Web ACL per resource. If you try to attach a second one, the new ACL replaces the old one—no merging, no warnings.
Web ACLs, Rules, and Rule Groups
A Web ACL is your policy document. It contains an ordered list of rules that WAF evaluates top-to-bottom. The first matching rule wins.
Rules define the match conditions and actions. You can write custom rules that check for specific patterns or behaviors. A simple rule might block all requests from a specific IP range. A complex rule might inspect the request body for SQL keywords and block only POST requests to /login that match.
Rule groups are collections of rules you can reuse. AWS provides managed rule groups maintained by the AWS security team and AWS Marketplace sellers. These cover common protections like the OWASP Top 10, known bad inputs, and IP reputation lists. You add them to your Web ACL with one click.
Start with managed rule groups. They give you baseline protection immediately and AWS updates them as new threats emerge. Then layer in custom rules for your application’s specific logic—rate limiting on your API endpoints, geo-blocking, or header validation.
Managed Rules and OWASP Coverage
AWS offers pre-built managed rule groups that you can enable without writing a single line of configuration. The Core Rule Set (CRS) covers OWASP Top 10 vulnerabilities: SQL injection, cross-site scripting, local file inclusion, and more.
There’s also a Known Bad Inputs rule group that blocks requests with patterns associated with vulnerability exploitation, and an IP Reputation list that blocks requests from IPs known for malicious activity.
Bot control is a separate managed offering. AWS provides a free tier that identifies and blocks common bots, and a paid tier with more sophisticated bot detection using machine learning and browser fingerprinting. The free tier covers 10 million bot control requests per month.
Real-world note: Managed rules are aggressive by default. When I enabled the OWASP CRS on a legacy PHP application, legitimate admin dashboard requests got blocked because they contained patterns that looked like path traversal attacks. Always test in count mode first.
Rate-Based Rules and DDoS Mitigation
Rate-based rules count requests from a single IP address over a five-minute window. When an IP exceeds your threshold, WAF blocks subsequent requests from that IP until the rate drops.
This is your first line of defense against layer 7 DDoS attacks and brute-force attempts. Set a rate limit of 2,000 requests per five minutes on your login endpoint, and attackers can’t spray credentials at scale.
You can scope rate rules narrowly. Count only POST requests to /api/login, or only requests without a valid session cookie. This lets you be strict on sensitive endpoints while keeping limits loose on static content.
Rate-based rules work well with CloudFront because the edge locations aggregate counts globally. An attacker sending requests from different edge locations still gets counted as one source IP.
Logging, Monitoring, and Tuning
AWS WAF sends metrics to CloudWatch automatically: allowed requests, blocked requests, and counted requests. You see these within minutes of enabling WAF.
For request-level detail, enable WAF logging. You can send logs to CloudWatch Logs, an S3 bucket, or Kinesis Data Firehose. The logs include the full request details, which rule matched, and the action taken.
Use count mode for new rules. The rule evaluates and logs matches but doesn’t block anything. Review the logs for a few days, check for false positives, then switch to block mode.
I always set up a CloudWatch dashboard with allowed vs. blocked request counts and a metric alarm when blocked requests spike. This catches both attacks and accidental over-blocking.
Warning: WAF logs can get expensive fast if you log every request on a high-traffic site. Use sampling or send logs to S3 with lifecycle policies to control costs.
Capacity Units and Rule Complexity
Every Web ACL has a capacity limit measured in Web ACL Capacity Units (WCU). The default maximum is 1,500 WCU per Web ACL.
Simple rules consume few WCU. A rule that matches a single IP address costs 1 WCU. Complex rules with regex patterns, large IP sets, or body inspections cost more. Managed rule groups also consume capacity—check the AWS documentation for each group’s WCU cost before you add it.
If you hit the limit, you can’t add more rules. You’ll need to simplify existing rules, remove unused rule groups, or request a limit increase from AWS support.
Plan your rule complexity early. I’ve seen teams hit the limit after adding five managed rule groups and a dozen custom rules, then have to spend days consolidating rules to make room for a critical new protection.
Centralized Management with Firewall Manager
If you run AWS WAF across multiple accounts or many resources, use AWS Firewall Manager to enforce consistent policies organization-wide.
Firewall Manager lets you create a master WAF policy, then automatically apply it to all CloudFront distributions, ALBs, or API Gateways across your organization. When you update the policy, the changes roll out everywhere.
You can also set compliance rules: every ALB must have the OWASP rule group enabled, or every CloudFront distribution must have bot control. Firewall Manager flags resources that don’t comply.
This is essential for large organizations. Without it, you rely on each team to configure WAF correctly, and you have no visibility into coverage gaps.
Getting Started: One-Click Protection for CloudFront
CloudFront offers a one-click security setup in the Security dashboard. It creates a Web ACL with AWS-recommended protections—OWASP rules, IP reputation lists, and rate limiting—and attaches it to your distribution.
This is the fastest way to get basic protection running, but don’t stop there. The default rules may block legitimate traffic for your application. Review the CloudWatch metrics and logs after enabling, tune the rules, and add application-specific protections.
If you prefer the CLI, associate a Web ACL manually:
aws wafv2 associate-web-acl \ --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:global/webacl/example/a1b2c3d4 \ --resource-arn arn:aws:cloudfront::123456789012:distribution/E1234567890ABCYou can also define Web ACLs as code using CloudFormation or Terraform, which is what I recommend for production deployments. Infrastructure as code makes WAF config auditable, repeatable, and testable in a pipeline.
FAQ
Can AWS WAF protect on-premises applications?
Yes, but only indirectly. Deploy CloudFront in front of your on-premises origin and attach AWS WAF to the CloudFront distribution. CloudFront fetches content from your origin over the public internet or via a dedicated connection, and WAF filters requests at the edge before they reach your data center. You can’t deploy WAF directly on on-premises infrastructure.
What’s the difference between AWS WAF and AWS Shield?
AWS Shield protects against network-layer (layer 3 and 4) DDoS attacks like SYN floods and UDP reflection attacks. AWS WAF protects against application-layer (layer 7) attacks like SQL injection and malicious bots. Shield Standard is automatic and free; Shield Advanced costs extra and includes DDoS response team support. Use both together for layered defense.
Do I need to enable WAF to see security metrics in CloudFront?
Yes. The CloudFront Security dashboard only displays metrics after you enable AWS WAF on the distribution. Without WAF, you won’t see request analysis or threat metrics in that dashboard.
How much does AWS WAF cost?
You pay per Web ACL ($5/month), per rule ($1/month), and per million requests processed ($0.60/million). Managed rule groups have additional monthly fees. Bot control has a free tier for common bot detection (10 million requests/month) and a paid tier for advanced bot management. Check the AWS WAF pricing page for current rates and estimate your costs based on traffic volume and rule complexity.
Can I test WAF rules safely without blocking real users?
Absolutely. Set rule actions to “count” instead of “block.” The rule will evaluate and log matches without affecting traffic. Review the logs, confirm the rule behaves as expected, then change the action to block. This is the standard workflow and prevents outages caused by overly aggressive rules.
Conclusion
AWS WAF gives you programmable, application-layer protection for web applications and APIs. You deploy it at CloudFront for global edge filtering, or at ALB and API Gateway for regional protection. Web ACLs, rules, and rule groups let you block SQL injection, XSS, bots, and abusive traffic using both AWS-managed protections and custom logic. Always test rules in count mode first, monitor CloudWatch metrics and logs, and tune for false positives. For multi-account deployments, Firewall Manager enforces consistent policies across your organization. Start with managed rule groups for quick baseline coverage, then add rate limiting and custom rules tailored to your application’s needs.