Category: WAF

AWS WAF protects five core scenarios extremely well: internet-facing web applications and APIs from OWASP Top 10 exploits, high-traffic endpoints from credential stuffing and bot abuse via rate-based rules and Bot Control, hybrid and on-premises origins through CloudFront edge filtering, multi-account enterprises through centralized Firewall Manager policies, and compliance-driven organizations that need detailed request logging for security operations and audit trails.

Key Takeaways

• Web application protection is the universal use case—deploy WAF on CloudFront, ALB, or API Gateway to block SQL injection, XSS, and OWASP Top 10 threats at layer 7
• Rate-based rules and Bot Control stop credential-stuffing, API abuse, and scraping by throttling or blocking IPs that exceed thresholds over five-minute windows
• CloudFront edge placement protects hybrid and on-premises origins by filtering malicious traffic at 450+ global locations before it consumes origin bandwidth or compute
• AWS Firewall Manager enables centralized policy enforcement across hundreds of AWS accounts and thousands of resources—critical for enterprise governance
• Logging to Kinesis Data Firehose, S3, or CloudWatch provides the telemetry security teams need for tuning, compliance, SIEM integration, and automated incident response
• Account takeover prevention combines rate-based rules on /login endpoints with managed Bot Control to detect and block credential-stuffing attacks
• Managed rule groups (OWASP, Known Bad Inputs, IP Reputation) give you continuous threat intelligence updates from AWS—start here, layer custom rules only when needed

Scenario 1: Protecting Internet-Facing Web Applications and APIs

The problem: Your web application or REST API is exposed to the internet. Attackers probe for SQL injection vulnerabilities, cross-site scripting flaws, remote code execution bugs, and known CVEs. A single successful exploit can result in data exfiltration, ransomware deployment, or full application takeover.

How AWS WAF solves it: Attach a Web ACL to your CloudFront distribution, Application Load Balancer, or API Gateway endpoint. Enable AWS Managed Rules—specifically the OWASP Core Rule Set and Known Bad Inputs rule group. These managed rules inspect every HTTP request for patterns that match common web exploits: SQL injection attempts in query parameters, XSS payloads in POST bodies, path traversal attempts in URIs, command injection in headers.

WAF evaluates requests in milliseconds. Malicious requests get blocked at the edge (CloudFront) or at the load balancer (ALB/API Gateway) before they ever reach your application code. Legitimate requests pass through with minimal latency overhead—typically 2–5ms for managed OWASP rules.

Real-world example: An e-commerce platform running on CloudFront and ALB faced automated scanners probing for vulnerabilities 24/7. Before WAF, these scanners triggered application errors, consumed database connections, and filled logs with garbage. After deploying the OWASP Core Rule Set, WAF blocked 98% of scanner traffic at the edge. Origin CPU usage dropped by 40%. Application logs became readable again. Security team could focus on legitimate threats instead of filtering scanner noise.

What you need:

• A Web ACL with CLOUDFRONT scope (for CloudFront) or REGIONAL scope (for ALB/API Gateway)
• AWS Managed Rules: OWASP Top 10, Known Bad Inputs, Amazon IP Reputation List
• Logging enabled (Kinesis Data Firehose or S3) to capture blocked requests
• CloudWatch metrics and alarms to alert on spikes in blocked traffic

Gotcha: Managed OWASP rules will trigger false positives on some applications—especially content management systems that accept JSON or XML in POST requests. Always deploy rules in Count mode first. Monitor logs for a week. Identify false positives. Create rule exceptions or scope-down statements. Then switch to Block.

Scenario 2: Stopping Credential Stuffing and Account Takeover

The problem: Attackers use stolen username/password pairs from data breaches to attempt logins on your application. They try thousands of credentials per minute, rotating through residential proxy IPs to evade simple IP blocking. Successful logins lead to account takeover, fraudulent transactions, and data theft.

How AWS WAF solves it: Create a rate-based rule targeting your login endpoint. Set a threshold—for example, 100 requests per 5 minutes per source IP on the /login URI path. When an IP exceeds the threshold, WAF blocks it for a configurable duration (10 minutes, 1 hour, 24 hours).

Layer Bot Control on top. Bot Control detects automated tools even when they rotate IPs or mimic browser user-agents. The free tier (common bot detection) identifies verified bots (Googlebot, Bingbot) and likely automated traffic. Targeted bot control (paid) adds granular categories, CAPTCHA challenges, and bot scoring.

Architecture pattern:

1. User (or bot) requests POST /login
2. CloudFront edge location receives request → WAF inspects
3. Rate-based rule checks: has this IP sent >100 requests to /login in the last 5 minutes?
4. Bot Control checks: does the request exhibit bot-like behavior (missing JavaScript execution, suspicious headers)?
5. If either rule matches → Block (403 response), log to Kinesis
6. If both pass → forward to origin ALB → application processes login

Real-world example: A SaaS company saw 200,000 login attempts per hour during a credential-stuffing attack. Origin instances scaled to 80+ EC2 instances to handle the load. After deploying a rate-based rule (50 requests per 5 minutes on /api/auth/login) and Bot Control, WAF blocked 99.5% of the attack at the CloudFront edge. Origin instances dropped to 12. The attack continued for three days. The origin never noticed.

What you need:

• Rate-based rule scoped to login endpoints (/login, /api/auth, /signin)
• Threshold tuned to your legitimate user patterns (monitor for a week, set threshold at 150–200% of 95th percentile)
• AWS Managed Rules Bot Control (free tier or targeted)
• Logging to track blocked IPs and bot categories

Tuning tip: Legitimate users occasionally trigger rate limits—someone frantically retrying a forgotten password, a mobile app with a buggy retry loop. Set your initial threshold high (500 requests per 5 minutes), run in Count mode, review logs, tune down to the lowest threshold that doesn’t block real users.

Scenario 3: Protecting Hybrid and On-Premises Origins

The problem: Your application runs on-premises or in a colocation facility. You expose it to the internet via a public IP. Attackers can reach your origin directly. Your on-premises firewall and IDS handle network-layer attacks, but they don’t inspect HTTP payloads deeply. Web exploits slip through. Your internet circuit bandwidth is expensive, and malicious traffic consumes it.

How AWS WAF solves it: Place CloudFront in front of your on-premises origin. Point the CloudFront distribution to your origin’s public IP or hostname (or use AWS Direct Connect for private connectivity). Attach a WAF Web ACL to the CloudFront distribution. Enable managed OWASP rules, IP reputation lists, and rate-based rules.

Now all internet traffic hits CloudFront’s edge locations first. WAF inspects every request at the edge—milliseconds after it arrives at the nearest CloudFront point of presence. Malicious requests get blocked there. Clean requests are forwarded to your on-premises origin over a persistent connection (or Direct Connect private link). Your origin sees only legitimate, WAF-approved traffic.

Benefits:

• Origin load reduction: Blocked requests never consume origin CPU, memory, or bandwidth
• Bandwidth cost savings: Your ISP charges for inbound and outbound traffic; WAF blocks malicious inbound traffic at CloudFront’s edge, not at your data center
• Reduced attack surface: Attackers cannot bypass CloudFront to hit your origin directly if you restrict origin firewall rules to accept traffic only from CloudFront IP ranges
• Edge caching: CloudFront caches static content (images, CSS, JS) at the edge, further reducing origin load

Real-world example: A manufacturing company ran a legacy web portal on-premises. Internet bandwidth was capped at 100 Mbps. During a layer 7 DDoS attack—50,000 HTTP requests per second—the circuit saturated. Legitimate customers couldn’t access the portal. After deploying CloudFront + WAF, the next attack was absorbed at CloudFront’s edge. Origin bandwidth usage stayed under 10 Mbps. The portal remained available throughout.

What you need:

• CloudFront distribution with on-prem origin (public IP or Direct Connect)
• Web ACL (CLOUDFRONT scope) with managed OWASP rules and rate-based rules
• Origin firewall rules that accept traffic only from CloudFront IP prefixes (published by AWS)
• Logging and CloudWatch alarms to monitor blocked traffic and origin health

Security hardening: Lock down your origin firewall to allow traffic only from CloudFront. AWS publishes the list of CloudFront IP ranges as a managed prefix list and via an API endpoint. Update your firewall rules to accept traffic from those IPs only. Now attackers cannot bypass CloudFront and hit your origin directly.

Scenario 4: Multi-Account Enterprise Governance with Firewall Manager

The problem: You manage 50+ AWS accounts under AWS Organizations. Each account has multiple CloudFront distributions, ALBs, and API Gateways. You need to enforce a baseline security policy—every public endpoint must have WAF protection with OWASP rules and rate limiting. Manual deployment is error-prone. Developers sometimes deploy new resources without attaching WAF. You lack visibility into which resources are protected.

How AWS WAF solves it: Use AWS Firewall Manager to create and enforce WAF policies across all accounts and resources. Define a policy: a Web ACL template with managed OWASP rules, IP reputation, and a rate-based rule. Apply the policy to an organizational unit (OU) or to all accounts. Tag resources that require protection.

