**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).
# Resource protections in AWS Shield Advanced
You can add and configure AWS Shield Advanced protections for your resources. You can manage protections for a single resource and you can group your protected resources into logical collections for better event management. You can also track changes to your Shield Advanced protections using AWS Config.
**Note**
Shield Advanced protects only resources that you have specified either in Shield Advanced or through an AWS Firewall Manager Shield Advanced policy. It doesn't automatically protect your resources.
If you're using an AWS Firewall Manager Shield Advanced policy, you don't need to manage protections for resources that are in scope of the policy. Firewall Manager automatically manages protections for accounts and resources that are in scope of a policy, according to the policy configuration. For more information, see [Using AWS Shield Advanced policies in Firewall Manager](shield-policies.md).
**Topics**
+ [List of resources that AWS Shield Advanced protects](ddos-protections-by-resource-type.md)
+ [Protecting Amazon EC2 instances and Network Load Balancers with Shield Advanced](ddos-protections-ec2-nlb.md)
+ [Protecting the application layer (layer 7) with AWS Shield Advanced and AWS WAF](ddos-app-layer-protections.md)
+ [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md)
+ [Adding AWS Shield Advanced protection to AWS resources](configure-new-protection.md)
+ [Editing AWS Shield Advanced protections](manage-protection.md)
+ [Creating alarms and notifications for resources protected by Shield Advanced](add-alarm-ddos.md)
+ [Removing AWS Shield Advanced protection from an AWS resource](remove-protection.md)
+ [Grouping your AWS Shield Advanced protections](ddos-protection-groups.md)
+ [Tracking Shield Advanced resource protection changes in AWS Config](ddos-add-config.md)
# List of resources that AWS Shield Advanced protects
This section provides information about Shield Advanced protections for each resource type.
Shield Advanced protects AWS resources in the network and transport layers (layers 3 and 4) and in the application layer (layer 7). You can protect some resources directly and others through association with protected resources. Shield Advanced supports IPv4, and does not support IPv6.
**Note**
Shield Advanced protects only resources that you have specified either in Shield Advanced or through an AWS Firewall Manager Shield Advanced policy. It doesn't automatically protect your resources.
You can use Shield Advanced for advanced monitoring and protection with the following resource types:
+ Amazon CloudFront distributions. For CloudFront continuous deployment, Shield Advanced protects any staging distribution that's associated with a protected primary distribution.
+ Amazon Route 53 hosted zones.
+ AWS Global Accelerator standard accelerators.
+ Amazon EC2 Elastic IP addresses. Shield Advanced protects the resources that are associated with protected Elastic IP addresses.
+ Amazon EC2 instances, through association to Amazon EC2 Elastic IP addresses.
+ The following Elastic Load Balancing (ELB) load balancers:
+ Application Load Balancers.
+ Classic Load Balancers.
+ Network Load Balancers, through associations to Amazon EC2 Elastic IP addresses.
**Note**
You can't use Shield Advanced to protect any other resource type. For example, you can't protect AWS Global Accelerator custom routing accelerators or Gateway Load Balancers.
**Note**
NAT Gateways handle outbound traffic only, whereas Shield Advanced protects against inbound DDoS. For outbound traffic protection, use [AWS Network Firewall](https://docs.aws.amazon.com//network-firewall/latest/developerguide/what-is-aws-network-firewall.html).
You can monitor and protect up to 1,000 resources for each resource type per AWS account. For example, in a single account, you could protect 1,000 Amazon EC2 Elastic IP addresses, 1,000 CloudFront distributions, and 1,000 Application Load Balancers. You can request an increase to the number of resources that you can protect with Shield Advanced through the Service Quotas console at [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
# Protecting Amazon EC2 instances and Network Load Balancers with Shield Advanced
This page explains how to use AWS Shield Advanced protections for Amazon EC2 instances and Network Load Balancers.
You can protect Amazon EC2 instances and Network Load Balancers by first attaching these resources to Elastic IP addresses, and then protecting the Elastic IP addresses in Shield Advanced.
When you protect Elastic IP addresses, Shield Advanced identifies and protects the resources that they're attached to. Shield Advanced automatically identifies the type of resource that's attached to an Elastic IP address and applies the appropriate detections and mitigations for that resource. This includes configuring network ACLs that are specific to the Elastic IP address. For more information about using Elastic IP addresses with your AWS resources, see the following guides: [Amazon Elastic Compute Cloud documentation](https://docs.aws.amazon.com/ec2/) or [Elastic Load Balancing documentation](https://docs.aws.amazon.com/elasticloadbalancing/).
During an attack, Shield Advanced automatically deploys your network ACLs to the border of the AWS network. When your network ACLs are at the border of the network, Shield Advanced can provide protection against larger DDoS events. Typically, network ACLs are applied near your Amazon EC2 instances within your Amazon VPC. The network ACL can mitigate attacks only as large as your Amazon VPC and instance can handle. For example, if the network interface attached to your Amazon EC2 instance can process up to 10 Gbps, then volumes over 10 Gbps will slow down and possibly block traffic to that instance. During an attack, Shield Advanced promotes your network ACL to the AWS border, which can process multiple terabytes of traffic. Your network ACL is able to provide protection for your resource well beyond your network's typical capacity. For more information about network ACLs, see [Network ACLs](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
Some scaling tools, like AWS Elastic Beanstalk, don't let you automatically attach an Elastic IP address to a Network Load Balancer. For those cases, you need to manually attach the Elastic IP address.
# Protecting the application layer (layer 7) with AWS Shield Advanced and AWS WAF
This page explains how Shield Advanced and AWS WAF work together to protect resources at the application layer (layer 7).
To protect your application layer resources with Shield Advanced, you start by associating an AWS WAF web ACL with the resource and adding one or more rate-based rules to it. You can additionally enable automatic application layer DDoS mitigation, which causes Shield Advanced to automatically create and manage web ACL rules on your behalf in response to DDoS attacks.
When you protect an application layer resource with Shield Advanced, Shield Advanced analyzes traffic over time to establish and maintain baselines. Shield Advanced uses these baselines to detect anomalies in traffic patterns that might indicate a DDoS attack. The point at which Shield Advanced detects an attack depends on the traffic that Shield Advanced has been able to observe prior to the attack and on the architecture you use for your web applications. The architectural variations that can affect Shield Advanced behavior include the type of instance you use, your instance size, and whether the instance type supports enhanced networking. You can also configure Shield Advanced to automatically place mitigations for application layer attacks.
**Shield Advanced subscriptions and AWS WAF costs**
Your Shield Advanced subscription covers the costs of using standard AWS WAF capabilities for resources that you protect with Shield Advanced. The standard AWS WAF fees that are covered by your Shield Advanced protections are the cost per protection pack (web ACL), the cost per rule, and the base price per million requests for web request inspection, up to 1,500 WCUs and up to the default body size.
Enabling Shield Advanced automatic application layer DDoS mitigation adds a rule group to your protection pack (web ACL) that uses 150 web ACL capacity units (WCUs). These WCUs count against the WCU usage in your protection pack (web ACL). For more information, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md), [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md), and [Web ACL capacity units (WCUs) in AWS WAF](aws-waf-capacity-units.md).
Your subscription to Shield Advanced does not cover the use of AWS WAF for resources that you do not protect using Shield Advanced. It also does not cover any additional non-standard AWS WAF costs for protected resources. Examples of non-standard AWS WAF costs are those for Bot Control, for the CAPTCHA rule action, for web ACLs that use more than 1,500 WCUs, and for inspecting the request body beyond the default body size. The full list is provided on the AWS WAF pricing page. Your subscription to Shield Advanced includes access to the Layer 7 Anti-DDoS Amazon Managed Rule group. As part of your subscription, you will get up to 50 billion requests to Shield Advanced protected AWS WAF resources in a calendar month. Requests beyond 50 billion will be billed as per the AWS Shield Advanced pricing page.
For full information and pricing examples, see [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Topics**
+ [List of factors that affect application layer event detection and mititgation with Shield Advanced](ddos-app-layer-detection-mitigation.md)
+ [Protecting the application layer with AWS WAF web ACLs and Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
+ [Protecting the application layer with AWS WAF rate-based rules and Shield Advanced](ddos-app-layer-rbr.md)
+ [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md)
# List of factors that affect application layer event detection and mititgation with Shield Advanced
This section describes the factors that affect the detection and mitigation of application layer events by Shield Advanced.
**Health checks**
Health checks that accurately report the overall health of your application provide Shield Advanced with information about the traffic conditions that your application is experiencing. Shield Advanced requires less information pointing to a potential attack when your application is reporting unhealthy and it requires more evidence of an attack if your application is reporting healthy.
It's important to configure your health checks so that they accurately report application health. For more information and guidance, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md).
**Traffic baselines**
Traffic baselines give Shield Advanced information about the characteristics of normal traffic for your application. Shield Advanced uses these baselines to recognize when your application isn't receiving normal traffic, so it can notify you and, as configured, start devising and testing mitigation options to counter a potential attack. For additional information about how Shield Advanced uses traffic baselines to detect potential events, see the overview section [Shield Advanced detection logic for application layer threats (layer 7)](ddos-event-detection-application.md).
Shield Advanced creates its baselines from information provided by the web ACL that's associated with the protected resource. The web ACL must be associated with the resource for at least 24 hours and up to 30 days before Shield Advanced can reliably determine the application's baselines. The time required begins when you associate the web ACL, either through Shield Advanced or through AWS WAF.
For more information about using a web ACL with your Shield Advanced application layer protections, see [Protecting the application layer with AWS WAF web ACLs and Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
**Rate-based rules**
Rate-based rules can help mitigate attacks. They can also obscure attacks, by mitigating them before they become a large enough problem to show up against normal traffic baselines or in health check status reporting.
We recommend using rate-based rules in your web ACL when you protect an application resource with Shield Advanced. Even though their mitigations can obscure a potential attack, they are a valuable first line of defense, helping ensure that your application stays available to your legitimate customers. The traffic that your rate-based rules detect and rate limit is visible in your AWS WAF metrics.
In addition to your own rate-based rules, if you enable automatic application layer DDoS mitigation, Shield Advanced adds a rule group to your web ACL that it uses to mitigate attacks. In this rule group, Shield Advanced always has a rate-based rule in place that limits the volume of requests from IP addresses that are known to be sources of DDoS attacks. Metrics for the traffic that the Shield Advanced rules mitigate aren't available for you to view.
For more information about rate-based rules, see [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md). For information about the rate-based rule that Shield Advanced uses for automatic application layer DDoS mitigation, see [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md).
For more information about Shield Advanced and AWS WAF metrics, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md).
# Protecting the application layer with AWS WAF web ACLs and Shield Advanced
This page explains how AWS WAF web ACLs and Shield Advanced work together to create basic application layer protections.
To protect an application layer resource with Shield Advanced, you start by associating an AWS WAF web ACL with the resource. AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to your application layer resources, and lets you control access to your content based on the characteristics of the requests. You can configure a web ACL to monitor and manage requests based on factors such as where the request originated, the contents of query strings and cookies, and the rate of requests coming from a single IP address. At a minimum, your Shield Advanced protection requires you to associate a web ACL with a rate-based rule, which limits the rate of requests for each IP address.
If the associated web ACL doesn't have a rate-based rule defined, Shield Advanced prompts you to define at least one. Rate-based rules automatically block traffic from source IPs when they exceed the thresholds that you define. They help protect your application against web request floods and can provide alerts about sudden spikes in traffic that might indicate a potential DDoS attack.
**Note**
A rate-based rule responds very quickly to spikes in the traffic that the rule is monitoring. Because of this, a rate-based rule can prevent not only an attack, but also the detection of a potential attack by Shield Advanced detection. This trade off favors prevention over complete visibility into attack patterns. We recommend using a rate-based rule as your first line of defense against attacks.
With your web ACL in place, if a DDoS attack occurs, you apply mitigations by adding and managing rules in the web ACL. You can do this directly, with the assistance of the Shield Response Team (SRT), or automatically through automatic application layer DDoS mitigation.
**Important**
If you also use automatic application layer DDoS mitigation, see the best practices for managing your web ACL at [Best practices for using automatic application layer DDoS mitigation](ddos-automatic-app-layer-response-bp.md).
For information about using AWS WAF to manage your web request monitoring and management rules, see [Creating a protection pack (web ACL) in AWS WAF](web-acl-creating.md).
# Protecting the application layer with AWS WAF rate-based rules and Shield Advanced
This page explains how AWS WAF rate-based rules and Shield Advanced work together to create basic application layer protections.
When you use a rate-based rule with its default configuration, AWS WAF periodically evaluates traffic for the prior 5-minute time window. AWS WAF blocks requests from any IP address that exceeds the rule's threshold until the request rate drops down to an acceptable level. When you configure a rate-based rule through Shield Advanced, configure its rate threshold to a value that's greater than the normal traffic rate that you expect from any one source IP in any five minute time window.
You might want to use more than one rate-based rule in a web ACL. For example, you could have one rate-based rule for all traffic that has a high threshold plus one or more additional rules that are configured to match select parts of your web application and that have lower thresholds. For example, you might match on the URI `/login.html` with a lower threshold, to mitigate abuse against a login page.
You can configure a rate-based rule to use a different evaluation time window and to aggregate requests by a number of request components, like header values, labels, and query arguments. For more information, see [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md).
For additional information and guidance, see the security blog post [The three most important AWS WAF rate-based rules](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/).
**Expanded configuration options through AWS WAF**
The Shield Advanced console enables you to add a rate-based rule and configure it with the basic, default settings. You can define additional configuration options by managing your rate-based rules through AWS WAF. For example, you can configure the rule to aggregate requests based on keys such as a forwarded IP address, a query string, and a label. You can also add a scope-down statement to the rule to filter out some requests from evaluation and rate limiting. For more information, see [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md).
# Automating application layer DDoS mitigation with Shield Advanced
**Note**
Starting March 26, 2026, the Anti-DDoS Managed Rule Group (Anti-DDOS AMR) for AWS WAF becomes the default solution for protection against HTTP request flood attacks (see the [Anti-DDoS AMR launch blog](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/)). It supersedes the Layer 7 Auto Mitigation (L7AM) feature. If you're an existing Shield Advanced customer, you can continue to use the legacy solution with existing or new AWS accounts. However, we encourage you to adopt the Anti-DDoS Managed Rule Group. The Anti-DDoS Managed Rule Group detects and mitigates attacks within seconds rather than minutes. If you're a new Shield Advanced customer and require access to the legacy solution, contact AWS Support.
This page introduces the topic of automatic application layer DDoS mitigation and lists associated caveats.
You can configure Shield Advanced to respond automatically to mitigate application layer (layer 7) attacks against your protected application layer resources, by counting or blocking web requests that are part of the attack. This option is an addition to the application layer protection that you add through Shield Advanced with an AWS WAF web ACL and your own rate-based rule.
When automatic mitigation is enabled for a resource, Shield Advanced maintains a rule group in the resource's associated web ACL where it manages mitigation rules on behalf of the resource. The rule group contains a rate-based rule that tracks the volume of requests from IP addresses that are known to be sources of DDoS attacks.
Additionally, Shield Advanced compares current traffic patterns against historic traffic baselines to detect deviations that might indicate a DDoS attack. Shield Advanced responds to detected DDoS attacks by creating, evaluating, and deploying additional, custom AWS WAF rules in the rule group.
## Caveats for using automatic application layer DDoS mitigation
The following list describes the caveats of Shield Advanced automatic application layer DDoS mitigation, and describes steps that you might want to take in response.
+ Automatic application layer DDoS mitigation works only with protection packs (web ACLs) that were created using the latest version of AWS WAF (v2).
+ Shield Advanced requires time to establish a baseline of your application's normal, historic traffic, which it leverages to detect and isolate attack traffic from normal traffic, to mitigate attack traffic. The time to establish a baseline is between 24 hours and 30 days from the time you associate a web ACL with the protected application resource. For additional information about traffic baselines, see [List of factors that affect application layer event detection and mititgation with Shield Advanced](ddos-app-layer-detection-mitigation.md).
+ Enabling automatic application layer DDoS mitigation adds a rule group to your protection pack (web ACL) that uses 150 web ACL capacity units (WCUs). These WCUs count against the WCU usage in your protection pack (web ACL). For more information, see [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md), and [Web ACL capacity units (WCUs) in AWS WAF](aws-waf-capacity-units.md).
+ The Shield Advanced rule group generates AWS WAF metrics, but they are not available to view. This is the same as for any other rule groups that you use in your protection pack (web ACL) but do not own, such as AWS Managed Rules rule groups. For more information about AWS WAF metrics, see [AWS WAF metrics and dimensions](waf-metrics.md). For information about this Shield Advanced protection option, see [Automating application layer DDoS mitigation with Shield Advanced](#ddos-automatic-app-layer-response).
+ For web ACLs that protect multiple resources, automatic mitigation only deploys custom mitigations that don't negatively impact any of the protected resources.
+ The time between the start of a DDoS attack and when Shield Advanced places custom automatic mitigation rules varies with each event. Some DDoS attacks might end before the custom rules are deployed. Other attacks might happen when a mitigation is already in place, and so might be mitigated by those rules from the start of the event. Additionally, rate-based rules in the web ACL and Shield Advanced rule group might mitigate attack traffic before it's detected as a possible event.
+ For Application Load Balancers that receive any traffic through a content delivery network (CDN), such as Amazon CloudFront, the application-layer automatic mitigation capabilities of Shield Advanced for those Application Load Balancer resources will be reduced. Shield Advanced uses client traffic attributes to identify and isolate attack traffic from normal traffic to your application, and CDNs may not preserve or forward the original client traffic attributes. If you use CloudFront, we recommend enabling automatic mitigation on the CloudFront distribution.
+ Automatic application layer DDoS mitigation does not interact with protection groups. You can enable automatic mitigation for resources that are in protection groups, but Shield Advanced does not automatically apply attack mitigations based on protection group findings. Shield Advanced applies automatic attack mitigations for individual resources.
**Contents**
+ [Caveats for using automatic application layer DDoS mitigation](#ddos-automatic-app-layer-response-caveats)
+ [Best practices for using automatic application layer DDoS mitigation](ddos-automatic-app-layer-response-bp.md)
+ [Enabling automatic application layer DDoS mitigation](ddos-automatic-app-layer-response-config.md)
+ [What happens when you enable automatic mitigation](ddos-automatic-app-layer-response-config.md#ddos-automatic-app-layer-response-enable)
+ [How Shield Advanced manages automatic mitigation](ddos-automatic-app-layer-response-behavior.md)
+ [How Shield Advanced responds to DDoS attacks with automatic mitigation](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-ddos-attack)
+ [How Shield Advanced manages the rule action setting](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)
+ [How Shield Advanced manages mitigations when an attack subsides](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-after-attack)
+ [What happens when you disable automatic mitigation](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-disable)
+ [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md)
+ [Viewing the automatic application layer DDoS mitigation configuration for a resource](view-automatic-app-layer-response-configuration.md)
+ [Enabling and disabling automatic application layer DDoS mitigation](enable-disable-automatic-app-layer-response.md)
+ [Changing the action used for automatic application layer DDoS mitigation](change-action-of-automatic-app-layer-response.md)
+ [Using AWS CloudFormation with automatic application layer DDoS mitigation](manage-automatic-mitigation-in-cfn.md)
# Best practices for using automatic application layer DDoS mitigation
Adhere to the guidance provided in this section when you use automatic mitigation.
**General protections management**
Follow these guidelines for planning and implementing your automatic mitigation protections.
+ Manage all of your automatic mitigation protections either through Shield Advanced or, if you're using AWS Firewall Manager to manage your Shield Advanced automatic mitigation settings, through Firewall Manager. Don't mix your use of Shield Advanced and Firewall Manager to manage these protections.
+ Manage similar resources using the same web ACLs and protection settings, and manage dissimilar resources using different web ACLs. When Shield Advanced mitigates a DDoS attack on a protected resource, it defines rules for the web ACL that's associated with the resource and then tests the rules against traffic of all resources that are associated with the web ACL. Shield Advanced will only apply the rules if they don't negatively impact any of the associated resources. For more information, see [How Shield Advanced manages automatic mitigation](ddos-automatic-app-layer-response-behavior.md).
+ For Application Load Balancers that have all their internet traffic proxied through a Amazon CloudFront distribution, only enable automatic mitigation on the CloudFront distribution. The CloudFront distribution will always have the greatest number of original traffic attributes, which Shield Advanced leverages to mitigate attacks.
**Detection and mitigation optimization**
Follow these guidelines to optimize the protections that automatic mitigation provides to protected resources. For an overview of application layer detection and mitigation, see [List of factors that affect application layer event detection and mititgation with Shield Advanced](ddos-app-layer-detection-mitigation.md).
+ Configure health checks for your protected resources and use them to enable health-based detection in your Shield Advanced protections. For guidance, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md).
+ Enable automatic mitigation in Count mode until Shield Advanced has established a baseline for normal, historic traffic. Shield Advanced needs from 24 hours to 30 days to establish a baseline.
Establishing a baseline of normal traffic patterns requires the following:
+ The association of a web ACL with the protected resource. You can use AWS WAF directly to associate your web ACL or you can have Shield Advanced associate it when you enable the Shield Advanced application layer protection and specify a web ACL to use.
+ Normal traffic flow to your protected application. If your application isn't experiencing normal traffic, such as before the application is launched or if it lacks production traffic for extended periods of time, the historical data can't be gathered.
**Web ACL management**
Follow these guidelines for managing the web ACLs that you use with automatic mitigation.
+ If you need to replace the web ACL that's associated with the protected resource, make the following changes in order:
1. In Shield Advanced, disable automatic mitigation.
1. In AWS WAF, disassociate the old web ACL and associate the new web ACL.
1. In Shield Advanced, enable automatic mitigation.
Shield Advanced doesn't automatically transfer automatic mitigation from the old web ACL to the new one.
+ Don't delete any rule group rule from your web ACLs whose name starts with `ShieldMitigationRuleGroup`. If you do delete this rule group, you disable the protections provided by Shield Advanced automatic mitigation for every resource that's associated with the web ACL. Additionally, it can take Shield Advanced some time to receive notice of the change and to update its settings. During this time, the Shield Advanced console pages will provide incorrect information.
For more information about the rule group, see [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md).
+ Don't modify the name of a rule group rule whose name starts with `ShieldMitigationRuleGroup`. Doing so can interfere with the protections provided by Shield Advanced automatic mitigation through the web ACL.
+ When you create rules and rule groups, don't use names that start with `ShieldMitigationRuleGroup`. This string is used by Shield Advanced to manage your automatic mitigations.
+ In your management of your web ACL rules, don't assign a priority setting of 10,000,000. Shield Advanced assigns this priority setting to its automatic mitigation rule group rule when it adds it.
+ Keep the `ShieldMitigationRuleGroup` rule prioritized so that it runs when you want it to in relation to the other rules in your web ACL. Shield Advanced adds the rule group rule to the web ACL with priority 10,000,000, to run after your other rules. If you use the AWS WAF console wizard to manage your web ACL, adjust the priority settings as needed after you add rules to the web ACL.
+ If you use AWS CloudFormation to manage your web ACLs, you don't need to manage the `ShieldMitigationRuleGroup` rule group rule. Follow the guidance at [Using AWS CloudFormation with automatic application layer DDoS mitigation](manage-automatic-mitigation-in-cfn.md).
# Enabling automatic application layer DDoS mitigation
This page explains how to configure Shield Advanced to automatically respond to application layer attacks.
You enable Shield Advanced automatic mitigation as part of the application layer DDoS protections for your resource. For information about doing this through the console, see [Configure application layer DDoS protections](manage-protection.md#configure-app-layer-protection).
The automatic mitigation functionality requires you to do the following:
+ **Associate a web ACL with the resource** – This is required for any Shield Advanced application layer protection. You can use the same web ACL for multiple resources. We recommend doing this only for resources that have similar traffic. For information about web ACLs, including the requirements for using them with multiple resources, see [How AWS WAF works](how-aws-waf-works.md).
+ **Enable and configure Shield Advanced automatic application layer DDoS mitigation** – When you enable this, you specify whether you want Shield Advanced to automatically block or count web requests that it determines to be part of a DDoS attack. Shield Advanced adds a rule group to the associated web ACL and uses it to dynamically manage its response to DDoS attacks on the resource. For information about the rule action options, see [Using rule actions in AWS WAF](waf-rule-action.md).
+ **(Optional, but recommended) Add a rate-based rule to the web ACL** – By default, the rate-based rule provides your resource with basic protection against DDoS attacks by preventing any individual IP address from sending too many requests in a short time. For information about rate-based rules, including custom request aggregation options and examples, see [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md).
## What happens when you enable automatic mitigation
Shield Advanced does the following when you enable automatic mitigation:
+ **As needed, adds a rule group for Shield Advanced use** – If the AWS WAF web ACL that you have associated with the resource doesn't already have an AWS WAF rule group rule that's dedicated to automatic application layer DDoS mitigation, Shield Advanced adds one.
The name of the rule group rule starts with `ShieldMitigationRuleGroup`. The rule group always contains a rate-based rule named `ShieldKnownOffenderIPRateBasedRule`, which limits the volume of requests from IP addresses that are known to be sources of DDoS attacks. For additional details about the Shield Advanced rule group and the web ACL rule that references it, see [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md).
+ **Starts responding to DDoS attacks against the resource** – Shield Advanced automatically responds to DDoS attacks for the protected resource. In addition to the rate-based rule, which is always present, Shield Advanced uses its rule group to deploy custom AWS WAF rules for DDoS attack mitigation. Shield Advanced tailors these rules to your application and to the attacks that your application experiences, and tests them against the resource's historical traffic before deploying them.
Shield Advanced uses a single rule group rule in any web ACL that you use for automatic mitigation. If Shield Advanced has already added the rule group for another protected resource, it doesn't add another rule group to the web ACL.
Automatic application layer DDoS mitigation depends on the presence of the rule group to mitigate attacks. If the rule group is removed from the AWS WAF web ACL for any reason, the removal disables automatic mitigation for all resources that are associated with the web ACL.
# How Shield Advanced manages automatic mitigation
The topics in this section describe how Shield Advanced handles your configuration changes for automatic application layer DDoS mitigation and how it handles DDoS attacks when automatic mitigation is enabled.
**Topics**
+ [How Shield Advanced responds to DDoS attacks with automatic mitigation](#ddos-automatic-app-layer-response-ddos-attack)
+ [How Shield Advanced manages the rule action setting](#ddos-automatic-app-layer-response-rule-action)
+ [How Shield Advanced manages mitigations when an attack subsides](#ddos-automatic-app-layer-response-after-attack)
+ [What happens when you disable automatic mitigation](#ddos-automatic-app-layer-response-disable)
## How Shield Advanced responds to DDoS attacks with automatic mitigation
When you have automatic mitigation enabled on a protected resource, the rate-based rule `ShieldKnownOffenderIPRateBasedRule` in the Shield Advanced rule group responds automatically to elevated traffic volumes from known DDoS sources. This rate-limiting is applied quickly and acts as a front-line defense against attacks.
When Shield Advanced detects an attack, it does the following:
1. Attempts to identify an attack signature that isolates the attack traffic from the normal traffic to your application. The goal is to produce high quality DDoS mitigation rules that, when placed, affect only the attack traffic and don't impact normal traffic to your application.
1. Evaluates the identified attack signature against the historical traffic patterns for the resource that's under attack as well as for any other resource that's associated with the same web ACL. Shield Advanced does this before it deploys any rules in response to the event.
Depending on the evaluation results, Shield Advanced does one of the following:
+ If Shield Advanced determines that the attack signature isolates only the traffic that is involved in the DDoS attack, it implements the signature in AWS WAF rules in the Shield Advanced mitigation rule group in the web ACL. Shield Advanced gives these rules the action setting that you've configured for the resource's automatic mitigation - either Count or Block.
+ Otherwise, Shield Advanced doesn't place a mitigation.
Throughout an attack, Shield Advanced sends the same notifications and provides the same event information as for basic Shield Advanced application layer protections. You can see the information about events and DDoS attacks, and about any Shield Advanced mitigations for attacks, in the Shield Advanced event console. For information, see [Visibility into DDoS events with Shield Advanced](ddos-viewing-events.md).
If you've configured automatic mitigation to use the Block rule action and you experience false positives from the mitigation rules that Shield Advanced has deployed, you can change the rule action to Count. For information about how to this, see [Changing the action used for automatic application layer DDoS mitigation](change-action-of-automatic-app-layer-response.md).
## How Shield Advanced manages the rule action setting
You can set the rule action for your automatic mitigations to Block or Count.
When you change the automatic mitigation rule action setting for a protected resource, Shield Advanced updates all rule settings for the resource. It updates any rules that are currently in place for the resource in the Shield Advanced rule group and it uses the new action setting when it creates new rules.
For resources that use the same web ACL, if you specify different actions, Shield Advanced uses the Block action setting for the rule group's rate-based rule `ShieldKnownOffenderIPRateBasedRule`. Shield Advanced creates and manages other rules in the rule group on behalf of a specific protected resource, and uses the action setting that you've specified for the resource. All rules in the Shield Advanced rule group in a web ACL are applied to the web traffic of all of the associated resources.
Changing the action setting can take a few seconds to propagate. During this time, you might see the old setting in some places where the rule group is in use, and the new setting in other places.
You can change the rule action setting for your automatic mitigation configuration in the events page of the console, and through the application layer configuration page. For information about the events page, see [Responding to DDoS events in AWS](ddos-responding.md). For information about the configuration page, see [Configure application layer DDoS protections](manage-protection.md#configure-app-layer-protection).
## How Shield Advanced manages mitigations when an attack subsides
When Shield Advanced determines that mitigation rules that were deployed for a particular attack are no longer needed, it removes them from the Shield Advanced mitigation rule group.
The removal of mitigating rules won't necessarily coincide with the end of an attack. Shield Advanced monitors patterns of attack that it detects on your protected resources. It might proactively defend against the recurrence of an attack with a specific signature by keeping the rules that it has deployed against the initial occurrence of that attack in place. As needed, Shield Advanced increases the window of time that it keeps rules in place. This way, Shield Advanced might mitigate repeated attacks with a specific signature before they impact your protected resources.
Shield Advanced never removes the rate-based rule `ShieldKnownOffenderIPRateBasedRule`, which limits the volume of requests from IP addresses that are known to be sources of DDoS attacks.
## What happens when you disable automatic mitigation
Shield Advanced does the following when you disable automatic mitigation for a resource:
+ **Stops automatically responding to DDoS attacks** – Shield Advanced discontinues its automatic response activities for the resource.
+ **Removes unneeded rules from the Shield Advanced rule group** – If Shield Advanced is maintaining any rules in its managed rule group on behalf of the protected resource, it removes them.
+ **Removes the Shield Advanced rule group, if it's no longer in use** – If the web ACL that you have associated with the resource isn't associated to any other resource that has automatic mitigation enabled, Shield Advanced removes its rule group rule from the web ACL.
# Protecting the application layer with the Shield Advanced rule group
This page explains how the Shield Advanced rule group works in your web ACL.
Shield Advanced manages automatic mitigation activities using rules in a rule group that it owns and manages for you. Shield Advanced references the rule group with a rule in the web ACL that you have associated with your protected resource.
**The rule group rule in your web ACL**
The Shield Advanced rule group rule in your web ACL has the following properties:
+ **Name** – `ShieldMitigationRuleGroup``_account-id_web-acl-id_unique-identifier`
+ **Web ACL capacity units (WCU)** – 150. These WCUs count against the WCU usage in your web ACL.
Shield Advanced creates this rule in your web ACL with a priority setting of 10,000,000, so that it runs after your other rules and rule groups in the web ACL. AWS WAF runs the rules in a web ACL from the lowest numeric priority setting on up. During your management of the web ACL, this priority setting might change.
The automatic mitigation functionality doesn't consume any additional AWS WAF resources in your account, other than the WCUs used by the rule group in your web ACL. For example, the Shield Advanced rule group isn't counted as one of your account's rule groups. For information about account limits in AWS WAF, see [AWS WAF quotas](limits.md).
**Rules in the rule group**
Within the referenced Shield Advanced rule group, Shield Advanced maintains a rate-based rule `ShieldKnownOffenderIPRateBasedRule`, which limits the volume of requests from IP addresses that are known to be sources of DDoS attacks. This rule serves as the first line of defense against any attack, because it's always present in the rule group and it doesn't rely on the analysis of traffic patterns to contain attacks. This rule's action is set to the action that you choose for your automatic mitigations, just like the other rules in the rule group. For information about rate-based rules, see [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md).
**Note**
The rate-based rule `ShieldKnownOffenderIPRateBasedRule` operates independent of Shield Advanced event detection. While automatic mitigation is enabled, this rule rate limits IP addresses that are known to be sources of DDoS attacks. For these IP addresses, the rule's rate limiting can prevent attacks and also keep attacks from appearing in the Shield Advanced detection information. This trade off favors prevention over complete visibility into attack patterns.
In addition to the permanent rate-based rule described above, the rule group contains any rules that Shield Advanced is currently using to mitigate DDoS attacks. Shield Advanced adds, modifies, and removes these rules as needed. For information, see [How Shield Advanced manages automatic mitigation](ddos-automatic-app-layer-response-behavior.md).
**Metrics**
The rule group generates AWS WAF metrics, but because this rule group is owned by Shield Advanced, these metrics aren't available to view. For more information, see [AWS WAF metrics and dimensions](waf-metrics.md).
# Viewing the automatic application layer DDoS mitigation configuration for a resource
You can view the automatic application layer DDoS mitigation configuration for a resource in the **Protected resources** page and in the individual protections pages.
**To view the automatic application layer DDoS mitigation configuration**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**. In the list of protected resources, the column **Automatic application layer DDoS mitigation** indicates whether automatic mitigation is enabled and, where enabled, the action that Shield Advanced is to use in its mitigations.
You can also select any application layer resource to see the same information listed on the protections page for the resource.
# Enabling and disabling automatic application layer DDoS mitigation
The following procedure shows how to enable or disable automatic response for a protected resource.
**To enable or disable automatic application layer DDoS mitigation for a single resource**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. In the **Protections** tab, select the application layer resource that you want to enable automatic mitigation for. The protections page opens for the resource.
1. In the resource's protections page, choose **Edit**.
1. In the page **Configure layer 7 DDoS mitigation for global resources - *optional***, for **Automatic application layer DDoS mitigation**, choose the option that you want to use for automatic mitigations. The options in the console are the following:
+ **Keep current settings** – Make no changes to the automatic mitigation settings of the protected resource.
+ **Enable** – Enable automatic mitigation for the protected resource. When you choose this, also select the rule action that you want the automatic mitigations to use in the web ACL rules. For information about rule action settings, see [Using rule actions in AWS WAF](waf-rule-action.md).
If your protected resource doesn’t yet have a history of normal application traffic, enable automatic mitigation in Count mode until Shield Advanced can establish a baseline. Shield Advanced begins to collect information for its baseline when you associate a web ACL with your protected resource, and it can take 24 hour to 30 days to establish a good baseline of normal traffic.
+ **Disable** – Disable automatic mitigation for the protected resource.
1. Walk through the rest of the pages until you finish and save the configuration.
In the **Protections** page, the automatic mitigation settings are updated for the resource.
# Changing the action used for automatic application layer DDoS mitigation
You can change the action that Shield Advanced uses for its application layer automatic response in multiple locations in the console:
+ **Automatic mitigation configuration** – Change the action when you configure automatic mitigation for your resource. For the procedure, see the preceding section [Enabling and disabling automatic application layer DDoS mitigation](enable-disable-automatic-app-layer-response.md).
+ **Event details page** – Change the action in the event details page, when you're viewing the event information in the console. For information, see [Viewing AWS Shield Advanced event details](ddos-event-details.md).
If you have two protected resources that share a web ACL, and you set the action to Count for one and Block for the other, Shield Advanced sets the action for the rule group's rate-based rule `ShieldKnownOffenderIPRateBasedRule` to Block.
# Using AWS CloudFormation with automatic application layer DDoS mitigation
This page explains how to use CloudFormation to manage your protections and AWS WAF web ACLs.
**Enabling or disabling automatic application layer DDoS mitigation**
You can enable and disable automatic application layer DDoS mitigation through AWS CloudFormation, using the `AWS::Shield::Protection` resource. The effect is the same as when you enable or disable the feature through the console or any other interface. For information about the CloudFormation resource, see [AWS::Shield::Protection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-shield-protection.html) in the *AWS CloudFormation user guide*.
**Managing web ACLs used with automatic mitigation**
Shield Advanced manages automatic mitigation for your protected resource using a rule group rule in the protected resource's AWS WAF web ACL. Through the AWS WAF console and APIs, you'll see the rule listed in your web ACL rules, with a name that starts with `ShieldMitigationRuleGroup`. This rule is dedicated to your automatic application layer DDoS mitigation and it's managed for you by Shield Advanced and AWS WAF. For more information, see [Protecting the application layer with the Shield Advanced rule group](ddos-automatic-app-layer-response-rg.md) and [How Shield Advanced manages automatic mitigation](ddos-automatic-app-layer-response-behavior.md).
If you use CloudFormation to manage your web ACLs, don't add the Shield Advanced rule group rule to your web ACL template. When you update a web ACL that's being used with your automatic mitigation protections, AWS WAF automatically manages the rule group rule in the web ACL.
You'll see the following differences compared to other web ACLs that you manage through CloudFormation:
+ CloudFormation won't report any drift in the stack drift status between the actual configuration of the web ACL, with the Shield Advanced rule group rule, and your web ACL template, without the rule. The Shield Advanced rule won't appear in the actual listing for the resource in the drift details.
You will be able to see the Shield Advanced rule group rule in web ACL listings that you retrieve from AWS WAF, such as through the AWS WAF console or AWS WAF APIs.
+ If you modify the web ACL template in a stack, AWS WAF and Shield Advanced automatically maintain the Shield Advanced automatic mitigation rule in the updated web ACL. The automatic mitigation protections provided by Shield Advanced are not interrupted by your update to the web ACL.
Don't manage the Shield Advanced rule in your CloudFormation web ACL template. The web ACL template shouldn't list the Shield Advanced rule. Follow the best practices for web ACL management at [Best practices for using automatic application layer DDoS mitigation](ddos-automatic-app-layer-response-bp.md).
# Health-based detection using health checks with Shield Advanced and Route 53
You can configure Shield Advanced to use health-based detection for improved responsiveness and accuracy in attack detection and mitigation. You can use this option with any resource type except for Route 53 hosted zones.
To configure health-based detection, you define a health check for your resource in Route 53, verify that it's reporting healthy, and then associate it with your Shield Advanced protection. For information about Route 53 health checks, see [How Amazon Route 53 checks the health of your resources](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html) and [Creating, updating, and deleting health checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html) in the Amazon Route 53 Developer Guide.
**Note**
Health checks are required for Shield Response Team (SRT) proactive engagement support. For information about proactive engagement, see [Setting up proactive engagement for the SRT to contact you directly](ddos-srt-proactive-engagement.md).
Health checks measure the health of your resources based on the requirements that you define. The health check status provides vital input to the Shield Advanced detection mechanisms, giving them greater sensitivity to the current state of your specific applications.
You can enable health-based detection for any resource type except for Route 53 hosted zones.
+ **Network and transport layer (layer 3/layer 4) resources** – Health-based detection improves the accuracy of network-layer and transport-layer event detection and mitigation for Network Load Balancers, Elastic IP addresses, and Global Accelerator standard accelerators. When you protect these resource types with Shield Advanced, Shield Advanced can provide mitigations for smaller attacks and faster mitigation for attacks, even when traffic is within the application’s capacity.
When you add health-based detection, during periods when the associated health check is unhealthy, Shield Advanced can place mitigations even more quickly and at even lower thresholds.
+ **Application layer (layer 7) resources** – Health-based detection improves the accuracy of web request flood detection for CloudFront distributions and Application Load Balancers. When you protect these resource types with Shield Advanced, you receive web request flood detection alerts when there's a statistically significant deviation in traffic volume that's combined with significant changes in traffic patterns, based on request characteristics.
With health-based detection, when the associated Route 53 health check is unhealthy, Shield Advanced requires smaller deviations to alert and it reports events more quickly. Conversely, when the associated Route 53 health check is healthy, Shield Advanced requires larger deviations to alert.
You'll benefit the most from using a health check with Shield Advanced if the health check only reports healthy when your application is running within acceptable parameters and only reports unhealthy when it's not. Use the guidance in this section to manage your health check associations in Shield Advanced.
**Note**
Shield Advanced doesn't automatically manage your health checks.
The following are required to use a health check with Shield Advanced:
+ The health check must report healthy when you associate it with your Shield Advanced protection.
+ The health check must be relevant to the health of your protected resource. You are responsible for defining and maintaining health checks that accurately report the health of your application, based on your application's specific requirements.
+ The health check must remain available for use by the Shield Advanced protection. Don't delete a health check in Route 53 that you're using for a Shield Advanced protection.
**Contents**
+ [Best practices for using health checks with Shield Advanced](health-checks-best-practices.md)
+ [CloudWatch metrics commonly used for health checks with Shield Advanced](health-checks-metrics.md)
+ [Metrics used to monitor application health](health-checks-metrics.md#health-checks-metrics-common)
+ [Amazon CloudWatch metrics for each resource type](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Associating a health check with your resource protected by Shield Advanced](associate-health-check.md)
+ [Disassociating a health check from your resource protected by Shield Advanced](disassociate-health-check.md)
+ [Viewing health check association status in Shield Advanced](health-check-association-status.md)
+ [Health check examples for Shield Advanced](health-checks-examples.md)
+ [Amazon CloudFront distributions](health-checks-examples.md#health-checks-example-cloudfront)
+ [Load balancers](health-checks-examples.md#health-checks-example-load-balancer)
+ [Amazon EC2 elastic IP address (EIP)](health-checks-examples.md#health-checks-example-elastic-ip)
# Best practices for using health checks with Shield Advanced
Follow the best practices in this section when you create and use health checks with Shield Advanced.
+ Plan your health checks by identifying the components of your infrastructure that you want to monitor. Consider the following resource types for health checks:
+ Critical resources.
+ Any resources where you want higher sensitivity in Shield Advanced detection and mitigation.
+ Resources for which you want Shield Advanced to proactively reach out to you. Proactive engagement is informed by the status of your health checks.
Examples of resources that you might want to monitor include Amazon CloudFront distributions, internet-facing load balancers, and Amazon EC2 instances.
+ Define health checks that accurately reflect the health of your application origin with as few notifications as possible.
+ Write health checks so that they're only unhealthy when your application is unavailable or isn't performing within acceptable parameters. You are responsible for defining and maintaining health checks based on your application's specific requirements.
+ Use as few health checks as possible while still accurately reporting on the health of your application. For example, multiple alarms from multiple areas of your application that all report the same problem might add overhead to your response activities without adding informational value.
+ Use calculated health checks to monitor application health using a combination of Amazon CloudWatch metrics. For example, you can calculate combined health based on the latency of your application servers and their 5xx error rates, which indicate that the origin server didn't fulfill the request.
+ Create and publish your own application health indicators to CloudWatch custom metrics as needed and use them in a calculated health check.
+ Implement and manage your health checks to improve detection and reduce unnecessary maintenance activities.
+ Before you associate a health check with a Shield Advanced protection, make sure that it's in a healthy state. Associating a health check that's reporting unhealthy can skew the Shield Advanced detection mechanisms for your protected resources.
+ Keep your health checks available for use by Shield Advanced. Don't delete a health check in Route 53 that you're using for a Shield Advanced protection.
+ Use staging and test environments only to test your health checks. Only maintain health check associations for environments that require production-level performance and availability. Don't maintain health check association in Shield Advanced for staging and test environments.
# CloudWatch metrics commonly used for health checks with Shield Advanced
This section lists the Amazon CloudWatch metrics that are commonly used in health checks to measure application health during distributed denial of service (DDoS) events. For full information about the CloudWatch metrics for each resource type, see the list that follows the table.
**Topics**
+ [Metrics used to monitor application health](#health-checks-metrics-common)
+ [Amazon CloudWatch metrics for each resource type](#health-checks-protected-resource-metrics)
## Metrics used to monitor application health
| Resource | Metric | Description |
| --- | --- | --- |
| Route 53 | `HealthCheckStatus` | The status of the health check endpoint. |
| CloudFront | `5xxErrorRate` | The percentage of all requests for which the HTTP status code is 5xx. This indicates an attack that's impacting the application. |
| Application Load Balancer | `HTTPCode_ELB_5XX_Count` | The number of HTTP 5xx client error codes generated by the load balancer. |
| Application Load Balancer | `RejectedConnectionCount` | The number of connections that were rejected because the load balancer reached its maximum number of connections. |
| Application Load Balancer | `TargetConnectionErrorCount` | The number of connections that were not successfully established between the load balancer and the target. |
| Application Load Balancer | `TargetResponseTime` | The time elapsed in seconds after the request leaves the load balancer and when it receives a response from the target. |
| Application Load Balancer | `UnHealthyHostCount` | The number of targets that are considered unhealthy. |
| Amazon EC2 | `CPUUtilization` | The percentage of allocated EC2 compute units that are currently in use. |
## Amazon CloudWatch metrics for each resource type
For additional information about the metrics that are available for your protected resources, see the following sections in the resource guides:
+ Amazon Route 53 – [Monitoring your resources with Amazon Route 53 health checks and Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html) in the Amazon Route 53 Developer Guide.
+ Amazon CloudFront – [Monitoring CloudFront with Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html) in the Amazon CloudFront Developer Guide.
+ Application Load Balancer – [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) in the User Guide for Application Load Balancers.
+ Network Load Balancer – [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) in the User Guide for Network Load Balancers.
+ AWS Global Accelerator – [Using Amazon CloudWatch with AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) in the AWS Global Accelerator Developer Guide.
+ Amazon Elastic Compute Cloud – [List the available CloudWatch metrics for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) in the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/.
+ Amazon EC2 Auto Scaling – [Monitoring CloudWatch metrics for your Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) in the Amazon EC2 Auto Scaling User Guide.
# Associating a health check with your resource protected by Shield Advanced
The following procedure shows how to associate an Amazon Route 53 health check with a protected resource.
**Note**
Before you associate a health check with a Shield Advanced protection, make sure that it's in a healthy state. For information, see [Monitoring health check status and getting notifications](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html) in the Amazon Route 53 Developer Guide.
**To associate a health check**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. On the **Protections** tab, select the resource that you want to associate with a health check.
1. Choose **Configure protections**.
1. Choose **Next** until you get to the page **Configure health check based DDoS detection - *optional***.
1. Under **Associated Health Check**, choose the ID of the health check that you want to associate with the protection.
**Note**
If you do not see the health check you need, go to the Route 53 console and verify the health check and its ID. For information, see [Creating and Updating Health Checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Walk through the rest of the pages until you finish the configuration. On the **Protections** page, your updated health check association is listed for the resource.
1. On the **Protections** page, check that your newly associated health check is reporting healthy.
You can't successfully begin using a health check in Shield Advanced while the health check is reporting unhealthy. Doing so causes Shield Advanced to detect false positives at very low thresholds and can also negatively impact the ability of the Shield Response Team (SRT) to provide proactive engagement for the resource.
If the newly associated health check is reporting unhealthy, do the following:
1. Disassociate the health check from your protection in Shield Advanced.
1. Revisit your health check specifications in Amazon Route 53 and verify your overall application performance and availability.
1. When your application is performing within your parameters for good health and your health check is reporting healthy, try again to associate the health check in Shield Advanced.
The health check association procedure is complete when you've established your new health check association and it reports healthy in Shield Advanced.
# Disassociating a health check from your resource protected by Shield Advanced
The following procedure shows how to disassociate an Amazon Route 53 health check from a protected resource.
**To disassociate a health check**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. On the **Protections** tab, select the resource that you want to disassociate from a health check.
1. Choose **Configure protections**.
1. Choose **Next** until you get to the page **Configure health check based DDoS detection - *optional***.
1. Under **Associated Health Check**, choose the empty option, listed as **-**.
1. Walk through the rest of the pages until you finish the configuration.
On the **Protections** page, the health check field for your resource is set to **-**, indicating no health check association.
# Viewing health check association status in Shield Advanced
You can see the status of the health check that's associated with a protection on the AWS WAF & Shield console **Protected resources** page and on the details page of each resource.
+ **Healthy** – The health check is available and is reporting healthy.
+ **Unhealthy** – The health check is available and is reporting unhealthy.
+ **Unavailable** – The health check is not available for use by Shield Advanced.
**To resolve an **Unavailable** health check**
Create and use a new health check. Don't try to associate a health check again after it has had a status of unavailable in Shield Advanced.
For detailed guidance on following these steps, see the preceding topics.
1. In Shield Advanced, disassociate the health check from the resource.
1. In Route 53, create a new health check for the resource and note its ID. For information, see [Creating and Updating Health Checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html) in the Amazon Route 53 Developer Guide.
1. In Shield Advanced, associate the new health check with the resource.
# Health check examples for Shield Advanced
This section shows examples of health checks that you could use in a calculated health check. A calculated health check uses a number of individual health checks to determine a combined status. The status of each individual health check is based on the health of an endpoint or on the state of an Amazon CloudWatch metric. You combine health checks into a calculated health check and then configure your calculated health check to report health based on the combined health status of the individual health checks. Tune the sensitivity of your calculated health checks according to your requirements for application performance and availability.
For information about calculated health checks, see [Monitoring other health checks (calculated health checks)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated) in the Amazon Route 53 Developer Guide. For additional information, see the blog post [Route 53 Improvements – Calculated Health Checks and Latency Checks](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/).
**Topics**
+ [Amazon CloudFront distributions](#health-checks-example-cloudfront)
+ [Load balancers](#health-checks-example-load-balancer)
+ [Amazon EC2 elastic IP address (EIP)](#health-checks-example-elastic-ip)
## Amazon CloudFront distributions
The following examples describe health checks that could be combined into a calculated health check for a CloudFront distribution:
+ Monitor an endpoint by specifying a domain name to a path on the distribution that's serving dynamic content. A healthy response would include HTTP response codes 2xx and 3xx.
+ Monitor the state of a CloudWatch alarm that's measuring the health of the CloudFront origin. For example, you can maintain a CloudWatch alarm on the Application Load Balancer metric `TargetResponseTime`, and create a health check that reflects the status of the alarm. The health check can be unhealthy when the response time, between request leaving the load balancer and when the load balancer receives a response from the target, exceeds the threshold configured in the alarm.
+ Monitor the state of a CloudWatch alarm that measures the percentage of requests for which the response’s HTTP status code is 5xx. If the CloudFront distribution's 5xx error rate is higher than the threshold defined in the CloudWatch alarm, the status of this health check will switch to unhealthy.
## Load balancers
The following examples describe health checks that could be used in calculated health checks for an Application Load Balancer, Network Load Balancer, or Global Accelerator standard accelerator.
+ Monitor the state of a CloudWatch alarm that measures the number of new connections established by clients to the load balancer. You can set the alarm threshold for the average number of new connections at some degree higher than your every day average. The metrics for each resource type are the following:
+ Application Load Balancer: `NewConnectionCount`
+ Network Load Balancer: `ActiveFlowCount`
+ Global Accelerator: `NewFlowCount`
+ For Application Load Balancer and Network Load Balancer, monitor the state of a CloudWatch alarm that measures the number of load balancers that are considered healthy. You can set the alarm threshold either on Availability Zone or on the minimum number of healthy hosts that your load balancer requires. The available metrics for the load balancer resources are as follows:
+ Application Load Balancer: `HealthyHostCount`
+ Network Load Balancer: `HealthyHostCount`
+ For Application Load Balancer, monitor the state of a CloudWatch alarm that measures the number of HTTP 5xx response codes generated by the load balancer targets. For an Application Load Balancer, you can use the metric `HTTPCode_Target_5XX_Count` and base the alarm threshold on the sum of all 5xx errors for the load balancer.
## Amazon EC2 elastic IP address (EIP)
The following example health checks could be combined into a calculated health check for an Amazon EC2 elastic IP address:
+ Monitor an endpoint by specifying an IP address to the Elastic IP address. The health check will remain healthy as long as a TCP connection can be established with the resource behind the IP address.
+ Monitor the state of a CloudWatch alarm that measures the percentage of allocated Amazon EC2 compute units that are currently in use on the instance. You can use the Amazon EC2 metric `CPUUtilization` and base the alarm threshold on what you consider to be a high CPU utilization rate for your application, such as 90%.
# Adding AWS Shield Advanced protection to AWS resources
Follow the guidance in this section to add Shield Advanced protection to one or more resources.
**To add protection for an AWS resource**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the navigation pane, under AWS Shield choose **Protected resources**.
1. Choose **Add resources to protect**.
1. In the **Choose resources to protect with Shield Advanced** page, in **Specify the Region and resource types**, provide the Region and resource type specifications for the resources that you want to protect. You can protect resources in multiple Regions by selecting **All Regions** and you can narrow the selection to global resources by selecting **Global**. You can deselect any resource types that you do not want to protect. For information about protections for your resource types, see [List of resources that AWS Shield Advanced protects](ddos-protections-by-resource-type.md).
1. Choose **Load resources**. Shield Advanced populates the **Select Resources** section with the AWS resources that match your criteria.
1. In the **Select Resources** section, you can filter the list of resources by entering a string to search for in the resource listings.
Select the resources that you want to protect.
1. In the **Tags** section, if you want to add tags to the Shield Advanced protections that you are creating, specify those. For information about tagging AWS resources, see [Working with Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Choose **Protect with Shield Advanced**. This adds Shield Advanced protections to the resources.
# Editing AWS Shield Advanced protections
You can change the settings for your AWS Shield Advanced protections at any time. To do this, walk through the options for your selected protections and modify the settings that you need to change.
**To manage protected resources**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. In the **Protections** tab, select the resources that you want to protect.
1. Choose **Configure protections** and the resource specification option that you want.
1. Walk through each of the resource protection options, making changes as needed.
## Configure application layer DDoS protections
For protection against attacks on Amazon CloudFront and Application Load Balancer resources, you can add AWS WAF web ACLs and add rate-based rules. For information about this, see [Protecting the application layer with AWS WAF web ACLs and Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
You can also enable the Shield Advanced automatic application layer DDoS mitigation. For information about how AWS WAF works, see [AWS WAF](waf-chapter.md). For information about the automatic mitigation feature, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md).
**Important**
If you manage your Shield Advanced protections through AWS Firewall Manager using a Shield Advanced policy, you can't manage the application layer protections here. For all other resources, we recommend that, at a minimum, you attach a web ACL to each resource, even if web ACL doesn't contain any rules.
**Note**
When you enable automatic application layer DDoS mitigation for a resource, if needed, the operation automatically adds a service-linked role to your account to give Shield Advanced the permissions it needs to manage your web ACL protections. For information, see [Using service-linked roles for Shield Advanced](shd-using-service-linked-roles.md).
**To configure application layer DDoS protections**
1. In the **Configure layer 7 DDoS protections** page, if the resource isn't already associated with a web ACL, you can choose an existing web ACL or create your own.
To create a web ACL, follow these steps:
1. Choose **Create web ACL**.
1. Enter a name. You can't change the name after you create the web ACL.
1. Choose **Create**.
**Note**
If a resource is already associated with a web ACL, you can't change to a different web ACL. If you want to change the web ACL, you must first remove the associated web ACLs from the resource. For more information, see [Associating or disassociating protection with an AWS resource](web-acl-associating-aws-resource.md).
1. If the web ACL doesn't have a rate-based rule defined, you can add one by choosing **Add rate limit rule** and then performing the following steps:
1. Enter a name.
1. Enter a rate limit. This is the maximum number of requests allowed in any five minute period from any single IP address before the rate-based rule action is applied to the IP address. When the requests from the IP address fall below the limit, the action is discontinued.
1. Set the rule action to count or block requests from IP addresses while their request counts are over the limit. The application and removal of the rule action might take effect a minute or two after the IP address request rate changes.
1. Choose **Add rule**.
1. For **Automatic application layer DDoS mitigation**, choose whether you want Shield Advanced to automatically mitigate DDoS attacks on your behalf, as follows:
+ To enable automatic mitigation, choose **Enable** and then select the AWS WAF rule action that you want Shield Advanced to use in its custom rules. Your choices are Count and Block. For information about these AWS WAF rule actions, see [Using rule actions in AWS WAF](waf-rule-action.md). For information about how Shield Advanced manages this action setting, see [How Shield Advanced manages the rule action setting](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action).
+ To disable automatic mitigation, choose **Disable**.
+ To leave the automatic mitigation settings unchanged for the resources that you're managing, leave the default choice **Keep current settings**.
For information about Shield Advanced automatic application layer DDoS mitigation, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md).
1. Choose **Next**.
# Creating alarms and notifications for resources protected by Shield Advanced
The following procedure shows how to manage CloudWatch alarms for protected resources.
**Note**
CloudWatch incurs additional costs. For CloudWatch pricing, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
**To create alarms and notifications**
1. In the protections page **Create alarms and notifications - *optional***, configure the SNS topics for the alarms and notifications that you want to receive. For resources that you don't want notifications for, choose **No topic**. You can add an Amazon SNS topic or create a new topic.
1. To create an Amazon SNS topic, follow these steps:
1. In the dropdown list, choose **Create an SNS topic**.
1. Enter a topic name.
1. Optionally enter an email address that the Amazon SNS messages will be sent to, and then choose **Add email**. You can enter more than one.
1. Choose **Create**.
1. Choose **Next**.
# Removing AWS Shield Advanced protection from an AWS resource
You can remove AWS Shield Advanced protection from any of your AWS resources at any time.
**Important**
Deleting an AWS resource doesn't remove the resource from AWS Shield Advanced. You must also remove the protection on the resource from AWS Shield Advanced, as described in this procedure.
**Remove AWS Shield Advanced protection from an AWS resource**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. In the **Protections** tab, select the resources whose protections you want to remove.
1. Choose **Delete protections**.
1. If you have an Amazon CloudWatch alarm configured for a protection, you are given the option to delete the alarm along with the protection. If you choose not to delete the alarm at this point, you can instead delete it later using the CloudWatch console.
**Note**
For protections that have an Amazon Route 53 health check configured, if you add the protection again later, the protection still includes the health check.
The preceding steps remove AWS Shield Advanced protection from specific AWS resources. They don't cancel your AWS Shield Advanced subscription. You will continue to be charged for the service. For information about your AWS Shield Advanced subscription, contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/).
## Removing a CloudWatch alarm from your Shield Advanced protections
To remove a CloudWatch alarm from your Shield Advanced protections, do one of the following:
+ Delete the protection as described in [Removing AWS Shield Advanced protection from an AWS resource](#remove-protection). Be sure to select the check box next to **Also delete related DDoSDetection alarm**.
+ Delete the alarm using the CloudWatch console. The name of the alarm to delete starts with **DDoSDetectedAlarmForProtection**.
# Grouping your AWS Shield Advanced protections
Use protection groups to create logical collections of your protected resources and manage their protections as a group. For information about managing resource protections, see [Editing AWS Shield Advanced protections](manage-protection.md).
**Note**
Automatic application layer DDoS mitigation does not interact with protection groups. You can enable automatic mitigation for resources that are in protection groups, but Shield Advanced does not automatically apply attack mitigations based on protection group findings. Shield Advanced applies automatic attack mitigations for individual resources.
AWS Shield Advanced protection groups give you a self-service way to customize the scope of detection and mitigation by treating multiple protected resources as a single unit. Resource grouping can provide a number of benefits.
+ Improve accuracy of detection.
+ Reduce unactionable event notifications.
+ Increase coverage of mitigation actions to include protected resources that also might be affected during an event.
+ Accelerate time to mitigation of attacks with multiple similar targets.
+ Facilitate automatic protection of newly created protected resources.
Protection groups can help reduce false positives in situations such as blue/green swap, where resources alternate between being near zero load and fully loaded. Another example is when you create and delete resources frequently while maintaining a load level that's shared among the members of the group. For situations such as these, monitoring individual resources can lead to false positives, while monitoring the health of the group of resources does not.
You can configure protection groups to include all protected resources, all resources of specific resource types, or individually specified resources. Newly protected resources that satisfy your protection group criteria are automatically included in your protection group. A protected resource can belong to multiple protection groups.
# Creating a Shield Advanced protection group
**To create a protection group**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. Choose the **Protection groups** tab, then choose **Create protection group**.
1. In the **Create protection group** page, provide a name for your group. You'll use this name to identify the group in your list of protected resources. You can't change the name of a protection group after you create it.
1. For **Protection grouping criteria**, select the criteria that you want Shield Advanced to use to identify the protected resources to include in the group. Make your additional selections based on the criteria that you've chosen.
1. For **Aggregation**, select how you want Shield Advanced to combine resource data for the group in order to detect, mitigate, and report events.
+ **Sum** – Use the total traffic across the group. This is a good choice for most cases. Examples include Elastic IP addresses for Amazon EC2 instances that scale manually or automatically.
+ **Mean** – Use the average of the traffic across the group. This is a good choice for resources that share traffic uniformly. Examples include accelerators and load balancers.
+ **Max** – Use the highest traffic from each resource. This is useful for resources that don't share traffic, and for resources that share traffic in a non-uniform way. Examples include Amazon CloudFront distributions and origin resources for CloudFront distributions.
1. Choose **Save** to save your protection group and return to the **Protected resources** page.
In the **Shield** **Events** page, you can view events for your protection group and drill down to see additional information for the protected resources that are in the group.
# Updating a Shield Advanced protection group
**To update a protection group**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. In the **Protection groups** tab, select the check box next to the protection group that you want to modify.
1. In the protection group's page, choose **Edit**. Make your changes to the protection group settings.
1. Choose **Save** to save your changes.
# Deleting a Shield Advanced protection group
**To delete a protection group**
1. Sign in to the AWS Management Console and open the AWS WAF & Shield console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. In the AWS Shield navigation pane, choose **Protected resources**.
1. In the **Protection groups** tab, select the check box next to the protection group that you want to remove.
1. In the protection group's page, choose **Delete** and confirm the action.
# Tracking Shield Advanced resource protection changes in AWS Config
This page explains how to record changes to the AWS Shield Advanced protection of your resources using AWS Config. You can then use this information to maintain a configuration change history for audit and troubleshooting purposes.
To record protection changes, enable AWS Config for each resource that you want to track. For more information, see [Getting Started with AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) in the *AWS Config Developer Guide*.
You must enable AWS Config for each AWS Region that contains the tracked resources. You can enable AWS Config manually, or you can use the CloudFormation template "Enable AWS Config" at [CloudFormation StackSets Sample Templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html) in the *CloudFormation User Guide*.
If you enable AWS Config, you're charged as detailed on the [AWS Config Pricing](https://aws.amazon.com/config/pricing/) page.
**Note**
If you already have AWS Config enabled for the necessary Regions and resources, you don't need to do anything. AWS Config logs regarding protection changes to your resources start populating automatically.
After enabling AWS Config, use the US East (N. Virginia) Region in the AWS Config console to view the configuration change history for AWS Shield Advanced global resources.
View the change history for AWS Shield Advanced regional resources via the AWS Config console in the US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), and Asia Pacific (Sydney) Regions.