How to Rate-Limit DDoS Protection for a CloudFront-Hosted S3 Website?
A company's public website is hosted in an Amazon S3 bucket in the us-east-1 Region behind an Amazon CloudFront distribution. The company wants to ensure that the website is protected from DDoS attacks. A CloudOps engineer needs to deploy a solution that gives the company the ability to maintain control over the rate limit at which DDoS protections are applied. Which solution will meet these requirements?
Community Insight
The exam tests WAF scope and rule action semantics for CloudFront, and the trap is assuming an S3 bucket can be directly associated with a WAF web ACL or that a block-by-default web ACL should be used.
This question tests how to apply AWS WAF rate-based rules through CloudFront to control DDoS throttling for an S3-backed public website. The correct design uses a global-scoped web ACL with an allow default action and a blocking rate-based rule attached to the CloudFront distribution.
Choosing B or D because they place the web ACL in us-east-1 and try to associate it with the S3 bucket; AWS WAF web ACLs for CloudFront are global and cannot be attached directly to an S3 bucket.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option A matches the AWS WAF deployment pattern for a CloudFront-fronted website: the web ACL must be global-scoped and associated with the CloudFront distribution, which is the public entry point where DDoS traffic is absorbed. An allow default action lets normal visitors through, while the rate-based rule blocks only sources that exceed the configured request rate. This directly satisfies the requirement to maintain control over the rate limit at which DDoS protections are applied. It also correctly avoids treating the S3 origin as the WAF enforcement point.Why the Other Options Are Wrong
Option B is wrong because it tries to associate the AWS WAF web ACL with the S3 bucket; AWS WAF protects supported entry points such as CloudFront distributions, not S3 buckets directly. Option C inverts the intended logic by using a block default action and a rate-based allow rule, which would block normal users unless they were explicitly allowed by rate. Option D repeats both errors: it uses block-by-default with rate-based allow and attempts an invalid S3 bucket association. Only option A combines the correct global scope, correct default action, correct rate-based block behavior, and correct CloudFront association.Community Comment Notes
As Bad_Mat noted, the correct approach is to "Deploy a global-scoped AWS WAF web ACL" with an allow default action and a rate-based block rule, then associate that web ACL with the CloudFront distribution. This aligns with the AWS WAF model for CloudFront protection and with the requirement to control the DDoS rate-limit threshold. The comment also correctly rejects associating the web ACL with the S3 bucket.Official Reference
Exam Strategy
When CloudFront is the public entry point, choose the WAF scope and association that match the distribution, not the origin bucket. For rate limiting, default allow plus a blocking rate-based rule preserves normal traffic; block-by-default with rate-based allow only makes sense for narrow allowlists.
Frequently Asked Questions
Why can't the AWS WAF web ACL be associated directly with the S3 bucket?
AWS WAF protects supported entry points such as CloudFront distributions and load balancers; an S3 bucket is not a direct WAF association target, so the web ACL must attach to CloudFront.
What scope should an AWS WAF web ACL use for CloudFront?
A web ACL associated with CloudFront is global-scoped, even though the console and API resources are created in us-east-1.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →