**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). 

# AWS WAF Distributed Denial of Service (DDoS) prevention
<a name="waf-anti-ddos"></a>

AWS WAF offers sophisticated and customizable protection against DDoS attacks in your AWS resources. Review the options described in this section and select the level of Anti-DDoS protection that meets your security and business needs.

You can choose from two tiers of DDoS protection in AWS WAF:

Resource-level DDoS protection  
The standard tier works within Application Load Balancers to defend against known malicious sources through on-host filtering. You can configure the protective behavior to best react to potential DDoS events.  
Resource-level DDoS protection:  
+ Monitors your traffic patterns automatically.
+ Updates threat intelligence in real time.
+ Protects against known malicious sources.
**To optimize web ACL request costs for your Application Load Balancer**  
You must associate a web ACL with your Application Load Balancer to enable resource-level protection. If your Application Load Balancer is associated with a web ACL that has no configuration, you will not incur charges from AWS WAF requests, however, AWS WAF will not provide sampled requests or report on the Application Load Balancer in CloudWatch metrics. You can take the following actions to enable observability features for the Application Load Balancer:  
+ Use the `Block` action or `Allow` action with custom request headers in the `DefaultAction`. For information, see [Inserting custom request headers for non-blocking actions](customizing-the-incoming-request.md).
+ Add any rules to the web ACL. For information, see [AWS WAF rules](waf-rules.md).
+ Enable a logging destination. For information, see [Configuring logging for a protection pack (web ACL)](logging-management-configure.md).
+ Associate the web ACL with an AWS Firewall Manager policy. For information, see [Creating an AWS Firewall Manager policy for AWS WAF](create-policy.md#creating-firewall-manager-policy-for-waf).
AWS WAF will not provide sampled requests or publish CloudWatch metrics without these configurations.

AWS managed rule group DDoS protection  
The advanced tier of DDoS protections is offered through the `AWSManagedRulesAntiDDoSRuleSet`. The managed rule group complements the resource-level tier of protection, with the following notable differences:  
+ Protection extends to both Application Load Balancers and CloudFront distributions
+ Traffic baselines are created for your protected resources to improve detection of novel attack patterns.
+ Protective behavior is activated according to sensitivity levels you select.
+ Manages and labels requests to protected resources during probable DDoS events.
For a comprehensive list of the rules and functionality included, see [AWS WAF Distributed Denial of Service (DDoS) prevention rule group](aws-managed-rule-groups-anti-ddos.md).

**Note**  
You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).

**Topics**
+ [Resource-level DDoS protection for Application Load Balancers](waf-anti-ddos-alb.md)
+ [Advanced Anti-DDoS protection using the AWS WAF Anti-DDoS managed rule group](waf-anti-ddos-advanced.md)

# Resource-level DDoS protection for Application Load Balancers
<a name="waf-anti-ddos-alb"></a>

**Resource level DDoS protection** adds immediate defense to Application Load Balancers without incurring charges of deploying AWS WAF managed rule groups. This standard tier of Anti-DDoS protection uses AWS threat intelligence and traffic pattern analysis to protect Application Load Balancers. To identify known malicous sources, Anti-DDoS protection performs on-host filtering of both direct client IP addresses and X-Forwarded-For (XFF) headers. After a known malicious source is identified, protection is activated through one of two modes:

**Active under DDoS** is the default protective mode and is recommended for most use cases. 

This mode:
+ Activates protection automatically when detecting high load conditions or potential DDoS events
+ Rate-limits traffic from known malicious sources only during attack conditions
+ Minimizes impact on legitimate traffic during normal operations
+ Uses Application Load Balancer health metrics and AWS WAF response data to determine when to engage protection

**Always on** is an optional mode that is always active once enabled.

This mode: 
+ Maintains continuous protection against known malicious sources
+ Rate-limits traffic from known malicious sources in real time
+ Applies protection to both direct connections and requests with malicious IPs in XFF headers
+ May have higher impact on legitimate traffic but provides maximum security