Firewall Manager automatically associates the Web ACL with matching CloudFront distributions, ALBs, and API Gateways across all accounts. When a developer deploys a new ALB in any account, Firewall Manager detects it (if it matches the policy scope or tags) and attaches the baseline Web ACL within minutes. You get centralized visibility—Firewall Manager dashboard shows which resources are protected, which are out of compliance, and which Web ACLs are attached where.

Governance model:

• Security team defines the baseline Web ACL policy in Firewall Manager
• Policy is applied to all accounts in the organization (or specific OUs)
• Application teams can layer additional custom rules on top of the baseline but cannot remove baseline protections
• Firewall Manager continuously monitors for new resources and enforces the policy
• Security team receives alerts when resources are out of compliance

Real-world example: A financial services company with 120 AWS accounts struggled to enforce WAF policies. Audits routinely found unprotected ALBs and API Gateways. After deploying Firewall Manager, the security team created a policy with OWASP rules and tagged all internet-facing resources with Tier:Public. Firewall Manager attached the baseline Web ACL to 300+ resources across all accounts within two hours. New deployments got protection automatically. Compliance violations dropped to zero within a month.

What you need:

• AWS Organizations with multiple member accounts
• AWS Firewall Manager (runs in the organization’s management account or a delegated admin account)
• A baseline Web ACL template (OWASP rules, IP reputation, rate-based rules)
• Resource tagging strategy or scope rules (apply to all resources, or only tagged resources)
• IAM permissions for Firewall Manager to attach Web ACLs across accounts

Cost consideration: Firewall Manager itself has no additional charge beyond the Web ACL and rule costs in each account. However, you pay for Web ACLs, rules, and requests across all protected resources. Budget accordingly—300 resources × $5 per Web ACL per month = $1,500/month baseline cost before request charges.

Scenario 5: Security Operations, Compliance, and Logging

The problem: Your security team needs detailed telemetry for every web request—allowed, blocked, and counted. Compliance frameworks (PCI DSS, SOC 2, HIPAA) require evidence of security controls and audit trails. You need to integrate WAF logs with your SIEM, run automated threat-hunting queries, and provide audit reports to external assessors.

How AWS WAF solves it: Enable logging on every Web ACL. Configure Kinesis Data Firehose as the log destination (recommended for high-volume environments) or send logs to S3 or CloudWatch Logs. Each log entry includes:

• timestamp: when the request was received
• httpRequest: client IP, headers, URI, method, query string, request body sample
• action: ALLOW, BLOCK, COUNT, CAPTCHA
• terminatingRuleId: which rule matched and triggered the action
• ruleGroupList: which managed rule groups were evaluated
• Web ACL ID, distribution ID (CloudFront), load balancer ARN (ALB)

Forward Kinesis logs to your SIEM (Splunk, Elastic, Chronicle). Set up automated queries: alert when BlockedRequests for a specific rule exceeds threshold, flag IPs with high block rates, detect patterns indicating zero-day exploit attempts.

For compliance, export logs to S3 with versioning and object lock. Retain for the required period (7 years for some frameworks). Generate reports: total requests inspected, breakdown by action (allowed/blocked/counted), top blocked IPs, most-triggered rules.

Audit workflow:

1. Assessor asks: “Prove your web applications are protected from SQL injection.”
2. You show: Web ACL configuration with OWASP SQLi rule enabled
3. You query logs: SELECT COUNT(*) FROM waf_logs WHERE terminatingRuleId LIKE '%SQLi%' AND action='BLOCK'
4. Result: 45,000 SQL injection attempts blocked in the last quarter
5. Assessor satisfied: control is active and effective

Real-world example: A healthcare SaaS platform needed SOC 2 Type II certification. Auditors required evidence of active web application firewall controls and detailed logs. The platform enabled WAF logging to S3, integrated logs with their Splunk SIEM, and created dashboards showing blocked attack attempts, rule effectiveness, and compliance metrics. During the audit, they provided Splunk reports and S3 log exports. Auditors verified the controls were active and effective. Certification granted.

What you need:

• Logging enabled on all Web ACLs
• Kinesis Data Firehose delivery stream → S3, OpenSearch, or CloudWatch Logs
• S3 bucket lifecycle policies for retention and cost management
• SIEM integration (Splunk, Elastic, AWS Security Lake)
• CloudWatch dashboards and alarms for real-time monitoring
• Automated reports and queries for compliance evidence

Cost warning: High-traffic applications generate massive log volumes. A CloudFront distribution serving 100 million requests per day writes 100 million log entries. At ~1 KB per entry, that’s 100 GB of logs per day = 3 TB per month. Kinesis Data Firehose charges ~$0.029 per GB ingested = $87/month. S3 storage adds ~$70/month (standard tier). Budget for logging costs upfront.

Scenario 6: API Abuse and Scraping Prevention

The problem: Your public API provides product data, pricing, or search functionality. Competitors scrape your API to build competing services. Abusive clients send millions of requests per day, consuming your infrastructure and degrading service for legitimate users. Standard API keys are easily leaked or shared.

How AWS WAF solves it: Deploy rate-based rules at the API route level. Create separate rate limits for different endpoints:

• /api/search: 1,000 requests per 5 minutes per IP
• /api/product/{id}: 500 requests per 5 minutes per IP
• /api/pricing: 100 requests per 5 minutes per IP (sensitive pricing data)

Add Bot Control to detect and block automated scrapers. Combine with custom rules: block requests missing required headers (API version header, custom signature), block known scraper user-agents, enforce geographic restrictions (block traffic from countries where you don’t operate).

Real-world example: A travel API provider faced scraping from hundreds of IPs rotating every few minutes. Rate-based rules alone weren’t enough—scrapers stayed under per-IP thresholds by distributing requests. Bot Control detected the automation patterns (missing JavaScript execution, suspicious request timing). Combining rate-based rules and Bot Control blocked 95% of scraping traffic. Legitimate API usage from customers’ mobile apps remained unaffected.

What you need:

• Rate-based rules scoped to specific API paths
• Bot Control (targeted tier recommended for API protection)
• Custom rules for header validation, user-agent filtering, geo-blocking
• Logging to identify scraping patterns and adjust rules

When NOT to Use AWS WAF

AWS WAF is not a universal solution. Here’s when to choose alternatives:

• Non-HTTP(S) traffic: WAF only inspects HTTP and HTTPS. For SSH, RDP, DNS, database protocols, or custom TCP/UDP applications, use AWS Network Firewall, security groups, or NACLs.
• Volumetric layer 3/4 DDoS: WAF operates at layer 7. It won’t stop a 100 Gbps SYN flood or UDP amplification attack. Use AWS Shield (Standard is free and automatic; Advanced adds DDoS Response Team support).
• Internal-only, low-latency services: If your application runs entirely within a VPC and never touches the internet, WAF adds unnecessary latency and cost. Use VPC security groups and NACLs instead.
• Advanced bot management beyond AWS capabilities: If you need specialized bot detection with device fingerprinting, behavioral analysis across sessions, and multi-CDN support, evaluate third-party bot management platforms (Cloudflare Bot Management, Akamai Bot Manager, DataDome).

Frequently Asked Questions

Can I use WAF to block traffic from specific countries?

Yes. Create a geo-match rule that inspects the request’s source country (based on IP geolocation). Set the action to Block for countries you want to exclude. This is useful for compliance (GDPR, data sovereignty) or reducing attack surface (block traffic from regions where you don’t operate).

How do I protect against zero-day vulnerabilities?

Use AWS Managed Rules—specifically the Known Bad Inputs rule group. AWS updates this rule group within hours when new CVEs or exploits become public. You benefit from AWS threat intelligence and rapid signature deployment without manual intervention. Layer virtual patching: if a CVE affects your application, create a custom rule to block the exploit pattern while you deploy the real patch.

What’s the difference between AWS WAF and third-party Marketplace WAFs?

AWS WAF is a managed service—no instances to run, tight AWS integration, pay-per-request pricing. Marketplace WAFs (Barracuda, Fortinet, Imperva) offer richer features: machine-learning-based detection, data loss prevention, vendor-managed rulesets, 24/7 SOC support. Trade-offs: Marketplace WAFs cost more (licensing + infrastructure), add operational overhead, and require separate management consoles. Start with AWS WAF. Evaluate Marketplace options if you need features AWS WAF doesn’t provide.

Can I automate WAF rule deployment with infrastructure-as-code?

Yes. AWS WAF supports CloudFormation, Terraform, and the AWS CLI. Define your Web ACL, rules, and rule groups as code. Deploy via CI/CD pipelines. Test rule changes in staging environments before promoting to production. This is the recommended approach for large-scale, multi-account deployments.

Conclusion

