WAF Configuration Across Clouds: AWS WAF, Azure WAF, and Cloud Armor

WAFs Are Not Optional Anymore

Five years ago, many teams treated web application firewalls as a nice-to-have, something the security team asked for but that engineers resisted because of false positives and latency concerns. That era is over. Automated bot traffic now accounts for nearly 30 percent of all web requests, credential stuffing attacks happen around the clock, and the OWASP Top 10 vulnerabilities still get exploited in production every day. If your application is on the public internet without a WAF, it is not a question of whether you will be attacked -- it is a question of whether you are being attacked right now and do not know it.

This guide covers the practical configuration of WAFs across the three major cloud providers: AWS WAF, Azure WAF (on Application Gateway and Front Door), and Google Cloud Armor. We will walk through rule group strategies, rate limiting, bot management, OWASP protection, and a realistic cost comparison. The goal is to help you deploy a WAF configuration that stops real attacks without blocking legitimate traffic.

AWS WAF: Flexible but Requires Assembly

AWS WAF operates on a Web ACL model. You create a Web ACL, attach rule groups to it, and associate the Web ACL with your CloudFront distribution, Application Load Balancer, API Gateway, or AppSync endpoint. Rules are evaluated in priority order, and each rule can count, allow, block, or send a CAPTCHA challenge.

The first thing to understand about AWS WAF is that it does very little out of the box. Unlike Azure WAF, which comes with pre-configured OWASP rule sets, AWS WAF starts as a blank slate. You need to add rule groups explicitly. AWS provides managed rule groups that cover the most common attack patterns, and these are what most teams should start with.

Recommended AWS WAF Starting Configuration

For a typical web application, start with these managed rule groups in this priority order:

1. AWSManagedRulesAmazonIpReputationList (priority 100) -- Blocks requests from IP addresses with poor reputation, including known botnets and scanners. This is free and catches a surprising amount of noise.
2. AWSManagedRulesCommonRuleSet (priority 200) -- The core OWASP protection rules covering SQL injection, cross-site scripting (XSS), path traversal, and other common web exploits. Set this to Count mode initially to observe matches before blocking.
3. AWSManagedRulesKnownBadInputsRuleSet (priority 300) -- Catches known exploit patterns including Log4j/Log4Shell attempts, which are still seen in the wild regularly.
4. AWSManagedRulesSQLiRuleSet (priority 400) -- Additional SQL injection detection beyond what the common rule set covers. Important if your application has any database-backed endpoints.
5. Rate-based rule (priority 500) -- A custom rate-based rule limiting requests per IP to 2,000 per 5-minute window. Adjust the threshold based on your application's normal traffic patterns.

Dealing with False Positives

The number one reason WAF deployments fail is false positives that block legitimate traffic, causing engineers to disable rules in frustration. The correct approach is to deploy rule groups in Count mode first, run them for one to two weeks while monitoring the WAF logs, identify which rules trigger on legitimate requests, then create scope-down statements or rule exclusions for those specific patterns before switching to Block mode.

Common false positive triggers include: JSON payloads that contain SQL-like syntax (the string "select" in a search query), rich text editors submitting HTML content that triggers XSS rules, API endpoints that accept file paths triggering path traversal rules, and health check endpoints being rate-limited. For each of these, create a rule that excludes the specific URI path or request pattern from the offending rule group, rather than disabling the entire rule group.

Azure WAF: Pre-Configured but Less Flexible

Azure offers WAF on two platforms: Application Gateway WAF v2 and Azure Front Door WAF. The core rule engine is the same, based on OWASP ModSecurity Core Rule Set (CRS), but the deployment model and pricing differ. Application Gateway WAF runs regionally alongside your backend, while Front Door WAF runs at Microsoft's global edge network.

Azure WAF's main advantage is that it ships with the OWASP CRS enabled by default. When you create a WAF policy and select the "Prevention" mode, you immediately get protection against the OWASP Top 10. The current default rule set (CRS 3.2) includes rules for SQL injection, XSS, local file inclusion, remote code execution, PHP injection, Java attacks, and session fixation.

The policy structure works differently from AWS. Instead of priority-ordered rule groups, Azure WAF evaluates custom rules first (in priority order), then managed rules. Custom rules support match conditions based on IP address, geo-location, request size, URI, headers, cookies, and query string parameters. Rate limiting is built into custom rules -- you define a rate limit rule with a threshold and time window, and Azure WAF tracks request rates per client IP.

Azure WAF Configuration Tips