Requests blocked by resource-level DDoS protection are recorded in CloudWatch logs as either `LowReputationPacketsDropped` or `LowReputationRequestsDenied` metrics. For information, see [AWS WAF core metrics and dimensions](waf-metrics.md#waf-metrics-general).

## Enable standard DDoS protection on an existing webACL
<a name="enabling-protection-alb"></a>

You can enable DDoS protection when you create a web ACL or update an existing web ACL associated with Application Load Balancer.

**Note**  
If you have an existing web ACL that is associated with an Application Load Balancer, Anti-DDoS protection is enabled by default with **Active under DDoS** mode.

**To enable Anti-DDoS protection in the AWS WAF console**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2). 

1. Choose **Web ACLs** in the navigation pane, and then open any web ACL that is associated with an Application Load Balancer.

1. Choose **Associated AWS resources**.

1. Under **Resource level DDoS protection**, choose **Edit**.

1. Select one of the following protection modes:
   + **Active under DDoS** (recommended) - Protection engages only during high load conditions
   + **Always on** - Always-on protection against known malicious sources

1. Choose **Save changes**.

**Note**  
For information about creating a web ACL, see [Creating a protection pack (web ACL) in AWS WAF](web-acl-creating.md).

**To optimize web ACL request costs for your Application Load Balancer**  
You must associate a web ACL with your Application Load Balancer to enable resource-level protection. If your Application Load Balancer is associated with a web ACL that has no configuration, you will not incur charges from AWS WAF requests, however, AWS WAF will not provide sampled requests or report on the Application Load Balancer in CloudWatch metrics. You can take the following actions to enable observability features for the Application Load Balancer:  
Use the `Block` action or `Allow` action with custom request headers in the `DefaultAction`. For information, see [Inserting custom request headers for non-blocking actions](customizing-the-incoming-request.md).
Add any rules to the web ACL. For information, see [AWS WAF rules](waf-rules.md).
Enable a logging destination. For information, see [Configuring logging for a protection pack (web ACL)](logging-management-configure.md).
Associate the web ACL with an AWS Firewall Manager policy. For information, see [Creating an AWS Firewall Manager policy for AWS WAF](create-policy.md#creating-firewall-manager-policy-for-waf).
AWS WAF will not provide sampled requests or publish CloudWatch metrics without these configurations.

# Advanced Anti-DDoS protection using the AWS WAF Anti-DDoS managed rule group
<a name="waf-anti-ddos-advanced"></a>

The `AWSManagedRulesAntiDDoSRuleSet` managed rule group is the most advanced tier of Anti-DDoS protections available in AWS WAF.

**Note**  
You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).

## AWS WAF Anti-DDoS protection components
<a name="waf-anti-ddos-components"></a>

The main components for implementing advanced Anti-DDoS protection in AWS WAF include the following:

**`AWSManagedRulesAntiDDoSRuleSet`** – Detects, labels, and challenges requests that are likely participating in a DDoS attack. It also labels all requests to a protected resource during an event. For details about the rule group's rules and labels, see [AWS WAF Distributed Denial of Service (DDoS) prevention rule group](aws-managed-rule-groups-anti-ddos.md). To use this rule group, include it in your protection pack (web ACL) using a managed rule group reference statement. For information, see [Adding the Anti-DDoS managed rule group to your protection pack (web ACL)](waf-anti-ddos-rg-using.md).
+ **Web ACL traffic overview dashboards** – Provide monitoring for DDoS activity and anti-DDoS responses in the console. For more information, see [Traffic overview dashboards for protection packs (web ACLs)](web-acl-dashboards.md).
+ **Logging and metrics** – Allow you to monitor traffic and understand Anti-DDoS protection effects. Configure logs, Amazon Security Lake data collection, and Amazon CloudWatch metrics for your protection pack (web ACL). For information about these options, see [Logging AWS WAF protection pack (web ACL) traffic](logging.md), [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md), and [What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html).
+ **Labels and label matching rules** – Allow you to customize handling of web requests identified by the Anti-DDoS managed rule group. For any rule in `AWSManagedRulesAntiDDoSRuleSet`, you can switch to count mode and match against added labels. For more information, see [Label match rule statement](waf-rule-statement-type-label-match.md) and [Web request labeling in AWS WAF](waf-labels.md).
+ **Custom requests and responses** – Allow you to add custom headers to allowed requests and send custom responses for blocked requests. Pair label matching with AWS WAF custom request and response features. For more information, see [Customized web requests and responses in AWS WAF](waf-custom-request-response.md).