We explored six core scenarios where AWS WAF delivers measurable protection: blocking OWASP Top 10 exploits on internet-facing web applications and APIs, stopping credential-stuffing and account takeover with rate-based rules and Bot Control, protecting hybrid and on-premises origins through CloudFront edge filtering, enforcing enterprise-wide baseline policies across hundreds of AWS accounts via Firewall Manager, providing detailed request logs for security operations and compliance audits, and preventing API abuse and scraping with granular rate limits and bot detection. In each scenario, the pattern is consistent—deploy managed rules as your baseline, enable logging from day one, use Count mode to validate rules before blocking, tune for your application’s traffic patterns, and integrate with CloudWatch and your SIEM for real-time visibility. Start with the scenario that matches your immediate pain point, prove the value, then expand WAF coverage across your entire AWS footprint.

AWS WAF attached to CloudFront distributions filters malicious HTTP(S) traffic at Amazon’s global edge locations before requests ever reach your origin servers. This edge placement blocks SQL injection, cross-site scripting, bot attacks, and abusive traffic closer to attackers—reducing origin load, improving performance, and protecting hybrid or on-premises origins behind CloudFront’s CDN layer.

Key Takeaways

• CloudFront WAF operates at 450+ global edge locations, inspecting requests milliseconds after they arrive and blocking threats before bandwidth or compute reaches your origin
• Web ACLs created for CloudFront require CLOUDFRONT scope and must be created in the us-east-1 region—this scope cannot be changed later
• CloudFront’s one-click protection flow auto-creates a Web ACL with AWS-managed OWASP rules, IP reputation feeds, and rate limiting; fast to deploy but requires tuning to avoid false positives
• Enabling WAF on a CloudFront distribution unlocks the Security dashboard metrics—without WAF attached, you won’t see blocked request counts or security insights
• Managed rule groups (OWASP Top 10, known bad inputs, bot control) provide continuous updates from AWS threat intelligence; start here, layer custom rules only when needed
• Rate-based rules at the edge throttle or block abusive IPs during login brute-force or API abuse—protects origin capacity and cuts bandwidth costs
• Always enable logging to Kinesis Data Firehose or S3 and run new rules in Count mode first; reviewing logs before switching to Block prevents accidental outages from legitimate traffic matches

Why Edge Protection Matters

When you attach AWS WAF to a CloudFront distribution, inspection happens at the edge—at one of CloudFront’s 450+ points of presence scattered across continents. A request from Tokyo hits a Tokyo edge location. WAF inspects it there. If the request matches a block rule, CloudFront returns a 403 response immediately. The malicious request never crosses the ocean to your origin in us-east-1. Your origin never allocates a thread, never parses the payload, never logs the attack.

This matters for three reasons:

1. Origin load reduction. Blocked requests consume zero origin CPU, memory, or bandwidth. During a layer 7 DDoS attack—thousands of malicious POST requests per second—your origin continues serving legitimate users while CloudFront and WAF absorb the attack at the edge.
2. Latency and performance. Legitimate requests pass through WAF inspection in single-digit milliseconds. Blocked requests terminate at the edge with sub-10ms response times. Users see fast error pages instead of waiting for an overloaded origin to timeout.
3. Bandwidth cost savings. AWS charges for data transfer out of your origin to the internet. Requests blocked at the edge never touch your origin, so you pay CloudFront’s lower edge-to-client transfer rates instead of origin-to-CloudFront plus CloudFront-to-client.

Real-world example: A SaaS platform running behind CloudFront faced credential-stuffing attacks—500,000 login attempts per hour from rotating IPs. Before WAF, origin EC2 instances scaled to 50+ instances to handle the load, costing $3,000/month in compute and bandwidth. After deploying a rate-based rule at the edge (100 requests per 5 minutes per IP on the /login path), CloudFront blocked 95% of abusive traffic. Origin instances dropped to 8. Monthly costs fell to $800.

CloudFront Scope and the us-east-1 Requirement

AWS WAF has two scopes: REGIONAL and CLOUDFRONT. A Web ACL created with REGIONAL scope protects Application Load Balancers and API Gateway endpoints in a single region. A Web ACL created with CLOUDFRONT scope protects CloudFront distributions globally.

Here’s the constraint: CloudFront Web ACLs must be created in us-east-1. This is a fixed requirement—not a best practice, a hard rule. If you try to create a CLOUDFRONT-scoped Web ACL in eu-west-1 via the CLI, the command will fail. The console will force you to select us-east-1.

Why? CloudFront is a global service. Its control plane lives in us-east-1. All CloudFront distributions, certificates (ACM), and associated WAF Web ACLs are managed from that region, even though the distribution itself serves traffic from 450+ edge locations worldwide.

Gotcha: Scope is permanent. You cannot convert a REGIONAL Web ACL to CLOUDFRONT or vice versa. If you create a Web ACL with the wrong scope, you must delete it and recreate it. Plan carefully before you start writing rules.

One-Click Protection: Fast Baseline, Manual Tuning Required

CloudFront’s Security dashboard offers a one-click flow to enable WAF protection. You select your distribution, click “Enable protections,” and CloudFront creates a new Web ACL, attaches AWS-managed rule groups (OWASP Core Rule Set, Amazon IP reputation list), configures rate-based rules, and associates the Web ACL with your distribution. The entire process takes 30 seconds.

This is the fastest way to get baseline protection running. The managed OWASP rules block SQL injection, cross-site scripting, local file inclusion, and remote code execution patterns. The IP reputation list blocks requests from known malicious IPs identified by Amazon’s internal threat intelligence. Rate-based rules throttle clients exceeding configurable thresholds.

But one-click protection is a starting point, not a finish line. Managed rules are tuned for broad applicability across thousands of different applications. Your application is unique. You will see false positives.

Common false positive scenario: A content management system uses JSON POST requests to update page metadata. The OWASP SQL injection rule sees patterns like "id": 1234 in the request body and flags it as a potential SQL injection attempt. Legitimate CMS editors get 403 errors when they try to save content.

The fix: review WAF logs (Kinesis Data Firehose or CloudWatch Logs), identify the specific rule ID causing the block, and create a rule exception or scope-down statement to allow that pattern for your CMS endpoints. This is why you must enable logging and monitor metrics from day one.

Managed Rule Groups: OWASP, Bot Control, and IP Reputation

AWS provides managed rule groups maintained by AWS security teams. These rule groups receive continuous updates—new signatures for emerging exploits, refined regex patterns to reduce false positives, IP reputation feeds updated hourly. You don’t write or maintain the rules. You subscribe to the rule group and AWS keeps it current.

Core managed rule groups for CloudFront:

• AWS Managed Rules OWASP Top 10: Covers SQL injection, XSS, remote file inclusion, local file inclusion, command injection, and other common web exploits. This is your baseline. Enable it on every public-facing application.
• AWS Managed Rules Known Bad Inputs: Blocks requests with patterns known to exploit specific vulnerabilities (e.g., Log4Shell, specific CVEs). Low false-positive rate.
• AWS Managed Rules Amazon IP Reputation List: Blocks IPs identified by Amazon’s threat intelligence as sources of malicious activity—botnets, scanners, attack infrastructure. Updated continuously.
• AWS Managed Rules Bot Control: Detects and categorizes bots. Free tier covers common bot detection (verified bots like Googlebot, unverified bots, likely humans). Targeted bot control (paid) adds granular categories, CAPTCHA challenges, and bot scoring. First 10 million requests per month are free for common bot control.

Each managed rule group consumes Web ACL Capacity Units (WCU). The OWASP rule set uses around 700 WCU. Bot Control uses 50 WCU. Your Web ACL has a default capacity limit of 1,500 WCU. Budget accordingly—if you add too many managed groups or complex custom rules, you’ll hit the limit and won’t be able to add more rules without removing others or requesting a limit increase.

Rate-Based Rules at the Edge

Rate-based rules count requests from a single IP address over a five-minute sliding window. When the count exceeds your threshold, WAF blocks that IP for the duration you specify (minimum 5 minutes, configurable up to 24 hours). Use rate-based rules to protect login endpoints, API routes, and any resource vulnerable to brute-force or volumetric abuse.

At the CloudFront edge, rate limiting is especially powerful. An attacker in Singapore hammering your /api/login endpoint triggers the rate rule at the Singapore edge location. CloudFront blocks subsequent requests from that IP at the edge. Your origin in Virginia never sees them. The attack is contained geographically, and your origin bandwidth stays clean.

Example rate-based rule:

• Threshold: 100 requests in 5 minutes
• Scope: URI path starts with /login
• Action: Block for 10 minutes
• Aggregation key: Source IP

This rule allows 100 login attempts per 5-minute window per IP. Legitimate users rarely exceed that. Credential-stuffing bots routinely send thousands. The first 100 requests pass through. Request 101 triggers a block. For the next 10 minutes, that IP gets 403 responses at the edge.

