AWS WAF Rate-Based Web ACL for CloudFront

Purpose of This Lesson

This lesson demonstrates how to add an AWS WAF web ACL to a CloudFront distribution and use a rate-based rule to block requests from an IP address that exceeds a configured request threshold. It also shows how to validate the rule with AWS CloudShell and how to clean up the lab resources.

The example environment contains:

• A CloudFront distribution with an Amazon S3 origin serving an index.html file.
• A hosted-zone A record mapping a custom domain to the CloudFront distribution.
• An HTTPS certificate configured for the distribution.
• A WAF web ACL associated with the CloudFront distribution.

Key Concepts

AWS WAF web ACL

An AWS WAF web ACL contains rules that inspect requests and determine whether they should be allowed or blocked. For CloudFront protection, the web ACL is created in the Global Resources scope.

Rate-based rule

A rate-based rule tracks request activity and applies an action when a client exceeds the configured request limit during the evaluation window. In this lab, the rule is configured as follows:

Setting	Lab value
Request threshold	100 requests
Evaluation window	5 minutes
Aggregation key	Source IP address
Action	Block

The practical result is that an IP address generating more than the configured volume of requests during the five-minute window can be blocked by AWS WAF.

CloudFront scope

CloudFront distributions use AWS WAF resources in the Global Resources scope. When creating the web ACL, the CloudFront distribution can be selected as an associated AWS resource.

CloudShell as a test client

AWS CloudShell provides a convenient environment for generating test requests. Requests issued from CloudShell originate from a specific public IP address, allowing the rate-based rule to observe repeated traffic from the same source.

CloudFront WAF Configuration Workflow

1. Open AWS WAF and select the CloudFront scope

Open the AWS WAF console and switch to Global Resources. This scope is used when protecting a CloudFront distribution.

2. Create the web ACL

Create a web ACL with a descriptive name. During resource association, add the target CloudFront distribution.

3. Add a custom rate-based rule

Choose the option to add your own rules and rule groups, then use the rule builder to create a rate-based rule. Configure:

• A descriptive rule name, such as rates limits 100.
• A maximum request count of 100.
• An evaluation window of five minutes.
• Source IP address as the request aggregation basis.
• Block as the rule action.

Complete the remaining wizard steps and create the web ACL.

4. Confirm normal access before testing

Before generating excess traffic, access the CloudFront distribution through its HTTPS custom domain. A successful response establishes a baseline showing that the distribution and its domain configuration work before WAF enforcement is triggered.

5. Generate repeated requests

Use a loop in CloudShell to request the site repeatedly. The lecture uses a loop that runs 140 times, which is sufficient to exceed the 100-request threshold in the lab. Replace the example domain with the domain for your own CloudFront distribution.

A conceptual example is:

for i in {1..140}; do curl -s https://YOUR_DOMAIN/; done

The exact command should use the learner’s own domain rather than the example domain from the demonstration.

6. Verify blocking behavior

Initially, the responses should indicate successful access through CloudFront. After enough requests are generated, AWS WAF should begin blocking requests from the testing IP address. The browser or client may display a generic connection or traffic error, but the meaningful diagnostic conclusion is that the WAF web ACL has applied its block action.

Exam- or Assessment-Relevant Takeaways

• For a CloudFront distribution, create or select the AWS WAF web ACL in the Global Resources scope.
• A rate-based rule is appropriate when the scenario requires limiting excessive request volume rather than matching a specific content pattern.
• The aggregation key determines how requests are counted. In this lab, counting is performed by source IP address.
• The rule threshold and evaluation window work together: the client is evaluated against 100 requests during five minutes.
• The rule action must be explicitly configured as Block; creating the rule alone does not imply that traffic will be denied.
• A test client must generate requests from a consistent source IP for the source-IP rate limit to be observed clearly.
• A successful response before testing is an important baseline; without it, a later failure could be caused by CloudFront, DNS, HTTPS, or origin configuration rather than WAF.
• CloudFront changes and distribution deletion are not immediate operations. A distribution may remain in a deploying or disabling state while AWS completes the change.