# Adding the Anti-DDoS managed rule group to your protection pack (web ACL)
<a name="waf-anti-ddos-rg-using"></a>

This section explains how to add and configure the `AWSManagedRulesAntiDDoSRuleSet` rule group.

To configure the Anti-DDoS managed rule group, you provide settings that include how sensitive the rule group is to DDoS attacks and the actions that it takes on requests that are or might be participating in the attacks. This configuration is in addition to the normal configuration for a managed rule group. 

For the rule group description and rules and labels listing, see [AWS WAF Distributed Denial of Service (DDoS) prevention rule group](aws-managed-rule-groups-anti-ddos.md).

This guidance is intended for users who know generally how to create and manage AWS WAF protection packs (web ACLs), rules, and rule groups. Those topics are covered in prior sections of this guide. For basic information about how to add a managed rule group to your protection pack (web ACL), see [Adding a managed rule group to a protection pack (web ACL) through the console](waf-using-managed-rule-group.md).

**Follow best practices**  
Use the Anti-DDoS rule group in accordance with the best practices at [Best practices for intelligent threat mitigation in AWS WAF](waf-managed-protections-best-practices.md). 

**To use the `AWSManagedRulesAntiDDoSRuleSet` rule group in your protection pack (web ACL)**

1. Add the AWS managed rule group, `AWSManagedRulesAntiDDoSRuleSet` to your protection pack (web ACL), and **Edit** the rule group settings before saving. 
**Note**  
You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).

1. In the **Rule group configuration** pane, provide any custom configuration for the `AWSManagedRulesAntiDDoSRuleSet` rule group. 

   1. For **Block sensitivity level**, specify how sensitive you want the rule `DDoSRequests` to be when matching on the rule group's DDoS suspicion labeling. The higher the sensitivity, the lower the levels of labeling that the rule matches: 
      + Low sensitivity is less sensitive, causing the rule to match only on the most obvious participants in an attack, which have the high suspicion label `awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request`.
      + Medium sensitivity causes the rule to match on the medium and high suspicion labels.
      + High sensitivity causes the rule to match on all of the suspicion labels: low, medium, and high.

      This rule provides the most severe handling of web requests that are suspected of participating in DDoS attacks. 

   1. For **Enable challenge**, choose whether to enable the rules `ChallengeDDoSRequests` and `ChallengeAllDuringEvent`, which by default apply the Challenge action to matching requests. 

      These rules provide request handling that's intended to permit legitimate users to proceed with their requests while blocking participants in the DDoS attack. You can override their action settings to Allow or Count or you can disable their use entirely.

      If you enable these rules, then provide any additional configuration that you want: 
      + For **Challenge sensitivity level**, specify how sensitive you want the rule `ChallengeDDoSRequests` to be. 

        The higher the sensitivity, the lower the levels of labeling that the rule matches: 
        + Low sensitivity is less sensitive, causing the rule to match only on the most obvious participants in an attack, which have the high suspicion label `awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request`.
        + Medium sensitivity causes the rule to match on the medium and high suspicion labels.
        + High sensitivity causes the rule to match on all of the suspicion labels: low, medium, and high.
      + For **Exempt URI regular expressions**, provide a regular expression that matches against URIs for web requests that can't handle a silent browser challenge. The Challenge action will effectively block requests from URIs that are missing the challenge token unless they can handle the silent browser challenge. 

        The Challenge action can only be handled properly by a client that's expecting HTML content. For more information about how the action works, see [CAPTCHA and Challenge action behavior](waf-captcha-and-challenge-actions.md). 

        Review the default regular expression and update it as needed. The rules use the specified regular expression to identify request URIs that can't handle the Challenge action and prevent the rules from sending a challenge back. Requests that you exclude in this way can only be blocked by the rule group with the rule `DDoSRequests`. 

        The default expression that's provided in the console covers most use cases, but you should review and adapt it for your application. 

        AWS WAF supports the pattern syntax used by the PCRE library `libpcre` with some exceptions. The library is documented at [PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/). For information about AWS WAF support, see [Supported regular expression syntax in AWS WAF](waf-regex-pattern-support.md).

