AWS WAF: Web Application Firewall Configuration for Production

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.

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:

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

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:

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:

Recommended: S3 for retention + CloudWatch Logs for real-time monitoring. This gives you both long-term storage for compliance and fast access for incident investigation.

Key Metrics and Alarms

WAF Dashboard

Create a CloudWatch dashboard 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

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:

• GuardDuty — 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. 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 for edge-level inspection and GuardDuty 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 through our managed services, talk to our team.

Contact us to secure your web applications →