**Introducing a new console experience for AWS WAF**

You can now use the updated experience to access AWS WAF functionality anywhere in the console. For more details, see [Working with the console](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html). 

# Using AWS WAF with Amazon CloudFront
<a name="cloudfront-features"></a>

Learn how to use AWS WAF with Amazon CloudFront features.

When you create a protection pack (web ACL), you can specify one or more CloudFront distributions that you want AWS WAF to inspect. CloudFront supports two types of distributions: standard distributions that protect individual tenants, and multi-tenant distributions that protect multiple tenants through a single, shared configuration template. AWS WAF inspects web requests for both distribution types based on the rules you define in your protection packs (web ACLs), with different implementation patterns for each type.

**Topics**
+ [

## How AWS WAF works with different distribution types
](#cloudfront-features-distribution-types)
+ [

## Using AWS WAF with CloudFront Flat-Rate Pricing Plans
](#waf-cf-pricing-plans)
+ [

# Common use cases for protecting CloudFront distributions with AWS WAF
](cloudfront-waf-use-cases.md)

## How AWS WAF works with different distribution types
<a name="cloudfront-features-distribution-types"></a>

### Distribution types
<a name="distribution-types-overview"></a>

AWS WAF provides web application firewall capabilities for both standard and multi-tenant distribution CloudFront distributions.

#### Standard distributions
<a name="standard-distribution-overview"></a>

For standard distributions, AWS WAF adds protection using a single protection pack (web ACL) for each distribution. You can enable this protection by associating an existing protection pack (web ACL) with a CloudFront distribution or by using one-click protection in the CloudFront console. This lets you manage the security controls for each of your distributions independently, since any changes to a protection pack (web ACL) will only affect the distribution associated with it.

This straightforward method of protecting CloudFront distributions is optimal for providing individual domains with specific protections from a single protection pack (web ACL).

##### Standard distribution considerations
<a name="standard-waf-considerations"></a>
+ Changes to a protection pack (web ACL) affect only its associated distribution
+ Each distribution requires independent protection pack (web ACL) configuration
+ Rules and rule groups are managed separately for each distribution

#### Multi-tenant distributions
<a name="tenant-distribution-overview"></a>

For multi-tenant distributions, AWS WAF adds protection across multiple domains using a single protection pack (web ACL). Domains that are managed by multi-tenant distributions are known as distribution tenants. You can only enable AWS WAF protection for multi-tenant distributions in the CloudFront console, either during or after the multi-tenant distribution creation process. However, changes to a protection pack (web ACL) are still managed through the AWS WAF console or API. 

Multi-tenant distributions offer the flexibility to enable AWS WAF protections at two levels:
+ **Multi-tenant distribution level** – Associated protection packs (web ACLs) provide baseline security controls that apply to all applications sharing that distribution
+ **Distribution tenant level** – Individual tenants within a multi-tenant distribution can have their own protection packs (web ACLs) to implement additional security controls or override multi-tenant distribution settings

These two tiers make multi-tenant distributions optimal for sharing AWS WAF protections across multiple domains without losing the ability to customize security for an individual distribution. 

#### Multi-tenant distribution considerations
<a name="tenant-waf-considerations"></a>
+ Individual distribution tenants inherit changes made to protection packs (web ACLs) that are associated with related multi-tenant distributions
+ The protection packs (web ACLs) associated with specific distribution tenants can override settings configured at the multi-tenant protection pack (web ACL) level
+ Managed rule groups can be implemented at both distribution and distribution tenant levels
+ Application identifiers can be located in logs to track security events by distribution

### AWS WAF features by distribution type
<a name="distribution-types-comparison"></a>


**Compare protection pack (web ACL) implementations**  

| AWS WAF Feature | Standard distributions | Multi-tenant distributions | 
| --- | --- | --- | 
| Associating protection packs (web ACLs) | One protection pack (web ACL) per distribution | You can share protection packs (web ACLs) across tenants, with optional tenant-specific protection packs (web ACLs) | 
| Rule management | Rules affect a single distribution | Multi-tenant distribution rules affect all associated tenants; distribution tenant-specific rules affect only that tenant | 
| Managed rule groups | Applied to individual distributions | Can be applied at multi-tenant distribution level for all tenants or at tenant level for specific applications | 
| Logging | Standard AWS WAF logs | Logs include tenant identifiers for security event attribution | 

## Using AWS WAF with CloudFront Flat-Rate Pricing Plans
<a name="waf-cf-pricing-plans"></a>

CloudFront flat-rate pricing plans combine the Amazon CloudFront global content delivery network (CDN) with multiple AWS services and features into a monthly price with no overage charges, regardless of traffic spikes or attacks.

Flat-rate pricing plans include the following AWS services and features for a simple monthly price:
+ CloudFront CDN
+ AWS WAF and DDoS protection
+ Bot management and analytics
+ Amazon Route 53 DNS
+ Amazon CloudWatch Logs ingestion
+ TLS certificate
+ Serverless edge compute
+ Amazon S3 storage credits each month

Plans are available in Free, Pro, Business, and Premium tiers to match your application's needs. Plans do not need an annual commitment to get the best available rates. Start with the Free plan and upgrade to access more capabilities and larger usage allowances.

For more information and a complete list of plans and features, see [CloudFront flat-rate pricing plans](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) in the *Amazon CloudFront Developer Guide*.

**Important**  
A valid AWS WAF protection pack (web ACL) must remain associated with your CloudFront distribution when using any pricing plan. You cannot remove the protection pack (web ACL) association unless you switch back to pay-as-you-go pricing.  
While a AWS WAF web ACL must remain associated with your distribution, you maintain full control over your security configuration. You can customize your protection by adjusting which rules are enabled or disabled in your web ACL, and modify rule settings to match your security requirements. For information about managing web ACL rules, see [AWS WAF Rules](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html).

# Common use cases for protecting CloudFront distributions with AWS WAF
<a name="cloudfront-waf-use-cases"></a>

The following AWS WAF features work the same way for all CloudFront distributions. Considerations for multi-tenant distributions are listed following each feature scenario.

## Using AWS WAF with CloudFront custom error pages
<a name="cloudfront-features-custom-error-pages"></a>

By default, when AWS WAF blocks a web request based on the criteria that you specify, it returns HTTP status code `403 (Forbidden)` to CloudFront, and CloudFront returns that status code to the viewer. The viewer then displays a brief and sparsely formatted default message similar to the following:

```
Forbidden: You don't have permission to access /myfilename.html on this server.
```

You can override this behavior in your AWS WAF protection pack (web ACL) rules by defining custom responses. For more information about customizing response behavior using AWS WAF rules, see [Sending custom responses for Block actions](customizing-the-response-for-blocked-requests.md).

**Note**  
Responses that you customize using AWS WAF rules take precedence over any response specifications that you define in CloudFront custom error pages.

If you'd rather display a custom error message through CloudFront, possibly using the same formatting as the rest of your website, you can configure CloudFront to return to the viewer an object (for example, an HTML file) that contains your custom error message.

**Note**  
CloudFront can't distinguish between an HTTP status code 403 that is returned by your origin and one that is returned by AWS WAF when a request is blocked. This means that you can't return different custom error pages based on the different causes of an HTTP status code 403.

For more information about CloudFront custom error pages, see [Generating custom error responses](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html) in the *Amazon CloudFront Developer Guide*.

### Custom error pages in multi-tenant distributions
<a name="custom-error-pages-template-distributions"></a>

For CloudFront multi-tenant distributions, you can configure custom error pages in the following ways:
+ At the multi-tenant level - These settings apply to all tenant distributions that use the multi-tenant distribution template
+ Through AWS WAF rules - Custom responses defined in protection packs (web ACLs) take precedence over both multi-tenant distribution and tenant-level custom error pages

## Using AWS WAF with CloudFront for applications running on your own HTTP server
<a name="cloudfront-features-your-own-http-server"></a>

When you use AWS WAF with CloudFront, you can protect your applications running on any HTTP webserver, whether it's a webserver that's running in Amazon Elastic Compute Cloud (Amazon EC2) or a webserver that you manage privately. You can also configure CloudFront to require HTTPS between CloudFront and your own webserver, as well as between viewers and CloudFront.

**Requiring HTTPS between CloudFront and your own webserver**  
To require HTTPS between CloudFront and your own webserver, you can use the CloudFront custom origin feature and configure the **Origin Protocol Policy** and the **Origin Domain Name** settings for specific origins. In your CloudFront configuration, you can specify the DNS name of the server along with the port and the protocol that you want CloudFront to use when fetching objects from your origin. You should also ensure that the SSL/TLS certificate on your custom origin server matches the origin domain name you've configured. When you use your own HTTP webserver outside of AWS, you must use a certificate that is signed by a trusted third-party certificate authority (CA), for example, Comodo, DigiCert, or Symantec. For more information about requiring HTTPS for communication between CloudFront and your own webserver, see the topic [Requiring HTTPS for Communication Between CloudFront and Your Custom Origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html) in the *Amazon CloudFront Developer Guide*.

**Requiring HTTPS between a viewer and CloudFront**  
To require HTTPS between viewers and CloudFront, you can change the **Viewer Protocol Policy** for one or more cache behaviors in your CloudFront distribution. For more information about using HTTPS between viewers and CloudFront, see the topic [Requiring HTTPS for Communication Between Viewers and CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) in the *Amazon CloudFront Developer Guide*. You can also bring your own SSL certificate so viewers can connect to your CloudFront distribution over HTTPS using your own domain name, for example *https://www.mysite.com*. For more information, see the topic [Configuring Alternate Domain Names and HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html) in the *Amazon CloudFront Developer Guide*.

For multi-tenant distributions, HTTP method configurations follow this hierarchy:
+ Template-level settings define the baseline HTTP methods allowed for all tenant distributions
+ Tenant distributions can override these settings to:
  + Allow fewer methods than the multi-tenant distribution (using AWS WAF rules to block additional methods)
  + Allow more methods if the multi-tenant distribution is configured to support them
+ AWS WAF rules at both multi-tenant distribution and tenant levels can further restrict HTTP methods regardless of the CloudFront configuration

## Choosing the HTTP methods that CloudFront responds to
<a name="cloudfront-features-allowed-http-methods"></a>

When you create an Amazon CloudFront web distribution, you choose the HTTP methods that you want CloudFront to process and forward to your origin. You can choose from the following options:
+ **`GET`, `HEAD`** – You can use CloudFront only to get objects from your origin or to get object headers.
+ **`GET`, `HEAD`, `OPTIONS`** – You can use CloudFront only to get objects from your origin, get object headers, or retrieve a list of the options that your origin server supports.
+ **`GET`, `HEAD`, `OPTIONS`, `PUT`, `POST`, `PATCH`, `DELETE`** – You can use CloudFront to get, add, update, and delete objects, and to get object headers. In addition, you can perform other `POST` operations such as submitting data from a web form.

You also can use AWS WAF byte match rule statements to allow or block requests based on the HTTP method, as described in [String match rule statement](waf-rule-statement-type-string-match.md). If you want to use a combination of methods that CloudFront supports, such as `GET` and `HEAD`, then you don't need to configure AWS WAF to block requests that use the other methods. If you want to allow a combination of methods that CloudFront doesn't support, such as `GET`, `HEAD`, and `POST`, you can configure CloudFront to respond to all methods, and then use AWS WAF to block requests that use other methods.

For more information about choosing the methods that CloudFront responds to, see [Allowed HTTP Methods](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesAllowedHTTPMethods) in the topic [Values that You Specify When You Create or Update a Web Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html) in the *Amazon CloudFront Developer Guide*.

**Allowed HTTP method configurations in multi-tenant distributions**  
For multi-tenant distributions, HTTP method configurations set at the multi-tenant distribution level apply to all tenant distributions by default. Tenant distributions can override these settings if needed.
+ If you want to use a combination of methods that CloudFront supports, such as `GET` and `HEAD`, you don't need to configure AWS WAF to block requests that use other methods.
+ If you want to allow a combination of methods that CloudFront doesn't support by default, such as `GET`, `HEAD`, and `POST`, you can configure CloudFront to respond to all methods, and then use AWS WAF to block requests that use other methods.

When implementing security headers in multi-tenant distributions, consider the following:
+ Template-level security headers provide baseline protection across all tenant distributions
+ Tenant distributions can:
  + Add new security headers not defined in the multi-tenant distribution
  + Modify values for tenant-specific headers
  + Cannot remove or override security headers set at the multi-tenant distribution level
+ Consider using multi-tenant distribution-level headers for critical security controls that should apply to all tenants

## Logging considerations
<a name="cloudfront-features-logging"></a>

Both standard and multi-tenant distributions support AWS WAF logging, but there are important differences in how logs are structured and managed:


**Logging comparison**  

| Standard distributions | Multi-tenant distributions | 
| --- | --- | 
| One log configuration per distribution | Template and tenant-level logging options | 
| Standard log fields | Additional tenant identifier fields | 
| Single destination per distribution | Separate destinations possible for multi-tenant distribution and tenant logs | 

## Additional resources
<a name="cloudfront-saas-additional-resources"></a>
+ To learn more about multi-tenant distributions, see [Configure distributions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html) in the *Amazon CloudFront Developer Guide*.
+ To learn more about using AWS WAF with CloudFront, see [Using AWS WAF protection](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html) in the *Amazon CloudFront Developer Guide*.
+ To learn more about AWS WAF logs, see [Log fields for protection pack (web ACL) traffic](logging-fields.md).