1. Provide any additional configuration that you want for the rule group and save the rule. 
**Note**  
AWS recommends against using a scope-down statement with this managed rule group. The scope-down statement limits the requests that the rule group observes, and so can result in an inaccurate traffic baseline and diminished DDoS event detection. The scope-down statement option is available for all of the managed rule group statements, but should not be used for this one. For information about scope-down statements, see [Using scope-down statements in AWS WAF](waf-rule-scope-down-statements.md).

1. In the **Set rule priority** page, move the new anti-DDoS managed rule group rule up so that it runs only after any Allow action rules that you have and before any other rules. This gives the rule group the ability to track the most traffic for Anti-DDoS protection. 

1. Save your changes to the protection pack (web ACL). 

Before you deploy your anti-DDoS implementation for production traffic, test and tune it in a staging or testing environment until you are comfortable with the potential impact to your traffic. Then test and tune the rules in count mode with your production traffic before enabling them. See the section that follows for guidance. 

# Testing and deploying Anti-DDoS
<a name="waf-anti-ddos-deploying"></a>

You will want to configure and test AWS WAF Distributed Denial of Service (DDoS) prevention before deploying the feature. This section provides general guidance for configuring and testing, however the specific steps that you choose to follow will depend on your needs, resources, and web requests that you receive. 

This information is in addition to the general information about testing and tuning provided at [Testing and tuning your AWS WAF protections](web-acl-testing.md).

**Note**  
AWS Managed Rules are designed to protect you from common web threats. When used in accordance with the documentation, AWS Managed Rules rule groups add another layer of security for your applications. However, AWS Managed Rules rule groups aren't intended as a replacement for your security responsibilities, which are determined by the AWS resources that you select. Refer to the [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/) to ensure that your resources in AWS are properly protected. 

**Production traffic risk**  
Test and tune your anti-DDoS implementation in a staging or testing environment until you are comfortable with the potential impact to your traffic. Then test and tune the rules in count mode with your production traffic before enabling them. 

This guidance is intended for users who know generally how to create and manage AWS WAF protection packs (web ACLs), rules, and rule groups. Those topics are covered in prior sections of this guide. 

**To configure and test an AWS WAF Distributed Denial of Service (DDoS) prevention implementation**

Perform these steps first in a test environment, then in production.

1. 

**Add the AWS WAF Distributed Denial of Service (DDoS) prevention managed rule group in count mode**
**Note**  
You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).

   Add the AWS Managed Rules rule group `AWSManagedRulesAntiDDoSRuleSet` to a new or existing protection pack (web ACL) and configure it so that it doesn't alter the current protection pack (web ACL) behavior. For details about the rules and labels for this rule group, see [AWS WAF Distributed Denial of Service (DDoS) prevention rule group](aws-managed-rule-groups-anti-ddos.md).
   + When you add the managed rule group, edit it and do the following: 
     + In the **Rule group configuration** pane, provide the details needed to perform anti-DDoS activities for your web traffic. For more information, see [Adding the Anti-DDoS managed rule group to your protection pack (web ACL)](waf-anti-ddos-rg-using.md).
     + In the **Rules** pane, open the **Override all rule actions** dropdown and choose **Count**. With this configuration, AWS WAF evaluates requests against all of the rules in the rule group and only counts the matches that result, while still adding labels to requests. For more information, see [Overriding rule actions in a rule group](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override).

       With this override, you can monitor the potential impact of the Anti-DDoS managed rules to determine whether you want to make modifications, such as expanding the regex for the URIs that can't handle a silent browser challenge. 
   + Position the rule group so that it's evaluated as early as possible, immediately after any rules that allow traffic. Rules are evaluated in ascending numeric priority order. The console sets the order for you, starting at the top of your rule list. For more information, see [Setting rule priority](web-acl-processing-order.md). 

