AWS WAF: 6 Practical Habits That Keep Your Web Apps Safe

A web application firewall is one of those services that sits quietly until the day it saves you — or the day it blocks your best customer's checkout. I have run AWS WAF in front of ALBs and CloudFront distributions for a while now, and most of the pain I hit came from my own configuration, not from attackers. These six habits are what I do differently now.

1. Start with AWS Managed Rules in Count mode

AWS ships managed rule groups (Core rule set, Known bad inputs, SQL injection protection) that catch the obvious junk. When you first attach them, set the action to Count, not Block. Count lets the rule fire and log without stopping traffic, so you spend a week watching which requests match. I once found our own health checker tripping a size-restriction rule — blocking from day one would have turned that into an outage. Flip to Block only after the noise settles.

2. Add a rate-based rule tuned to your real traffic

The managed rules don't stop a botnet hammering your login page. A rate-based rule (e.g. block IPs exceeding 2,000 requests per 5 minutes) is the cheapest anti-scraping tool you have. Tune the threshold from your CloudWatch metrics, not from a guess — look at your p95 request rate per IP first, then set the limit a comfortable margin above it. And scope it: apply it to /login and /api/* paths, not the whole site, so a viral homepage spike doesn't throttle your real users.

3. Turn on logging from day one

WAF logs every evaluated request to S3, CloudWatch Logs, or Kinesis Data Firehose. Enable it before you need it. When a customer says "your site blocked me", the log tells you exactly which rule matched and why — without it, you're guessing. I send mine to S3 and query with Athena when investigating; the partitioned format makes "show me every block for this IP today" a 30-second query.

4. Associate WAF at CloudFront when you can

You can attach WAF to an ALB, an API Gateway, or a CloudFront distribution. If your traffic goes through CloudFront, put WAF there: malicious requests get dropped at the edge, before they ever reach your region or cost you origin bandwidth. Same rule set, but the block happens ~200 edge locations closer to the attacker.

5. Stage rule changes like code deploys

Every rule change is a potential self-inflicted outage. I keep a staging web ACL attached to a test distribution, flip new rules to Count there first, and only promote to Block in production after a quiet week. Label your rules clearly — "rate-limit-login-count" beats "rule-3" when you're debugging at 2 a.m.

6. Watch the bill — WAF charges per rule

WAF pricing is per web ACL, per rule, plus per million requests. Ten unused managed rule groups attached "just in case" quietly cost real money every month. Audit quarterly: remove rules that never fire (check the logs), and prefer one well-tuned custom rule over three overlapping managed ones.

Key takeaways

- Start managed rules in Count mode; earn your way to Block.
- Tune rate limits from real p95 traffic, scoped to sensitive paths.
- Logging is non-negotiable — it's your only "why was I blocked" evidence.
- Edge placement (CloudFront) blocks attacks cheapest.
- Treat rule changes like deploys: stage, observe, promote.
- Prune unused rules; WAF bills per rule.