Do you need AWS WAF when using Amazon CloudFront to serve a static website fronted on S3?

TL;DR: Absolutely! Using a Web Application Firewall (WAF) can be very advantageous, even when serving a static website through Amazon CloudFront.

Here’s why:

1. Protection Against Common Threats: S3 charges for most object operations including objects not found, so it is important to block SQL injection, cross-site scripting (XSS) type of vulnerabilities to mitigate potential S3 cost blow outs.
2. Access Control: WAF WebALCs rules allow you to implement rules for controlling access to your content, such as blocking specific IP addresses or regions
3. Rate Limiting: You can use WAF WebACL rules to enforce rate limiting, which helps to mitigate potential denial-of-service (DoS) attacks or abusive traffic patterns that could affect your site’s availability.
4. Custom Rules: AWS WAF offers the ability to create custom rules tailored to your specific needs, even for static content. This could include blocking certain user agents, monitoring specific patterns, or handling traffic in ways that align with your security policies.
5. Logging and Monitoring: AWS WAFs provides logging and monitoring capabilities, giving you insights into traffic patterns and potential security incidents. This can be valuable for maintaining a secure environment and responding to potential threats.

How to implement it:

1. Firstly, you should restrict access to your S3 bucket via OAC (if not already done) to prevent attackers from circumventing CloudFront and WAF. This also means you can also block the creation of public S3 buckets in SCPs to prevent accidental creation of public buckets.
2. Add AWSManagedRulesCommonRuleSet to your WebACL using the COUNT. This is a core rule set (CRS) rule group contains rules that are generally applicable to web applications, can have a lot of false-positives, so you’ll want to monitor this before moving to BLOCK.
3. Add AWSManagedRulesAmazonIpReputationList to your WebACL with the BLOCK action. This rule group has a really low false-positive rate and is effective in blocking the most obvious malicious IPs.
4. Additionally, AWSManagedRulesAnonymousIpList might be good to add; however, depending on the users of your website, this might lead to false positives, so I would use it with care – start with COUNT and slowly move to BLOCK.
5. Set a rate limit rule with a conservative limit, e.g., 3000 requests per minute. Use source IP as the aggregation key (this is the default). These three configuration settings (request limit, time frame, and aggregation key) are all you need to set. No further configuration is necessary for a simple rate limit rule.
6. Block requests that are coming from countries in which you don’t have customers with a rule that uses a geo match statement, this is also useful if you have to block countries which are on sanctions list or may want to avoid doing business with e.g block the EU due to GDPR Compliance.

Monitor your WAF rules for issues:

1. Enable WAF logs with a filter for requests where the BLOCK and COUNT actions were applied. If you don’t apply the filter and also log ALLOW requests, you might quickly run into cost issues (depending on the number of requests you receive, of course).
2. Add multiple rate limit rules, each with a different rate limit (e.g., 8000, 2000, 1000, etc.), and put them in COUNT mode. Use WAF’s CloudWatch metrics with the dimensions “rule” and “webacl” together with the WAF logs, to analyse which of those rules would block malicious requests and not legitimate ones.
3. Add CloudWatch WAF metric alerts for allowed requests. If you receive a peak of requests that is out of the ordinary, you should get alerted so that you can investigate and mitigate the potential attack.

AWS Advanced DDoS Protection:

1. If your budget allows, consider subscribing to Shield Advanced (~USD $3000 per month). With this, you would get access to the Shield Response Team (SRT), which can assist you immediately with managing DDoS attacks. Additionally, it would allow you to get a refund of AWS costs that have been incurred by malicious requests that have not been blocked by Shield. For this, you need to fulfil these pre-requisites, which I recommend following regardless of whether you have Shield Advanced or not.
2. Shield Advanced might also be useful since it comes with a WAF cost flat rate. As long as you are not exceeding 1500 WCUs, don’t use certain AWS managed rule groups (e.g., bot control) or rule groups from the AWS marketplace, the $3000 Shield Advanced costs will cover your WAF costs.
3. Additionally, it comes with a layer-7 auto-mitigation protection feature. This feature observes your baseline traffic and automatically puts WAF rules in place that block the malicious part of your traffic.
4. Last but not least, if you are using “AWS Organizations”, then you only need to pay once for a subscription. Once you have subscribed one account in your org to it, the costs of all following subscriptions in other accounts of your org will be covered by the first one.