Start in Detection mode, not Prevention mode. Azure's Detection mode logs all rule matches without blocking anything, which is equivalent to AWS WAF's Count action. Review the diagnostic logs in Log Analytics Workspace to identify false positives before switching to Prevention mode.

Use exclusion lists strategically. Azure WAF lets you exclude specific request attributes (headers, cookies, query parameters, or body fields) from specific rule groups or individual rules. For example, if rule 942430 (SQL comment injection detection) triggers on your application's "description" form field because users type content that looks like SQL syntax, exclude that specific field from that specific rule rather than disabling the entire SQL injection rule group.

For Front Door WAF, enable the bot protection managed rule set. This adds detection for known bot user agents, search engine crawlers (allowed), and suspicious crawler patterns (blocked). The bot protection rules add $1 per million requests to the cost but are effective at reducing automated scan traffic.

Google Cloud Armor: Network-Level Protection with Edge Capabilities

Google Cloud Armor operates at the Google Front End (GFE) layer, protecting backend services behind external HTTP(S) load balancers, TCP/SSL proxy load balancers, and Cloud CDN. It integrates with Google's threat intelligence, which benefits from the visibility Google has across the internet -- the same infrastructure that protects Google Search, Gmail, and YouTube analyzes patterns to identify malicious traffic.

Cloud Armor policies contain rules evaluated in priority order. Each rule has a match condition (IP range, expression, or preconfigured WAF rule), an action (allow, deny, rate-limit, redirect, or throttle), and a priority (lower number = higher priority). The preconfigured WAF rules are based on the OWASP ModSecurity CRS and cover SQL injection, XSS, local file inclusion, remote file inclusion, remote code execution, method enforcement, scanner detection, and protocol enforcement.

Recommended Cloud Armor Starting Configuration

1. Priority 1000: Allow rule for your office/VPN IP ranges (so you never lock yourself out during testing)
2. Priority 2000: Deny rule for known bad IP ranges from your threat intelligence feeds
3. Priority 3000: Preconfigured WAF rule for SQL injection (sqli-v33-stable) in preview mode
4. Priority 4000: Preconfigured WAF rule for XSS (xss-v33-stable) in preview mode
5. Priority 5000: Preconfigured WAF rule for local file inclusion (lfi-v33-stable)
6. Priority 6000: Rate limiting rule -- 1,000 requests per minute per IP with 403 response
7. Priority 2147483647: Default deny rule (or default allow, depending on your model)

Cloud Armor Adaptive Protection

Cloud Armor's standout feature is Adaptive Protection, a machine learning-based system that detects and alerts on Layer 7 DDoS attacks. When enabled, it monitors your traffic baseline and generates alerts with suggested rules when it detects anomalous patterns -- such as a sudden spike in requests from a specific country or an unusual distribution of request sizes. In my experience, Adaptive Protection correctly identifies about 80 percent of application-layer DDoS attacks within 2 to 5 minutes of onset, which is fast enough to mitigate before impact if you have alerting configured.

Adaptive Protection requires the Cloud Armor Enterprise tier (formerly Cloud Armor Managed Protection Plus), which costs $200 per month plus $1 per million requests. This is expensive for small projects but reasonable for any production application that handles significant traffic.

Rate Limiting: The Most Important Rule You Will Write

Rate limiting is the single most effective WAF rule for protecting applications. It stops brute-force login attempts, credential stuffing, API abuse, and simple DDoS attacks. Every WAF deployment should include rate limiting rules, even if you skip everything else.

Setting the Right Threshold

The biggest mistake teams make with rate limiting is setting thresholds too low, which blocks legitimate users, or too high, which fails to stop attacks. The correct approach is data-driven: analyze your access logs to understand normal traffic patterns before setting limits.

For a typical web application, a starting point is 2,000 requests per 5-minute window per IP address. For login endpoints specifically, a much lower limit of 10 to 20 requests per 5-minute window per IP is appropriate. For API endpoints, the limit depends on your API's usage patterns, but 100 to 500 requests per minute per IP is a common starting range.

Consider using different rate limits for different URI paths. Your marketing pages can tolerate higher limits than your authentication endpoints. On AWS WAF, you achieve this by combining a rate-based rule with a scope-down statement that matches specific paths. On Cloud Armor, you use separate rules with different match conditions and priorities.

OWASP Top 10 Protection: What Each WAF Actually Covers

All three WAFs claim OWASP Top 10 protection, but coverage varies. Here is what each actually detects and blocks effectively:

