A Deep Dive into AWS WAF: Web Application Firewall

AWS WAF has gotten complicated with all the rule groups, managed rules, and configuration options flying around. As someone who has spent years configuring web application firewalls across multiple AWS accounts, I learned everything there is to know about this service. Today, I will share it all with you.

Web application security used to mean slapping a hardware firewall in front of your servers and calling it a day. Those days are long gone. Modern applications face SQL injection, cross-site scripting, DDoS attacks, and bot traffic that gets more sophisticated by the month. AWS WAF is Amazon’s answer to all of that, and honestly, it’s become one of those services I can’t imagine running production workloads without.

What is AWS WAF?

Probably should have led with this section, honestly. AWS WAF stands for Web Application Firewall, and it sits in front of your web applications to filter, monitor, and block malicious HTTP/HTTPS traffic. Think of it as a bouncer for your APIs and websites — it checks every request against your rules and decides whether to let it through or kick it to the curb.

You attach WAF to CloudFront distributions, Application Load Balancers, API Gateway REST APIs, or AppSync GraphQL APIs. I typically attach it at the CloudFront level because that catches bad traffic before it even reaches my origin servers, which saves on compute costs too.

How AWS WAF Works

The core concept is straightforward: you create a Web ACL (Access Control List), add rules to it, and attach it to your resources. Each rule inspects incoming requests and either allows, blocks, or counts them. Rules can check IP addresses, HTTP headers, body content, URI strings, query parameters — pretty much anything in the request.

What I love about the rule system is the layering. You can combine conditions using AND/OR logic. For example, I have a rule that blocks requests only if they come from outside the US AND contain SQL injection patterns AND target specific API endpoints. That level of granularity keeps false positives low, which is always the balancing act with WAFs.

Key Features of AWS WAF

There are several features that make WAF stand out from other firewall options I’ve worked with:

• Managed Rule Groups: AWS and third-party vendors provide pre-built rule sets for common threats. The AWS Managed Rules for common vulnerabilities alone save hours of configuration. I use the Core Rule Set and the SQL Database rule set on virtually every deployment.
• Rate-Based Rules: You can throttle requests from individual IPs. This is your first line of defense against DDoS and brute force attacks. I usually set mine to 2,000 requests per 5-minute window per IP.
• IP Reputation Lists: AWS maintains lists of known malicious IPs. Enable the Amazon IP Reputation list and you’re blocking traffic from known bad actors with zero effort.
• Bot Control: This managed rule group identifies and manages bot traffic. It can tell the difference between legitimate bots like Googlebot and malicious scrapers.
• Custom Rules: When managed rules aren’t enough, you write your own. I’ve built custom rules for geo-blocking, header validation, and even content-type enforcement.

Use Cases for AWS WAF

Let me share some real scenarios where WAF has saved my teams from headaches:

• API Protection: We had an API endpoint getting hammered by automated credential stuffing attacks. A rate-based rule combined with the Bot Control managed rules cut the attack traffic by 99% within minutes.
• Geo-Blocking: For a client that only served US customers, we blocked all traffic from countries where we were seeing concentrated attack patterns. Simple but effective.
• SQL Injection Prevention: The SQL injection rule set catches most common injection patterns automatically. I’ve tested it against OWASP’s Top 10 payloads and it blocks them all.
• Content Scraping: Competitors were scraping product pages. We used rate limiting combined with header inspection to identify and block scraper bots while letting legitimate users through.

Implementing AWS WAF

That’s what makes AWS WAF endearing to us security professionals — the implementation is genuinely flexible without being overwhelming. You start with a Web ACL, pick your resource type, add some managed rules, and you’re protected within minutes.

Here’s my typical deployment process: First, I create the Web ACL in count mode. This means it logs what it would block without actually blocking anything. I let it run for a week, review the logs in CloudWatch, identify any false positives, and adjust rules accordingly. Only then do I switch to block mode. Skipping this step is how you accidentally break your own application, and I’ve made that mistake exactly once.

Best Practices

After managing WAF across dozens of accounts, here are the practices I swear by:

• Always start in count mode before blocking
• Use AWS Firewall Manager if you’re managing WAF across multiple accounts
• Set up CloudWatch metrics and alarms for blocked request spikes
• Regularly review and update your rule groups — threats evolve
• Keep your managed rules updated — AWS publishes new versions regularly
• Document your custom rules with clear descriptions so your team understands what each one does

Pricing Considerations

WAF pricing is based on the number of Web ACLs, rules per ACL, and requests processed. For most applications, the cost is quite reasonable — we’re typically talking $5-20/month for the ACL and rules, plus $0.60 per million requests. The managed rule groups add additional per-request charges but are worth every penny compared to building those detection capabilities yourself.

One cost tip: consolidate your rules where possible. Having fewer, more complex rules costs less than many simple rules, and it makes your configuration easier to manage too.