---
title: AWS WAF: Web Application Firewall Configuration for Production
description: AWS WAF blocks attacks. It also blocks legitimate users when the rules are wrong — and that's a worse incident. Managed rule groups, custom rules, rate limiting, bot control, and the layered defense strategy that protects without flooding your support queue.
url: https://www.factualminds.com/blog/aws-waf-web-application-firewall-production-guide/
datePublished: 2026-02-11T00:00:00.000Z
dateModified: 2026-05-14T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: waf, security, aws, cloudfront, compliance
---

# AWS WAF: Web Application Firewall Configuration for Production

> AWS WAF blocks attacks. It also blocks legitimate users when the rules are wrong — and that's a worse incident. Managed rule groups, custom rules, rate limiting, bot control, and the layered defense strategy that protects without flooding your support queue.

Every web application exposed to the internet receives malicious traffic — SQL injection attempts, cross-site scripting probes, credential stuffing attacks, and automated bots scraping content or testing for vulnerabilities. AWS WAF (Web Application Firewall) inspects HTTP requests before they reach your application and blocks the malicious ones.

**May 2026 refresh:** Managed rule group revisions ship weekly—pin versions in Terraform/CDN pipelines and monitor AWS WAF release notes so silent rule updates don't flatten legitimate traffic.

But WAF is not a set-and-forget firewall. Poorly configured rules block legitimate users, overly permissive rules miss attacks, and misconfigured rate limits either throttle real customers or fail to stop automated abuse. This guide covers the production configuration patterns that protect your application without creating false positives.

## Where WAF Fits

AWS WAF integrates with the services that receive inbound HTTP traffic:

| Resource                                           | Use Case                                       |
| -------------------------------------------------- | ---------------------------------------------- |
| [CloudFront](/services/aws-cloudfront-consultant/) | Global web applications, CDN-delivered content |
| Application Load Balancer (ALB)                    | Regional web applications, APIs                |
| API Gateway                                        | REST and HTTP APIs                             |
| AppSync                                            | GraphQL APIs                                   |
| Cognito User Pools                                 | Authentication endpoints                       |

**Recommendation:** Attach WAF to CloudFront when possible. CloudFront WAF inspects traffic at the edge (225+ locations globally), blocking attacks before they reach your origin Region. This reduces origin load and provides lower-latency enforcement.

For applications without CloudFront, attach WAF to the ALB or API Gateway that receives traffic.

## Web ACL Structure

A Web ACL (Access Control List) is the container for your WAF rules. It evaluates rules in priority order and takes the action of the first matching rule.

```
Web ACL
├── Rule 1 (priority 0): Rate limiting — Block (highest priority)
├── Rule 2 (priority 1): IP reputation — Block
├── Rule 3 (priority 2): Bot Control — Block/Challenge
├── Rule 4 (priority 3): AWS Managed Core Rule Set — Block
├── Rule 5 (priority 4): SQL injection rules — Block
├── Rule 6 (priority 5): Custom allow rules — Allow
└── Default action: Allow (if no rule matches)
```

**Rule evaluation order matters.** Place rate limiting and IP reputation rules first (cheapest to evaluate, block the most traffic). Place complex inspection rules later (more expensive, applied to less traffic after early filtering).

## Managed Rule Groups

AWS and AWS Marketplace partners provide pre-built rule groups that cover common attack patterns. These are the fastest path to production protection.

### AWS Managed Rules

| Rule Group                | Protects Against                               | WCU Cost |
| ------------------------- | ---------------------------------------------- | -------- |
| Core Rule Set (CRS)       | OWASP Top 10 (XSS, SQLi, path traversal, SSRF) | 700      |
| Known Bad Inputs          | Request patterns known to be malicious         | 200      |
| Admin Protection          | Admin page access from unauthorized IPs        | 100      |
| Amazon IP Reputation List | Known malicious IPs, botnets, Tor exit nodes   | 25       |
| Anonymous IP List         | VPNs, proxies, anonymizers                     | 50       |
| SQL Database              | SQL injection attack patterns                  | 200      |
| Linux/POSIX OS            | LFI, command injection targeting Linux         | 200      |
| PHP Application           | PHP-specific exploits                          | 100      |
| WordPress Application     | WordPress-specific exploits                    | 100      |

**Recommended baseline (every web application):**