Tuning tip: Start with a high threshold (500 requests per 5 minutes) in Count mode. Monitor CloudWatch metrics and logs for a week. Identify your 95th percentile legitimate request rate. Set your block threshold at 150–200% of that rate. Move the rule to Block. Monitor for false positives. Adjust down if needed.

Logging and the Security Dashboard

CloudFront’s Security dashboard shows aggregate metrics: total requests, blocked requests, allowed requests, counted requests (rules in Count mode), and top blocking rules. You see charts, you see trends, you can drill into specific time windows.

But the dashboard only appears if you enable AWS WAF on the distribution. No WAF attachment = no security metrics. The console will show a message: “Enable AWS WAF to view security metrics.” This is a hard requirement. You cannot see CloudFront security metrics without a Web ACL attached, even if you have zero rules in the ACL.

Enable logging at the Web ACL level to capture request-level details. Configure a Kinesis Data Firehose delivery stream (recommended for high-volume distributions) or send logs to an S3 bucket or CloudWatch Logs group. Each log entry includes:

• terminatingRuleId: which rule matched and triggered the action
• action: ALLOW, BLOCK, COUNT, CAPTCHA
• httpRequest: client IP, headers, URI, method, query string
• Timestamp, Web ACL ID, rule group details

When you see a spike in blocked requests in the Security dashboard, query your logs for that time window, filter by action: BLOCK, and inspect terminatingRuleId. You’ll see exactly which rule fired and what the HTTP request looked like. This is how you identify false positives and tune rules.

Warning: High-traffic distributions generate massive log volumes. A distribution serving 10 million requests per day writes 10 million log entries. At 1 KB per entry, that’s 10 GB of logs per day. Kinesis Data Firehose charges per GB ingested. S3 charges for storage. Plan retention policies and budget accordingly. Consider sampling—log only blocked requests, or sample 10% of allowed traffic.

Hybrid and On-Premises Origin Protection

CloudFront can front on-premises origins. Point your CloudFront distribution to your data center’s public IP or hostname (or use AWS Direct Connect for private connectivity). Attach a WAF Web ACL to the distribution. Now WAF inspects all traffic at the CloudFront edge before forwarding clean requests to your on-prem origin.

This architecture protects legacy applications and hybrid environments without touching the origin servers. Your on-prem firewall, application server, and database never see malicious payloads. CloudFront and WAF absorb the attack at the edge. Your internet circuit bandwidth stays clean. Your origin handles only legitimate, WAF-approved traffic.

Architecture pattern:

1. User requests https://www.example.com → DNS resolves to CloudFront
2. Request hits CloudFront edge location → WAF inspects
3. If blocked: CloudFront returns 403, origin never contacted
4. If allowed: CloudFront fetches from origin (on-prem server via public IP or Direct Connect)
5. CloudFront caches response, serves subsequent requests from cache

You get edge caching and edge security. Origin load drops by 80–90% (typical cache hit ratio). Attack traffic never reaches your data center.

Creating and Associating a Web ACL (CLI Example)

Here’s the minimal CLI workflow to create a CloudFront-scoped Web ACL and attach it to a distribution.

# Step 1: Create a Web ACL (CloudFront scope, us-east-1 required)
aws wafv2 create-web-acl \
  --name "cloudfront-edge-protection" \
  --scope CLOUDFRONT \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName="CloudFrontWAF" \
  --region us-east-1 \
  --description "Edge WAF for CloudFront distribution"

# Output will include the Web ACL ARN. Copy it.

# Step 2: Associate the Web ACL with your CloudFront distribution
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:global/webacl/cloudfront-edge-protection/abcd1234-... \
  --resource-arn arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE

# Step 3: Verify association
aws wafv2 list-resources-for-web-acl \
  --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:global/webacl/cloudfront-edge-protection/abcd1234-...

# Expected output: your distribution ARN in the list

After association, CloudFront begins sending traffic through the Web ACL. With --default-action Allow={} and no rules yet, all traffic passes. Add managed rule groups or custom rules to start filtering.

Count Mode: Test Before You Block

Every WAF rule supports three primary actions: Allow, Block, and Count. Count mode logs the match but takes no enforcement action. The request proceeds as if the rule didn’t exist, but WAF records the match in CloudWatch metrics and logs.

Use Count mode to test new rules safely in production. You enable a managed OWASP rule group in Count mode. Traffic flows normally. You watch metrics for a week. If you see 50,000 counted requests and zero customer complaints, the rule is working—it’s matching actual attack patterns, not legitimate traffic. Flip the action to Block. If you see counted requests and simultaneous support tickets about broken functionality, you’ve found a false positive. Tune the rule before blocking.

Workflow:

1. Add new rule or managed rule group with action = Count
2. Enable logging to Kinesis or S3
3. Monitor CloudWatch CountedRequests metric for 3–7 days
4. Query logs: filter for action: COUNT and inspect terminatingRuleId and httpRequest
5. If matches look malicious (SQL injection patterns, scanner user-agents): change action to Block
6. If matches include legitimate traffic: create rule exceptions or scope-down statements, re-test in Count mode

Never skip Count mode on a production application. The cost of a false positive—blocking legitimate users—far exceeds the time investment to validate rules first.

Common Mistakes

Creating the Web ACL in the wrong region. You create a Web ACL in eu-central-1, try to attach it to CloudFront, and it doesn’t appear in the console dropdown. CloudFront Web ACLs must be in us-east-1. Delete and recreate.

Using REGIONAL scope for CloudFront. You create a REGIONAL Web ACL and try to associate it with a CloudFront distribution. The API call fails. Scope is permanent—you cannot change it. Create a new Web ACL with CLOUDFRONT scope.

Enabling one-click protection and ignoring tuning. One-click gives you instant baseline protection, but managed rules trigger false positives on many custom applications. If you don’t enable logging and monitor for false positives, you’ll block legitimate users and blame WAF for breaking your app.

Not enabling logging. Without logs, you cannot debug blocks or tune rules. You’re flying blind. Enable Kinesis Data Firehose or S3 logging from day one.

Hitting WCU limits. You add five managed rule groups and a dozen custom regex rules. Total WCU exceeds 1,500. The console refuses to save. You cannot add more rules. Either simplify existing rules, remove a managed group, or request a limit increase. Plan WCU budget before you start adding rules.

Frequently Asked Questions

Can I use the same Web ACL on multiple CloudFront distributions?

Yes. A single CLOUDFRONT-scoped Web ACL can be associated with multiple CloudFront distributions. This reduces management overhead—one set of rules protects all your distributions. However, if distributions serve different applications with different traffic patterns, consider separate Web ACLs to allow application-specific tuning.

Does WAF at the edge add latency to requests?

Minimal. AWS reports single-digit millisecond inspection overhead for typical rule sets. Managed OWASP rules add ~2–5ms. Rate-based rules add <1ms. Complex regex patterns in custom rules can add more. For most applications, WAF latency is negligible compared to origin response time and network transit.

How do I protect a CloudFront distribution with a custom domain (CNAME)?

Configure your CloudFront distribution with an alternate domain name (CNAME) and attach an ACM certificate. Attach your WAF Web ACL to the distribution as usual. WAF inspects all requests to the distribution, regardless of whether users access it via the CloudFront domain (d111111abcdef8.cloudfront.net) or your custom domain (www.example.com). The domain name is irrelevant to WAF—it inspects the HTTP request reaching the distribution.

What happens if I detach the Web ACL from a CloudFront distribution?

Traffic flows normally—no blocking, no inspection, no logging. The distribution serves all requests. Security dashboard metrics disappear. If you had rules blocking attacks, those attacks now reach your origin. Only detach a Web ACL if you’re replacing it with another or intentionally removing protection (not recommended for production).

Conclusion

We covered how AWS WAF on CloudFront provides edge protection by inspecting HTTP(S) traffic at 450+ global locations before requests reach your origin. You learned that CloudFront Web ACLs require CLOUDFRONT scope and must be created in us-east-1, that one-click protection offers a fast baseline with AWS-managed OWASP and IP reputation rules but requires tuning for your application, and that rate-based rules at the edge throttle abusive traffic and protect origin capacity. Enabling logging to Kinesis Data Firehose or S3 and running new rules in Count mode first prevents false positives and outages. The Security dashboard unlocks only when WAF is attached, and hybrid architectures benefit from edge filtering that keeps malicious payloads away from on-premises origins. Start with managed rule groups, enable logging, test in Count mode, monitor metrics, tune for your traffic patterns, and you’ll have robust edge protection running in days—not weeks.

AWS offers three distinct network security services that protect different layers of your infrastructure: WAF filters application-layer HTTP(S) traffic, Shield defends against volumetric DDoS attacks at layers 3 and 4, and Network Firewall inspects VPC traffic for threats across all network layers. You need to understand which layer you’re protecting—and often you’ll use more than one—to build effective defense in depth.

Key Takeaways