Tool / Feature Decision Guide

Requirement	Suitable choice	Reason
Protect a CloudFront distribution with AWS WAF	Global Resources web ACL	CloudFront is handled through the global WAF scope.
Limit unusually high request volume	Rate-based rule	The rule evaluates request counts over a time window.
Apply the limit independently to clients	Source IP aggregation	Requests are counted according to the originating IP address.
Deny clients exceeding the threshold	Block action	The action determines the enforcement result.
Generate repeatable lab traffic	CloudShell loop	CloudShell can issue many requests from a consistent source environment.
Remove the lab distribution	Disable first, wait for completion, then delete	CloudFront must finish disabling before deletion can proceed.

A rate-based rule is not presented here as a replacement for every WAF control. This lab focuses specifically on request-rate enforcement for a CloudFront distribution; it does not demonstrate managed rule groups, IP sets, or content-matching rules.

Common Traps / Misconceptions

• Using the wrong WAF scope: A CloudFront web ACL is associated through the Global Resources scope, not the regional scope used by regional resources.
• Assuming the threshold is instantaneous: The rule evaluates requests during its configured five-minute window; it is not simply a per-second counter.
• Forgetting the aggregation key: With source IP aggregation, requests from different IP addresses are evaluated separately.
• Testing with too few requests: A single page load or a handful of manual refreshes may not exceed a threshold of 100 requests.
• Using the demonstration domain: The test loop must target the learner’s own custom domain or CloudFront endpoint.
• Treating a browser error as the root cause: Once the rule is active, a generic client error can be the visible symptom of a WAF block.
• Deleting CloudFront immediately: The distribution must first be disabled and allowed to finish its state transition before deletion.
• Ignoring the baseline: If the site was not confirmed to work before WAF testing, it is difficult to distinguish WAF blocking from an existing configuration problem.

Real-World Engineer / Analyst Notes

• Use descriptive names for web ACLs and rules so that logs, metrics, and future troubleshooting are easier to interpret.
• Choose a threshold and evaluation period based on expected application traffic. The value of 100 requests in five minutes is a lab setting, not a universal production recommendation.
• Validate both sides of the behavior: confirm legitimate access before the threshold and confirm blocking after the threshold is exceeded.
• Keep the test traffic controlled. A simple CloudShell loop is useful for a lab, but repeated requests against a production service should be authorized and carefully bounded.
• When troubleshooting, separate the layers: DNS and the certificate establish access to the custom domain, CloudFront routes the request, and AWS WAF evaluates the request before the protected content is served.
• Plan cleanup before creating temporary CloudFront and WAF resources. CloudFront state transitions can make teardown take longer than expected.

Quick Reference Summary

• Scope: AWS WAF Global Resources for CloudFront.
• Protected resource: A CloudFront distribution backed by an Amazon S3 origin.
• Rule type: Rate-based rule.
• Lab threshold: 100 requests.
• Evaluation period: 5 minutes.
• Aggregation: Source IP address.
• Action: Block.
• Test method: Generate repeated HTTPS requests from CloudShell.
• Expected result: Normal responses initially, followed by blocked requests after the limit is exceeded.
• Cleanup sequence: Disable the CloudFront distribution, wait until disabling completes, delete the distribution, and then delete the web ACL as demonstrated in the lab.

Flashcards

Q: Which AWS WAF scope should be used when creating a web ACL for a CloudFront distribution?

A: Use the Global Resources scope because the lesson’s CloudFront-protection workflow uses the global WAF resource scope.

Q: A CloudFront site needs protection against clients sending excessive requests. Which WAF rule type fits this requirement?

A: Use a rate-based rule, because it evaluates request volume over a defined time window.

Q: In the demonstrated rule, what combination causes a client to be blocked?

