PacketSensei

AWS WAF for CloudFront: Edge Protection Overview

Written by

packetadmin

in

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.

More posts