1. 

**Enable logging and metrics for the protection pack (web ACL)**

   As needed, configure logging, Amazon Security Lake data collection, request sampling, and Amazon CloudWatch metrics for the protection pack (web ACL). You can use these visibility tools to monitor the interaction of the Anti-DDoS managed rule group with your traffic. 
   + For information about configuring and using logging, see [Logging AWS WAF protection pack (web ACL) traffic](logging.md). 
   + For information about Amazon Security Lake, see [What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) and [Collecting data from AWS services](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html) in the *Amazon Security Lake user guide*. 
   + For information about Amazon CloudWatch metrics, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md). 
   + For information about web request sampling, see [Viewing a sample of web requests](web-acl-testing-view-sample.md). 

1. 

**Associate the protection pack (web ACL) with a resource**

   If the protection pack (web ACL) isn't already associated with a test resource, associate it. For information, see [Associating or disassociating protection with an AWS resource](web-acl-associating-aws-resource.md).

1. 

**Monitor traffic and Anti-DDoS rule matches**

   Make sure that your normal traffic is flowing and that the Anti-DDoS managed rule group rules are adding labels to matching web requests. You can see the labels in the logs and see the Anti-DDoS and label metrics in the Amazon CloudWatch metrics. In the logs, the rules that you've overridden to count in the rule group show up in the `ruleGroupList` with `action` set to count, and with `overriddenAction` indicating the configured rule action that you overrode. 

1. 

**Customize Anti-DDoS web request handling**

   As needed, add your own rules that explicitly allow or block requests, to change how Anti-DDoS rules would otherwise handle them. 

   For example, you can use Anti-DDoS labels to allow or block requests or to customize request handling. You can add a label match rule after the Anti-DDoS managed rule group to filter labeled requests for the handling that you want to apply. After testing, keep the related Anti-DDoS rules in count mode, and maintain the request handling decisions in your custom rule. 

1. 

**Remove test rules and configure Anti-DDoS settings**

   Review your testing results to determine which Anti-DDoS rules you want to keep in count mode for monitoring only. For any rules you want to run with active protection, disable count mode in the protection pack (web ACL) rule group configuration to allow them to perform their configured actions. Once you've finalized these settings, remove any temporary test label match rules while retaining any custom rules you created for production use. For additional Anti-DDoS configuration considerations, see [Best practices for intelligent threat mitigation in AWS WAF](waf-managed-protections-best-practices.md).

1. 

**Monitor and tune**

   To be sure that web requests are being handled as you want, closely monitor your traffic after you enable the Anti-DDoS functionality that you intend to use. Adjust the behavior as needed with the rules count override on the rule group and with your own rules. 

# Best Practices for Anti-DDoS
<a name="waf-anti-ddos-best-practices"></a>
+ **Enable protection during normal traffic periods** – This allows the protection to establish baseline traffic patterns before responding to attacks. Add protection when you are not experiencing an attack and allow time for baseline establishment.
+ **Monitor metrics regularly** – Review CloudWatch metrics to understand traffic patterns and protection effectiveness.
+ **Consider proactive mode for critical applications** – While reactive mode is recommended for most use cases, consider using proactive mode for applications that require continuous protection against known threats.
+ **Test in staging environments** – Before enabling protection in production, test and tune settings in a staging environment to understand the impact on legitimate traffic.