1. Amazon IP Reputation List
2. Core Rule Set (CRS)
3. Known Bad Inputs
4. SQL Database (if your application uses a database)

This combination costs 1,125 WCUs (Web ACL Capacity Units) and provides broad protection against the most common web attacks. The default Web ACL capacity is 5,000 WCUs, leaving ample room for custom rules.

### Bot Control

AWS WAF Bot Control identifies and manages automated traffic:

**Common bots (free with Bot Control):**

- Search engine crawlers (Googlebot, Bingbot)
- Social media crawlers (Facebook, Twitter)
- Monitoring bots (Pingdom, UptimeRobot)

**Targeted bots (Bot Control - Targeted):**

- Credential stuffing bots
- Scraping bots
- Scalping bots (sneaker bots, ticket bots)
- Account creation bots

**Actions for bots:**

- **Allow** — Let verified bots through (search engines)
- **Block** — Reject the request
- **Challenge (CAPTCHA)** — Present a CAPTCHA challenge
- **Challenge (Silent)** — JavaScript challenge (invisible to users)
- **Count** — Log but do not block (monitoring mode)

**Recommendation:** Start Bot Control in Count mode for 2 weeks. Review the logs to understand your bot traffic before enabling blocking. Blocking all bots blindly breaks search engine indexing, monitoring tools, and legitimate API consumers.

## Custom Rules

Managed rules cover common attacks. Custom rules address your application's specific needs.

### Rate Limiting

Rate-based rules block IPs that exceed a request threshold:

```
Rule: Rate Limit Login
  - Rate limit: 100 requests per 5 minutes
  - Scope: Requests matching URI path /login or /api/auth
  - Action: Block for 5 minutes
```

**Rate limiting strategies:**

| Endpoint              | Threshold              | Rationale                     |
| --------------------- | ---------------------- | ----------------------------- |
| Login/auth            | 20-50 per 5 min        | Prevent credential stuffing   |
| Registration          | 5-10 per 5 min         | Prevent fake account creation |
| API endpoints         | 1,000-5,000 per 5 min  | Prevent API abuse             |
| Global (all requests) | 2,000-10,000 per 5 min | Prevent DDoS from single IP   |

**Important:** Rate-based rules use a 5-minute evaluation window (minimum). They are not suitable for per-second rate limiting — use API Gateway throttling or CloudFront origin request policies for fine-grained rate control.

### Geo-Blocking

Block requests from countries where you have no legitimate users:

```
Rule: Block Non-Served Countries
  - Match: Country NOT IN [US, CA, GB, DE, FR, AU]
  - Action: Block
```

**Use with caution.** Geo-blocking is a blunt instrument — it blocks all traffic from a country, including legitimate users traveling or using VPNs. Use it only when you have regulatory requirements (data residency) or when attack traffic overwhelmingly originates from specific countries.

### URI-Based Rules

Protect sensitive endpoints with targeted rules:

```
Rule: Protect Admin Panel
  - Match: URI path starts with /admin
  - AND: Source IP NOT IN [office-ip-1, office-ip-2, vpn-range]
  - Action: Block
```

```
Rule: Block wp-admin probes
  - Match: URI path contains /wp-admin or /wp-login
  - Action: Block (when not running WordPress)
```

### Header Inspection

Inspect request headers for common attack patterns:

```
Rule: Require valid User-Agent
  - Match: User-Agent header is empty or matches known attack tools
  - Action: Block
```

```
Rule: Block known vulnerability scanners
  - Match: User-Agent contains "sqlmap" or "nikto" or "dirbuster"
  - Action: Block
```

## Deployment Strategy: Count Before Block

The most common WAF deployment mistake is enabling blocking rules without testing. A rule that looks correct on paper may block legitimate traffic in ways you did not anticipate.

### Phase 1: Count Mode (2 weeks)

Deploy all rules in Count mode. WAF logs every request that would be blocked but allows it through:

```
Rule action: Count (not Block)
→ CloudWatch metrics show match count
→ WAF logs show matched request details
→ Application receives all traffic normally
```

### Phase 2: Analyze False Positives

Review WAF logs for legitimate requests that match blocking rules:

- API clients sending valid JSON that triggers SQL injection rules
- Users with special characters in form inputs that trigger XSS rules
- Legitimate automated tools (CI/CD, monitoring) that trigger bot rules
- Internal systems making rapid requests that trigger rate limits