• AWS WAF operates at layer 7 (application) and inspects HTTP(S) requests for web exploits like SQL injection and XSS; attach it to CloudFront, ALB, or API Gateway
• AWS Shield protects against layers 3 and 4 volumetric DDoS attacks (SYN floods, UDP reflection); Shield Standard is free and automatic, Shield Advanced adds DDoS response team support
• AWS Network Firewall is a stateful layer 3–7 firewall for VPC traffic that inspects all protocols, not just HTTP—use it for east-west traffic and egress filtering
• WAF and Shield work together: Shield absorbs the bandwidth flood, WAF blocks the malicious application-layer requests that slip through
• Network Firewall and WAF serve different scopes: Network Firewall sits inside your VPC and sees all traffic flows; WAF sits in front of specific web services
• You cannot replace one with another—they’re complementary, not alternatives

What Each Service Actually Does

AWS WAF: Application-Layer Web Filtering

AWS WAF inspects HTTP and HTTPS requests. It attaches to three AWS resources: CloudFront distributions, Application Load Balancers, and API Gateway APIs. Every request passes through a Web ACL—a set of rules that match on IP addresses, headers, URIs, query strings, or request bodies. When a rule matches, WAF allows, blocks, counts, or challenges the request.

WAF sees inside the HTTP payload. It can detect SQL injection patterns in a form submission, block cross-site scripting in a query parameter, or rate-limit clients hammering your login endpoint. It operates at layer 7—the application layer. It knows nothing about TCP handshakes or UDP packets. If the traffic isn’t HTTP or HTTPS, WAF won’t touch it.

AWS Shield: Volumetric DDoS Protection

AWS Shield protects against distributed denial-of-service attacks at the network and transport layers—layers 3 and 4. Think SYN floods, UDP amplification, DNS reflection. These attacks don’t care about your application logic. They just flood your infrastructure with packets until legitimate traffic can’t get through.

Shield Standard is enabled by default on CloudFront and Route 53 at no extra cost. It absorbs most common DDoS attacks automatically. You don’t configure it. You don’t see its rules. It just works in the background, scrubbing malicious traffic before it reaches your origin.

Shield Advanced costs $3,000 per month per organization and adds:

• Protection for Elastic IPs, Application Load Balancers, Network Load Balancers, and Global Accelerator endpoints
• 24/7 access to the AWS DDoS Response Team (DRT)
• Advanced real-time metrics and attack diagnostics
• Cost protection—AWS credits back charges incurred from scaling during a DDoS attack

Shield doesn’t inspect application payloads. It can’t tell the difference between a legitimate POST request and one carrying a SQL injection. It only cares about packet volume and transport-layer anomalies.

AWS Network Firewall: Stateful VPC Traffic Inspection

AWS Network Firewall is a managed stateful firewall for your VPC. It sits at the edge of your VPC or between subnets and inspects all traffic—inbound, outbound, and east-west. Unlike WAF, which only sees HTTP(S) attached to specific services, Network Firewall sees everything: SSH, RDP, database connections, custom protocols, DNS queries.

You define rule groups with allow/deny logic, domain filtering, intrusion prevention signatures (Suricata-compatible), and protocol-specific inspection. Network Firewall enforces these rules on every packet crossing the inspection boundary. It’s stateful, so it tracks connections and can block return traffic for sessions you never initiated.

Use Network Firewall when you need:

• Centralized egress filtering—blocking outbound connections to known-bad domains or IPs
• East-west traffic inspection between VPCs or between application tiers
• IDS/IPS signatures for non-HTTP protocols
• Fine-grained control over which internal services can talk to each other

Network Firewall does not attach to CloudFront or ALB. It lives in your VPC routing path. You send traffic to it via route tables and gateway endpoints.

Layer-by-Layer Breakdown

Understanding which OSI layer each service protects clarifies when to use what.

• Layer 7 (Application): AWS WAF. Inspects HTTP(S) requests, headers, bodies. Blocks web exploits, bot traffic, application-layer DDoS.
• Layers 3–4 (Network & Transport): AWS Shield. Absorbs SYN floods, UDP reflection, volumetric attacks. No configuration required for Standard; Advanced adds DRT and cost protection.
• Layers 3–7 (Full stack): AWS Network Firewall. Stateful inspection of all IP traffic in your VPC. Protocol-agnostic, works for SSH, databases, custom apps, and HTTP if needed.

Real-world scenario: An attacker launches a multi-vector attack. They flood your ALB with 50 Gbps of SYN packets (layer 4) and simultaneously send thousands of HTTP requests with SQL injection payloads (layer 7). Shield absorbs the SYN flood before it saturates your network. WAF inspects the HTTP requests that make it through and blocks the injection attempts. Neither service alone stops both attack vectors.

When to Use AWS WAF

Choose AWS WAF when you need to protect internet-facing web applications and APIs from application-layer threats.

• You’re running a web app behind CloudFront, ALB, or API Gateway
• You need to block SQL injection, cross-site scripting, or other OWASP Top 10 exploits
• You want to rate-limit specific endpoints (login pages, API routes) to prevent brute-force or credential stuffing
• You need bot detection and mitigation—distinguishing Googlebot from malicious scrapers
• You want centralized logging of HTTP requests for security analytics and compliance

Do not use WAF for:

• Non-HTTP traffic (SSH, RDP, DNS, database protocols)
• Volumetric layer 3/4 DDoS defense—that’s Shield’s job
• Filtering traffic between VPCs or internal subnets—that’s Network Firewall

When to Use AWS Shield

Use Shield Standard (automatic and free) for baseline DDoS protection on CloudFront and Route 53. You don’t opt in—it’s already running.

Upgrade to Shield Advanced when:

• You need DDoS protection for Elastic IPs, ALBs, NLBs, or Global Accelerator (Standard only covers CloudFront and Route 53)
• Your application is mission-critical and downtime from a DDoS attack costs more than $3,000/month
• You want 24/7 access to the AWS DDoS Response Team to help mitigate sophisticated attacks
• You need cost protection—AWS credits back scaling charges incurred during a verified DDoS event
• You require advanced metrics, attack forensics, and integration with AWS Firewall Manager for centralized policy

Shield does not:

• Inspect HTTP payloads or block application-layer attacks
• Provide stateful firewall rules or egress filtering
• Protect non-AWS resources (on-premises servers, other cloud providers)

Gotcha: Shield Advanced’s cost protection only applies if AWS confirms the traffic spike was a DDoS attack. Normal traffic surges from a product launch or viral content won’t trigger credits. Read the fine print.

When to Use AWS Network Firewall

Choose Network Firewall when you need to inspect and filter VPC traffic that WAF cannot see.

• You want to control egress—blocking outbound connections to known-bad domains, cryptomining pools, or entire geographic regions
• You need east-west filtering between application tiers, between VPCs, or across Transit Gateway attachments
• You require IDS/IPS signatures for protocols other than HTTP (SSH brute-force detection, database exploit signatures)
• You want centralized logging and inspection for all VPC traffic in one place, not just web traffic
• You’re replacing third-party virtual firewall appliances (Palo Alto, Fortinet) with a managed AWS service

Do not use Network Firewall for:

• Protecting CloudFront distributions—WAF is the right tool
• Layer 3/4 DDoS mitigation—Shield handles that
• Deep HTTP payload inspection and web exploit blocking—WAF’s managed rules do this better and more efficiently

Network Firewall charges per firewall endpoint per hour plus data processing fees. For high-throughput workloads, costs add up fast. Budget accordingly and use it where you genuinely need stateful inspection across all protocols.

How They Work Together

Defense in depth means layering these services, not choosing one.

Common architecture: Internet-facing web application

1. Shield Standard (automatic): Absorbs volumetric DDoS at the CloudFront edge. Scrubs SYN floods, UDP reflection, DNS amplification.
2. AWS WAF (attached to CloudFront): Inspects HTTP requests. Blocks SQL injection, XSS, malicious bots, and rate-limits abusive clients. Managed OWASP rules provide baseline protection.
3. CloudFront → ALB → EC2/ECS: Legitimate traffic that passes WAF reaches your Application Load Balancer. Security groups limit which ports and IPs can connect.
4. Network Firewall (optional, in VPC): Inspects outbound traffic from your application tier. Blocks connections to known-bad IPs, filters DNS queries, logs all egress flows.

Shield stops the flood. WAF stops the application-layer exploits. Network Firewall stops your compromised instance from phoning home to a command-and-control server.

Example: Multi-vector attack mitigation

An attacker sends 100 Gbps of spoofed UDP traffic to your CloudFront distribution (layer 3/4 attack) and simultaneously launches 50,000 HTTP requests per second with crafted payloads targeting a known vulnerability in your CMS (layer 7 attack).

• Shield scrubs the UDP flood at the edge. CloudFront never sees it. Your origin bandwidth stays clean.
• WAF inspects the HTTP flood. Managed OWASP rules detect the CMS exploit patterns. Rate-based rules throttle the source IPs. Legitimate users experience no impact.