• SQL Injection (A03): All three handle this well. AWS WAF's SQLi detection with sensitivity level set to HIGH catches the most variants. Cloud Armor's paranoia level 3 is the most aggressive but also generates the most false positives.
• XSS (A03): Solid coverage across all three. The main gap is DOM-based XSS, which WAFs cannot detect because the attack executes entirely in the browser.
• Broken Access Control (A01): WAFs provide limited protection here. Path traversal rules help, but most access control issues are application logic bugs that no WAF can fix.
• Injection beyond SQL (A03): Command injection and LDAP injection coverage varies. AWS WAF's Known Bad Inputs rule set covers Log4Shell and similar; Azure CRS covers LDAP and OS command injection; Cloud Armor covers remote code execution patterns.
• Server-Side Request Forgery (A10): Limited WAF coverage. You can write custom rules to block requests with internal IP addresses in headers or parameters, but comprehensive SSRF protection requires application-level controls.

Cost Comparison

Let us compare costs for a production web application handling 50 million requests per month with 5 managed rule groups.

• AWS WAF: Web ACL ($5/month) + 5 rule groups (varies, AWS managed rules are $1 to $3 each, so approximately $10/month) + 50M requests at $0.60/million ($30/month) = approximately $45/month. Adding Bot Control (targeted) adds $10/month plus $1/million requests ($50/month additional). Total: $45 to $95/month.
• Azure WAF on Front Door: WAF policy ($5/month) + 50M requests at $0.65/million ($32.50/month) + managed rule set ($20/month) = approximately $57.50/month. Bot protection adds $1/million requests ($50/month additional). Total: $57.50 to $107.50/month.
• Google Cloud Armor Standard: Security policy ($5/month) + rules (5 rules at $1/month each = $5/month) + 50M requests at $0.75/million ($37.50/month) = approximately $47.50/month. Enterprise tier with Adaptive Protection adds $200/month. Total: $47.50 to $247.50/month.

At the standard tier, costs are remarkably similar across providers, roughly $45 to $60 per month for moderate traffic. The differences emerge when you add premium features: bot management and adaptive protection significantly increase costs on all platforms.

Practical Rule Examples for Common Attacks

Blocking Known Vulnerability Scanners

Automated scanners like Nuclei, sqlmap, and Nikto include identifiable patterns in their requests. Create a custom rule that inspects the User-Agent header for known scanner strings. On AWS WAF, this is a string match condition with a block action. This will not stop sophisticated attackers who customize their User-Agent, but it eliminates 60 to 70 percent of automated scanning noise from your logs.

Geo-Blocking for Compliance

If your application serves a specific geographic market, consider rate-limiting or blocking traffic from countries where you have no customers. This is not a security measure per se -- attackers use VPNs -- but it reduces the volume of automated attacks. On AWS WAF, use a geo match statement. On Cloud Armor, use the origin.region_code expression. On Azure WAF, use a geo-match condition in a custom rule. Always use rate-limiting rather than outright blocking for geo-restrictions, to avoid blocking legitimate users on VPNs or traveling abroad.

Protecting Login Endpoints

Create a targeted rate-limiting rule that matches your authentication endpoints (/login, /auth, /oauth/token, /api/v1/sessions). Set the limit to 10 requests per 5-minute window per IP. This stops credential stuffing while being generous enough to accommodate users who mistype their password a few times. Combine this with a CAPTCHA action (on AWS WAF) or reCAPTCHA integration (on Cloud Armor) after the rate limit is exceeded, rather than outright blocking.

Recommendations

After deploying WAFs across production applications on all three clouds, here is my practical advice.

If you are on AWS and already using CloudFront, AWS WAF is the obvious choice. The integration is seamless, and the managed rule groups provide good coverage with minimal configuration. Invest the time to deploy in Count mode first and tune out false positives before switching to Block. Enable AWS WAF logging to S3 via Kinesis Firehose from day one -- you need the data for tuning.

If you are on Azure, use Front Door WAF for internet-facing applications and Application Gateway WAF for internal-facing applications. The OWASP CRS is well-tested and the managed bot protection is worth the cost.

If you are on GCP, Cloud Armor Standard is sufficient for most applications. Upgrade to Enterprise only if you handle enough traffic to justify the $200/month base cost for Adaptive Protection.

Regardless of provider, always deploy rate limiting on authentication endpoints, always start managed rules in detection/count mode, and always configure logging and alerting before switching to blocking mode. A WAF that blocks legitimate traffic is worse than no WAF at all.