### Phase 3: Tune Rules

Add exceptions for identified false positives:

```
Rule: Exclude API endpoint from SQLi inspection
  - Match: URI path starts with /api/v1/search AND Core Rule Set matches
  - Action: Allow (overrides the CRS block)
```

Place these allow rules before the managed rule groups in priority order.

### Phase 4: Enable Blocking

Switch rules from Count to Block after confirming acceptable false-positive rates. Monitor application error rates and user reports closely for the first 48 hours.

## Logging and Monitoring

### WAF Logging

Send WAF logs to one of three destinations:

| Destination           | Cost      | Query Capability      | Best For                                     |
| --------------------- | --------- | --------------------- | -------------------------------------------- |
| CloudWatch Logs       | $0.50/GB  | Logs Insights queries | Real-time monitoring, small-medium volume    |
| S3                    | $0.023/GB | Athena queries        | Long-term retention, compliance, high volume |
| Kinesis Data Firehose | Variable  | Real-time processing  | SIEM integration, real-time analytics        |

**Recommended:** S3 for retention + [CloudWatch Logs](/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) for real-time monitoring. This gives you both long-term storage for compliance and fast access for incident investigation.

### Key Metrics and Alarms

| Metric           | Alarm Threshold                  | Indicates                                 |
| ---------------- | -------------------------------- | ----------------------------------------- |
| BlockedRequests  | Sudden spike (anomaly detection) | Active attack                             |
| AllowedRequests  | Sudden drop                      | WAF over-blocking legitimate traffic      |
| CountedRequests  | Increasing trend                 | Rules in count mode matching more traffic |
| Rate-limited IPs | > 10 per minute                  | Coordinated attack                        |

### WAF Dashboard

Create a [CloudWatch dashboard](/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) with:

- Blocked vs allowed requests over time
- Top blocked rules (which rules trigger most)
- Top blocked IPs (identify persistent attackers)
- Top blocked countries
- Rate-limited IPs count

## WAF + Shield for DDoS Protection

AWS WAF and AWS Shield work together for layered DDoS protection:

**Shield Standard (free):**

- Automatic protection against Layer 3/4 DDoS attacks
- Enabled by default on all AWS resources
- Protects against SYN floods, UDP reflection, and other volumetric attacks

**Shield Advanced ($3,000/month + data transfer):**

- Layer 7 DDoS protection (HTTP floods)
- 24/7 access to AWS DDoS Response Team (DRT)
- Cost protection — AWS credits charges incurred during DDoS attacks
- Automatic WAF rule creation to mitigate detected attacks
- Health-based detection for more accurate attack identification

**Recommendation:** Shield Standard is sufficient for most applications. Shield Advanced is justified for applications where DDoS downtime directly impacts revenue (e-commerce, SaaS platforms, financial services) and the $3,000/month cost is small relative to the hourly cost of downtime.

## Cost Management

### WAF Pricing

| Component              | Cost                                 |
| ---------------------- | ------------------------------------ |
| Web ACL                | $5/month                             |
| Rule                   | $1/month per rule                    |
| Request inspection     | $0.60 per million requests           |
| Bot Control (common)   | $10/month + $1 per million requests  |
| Bot Control (targeted) | $10/month + $10 per million requests |

**Example:** A Web ACL with 10 rules processing 50 million requests/month:

- Web ACL: $5
- Rules: $10
- Requests: 50 × $0.60 = $30
- **Total: $45/month**

This is remarkably cost-effective for the protection provided. The cost of a single security breach — incident response, customer notification, reputation damage — far exceeds years of WAF charges.

### Reducing Costs

- Use CloudFront caching to reduce the number of requests that reach WAF (cached responses skip WAF evaluation)
- Remove rules that never match (review monthly)
- Use managed rule groups efficiently — one CRS covers most attack types, no need for overlapping rules

## Integration with AWS Security Services

WAF works alongside other [AWS security services](/services/aws-cloud-security/):

- **[GuardDuty](/blog/aws-guardduty-threat-detection-production-guide/)** — Detects compromised credentials and suspicious API activity. Findings can trigger automated WAF IP blocks via Lambda.
- **Security Hub** — Aggregates WAF findings alongside other security service findings for centralized security posture management.
- **Firewall Manager** — Manages WAF rules across multiple accounts in an [AWS Organization](/blog/aws-multi-account-strategy-landing-zone-best-practices/). Deploy consistent WAF policies from a central security account.