Without both, you’re exposed. Shield alone lets the exploit through. WAF alone gets overwhelmed by the volumetric flood.

Decision Matrix

Use this table to quickly identify which service(s) you need.

Your requirement	Use this	Not this
Block SQL injection in web forms	AWS WAF	Shield, Network Firewall
Absorb 50 Gbps SYN flood	Shield (Standard or Advanced)	WAF, Network Firewall
Filter outbound SSH from EC2 instances	Network Firewall	WAF, Shield
Rate-limit API login endpoint	AWS WAF	Shield, Network Firewall
Inspect east-west database traffic	Network Firewall	WAF, Shield
Detect and block bots scraping your site	AWS WAF (Bot Control)	Shield, Network Firewall
Protect against DNS amplification attack	Shield Standard (automatic)	WAF, Network Firewall
Block outbound connections to known-bad domains	Network Firewall	WAF, Shield
Get DDoS cost protection and DRT support	Shield Advanced	WAF, Network Firewall

Cost Considerations

AWS WAF: Pay per Web ACL ($5/month), per rule ($1/month), and per million requests ($0.60). Managed rule groups have additional fees. Bot Control’s basic tier is free for the first 10 million requests per month. Logging to Kinesis or S3 adds data transfer and storage costs.

AWS Shield Standard: Free. Enabled automatically on CloudFront and Route 53.

AWS Shield Advanced: $3,000/month per organization, plus data transfer fees. Includes cost protection and DRT access. Expensive, but justifiable for mission-critical apps where downtime costs exceed the subscription fee.

AWS Network Firewall: Pay per firewall endpoint per hour (~$0.395/hour per AZ) plus data processing ($0.065 per GB). A multi-AZ deployment processing 10 TB/month costs roughly $1,000/month. High-throughput workloads (100+ TB) can run into thousands per month in data processing fees alone.

Start with Shield Standard (free) and WAF with managed rules (low cost, high value). Add Shield Advanced only if you’ve experienced costly DDoS incidents or run revenue-critical services. Deploy Network Firewall when security groups and NACLs are insufficient for your egress or east-west filtering requirements.

Common Mistakes

Assuming WAF protects against DDoS. WAF helps with application-layer DDoS (HTTP floods), but it won’t stop a 100 Gbps SYN flood. That’s Shield’s job. Use both.

Deploying Network Firewall for HTTP filtering. Network Firewall can inspect HTTP, but WAF does it better, faster, and cheaper. Use Network Firewall for non-HTTP protocols and VPC-level inspection. Use WAF for web traffic attached to CloudFront, ALB, or API Gateway.

Paying for Shield Advanced without using it. Shield Advanced requires you to associate protected resources and configure health checks. If you subscribe but never associate your ALB or Elastic IP, you’re paying $3,000/month for nothing. The DRT can’t help if they don’t know what to protect.

Not enabling logging. All three services support logging. Without logs, you can’t tune WAF rules, investigate DDoS events, or prove compliance. Enable CloudWatch, Kinesis, or S3 logging from day one.

Frequently Asked Questions

Can I use Network Firewall instead of WAF for my web application?

Technically yes—Network Firewall can inspect HTTP traffic—but you shouldn’t. WAF is purpose-built for web exploits with managed OWASP rules, bot detection, and pay-per-request pricing that scales efficiently. Network Firewall charges per GB processed and lacks WAF’s application-specific protections. Use Network Firewall for VPC-level filtering and WAF for HTTP(S) services.

Do I need Shield Advanced if I already have WAF?

It depends on your risk tolerance and budget. WAF protects against application-layer attacks. Shield Advanced adds layer 3/4 DDoS protection for ALB, NLB, Elastic IPs, and Global Accelerator, plus 24/7 DRT support and cost protection. If a DDoS outage costs you more than $36,000/year, Shield Advanced pays for itself. If your app runs behind CloudFront only and you’re comfortable with Shield Standard’s automatic protections, skip Advanced.

Can Network Firewall replace security groups and NACLs?

No. Security groups and NACLs are stateful/stateless layer 3/4 firewalls that run at the instance and subnet level with no additional cost. Network Firewall adds stateful inspection, IDS/IPS signatures, and centralized logging across your VPC. Use security groups for basic instance-level allow/deny rules. Add Network Firewall when you need deep inspection, domain filtering, or centralized egress control across multiple VPCs.

How do I protect an on-premises web server with AWS WAF?

Place CloudFront in front of your on-premises origin (via public IP or AWS Direct Connect). Attach a WAF Web ACL to the CloudFront distribution. WAF inspects traffic at the CloudFront edge before forwarding clean requests to your data center. This works well for hybrid architectures but requires CloudFront as the entry point—WAF cannot attach directly to on-prem servers.

Conclusion

We covered the core differences between AWS WAF, Shield, and Network Firewall. WAF operates at layer 7 to block web exploits in HTTP(S) traffic attached to CloudFront, ALB, and API Gateway. Shield defends against volumetric layers 3 and 4 DDoS attacks—Standard is automatic and free, Advanced adds DRT support and cost protection for $3,000/month. Network Firewall provides stateful inspection for all VPC traffic across layers 3 through 7, ideal for egress filtering and east-west traffic control. You cannot replace one with another—they’re complementary layers of defense. Start with Shield Standard and WAF with managed rules for internet-facing apps, add Shield Advanced if DDoS downtime costs justify the subscription, and deploy Network Firewall when security groups and NACLs are insufficient for your VPC-level filtering and IDS/IPS needs.

AWS WAF is Amazon’s managed web application firewall that protects your applications from common web exploits at layer 7. You can deploy it natively with CloudFront, Application Load Balancer, and API Gateway—or choose third-party alternatives from AWS Marketplace when you need vendor-specific features like advanced ML detection or next-generation firewall capabilities.

Key Takeaways

• AWS WAF inspects HTTP(S) traffic at the application layer to block OWASP Top 10 threats, bots, and volumetric abuse before they reach your origin
• You attach Web ACLs to CloudFront (global edge), Application Load Balancer, or API Gateway (regional)—scope matters and cannot be changed after creation
• Managed rule groups give you instant protection against common attacks; start there, then layer minimal custom rules only when needed
• Always enable logging to Kinesis Data Firehose or CloudWatch and run new rules in Count mode first to catch false positives before blocking
• Rate-based rules and Bot Control significantly reduce origin load during abuse events and credential-stuffing attacks
• AWS Marketplace WAF vendors (Barracuda, Fortinet, Palo Alto, Imperva) offer richer enterprise features—ML detection, NGFW capabilities, managed service options—at the cost of licensing and operational overhead
• Use AWS Firewall Manager when you operate multiple accounts and need centralized, consistent policy enforcement

What AWS WAF Actually Does

AWS WAF sits in front of your web applications and APIs. Every HTTP or HTTPS request passes through a set of rules you define—called a Web ACL. Each rule inspects parts of the request: source IP, headers, URI, query strings, or the body itself. When a request matches a rule, WAF takes an action: allow, block, count, or challenge.

The service integrates natively with three AWS resources: CloudFront distributions (for global, edge protection), Application Load Balancers (regional), and API Gateway REST and HTTP APIs (regional). You create a Web ACL, attach it to one of these resources, and traffic filtering begins immediately.

Gotcha: Scope is permanent. A Web ACL created with CLOUDFRONT scope protects only CloudFront distributions and must be created in us-east-1. A REGIONAL Web ACL protects ALB and API Gateway resources in a single region. You cannot convert scope—you must recreate the ACL if you picked wrong.

Core Components: Web ACLs, Rules, and Rule Groups

A Web ACL is the top-level container. It holds an ordered list of rules and a default action (allow or block) for requests that don’t match any rule.

Rules define match conditions and actions. You can write custom rules (IP sets, regex patterns, size constraints, geo-blocks) or reference managed rule groups. Each rule consumes Web ACL Capacity Units (WCU)—think of WCU as a budget. Complex regex rules and large rule groups eat more WCU. Every Web ACL has a maximum capacity (default 1,500 WCU). Hit the limit and you cannot add more rules.

Rule groups bundle multiple rules. AWS provides managed rule groups: the OWASP Core Rule Set, known bad inputs, IP reputation lists, bot control, and more. These are continuously updated by AWS. You can also create custom rule groups to share rules across Web ACLs or accounts.

Rule evaluation is top-down. The first matching rule wins. If you place a broad allow rule before a specific block rule, the allow wins. Order matters.

Managed Rules vs. Custom Rules: Where to Start

Starting with AWS Managed Rules is a good idea. They cover the OWASP Top 10 (SQL injection, cross-site scripting, file inclusion), IP reputation feeds maintained by Amazon, and Linux/Windows-specific exploits. You get continuous updates without lifting a finger.

CloudFront offers a one-click flow in the Security dashboard. It creates a Web ACL, attaches baseline protections (OWASP rules, IP reputation, rate limiting), and associates it with your distribution. Fast, but not tuned to your application. You will see false positives.