A: More than 100 requests from the same source IP during the five-minute evaluation window triggers the configured Block action.

Q: Why is source IP address selected for the rate-based rule in this lab?

A: It allows AWS WAF to count requests separately for each originating IP address and identify the CloudShell test client.

Q: What is the decisive difference between the rule threshold and the evaluation window?

A: The threshold is the maximum request count, while the evaluation window defines the period over which that count is evaluated.

Q: What action must be selected if the requirement is to deny traffic that exceeds the rate limit?

A: Select the Block action; configuring a rate limit without a blocking action does not produce the demonstrated denial behavior.

Q: Why should normal HTTPS access be verified before generating test traffic?

A: It provides a working baseline, helping distinguish a later WAF block from an existing DNS, certificate, CloudFront, or origin problem.

Q: Why is CloudShell useful for testing this rate-based rule?

A: It can run a request loop from a consistent source environment, making it practical to exceed the request threshold from one observed IP address.

Q: What is the trap when adapting the request loop from the lesson?

A: The example domain must be replaced with the learner’s own domain; using the demonstration domain does not test the learner’s distribution.

Q: What response pattern indicates that the WAF rule has likely taken effect?

A: Requests succeed initially, then begin returning a blocked or generic connection-error response after the rate threshold is exceeded.

Q: When should a CloudFront distribution be deleted during cleanup?

A: Disable it first and wait until the disabling operation completes; only then should it be deleted.

Q: Why can cleanup take longer than expected for CloudFront?

A: CloudFront changes are deployed asynchronously, so the distribution can remain in a deploying or disabling state for several minutes.

Practice Questions

Question 1

A learner creates an AWS WAF web ACL but cannot find the CloudFront distribution to associate with it. Which correction is most appropriate?

A. Change the rule action from Block to Allow.
B. Switch the WAF console to Global Resources.
C. Disable the S3 origin.
D. Change the evaluation window to one minute.

Correct answer: B. CloudFront distributions are handled through the AWS WAF Global Resources scope in the demonstrated workflow.

Question 2

A test requires blocking a client that sends 100 requests within five minutes. Which configuration matches the lab?

A. IP aggregation, 100 requests, five-minute window, Block action.
B. Host-name aggregation, 100 requests, five-second window, Allow action.
C. IP aggregation, 10 requests, one-hour window, Count action.
D. URI aggregation, 140 requests, five-minute window, Allow action.

Correct answer: A. It matches the demonstrated threshold, evaluation period, source-IP aggregation, and enforcement action.

Question 3

The CloudFront site works before testing. After a CloudShell loop sends repeated requests, the client begins reporting that the request is blocked. What is the most likely explanation?

A. The S3 index file was automatically deleted.
B. The HTTPS certificate was revoked by CloudFront.
C. The source IP exceeded the WAF rate threshold and the web ACL blocked it.
D. The hosted-zone A record changed to an S3 endpoint.

Correct answer: C. The successful baseline followed by blocking after repeated requests is the expected behavior of the configured rate-based rule.

Question 4

An engineer wants to delete the temporary CloudFront distribution immediately after the test, but the distribution is still in a deploying or disabling state. What should the engineer do?

A. Delete the WAF web ACL first and retry immediately.
B. Change the WAF aggregation key and delete the distribution.
C. Wait for the CloudFront distribution to finish disabling, then delete it.
D. Remove the HTTPS certificate and force deletion.

Correct answer: C. CloudFront must complete the disabling transition before deletion can proceed.

WordPress Metadata

Suggested Slug:
aws-waf-rate-based-web-acl-cloudfront

Meta Description:
Configure an AWS WAF rate-based web ACL for a CloudFront distribution, test IP-based blocking with CloudShell, and clean up the associated resources safely.

Tags:
AWS WAF, AWS CloudFront, Web ACL, Rate-Based Rules, CloudShell, Amazon S3, HTTPS, DDoS Protection, AWS CloudOps, Network Security