AWS WAF pricing: what to model (ACLs, rules, requests)
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
Use this page when you need to decide what belongs inside the WAF bill model before you argue about optimization. This is the AWS WAF bill-boundary page.
Stay here when the open question is Web ACLs, rules, evaluated requests, and the downstream logging or SIEM costs that should be tracked beside WAF rather than confused with it. Go back to the security parent page if the broader security spike question is still unclear.
What to model (baseline + variable)
- Web ACL count: how many ACLs you maintain (often per environment/app)
- Rule count: custom rules + managed rule groups you enable (based on your pricing model)
- Requests/month: total evaluated requests (watch out for attack traffic)
- Downstream: log delivery, storage, search/analytics, and SIEM ingestion
The two most common budgeting failures are (1) modeling only the baseline and missing request spikes and (2) paying a second bill for logs and analysis.
Inside the WAF bill vs outside the WAF bill
- Inside the WAF bill: Web ACL baselines, rule or managed-rule coverage, and evaluated requests including blocked traffic during attack windows.
- Usually outside the WAF bill: log delivery, retention, query scans, SIEM ingestion, and analyst workflows triggered by WAF events.
- Why that boundary matters: teams often blame WAF for total security-observability spend when the real multiplier sits in downstream logging and investigation.
A fast estimate (baseline + spike)
Use AWS WAF Cost Calculator for the baseline + request model, then add log/analysis and any security tooling.
- Baseline scenario: typical month requests and current ACL/rule inventory.
- Spike scenario: attack/bot window where evaluated requests are much higher.
Worked estimate template (copy/paste)
- Baseline = ACLs + rules (and any managed add-ons you actually use)
- Requests/month = evaluated requests (allowed + blocked), baseline + spike
- Logs = (bytes per request) * requests/month + retention + query scans
Where to get inputs (evidence path)
- Evaluated requests: from WAF metrics/logs for a representative week; keep a separate spike window.
- ACL and rule inventory: list ACLs by environment and identify duplicated policies (sprawl is common).
- Log volume: measure bytes per event and multiply by events/day; do not assume "logs are small".
Common pitfalls
- Underestimating request volume during incidents (bot traffic, attacks).
- Keeping many almost-identical ACLs and rules across environments.
- Streaming full logs everywhere without volume controls.
- Measuring allowed requests only and forgetting blocked traffic in evaluated volume.
- Using one average and missing peak hours (spikes drive the bill).
How to validate the pricing model
- Reconcile evaluated requests against the bill for the same window (baseline week + spike window).
- Confirm rule/ACL inventory matches what is deployed (copy/paste ACL sprawl is common).
- Verify logging controls: sampling, retention, and dashboard query windows.
When this is not the right page
- If you still need to separate WAF from KMS, secrets, or audit logging as the main security cost surface, go back to security costs first.
- If your main problem is turning real traffic and attack windows into a defendable evaluated-request model, go to Estimate WAF requests.
- If the model is already believable and you now need operational changes, go to WAF cost optimization.
- If you are investigating a specific surge window, use WAF cost spikes during attacks instead of treating every month like the same pattern.
Related guides
Validation checklist
- Validate the primary driver with measured usage from a representative window.
- Confirm units and pricing units (per 10k vs per 1M, GB vs GiB) before trusting the estimate.
- Re-check incident windows: retries/timeouts often multiply cost drivers.