Real-world lesson: I once enabled the OWASP Core Rule Set on a legacy CMS without testing. Legitimate admin POST requests with JSON payloads triggered the SQL injection rule. The CMS locked out editors. Always run new rules in Count mode first—WAF logs the match but takes no action. Review CloudWatch metrics and Kinesis logs for a few days, create exceptions if needed, then switch to Block.

Custom rules shine when you have application-specific threats: blocking a known attack signature in your API, rate-limiting a specific endpoint, or allowing traffic only from your corporate IP ranges. Keep custom rules minimal. Every regex you add increases WCU and maintenance burden.

Rate-Based Rules and Bot Control

Rate-based rules count requests from a single IP over a five-minute window. When the count exceeds your threshold, WAF blocks that IP for the duration you specify (minimum 5 minutes). Use this for login endpoints, API routes, and any resource vulnerable to brute-force or scraping.

Bot Control is a managed rule group that classifies traffic: verified bots (Googlebot, Bingbot), unverified bots, and likely humans. You can allow verified bots, challenge unknowns with CAPTCHA, and block the rest. AWS offers a free tier: 10 million requests per month for common bot detection. Targeted bot control (more granular categories and signals) costs extra.

Combine rate rules and bot control to cut malicious traffic by orders of magnitude. In one public-sector case study from AWS Marketplace, a Barracuda WAF deployment blocked tens of thousands of attacks immediately after deployment—most were automated bot scans and credential-stuffing attempts.

Logging, Metrics, and the Tuning Loop

AWS WAF without logging is flying blind. You must enable request logging—either to Kinesis Data Firehose (recommended for high volume), an S3 bucket, or CloudWatch Logs. Each log entry includes the matching rule ID, the action taken, and the full HTTP request metadata (IP, headers, URI, body sample).

CloudWatch metrics give you aggregate counts: AllowedRequests, BlockedRequests, CountedRequests. Set alarms for spikes. A sudden increase in blocked requests might be an attack—or a broken deployment that trips your own rules.

Warning: CloudFront’s Security dashboard will not show WAF metrics unless you enable a Web ACL on the distribution. You’ll see “Enable AWS WAF to view security metrics.” Don’t assume silence means safety.

The tuning loop is simple: deploy rules in Count mode → collect logs → identify false positives → create rule exceptions or scope statements → promote to Block → monitor → repeat. Budget at least two weeks for initial tuning on a production application.

AWS Firewall Manager: Central Policy for Multi-Account Environments

If you manage multiple AWS accounts under Organizations, Firewall Manager lets you create and enforce WAF policies across all accounts and resources from a single pane. You define a policy (a Web ACL template), apply it to organizational units or tags, and Firewall Manager automatically associates it with matching CloudFront distributions, ALBs, or API Gateways.

This is powerful for compliance and governance. Security teams set baseline protections; application teams can layer additional rules on top but cannot remove the baseline. It does add overhead—you need to design policies carefully to avoid breaking individual workloads.

AWS Marketplace WAF Alternatives: When and Why

AWS Marketplace lists third-party WAF and next-generation firewall solutions: Barracuda CloudGen WAF, Fortinet FortiWeb Cloud, Palo Alto VM-Series, Imperva SecureSphere, Check Point CloudGuard, and Juniper vSRX. These vendors offer features AWS WAF does not: machine-learning-driven threat detection, data-loss prevention, hybrid on-premises and cloud management, and vendor-managed rulesets with 24/7 SOC support.

Choose a Marketplace WAF when:

• You need ML-enhanced detection that adapts to zero-day exploits faster than signature updates
• You require next-gen firewall capabilities (deep packet inspection, SSL decryption, intrusion prevention) in the same appliance
• Your organization already has a vendor relationship and wants consistent tooling across cloud and on-prem
• Procurement timelines favor Marketplace subscriptions over custom contract negotiations

Trade-offs are real. You pay subscription or instance fees on top of AWS infrastructure costs. You introduce another management surface—vendor consoles, APIs, update cycles. You may need to size EC2 instances or containers yourself (for AMI/VM deployments). And you lose some of the tight AWS integration: CloudFormation support may be limited, and you’ll likely manage logs and metrics separately.

Practical advice: Start with AWS WAF and managed rules. Prove the baseline works. If you hit a wall—false positives you can’t tune away, threats your rules can’t catch, or operational overhead that scales poorly—run a proof-of-concept with one or two Marketplace vendors. Test detection fidelity, false-positive rates, latency impact, and day-two operational burden. Make the call with data.

Common Pitfalls and How to Avoid Them

Wrong scope. Creating a REGIONAL Web ACL and trying to attach it to CloudFront fails silently in the console—you just won’t see the ACL in the CloudFront association dropdown. Always confirm scope before you build rules.

No association. A Web ACL with perfect rules does nothing if it’s not attached to a resource. Use aws wafv2 list-resources-for-web-acl --web-acl-arn <arn> to verify associations. An empty list means your WAF is decorative.

Skipping Count mode. Enabling aggressive managed rules directly in Block mode will cause outages. Your legitimate traffic will get blocked. Run Count mode, analyze logs, tune, then block.

Ignoring WCU. Adding too many complex rules or large managed rule groups pushes you past the 1,500 WCU default limit. The console will reject your changes with a cryptic error. Check Capacity in the Web ACL details and simplify or remove rules before adding more.

No logging. Without logs, you cannot investigate blocked requests or tune rules. Enable logging from day one. Send to Kinesis Data Firehose if you handle significant traffic; S3 or CloudWatch Logs work for smaller deployments.

Frequently Asked Questions

Can AWS WAF protect on-premises applications?

Not directly. AWS WAF attaches only to CloudFront, ALB, and API Gateway. However, you can place CloudFront in front of an on-premises origin (via public IP or AWS Direct Connect). WAF inspects traffic at the CloudFront edge before forwarding to your data center. This works well for hybrid architectures.

What’s the difference between AWS WAF and AWS Shield?

AWS WAF operates at layer 7 (HTTP/HTTPS) and inspects application-layer requests. AWS Shield protects against layer 3 and 4 volumetric DDoS attacks (SYN floods, UDP reflection). Shield Standard is free and automatic for CloudFront and Route 53. Shield Advanced adds cost but includes DDoS response team support and cost protection. Use both together for defense in depth.

How much does AWS WAF cost?

You pay per Web ACL ($5/month), per rule ($1/month), and per million requests processed ($0.60/million as of this writing). Managed rule groups have additional fees—check AWS pricing. Bot Control’s common tier is free for the first 10 million requests per month; targeted bot control costs extra. Logging to Kinesis or S3 incurs separate data transfer and storage charges.

Can I use the same Web ACL across multiple CloudFront distributions?

Yes. A single Web ACL can be associated with multiple resources—CloudFront distributions, ALBs, or API Gateways—as long as they all match the ACL’s scope (CLOUDFRONT or REGIONAL) and region (for REGIONAL ACLs). This saves cost and simplifies management.

How do I test WAF rules safely in production?

Set the rule action to Count instead of Block. WAF logs the match but allows the request through. Monitor metrics and logs for a few days. If you see legitimate traffic matching, create exceptions or refine the rule. Once confident, change the action to Block.

Conclusion

We covered how AWS WAF inspects HTTP(S) traffic at the application layer using Web ACLs, rules, and managed rule groups. You learned that scope (CLOUDFRONT vs. REGIONAL) is permanent and must match your target resources, that managed rules provide a fast baseline for OWASP and bot threats, and that enabling logging and using Count mode first prevents painful outages from false positives. Rate-based rules and Bot Control cut abusive traffic before it hits your origin. AWS Firewall Manager extends WAF policies across multiple accounts for centralized governance. When you need advanced ML detection, NGFW features, or vendor-managed services, AWS Marketplace offers third-party alternatives—at the cost of licensing and operational complexity. Start with AWS WAF, enable logging, tune your rules, and upgrade to Marketplace solutions only when proven gaps justify the investment.

Amazon WAF is a managed web application firewall that protects your web applications and APIs from common exploits like SQL injection, cross-site scripting, and bot attacks. It works by inspecting HTTP(S) requests against configurable rules before they reach your origin servers, filtering malicious traffic at Amazon CloudFront edges, Application Load Balancers, or API Gateways.

Key Takeaways

• AWS WAF protects web applications from OWASP Top 10 threats, malicious bots, and layer 7 DDoS attacks by inspecting HTTP(S) requests at the application layer
• You can deploy WAF at CloudFront (edge/global), Application Load Balancer, or API Gateway depending on where you need protection
• Web ACLs, rules, and rule groups are the core building blocks—start with AWS-managed rule groups, then add custom rules as needed
• Always test new rules in count mode first and review CloudWatch logs before switching to block mode to avoid false positives
• Rate-based rules and bot control features help you throttle abusive traffic and mitigate automated attacks
• Placing WAF at CloudFront edges blocks threats before they reach your origin, reducing load and improving performance