## Common Mistakes

### Mistake 1: Blocking Without Count Mode First

Deploying blocking rules without testing causes false positives that block legitimate users. Always deploy in Count mode first, analyze for 1-2 weeks, then switch to Block.

### Mistake 2: Relying Only on Managed Rules

Managed rules protect against common attacks. They do not protect against application-specific abuse — credential stuffing against your login page, API abuse specific to your endpoints, or scraping your proprietary content. Supplement managed rules with custom rules for your application's specific threats.

### Mistake 3: Ignoring WAF Logs

WAF logs are a goldmine of security intelligence — attack patterns, targeted endpoints, attacker IPs, and bot behavior. If you are not reviewing logs, you are flying blind. Set up automated alerts for anomalies and review logs weekly for trends.

### Mistake 4: No Rate Limiting

Even with perfect rule coverage, an attacker can overwhelm your application with high-volume requests that pass all rules individually. Rate-based rules are essential for preventing volumetric abuse.

## Getting Started

WAF is the first layer of defense for any internet-facing application. Combined with [CloudFront](/services/aws-cloudfront-consultant/) for edge-level inspection and [GuardDuty](/blog/aws-guardduty-threat-detection-production-guide/) for threat detection, it forms a comprehensive security perimeter that protects your application while you focus on building features.

For WAF configuration, security architecture design, and ongoing [security management](/services/aws-cloud-security/) through our [managed services](/services/aws-managed-services/), talk to our team.

[Contact us to secure your web applications →](/contact-us/)

## FAQ

### When should I attach AWS WAF to CloudFront vs ALB or API Gateway?
Attach to CloudFront whenever the application sits behind CloudFront — WAF inspects and blocks at the 600+ edge locations before traffic reaches your origin region, reducing origin load and dropping attack-traffic latency. Use ALB or API Gateway WAF only for regional applications without CloudFront. For mixed estates, you can layer both: edge WAF for broad attack patterns, regional WAF for app-specific custom rules.

### What AWS Managed Rule Groups should I enable as a baseline?
For every web application: Amazon IP Reputation List (cheapest, blocks known-bad IPs), Core Rule Set (OWASP Top 10 — XSS, SQLi, path traversal, SSRF), and Known Bad Inputs. Add the SQL Database rule group for any app with a database, plus the framework-specific group (PHP Application, WordPress Application) if relevant. This bundle uses ~1,125 WCUs of the 5,000-WCU default capacity, leaving room for custom rules.

### How does AWS WAF Bot Control work?
Bot Control identifies automated traffic via heuristics (request rate, headers, JA3 fingerprints) plus AWS-managed bot signatures. The Common feature tier ($1/million requests) labels search engine crawlers, monitoring bots, and known-bad bots; the Targeted tier adds challenge-based detection (silent CAPTCHA, JavaScript challenge) for sophisticated scrapers and credential-stuffing bots. Use rule actions to allow Googlebot/Bingbot, challenge unknown bots, and block known-bad signatures.

### How do I prevent rate-limit rules from blocking legitimate users?
Rate limits should aggregate by `aws:ip` for anonymous traffic and by a custom key (auth token, API key) for authenticated traffic — otherwise users behind a corporate NAT all share one bucket. Set the limit per 5-minute window based on real-traffic 99th-percentile observation, not guesswork. Start in count mode for two weeks before flipping to block, and exclude known good crawlers (Googlebot, monitoring tools) via an upstream allow rule.

### Does AWS WAF replace AWS Shield?
No — they are complementary. Shield Standard is automatic free DDoS protection at the network layer (L3/L4) for every AWS resource. Shield Advanced ($3,000/month) adds enhanced L3/L4 protection, 24x7 SRT response, cost protection, and global threat intel that feeds into WAF. WAF handles application-layer (L7) attacks. For internet-exposed production: Shield Standard is automatic, WAF is required for L7, Shield Advanced is justified above mid-six-figure ARR or if a single hour of downtime exceeds $3,000.

---

*Source: https://www.factualminds.com/blog/aws-waf-web-application-firewall-production-guide/*