AWS WAF — Which Rules Should I Choose?

Why Rule Priority Confuses Most People

AWS WAF evaluates rules from the lowest numeric priority (top) to the highest (bottom). The first rule that matches can terminate evaluation — so order directly affects what gets blocked and what slips through.

Most people get confused because:

• They think "strongest" should go first. Intuitively, you'd want your most aggressive protection at the top. But the correct approach is the opposite — put your cheapest, most certain decisions first (IP allow/block lists) and leave expensive pattern matching for later.
• They mix up allow and block logic. If a rate-based rule sits above your allow list, you might accidentally rate-limit a trusted partner IP before the allow rule ever fires.
• They don't realize AWS managed rules have internal priorities too. Each managed rule group contains multiple rules inside it, and their relative position in your Web ACL matters as much as the rules within each group.
• They add everything at once without understanding the layers. AWS offers dozens of managed rule groups. Adding all of them creates WCU (Web ACL Capacity Unit) pressure, increases false positives, and makes debugging painful. The recommended approach is to layer them incrementally.

The key mental model: think of your WAF rules like a funnel. The top filters out the obvious junk cheaply, and each layer below gets progressively more specific and expensive.

---

The Recommended Priority Order

AWS recommends building your Web ACL in this order, from highest priority (evaluated first) to lowest:

1. Customer's IP Reputation Lists (Your Own)

Rule	Purpose
Blocked lists	IPs you know are malicious — scrapers, attackers, abusive clients
Allowed lists	Trusted IPs that should never be blocked (partners, monitoring, VPN)

Why first? These are absolute decisions. If you know an IP is bad, block it immediately without wasting capacity on deeper inspection. If you know an IP is trusted, let it through before any managed rule accidentally flags it.

Tip: Use IP sets and update them through automation (e.g., Lambda + GuardDuty findings, or a threat intel feed).

2. AWS IP Reputation Managed Rule Groups

Rule	Purpose
Amazon IP reputation list	Blocks IPs that AWS has identified as actively engaging in malicious activity
Anonymous IP list	Blocks requests from VPNs, Tor exit nodes, hosting providers, and proxies commonly used to hide identity

Why second? These are maintained by AWS's threat intelligence team and updated automatically. They catch known-bad infrastructure before your application-layer rules even need to run.

Note: The Anonymous IP list can produce false positives for legitimate VPN users. Consider setting it to Count mode first and reviewing the logs.

3. AWS Baseline Managed Rule Groups

Rule	Purpose
Core Rule Set (CRS)	Protects against common OWASP Top 10 threats — XSS, SQLi, path traversal, command injection
Known bad inputs rule group	Blocks request patterns known to be invalid or exploitative (e.g., Log4j, Spring4Shell payloads)

Why third? After filtering out bad IPs, you want broad application-layer protection. The Core Rule Set covers the widest range of attacks. Known bad inputs catches specific exploit payloads that emerge from CVEs.

This is where most of your protection lives. For a typical web application, these two rule groups alone block the majority of opportunistic attacks.

4. AWS Use-Case Specific Managed Rule Groups

Rule	Purpose
Linux OS rule group	Blocks Linux-specific LFI patterns (e.g., /etc/passwd)
SQL database rule group	Blocks SQL injection patterns beyond what CRS catches
PHP application rule group	Blocks PHP-specific exploits
WordPress application rule group	Blocks WordPress-specific attack vectors
Bot Control	Identifies and manages bot traffic

Why fourth? These are specialized. You only add the ones relevant to your stack. Running a Node.js app on Linux? Add the Linux OS rule group but skip PHP and WordPress. Running WordPress? Add all three.

Important: Each managed rule group consumes WCUs. Don't add groups that don't apply to your application — they add cost, latency, and false positive risk without benefit.

5. Rate-Based Rules

Rule	Purpose
Blanket rate-based rule	Limits request volume per IP over a 5-minute window

Why last? Rate-based rules are your safety net. If an attacker bypasses all pattern-based rules but hammers your application with volume, this catches them. It sits at the bottom because you want all the smarter rules to make their decisions first.

Common threshold: Start with 2000 requests per 5 minutes per IP for a general web application, then tune based on your traffic patterns.

---

Putting It Together — A Typical Production Web ACL

For a web application behind CloudFront or ALB, a solid starting point:

Priority 0:  Your Blocked IP Set (Block)
Priority 1:  Your Allowed IP Set (Allow)
Priority 2:  AWS Amazon IP Reputation List (Block)
Priority 3:  AWS Anonymous IP List (Count → Block after tuning)
Priority 4:  AWS Core Rule Set (Block)
Priority 5:  AWS Known Bad Inputs (Block)
Priority 6:  AWS Linux OS Rule Group (Block, if applicable)
Priority 7:  AWS SQL Database Rule Group (Block, if applicable)
Priority 8:  Rate-based rule — 2000 req/5min (Block)
Priority 9:  Default action: Allow

---

Tips for Production

• Start in Count mode. Deploy new rule groups in Count mode first. Review CloudWatch metrics and WAF logs for false positives before switching to Block.
• Use WAF logging. Send logs to S3 or CloudWatch Logs. Without logs, you cannot debug false positives or verify that rules are working.
• Review WCU usage. Each Web ACL has a 5000 WCU limit (soft). Managed rule groups vary from 200 to 700+ WCUs each. Plan accordingly.
• Automate IP set updates. Use Lambda or EventBridge to feed threat intelligence into your blocked IP set automatically.
• Scope down rules when possible. Some managed rules support scope-down statements — e.g., only apply the SQL rule group to paths that interact with your database.
• Re-evaluate regularly. New managed rule groups and versions get released. Review your Web ACL quarterly.

---

Summary

The correct mental model for AWS WAF rule priority:

1. Known IPs — cheapest, most certain decisions
2. Reputation — AWS-maintained threat intelligence
3. Baseline protection — OWASP Top 10 and known exploits
4. Stack-specific rules — only what applies to your technology
5. Rate limiting — volumetric safety net

Don't over-complicate it. Start with the basics, deploy in Count mode, review your logs, and add layers only when needed.