What AWS WAF Does

AWS WAF sits between your users and your application, inspecting every HTTP or HTTPS request. Think of it as a bouncer at the door who checks ID before anyone gets in.

The service evaluates requests against rules you define in Web Access Control Lists (Web ACLs). Each rule looks at specific parts of the request—IP address, headers, URI path, query strings, or the request body. When a request matches a rule, WAF takes action: allow it through, block it, count it for monitoring, or challenge the user with a CAPTCHA.

Here’s what makes it useful: WAF handles the threats that traditional network firewalls miss. A network firewall can block port 80 traffic, but it won’t catch a SQL injection hidden in a form submission. WAF works at layer 7, understanding the application protocol itself.

Where You Can Deploy It

You attach AWS WAF to three types of resources:

• Amazon CloudFront — Your CDN distributions. This is the edge deployment option, filtering traffic at AWS edge locations closest to your users globally.
• Application Load Balancer — Regional deployment. Protects applications behind your ALBs in a specific AWS region.
• API Gateway — Also regional. Secures your REST APIs and HTTP APIs.

The choice matters. Deploy at CloudFront when you want global, low-latency protection that stops attacks before they consume your origin bandwidth. Deploy at ALB or API Gateway when you need region-specific controls or don’t use CloudFront.

Gotcha: You can only associate one Web ACL per resource. If you try to attach a second one, the new ACL replaces the old one—no merging, no warnings.

Web ACLs, Rules, and Rule Groups

A Web ACL is your policy document. It contains an ordered list of rules that WAF evaluates top-to-bottom. The first matching rule wins.

Rules define the match conditions and actions. You can write custom rules that check for specific patterns or behaviors. A simple rule might block all requests from a specific IP range. A complex rule might inspect the request body for SQL keywords and block only POST requests to /login that match.

Rule groups are collections of rules you can reuse. AWS provides managed rule groups maintained by the AWS security team and AWS Marketplace sellers. These cover common protections like the OWASP Top 10, known bad inputs, and IP reputation lists. You add them to your Web ACL with one click.

Start with managed rule groups. They give you baseline protection immediately and AWS updates them as new threats emerge. Then layer in custom rules for your application’s specific logic—rate limiting on your API endpoints, geo-blocking, or header validation.

Managed Rules and OWASP Coverage

AWS offers pre-built managed rule groups that you can enable without writing a single line of configuration. The Core Rule Set (CRS) covers OWASP Top 10 vulnerabilities: SQL injection, cross-site scripting, local file inclusion, and more.

There’s also a Known Bad Inputs rule group that blocks requests with patterns associated with vulnerability exploitation, and an IP Reputation list that blocks requests from IPs known for malicious activity.

Bot control is a separate managed offering. AWS provides a free tier that identifies and blocks common bots, and a paid tier with more sophisticated bot detection using machine learning and browser fingerprinting. The free tier covers 10 million bot control requests per month.

Real-world note: Managed rules are aggressive by default. When I enabled the OWASP CRS on a legacy PHP application, legitimate admin dashboard requests got blocked because they contained patterns that looked like path traversal attacks. Always test in count mode first.

Rate-Based Rules and DDoS Mitigation

Rate-based rules count requests from a single IP address over a five-minute window. When an IP exceeds your threshold, WAF blocks subsequent requests from that IP until the rate drops.

This is your first line of defense against layer 7 DDoS attacks and brute-force attempts. Set a rate limit of 2,000 requests per five minutes on your login endpoint, and attackers can’t spray credentials at scale.

You can scope rate rules narrowly. Count only POST requests to /api/login, or only requests without a valid session cookie. This lets you be strict on sensitive endpoints while keeping limits loose on static content.

Rate-based rules work well with CloudFront because the edge locations aggregate counts globally. An attacker sending requests from different edge locations still gets counted as one source IP.

Logging, Monitoring, and Tuning

AWS WAF sends metrics to CloudWatch automatically: allowed requests, blocked requests, and counted requests. You see these within minutes of enabling WAF.

For request-level detail, enable WAF logging. You can send logs to CloudWatch Logs, an S3 bucket, or Kinesis Data Firehose. The logs include the full request details, which rule matched, and the action taken.

Use count mode for new rules. The rule evaluates and logs matches but doesn’t block anything. Review the logs for a few days, check for false positives, then switch to block mode.

I always set up a CloudWatch dashboard with allowed vs. blocked request counts and a metric alarm when blocked requests spike. This catches both attacks and accidental over-blocking.

Warning: WAF logs can get expensive fast if you log every request on a high-traffic site. Use sampling or send logs to S3 with lifecycle policies to control costs.

Capacity Units and Rule Complexity

Every Web ACL has a capacity limit measured in Web ACL Capacity Units (WCU). The default maximum is 1,500 WCU per Web ACL.

Simple rules consume few WCU. A rule that matches a single IP address costs 1 WCU. Complex rules with regex patterns, large IP sets, or body inspections cost more. Managed rule groups also consume capacity—check the AWS documentation for each group’s WCU cost before you add it.

If you hit the limit, you can’t add more rules. You’ll need to simplify existing rules, remove unused rule groups, or request a limit increase from AWS support.

Plan your rule complexity early. I’ve seen teams hit the limit after adding five managed rule groups and a dozen custom rules, then have to spend days consolidating rules to make room for a critical new protection.

Centralized Management with Firewall Manager

If you run AWS WAF across multiple accounts or many resources, use AWS Firewall Manager to enforce consistent policies organization-wide.

Firewall Manager lets you create a master WAF policy, then automatically apply it to all CloudFront distributions, ALBs, or API Gateways across your organization. When you update the policy, the changes roll out everywhere.

You can also set compliance rules: every ALB must have the OWASP rule group enabled, or every CloudFront distribution must have bot control. Firewall Manager flags resources that don’t comply.

This is essential for large organizations. Without it, you rely on each team to configure WAF correctly, and you have no visibility into coverage gaps.

Getting Started: One-Click Protection for CloudFront

CloudFront offers a one-click security setup in the Security dashboard. It creates a Web ACL with AWS-recommended protections—OWASP rules, IP reputation lists, and rate limiting—and attaches it to your distribution.

This is the fastest way to get basic protection running, but don’t stop there. The default rules may block legitimate traffic for your application. Review the CloudWatch metrics and logs after enabling, tune the rules, and add application-specific protections.

If you prefer the CLI, associate a Web ACL manually:

aws wafv2 associate-web-acl \ --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:global/webacl/example/a1b2c3d4 \ --resource-arn arn:aws:cloudfront::123456789012:distribution/E1234567890ABC

You can also define Web ACLs as code using CloudFormation or Terraform, which is what I recommend for production deployments. Infrastructure as code makes WAF config auditable, repeatable, and testable in a pipeline.

FAQ

Can AWS WAF protect on-premises applications?

Yes, but only indirectly. Deploy CloudFront in front of your on-premises origin and attach AWS WAF to the CloudFront distribution. CloudFront fetches content from your origin over the public internet or via a dedicated connection, and WAF filters requests at the edge before they reach your data center. You can’t deploy WAF directly on on-premises infrastructure.

What’s the difference between AWS WAF and AWS Shield?

AWS Shield protects against network-layer (layer 3 and 4) DDoS attacks like SYN floods and UDP reflection attacks. AWS WAF protects against application-layer (layer 7) attacks like SQL injection and malicious bots. Shield Standard is automatic and free; Shield Advanced costs extra and includes DDoS response team support. Use both together for layered defense.

Do I need to enable WAF to see security metrics in CloudFront?

Yes. The CloudFront Security dashboard only displays metrics after you enable AWS WAF on the distribution. Without WAF, you won’t see request analysis or threat metrics in that dashboard.

How much does AWS WAF cost?

You pay per Web ACL ($5/month), per rule ($1/month), and per million requests processed ($0.60/million). Managed rule groups have additional monthly fees. Bot control has a free tier for common bot detection (10 million requests/month) and a paid tier for advanced bot management. Check the AWS WAF pricing page for current rates and estimate your costs based on traffic volume and rule complexity.

Can I test WAF rules safely without blocking real users?

Absolutely. Set rule actions to “count” instead of “block.” The rule will evaluate and log matches without affecting traffic. Review the logs, confirm the rule behaves as expected, then change the action to block. This is the standard workflow and prevents outages caused by overly aggressive rules.

Conclusion

AWS WAF gives you programmable, application-layer protection for web applications and APIs. You deploy it at CloudFront for global edge filtering, or at ALB and API Gateway for regional protection. Web ACLs, rules, and rule groups let you block SQL injection, XSS, bots, and abusive traffic using both AWS-managed protections and custom logic. Always test rules in count mode first, monitor CloudWatch metrics and logs, and tune for false positives. For multi-account deployments, Firewall Manager enforces consistent policies across your organization. Start with managed rule groups for quick baseline coverage, then add rate limiting and custom rules tailored to your application’s needs.