**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 Shield
<a name="shield-chapter"></a>

Protection against Distributed Denial of Service (DDoS) attacks is of primary importance for your internet-facing applications. When you build your application on AWS, you can make use of protections that AWS provides at no additional cost. Additionally, you can use the AWS Shield Advanced managed threat protection service to improve your security posture with additional DDoS detection, mitigation, and response capabilities. 

AWS is committed to providing you with the tools, best practices, and services to help ensure high availability, security, and resiliency in your defense against bad actors on the internet. This guide is provided to help IT decision makers and security engineers understand how to use Shield and Shield Advanced to better protect their applications from DDoS attacks and other external threats. 

When you build your application on AWS, you receive automatic protection by AWS against common volumetric DDoS attack vectors, like UDP reflection attacks and TCP SYN floods. You can leverage these protections to ensure the availability of the applications that you run on AWS by designing and configuring your architecture for DDoS resiliency. 

This guide provides recommendations that can help you design, create, and configure your application architectures for DDoS resiliency. Applications that adhere to the best practices provided in this guide can benefit from an improved continuity of availability when they are targeted by larger DDoS attacks and by wider ranges of DDoS attack vectors. Additionally, this guide shows you how to use Shield Advanced to implement an optimized DDoS protection posture for your critical applications. These include applications for which you've guaranteed a certain level of availability to your customers and those that require operational support from AWS during DDoS events.

Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. The effectiveness of our security is regularly tested and verified by third-party auditors as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Shield Advanced, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your organization’s requirements, and applicable laws and regulations. 

![\[A diagram shows a rectangle that's split horizontally. The top half is titled Customer: Responsibility for security 'in' the cloud and the bottom half is titled AWS: Responsibility for security 'of' the cloud. The top customer half contains four tiers. The top one is Customer data. The second one is Platform, applications, identity and access management. The third one is Operating system, network and firewall configuration. The fourth and bottom tier for the customer area is split into three sections that are side by side. The left of these is Client-side data, encryption and data integrity, authentication. The middle one is Server-side encryption (file system and/or data). The right one is Networking traffic protection (encryption, integrity, identity). This concludes the contents of the top customer half of the figure. The bottom AWS half of the figure, contains a tier titled Software at the top and below it, a tier titled Hardware/AWS global infrastructure. The software tier is split into four subsections that are side by side and that read Compute, Storage, Database, Networking. The hardware tier is split into three subsections that are side by side and that read Regions, Availability Zones, edge locations.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shared-responsibility-model.png)


# How AWS Shield and Shield Advanced work
<a name="ddos-overview"></a>

This page explains the difference between AWS Shield Standard and AWS Shield Advanced. It also describes the classes of attacks that Shield detects.

AWS Shield Standard and AWS Shield Advanced provide protections against Distributed Denial of Service (DDoS) attacks for AWS resources at the network and transport layers (layer 3 and 4) and the application layer (layer 7). A DDoS attack is an attack in which multiple compromised systems try to flood a target with traffic. A DDoS attack can prevent legitimate end users from accessing the target services and can cause the target to crash due to overwhelming traffic volume. 

AWS Shield provides protection against a wide range of known DDoS attack vectors and zero-day attack vectors. Shield detection and mitigation is designed to provide coverage against threats even if they are not explicitly known to the service at the time of detection.

Shield Standard is provided automatically and at no extra charge when you use AWS. For higher levels of protection against attacks, you can subscribe to AWS Shield Advanced.

Classes of attacks that Shield detects include the following:
+ **Network volumetric attacks (layer 3)** – This is a sub category of infrastructure layer attack vectors. These vectors attempt to saturate the capacity of the targeted network or resource, to deny service to legitimate users.
+ **Network protocol attacks (layer 4)** – This is a sub category of infrastructure layer attack vectors. These vectors abuse a protocol to deny service to the targeted resource. A common example of a network protocol attack is a TCP SYN flood, which can exhaust connection state on resources like servers, load balancers, or firewalls. A network protocol attack can also be volumetric. For example, a larger TCP SYN flood may intend to saturate the capacity of a network while also exhausting the state of the targeted resource or intermediate resources.
+ **Application layer attacks (layer 7)** – This category of attack vector attempts to deny service to legitimate users by flooding an application with queries that are valid for the target, such as web request floods.

**Contents**
+ [AWS Shield Standard overview](ddos-standard-summary.md)
+ [AWS Shield Advanced overview](ddos-advanced-summary.md)
+ [List of AWS resources that AWS Shield Advanced protects](ddos-advanced-summary-protected-resources.md)
+ [AWS Shield Advanced capabilities and options](ddos-advanced-summary-capabilities.md)
+ [Deciding whether to subscribe to AWS Shield Advanced and apply additional protections](ddos-advanced-summary-deciding.md)
+ [Examples of DDoS attacks](types-of-ddos-attacks.md)
+ [How AWS Shield detects events](ddos-event-detection.md)
  + [AWS Shield detection logic for infrastructure layer threats (layer 3 and layer 4)](ddos-event-detection-infrastructure.md)
  + [Shield Advanced detection logic for application layer threats (layer 7)](ddos-event-detection-application.md)
  + [Shield Advanced detection logic for multiple resources in an application](ddos-event-detection-multiple-resources.md)
+ [How AWS Shield mitigates events](ddos-event-mitigation.md)
  + [List of AWS Shield DDoS mitigation features](ddos-event-mitigation-features.md)
  + [AWS Shield mitigation logic for CloudFront and Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
  + [AWS Shield mitigation logic for AWS Regions](ddos-event-mitigation-logic-regions.md)
  + [AWS Shield mitigation logic for AWS Global Accelerator standard accelerators](ddos-event-mitigation-logic-gax.md)
  + [AWS Shield Advanced mitigation logic for Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
  + [AWS Shield Advanced mitigation logic for web applications](ddos-event-mitigation-logic-adv-web-app.md)

# AWS Shield Standard overview
<a name="ddos-standard-summary"></a>

AWS Shield is a managed threat protection service that protects the perimeter of your application. The perimeter is the first point of entry for application traffic coming from outside the AWS network. 

To determine where your application perimeter lies, consider how users access your application from the internet. If the first point of entry is in an AWS Region, then the application perimeter is your Amazon Virtual Private Cloud (VPC). If users are directed to your application by Amazon Route 53, and first access the application using Amazon CloudFront or AWS Global Accelerator, then the application perimeter begins at the edge of the AWS network. 

Shield provides DDoS detection and mitigation benefits for all applications running on AWS, but the decisions that you make when you design your application architecture will influence your level of DDoS resiliency. DDoS Resiliency is your application’s ability to continue operating within expected parameters during an attack. 

All AWS customers benefit from the automatic protection of Shield Standard, at no additional charge. Shield Standard defends against the most common, frequently occurring network and transport layer DDoS attacks that target your website or applications. While Shield Standard helps protect all AWS customers, you get particular benefit with Amazon Route 53 hosted zones, Amazon CloudFront distributions, and AWS Global Accelerator standard accelerators. These resources receive comprehensive availability protection against all known network and transport layer attacks.

# AWS Shield Advanced overview
<a name="ddos-advanced-summary"></a>

AWS Shield Advanced is a managed service that helps you protect your application against external threats, like DDoS attacks, volumetric bots, and vulnerability exploitation attempts. For higher levels of protection against attacks, you can subscribe to AWS Shield Advanced. 

When you subscribe to Shield Advanced and add protection to your resources, Shield Advanced provides expanded DDoS attack protection for those resources. The protections that you receive from Shield Advanced can vary depending on your architecture and configuration choices. Use the information in this guide to build and protect resilient applications using Shield Advanced, and to escalate when you need expert help. 

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

**Shield Advanced subscription billing**  
If you’re an AWS Channel Reseller, talk to your account team for information and guidance. This billing information is for customers that are not AWS Channel Resellers. 

For all others, the following subscription and billing guidelines apply:
+ For accounts that are members of an AWS Organizations organization, AWS bills the Shield Advanced subscriptions against the payer account for the organization, regardless of whether the payer account itself is subscribed. 
+ When you subscribe multiple accounts that are in the same [AWS Organizations consolidated billing account family](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), one subscription price covers all subscribed accounts in the family. The organization must own all of the AWS accounts and all of their resources. 
+ When you subscribe multiple accounts for multiple organizations, you can still pay one subscription fee across all of the organizations, accounts, and resources providing you own all of them. Contact your account manager or AWS support and request a fee waiver on the AWS Shield Advanced subscription charges for all but one of the organizations. 

For detailed pricing information and examples, see [AWS Shield Pricing](https://aws.amazon.com/shield/pricing/). 

**Topics**

# List of AWS resources that AWS Shield Advanced protects
<a name="ddos-advanced-summary-protected-resources"></a>

**Note**  
Shield Advanced protections are only enabled for resources that you have explicitly specified in Shield Advanced or that you protect through an AWS Firewall Manager Shield Advanced policy. Shield Advanced 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. 

For additional information about protections for these resource types, see [List of resources that AWS Shield Advanced protects](ddos-protections-by-resource-type.md).

# AWS Shield Advanced capabilities and options
<a name="ddos-advanced-summary-capabilities"></a>

AWS Shield Advanced subscription includes the following capabilities and options. These supplement the DDoS detection and mitigation capabilities that you already receive with AWS. 
+ **AWS WAF integration** – Shield Advanced uses AWS WAF web ACLs, rules, and rule groups as part of its application layer protections. For more information about AWS WAF, see [How AWS WAF works](how-aws-waf-works.md). 
**Note**  
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/).
+ **Automatic application layer DDoS mitigation** – You can configure Shield Advanced to respond automatically to mitigate application layer (layer 7) attacks against your protected resources. With automatic mitigation, Shield Advanced enforces AWS WAF rate limiting on requests from known DDoS sources, and it automatically adds and manages custom AWS WAF protections in response to detected DDoS attacks. You can configure automatic mitigation to count or block the web requests that are part of an attack. 

  For more information, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Health-based detection** – You can use Amazon Route 53 health checks with Shield Advanced to inform event detection and mitigation. Health checks monitor your application according to your specifications, reporting healthy when your specifications are met and unhealthy when they aren't. Using health checks with Shield Advanced helps prevent false positives and provides faster detection and mitigation when a protected resource is unhealthy. You can use health-based detection for any resource type except Route 53 hosted zones. Shield Advanced proactive engagement is available only for resources that have health-based detection enabled. 

  For more information, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md).
+ **Protection groups** – You can use protection groups to create logical groupings of your protected resources, for enhanced detection and mitigation of the group as a whole. You can define the criteria for membership in a protection group so that newly protected resources are automatically included. A protected resource can belong to multiple protection groups. 

  For more information, see [Grouping your AWS Shield Advanced protections](ddos-protection-groups.md).
+ **Enhanced visibility into DDoS events and attacks** – Shield Advanced gives you access to advanced, real-time metrics and reports for extensive visibility into events and attacks on your protected AWS resources. You can access this information through the Shield Advanced API and console, and through Amazon CloudWatch metrics. 

  For more information, see [Visibility into DDoS events with Shield Advanced](ddos-viewing-events.md).
+ **Centralized management of Shield Advanced protections by AWS Firewall Manager** – You can use Firewall Manager to automatically apply Shield Advanced protections to your new accounts and resources and to deploy AWS WAF rules to your web ACLs. Firewall Manager Shield Advanced protection policies are included at no additional charge for Shield Advanced customers. You can also centralize your Shield Advanced monitoring activities for your accounts by using Firewall Manager with an Amazon Simple Notification Service (SNS) topic or AWS Security Hub CSPM. 

  For more information about using Firewall Manager to manage Shield Advanced protections, see [AWS Firewall Manager](fms-chapter.md) and [Using AWS Shield Advanced policies in Firewall Manager](shield-policies.md). For information about Firewall Manager pricing, see [AWS Firewall Manager Pricing](https://aws.amazon.com/firewall-manager/pricing/).
+ **AWS Shield Response Team (SRT)** – The SRT has deep experience in protecting AWS, Amazon.com, and its subsidiaries. As an AWS Shield Advanced customer, you can contact the SRT at any time for assistance during a DDoS attack that affects the availability of your application. You can also work with the SRT to create and manage custom mitigations for your resources. To use the services of the SRT, you must also be subscribed to the [Business Support plan](https://aws.amazon.com/premiumsupport/business-support/) or the [Enterprise Support plan](https://aws.amazon.com/premiumsupport/enterprise-support/).

  For more information, see [Managed DDoS event response with Shield Response Team (SRT) support](ddos-srt-support.md).
+ **Proactive engagement** – With proactive engagement, the Shield Response Team (SRT) contacts you directly if the Amazon Route 53 health check that you have associated with your protected resource becomes unhealthy during an event that's detected by Shield Advanced. This gives you quicker engagement with experts when the availability of your application might be affected by a suspected attack. 

  For more information, see [Setting up proactive engagement for the SRT to contact you directly](ddos-srt-proactive-engagement.md).
+ **Cost protection opportunities** – Shield Advanced offers some cost protection against spikes in your AWS bill that might result from a DDoS attack against your protected resources. This can include coverage for spikes in Shield Advanced data transfer out (DTO) usage fees. Shield Advanced provides any cost protection in the form of Shield Advanced service credits.

  For more information, see [Requesting a credit in AWS Shield Advanced after an attack](ddos-request-service-credit.md). 

# Deciding whether to subscribe to AWS Shield Advanced and apply additional protections
<a name="ddos-advanced-summary-deciding"></a>

Review the scenarios in this section for help deciding which accounts to subscribe to AWS Shield Advanced and where to apply additional protections. With Shield Advanced, you pay one monthly subscription fee for all accounts created under a consolidated billing account, plus usage fees based on GB of data transferred out. For information about Shield Advanced pricing, see [AWS Shield Advanced Pricing](https://aws.amazon.com/shield/pricing/).

To protect an application and its resources with Shield Advanced, you subscribe the accounts that manage the application to Shield Advanced and then you add protections to the application's resources. For information about subscribing accounts and protecting resources, see [Setting up AWS Shield Advanced](getting-started-ddos.md).

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

**Shield Advanced subscription billing**  
If you’re an AWS Channel Reseller, talk to your account team for information and guidance. This billing information is for customers that are not AWS Channel Resellers. 

For all others, the following subscription and billing guidelines apply:
+ For accounts that are members of an AWS Organizations organization, AWS bills the Shield Advanced subscriptions against the payer account for the organization, regardless of whether the payer account itself is subscribed. 
+ When you subscribe multiple accounts that are in the same [AWS Organizations consolidated billing account family](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), one subscription price covers all subscribed accounts in the family. The organization must own all of the AWS accounts and all of their resources. 
+ When you subscribe multiple accounts for multiple organizations, you can still pay one subscription fee across all of the organizations, accounts, and resources providing you own all of them. Contact your account manager or AWS support and request a fee waiver on the AWS Shield Advanced subscription charges for all but one of the organizations. 

For detailed pricing information and examples, see [AWS Shield Pricing](https://aws.amazon.com/shield/pricing/). 

**Identifying the applications to protect**  
Consider implementing Shield Advanced protections for applications where you need any of the following: 
+ Guaranteed availability for the users of the application. 
+ Rapid access to DDoS mitigation experts if the application is affected by a DDoS attack.
+ Awareness by AWS that the application might be affected by a DDoS attack and notification of attacks from AWS and escalation to your security or operations teams.
+ Predictability in your cloud costs, including when a DDoS attack affects your use of AWS services.

If an application or its resources require any of the above, consider creating subscriptions for the related accounts. 

**Identifying the resources to protect**  
For each subscribed account, consider adding a Shield Advanced protection to each resource that has any of the following characteristics:
+ The resource serves external users on the internet. 
+ The resource is exposed to the internet and is also part of a critical application. Consider every exposed resource, regardless of whether you intend it to be accessed by users on the internet. 
+ The resource is protected by an AWS WAF web ACL.

To learn more about creating and managing protections for your resources, see [Resource protections in AWS Shield Advanced](ddos-resource-protections.md). 

Additionally, follow the recommendations in this guide to help ensure that you architect your application for DDoS resiliency and that you have properly configured the features of Shield Advanced for optimal protections. 

# Examples of DDoS attacks
<a name="types-of-ddos-attacks"></a>

AWS Shield Advanced provides expanded protection against many types of attacks. 

The following list describes some common attack types:



**User Datagram Protocol (UDP) reflection attacks**  
In UDP reflection attacks, an attacker can spoof the source of a request and use UDP to elicit a large response from the server. The extra network traffic directed towards the spoofed, attacked IP address can slow the targeted server and prevent legitimate end users from accessing needed resources.

**TCP SYN flood**  
The intent of an TCP SYN flood attack is to exhaust the available resources of a system by leaving connections in a half-open state. When a user connects to a TCP service like a web server, the client sends a TCP SYN packet. The server returns an acknowledgment, and the client returns its own acknowledgement, completing the three-way handshake. In a TCP SYN flood, the third acknowledgment is never returned, and the server is left waiting for a response. This can prevent other users from connecting to the server. 

**DNS query flood**  
In a DNS query flood, an attacker uses multiple DNS queries to exhaust the resources of a DNS server. AWS Shield Advanced can help provide protection against DNS query flood attacks on Route 53 DNS servers.

**HTTP flood/cache-busting (layer 7) attacks**  
With an HTTP flood, including `GET` and `POST` floods, an attacker sends multiple HTTP requests that appear to be from a real user of the web application. Cache-busting attacks are a type of HTTP flood that uses variations in the HTTP request's query string that prevent use of edge-located cached content and forces the content to be served from the origin web server, causing additional and potentially damaging strain on the origin web server. 

# How AWS Shield detects events
<a name="ddos-event-detection"></a>

AWS operates service-level detection systems for the AWS network and individual AWS services, to ensure that they remain available during a DDoS attack. Additionally, resource-level detection systems monitor each individual AWS resource to ensure that traffic toward the resource remains within expected parameters. This combination protects both the targeted AWS resource and AWS services, by applying mitigations that drop known bad packets, highlight potentially malicious traffic, and prioritize traffic from end users.

Detected events appear in your Shield Advanced event summaries, attack details, and Amazon CloudWatch metrics as either the name of the DDoS attack vector or as `Volumetric` if the evaluation was based on traffic volume instead of signature. For more information on the attack vector dimensions that are available within the `DDoSDetected` CloudWatch metric, see [AWS Shield Advanced metrics](shield-metrics.md).

**Topics**
+ [AWS Shield detection logic for infrastructure layer threats (layer 3 and layer 4)](ddos-event-detection-infrastructure.md)
+ [Shield Advanced detection logic for application layer threats (layer 7)](ddos-event-detection-application.md)
+ [Shield Advanced detection logic for multiple resources in an application](ddos-event-detection-multiple-resources.md)

# AWS Shield detection logic for infrastructure layer threats (layer 3 and layer 4)
<a name="ddos-event-detection-infrastructure"></a>

This page explains how event detection works for the infrastructure (network and transport) layers.

The detection logic used to protect targeted AWS resources against DDoS attacks in the infrastructure layers (layer 3 and layer 4) depends on the resource type and whether the resource is protected with AWS Shield Advanced. 

**Detection for Amazon CloudFront and Amazon Route 53**  
When you serve your web application with CloudFront and Route 53, all packets to the application are inspected by a fully inline DDoS mitigation system, which does not introduce any observable latency. DDoS attacks against CloudFront distributions and Route 53 hosted zones are mitigated in real time. These protections apply regardless of whether you use AWS Shield Advanced.

Follow the best practice of using CloudFront and Route 53 as the entry point of your web application wherever possible for the fastest detection and mitigation of DDoS events.

**Detection for AWS Global Accelerator and regional services**  
Resource-level detection protects AWS Global Accelerator standard accelerators and resources that are launched in AWS Regions, like Classic Load Balancers, Application Load Balancers, and Elastic IP addresses (EIPs). These resource types are monitored for traffic elevations that may indicate the presence of a DDoS attack that requires a mitigation. Every minute, traffic to each AWS resource is evaluated. If traffic to a resource is elevated, additional checks are performed to measure the capacity of the resource. 

Shield performs the following standard checks: 
+ **Amazon Elastic Compute Cloud (Amazon EC2) instances, EIPs attached to Amazon EC2 instances** – Shield retrieves capacity from the protected resource. The capacity depends on the target’s instance type, instance size, and other factors such as whether the instance is using enhanced networking.
+ **Classic Load Balancers and Application Load Balancers** – Shield retrieves capacity from the targeted load balancer node.
+ **EIPs attached to Network Load Balancers** – Shield retrieves capacity from the targeted load balancer. The capacity is independent of the target load balancer's group configuration.
+ **AWS Global Accelerator standard accelerators** – Shield retrieves capacity, which is based on the endpoint configuration.

These evaluations occur across multiple dimensions of network traffic, such as port and protocol. If the capacity of the targeted resource is exceeded, Shield places a DDoS mitigation. The mitigations placed by Shield will reduce DDoS traffic, but might not eliminate it. Shield may also place a mitigation if a fraction of the resource’s capacity is exceeded on a traffic dimension that's consistent with known DDoS attack vectors. Shield places this mitigation with a limited time to live (TTL), which it extends as long as the attack is ongoing.

**Note**  
Mitigations placed by Shield will reduce DDoS traffic, but may not eliminate it. You can augment Shield with solutions like AWS Network Firewall or an on-host firewall like iptables to prevent your application from processing traffic that is not valid for your application or was not generated by legitimate end users.

Shield Advanced protections add the following to the existing Shield detection activities: 
+ **Lower detection thresholds** – Shield Advanced places mitigations at one half of the calculated capacity. This can provide faster mitigations for attacks that ramp up slowly and mitigation of attacks that have a more ambiguous volumetric signature. 
+ **Intermittent attack protection** – Shield Advanced places mitigations with an exponentially increasing time to live (TTL), based on the frequency and duration of attacks. This keeps mitigations in place longer when a resource is frequently targeted and when an attack occurs in short bursts. 
+ **Health-based detection** – When you associate a Route 53 health check with a Shield Advanced protected resource, the status of the health check is used in the detection logic. During a detected event, if the health check is healthy, Shield Advanced requires greater confidence that the event is an attack before placing a mitigation. If instead the health check is unhealthy, Shield Advanced might place a mitigation even before confidence has been established. This feature helps avoid false positives and provides quicker reactions to attacks that affect your application. For information about health checks with Shield Advanced, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md).

# Shield Advanced detection logic for application layer threats (layer 7)
<a name="ddos-event-detection-application"></a>

This page explains how event detection works for the application layer.

AWS Shield Advanced provides web application layer detection for protected Amazon CloudFront distributions and Application Load Balancers. When you protect these resource types with Shield Advanced, you can associate an AWS WAF web ACL with your protection to enable web application layer detection. Shield Advanced consumes request data for the associated web ACL and builds a traffic baseline for your application. Web application layer detection relies on the native integration between Shield Advanced and AWS WAF. To learn more about application layer protections, including associating an AWS WAF web ACL to a Shield Advanced protected resource, see [Protecting the application layer (layer 7) with AWS Shield Advanced and AWS WAF](ddos-app-layer-protections.md). 

For web application layer detection, Shield Advanced monitors application traffic and compares it to historic baselines looking for anomalies. This monitoring covers total volume and the composition of traffic. During a DDoS attack, we expect both the volume and composition of traffic to change, and Shield Advanced requires a statistically significant deviation in both to declare an event. 

Shield Advanced performs its measurements against historical time windows. This approach reduces false positive notifications from legitimate changes in traffic volume or from changes in traffic that match an expected pattern, such as a sale that's offered at the same time each day. 

**Note**  
Avoid false positives in your Shield Advanced protections by giving Shield Advanced time to establish baselines that represent normal, legitimate traffic patterns. Shield Advanced begins to collect information for its baseline when you associate a web ACL with your protected resource. Associate a web ACL with your protected resource at least 24 hours before any planned event that might cause unusual patterns in your web traffic. Shield Advanced web application layer detection is most accurate when it has observed 30 days of normal traffic.

The time that Shield Advanced takes to detect an event is affected by how much change it observes in the volume of traffic. For lower volume changes, Shield Advanced observes traffic for a longer period, in order to build confidence that an event is occurring. For higher volume changes, Shield Advanced detects and reports an event more quickly. 

A rate-based rule in your web ACL, whether added by you or by the Shield Advanced automatic application layer mitigation feature, can mitigate an attack before it reaches a detectable level. For more information about automatic application layer DDoS mitigation, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md).

**Note**  
You can architect your application to scale in response to elevated traffic or load to ensure that it is not affected by smaller request floods. With Shield Advanced, your protected resources are covered by cost protection. This helps protect you against unexpected increases in your cloud bill that might occur as the result of a DDoS attack. To learn more about Shield Advanced cost protection, see [Requesting a credit in AWS Shield Advanced after an attack](ddos-request-service-credit.md).

# Shield Advanced detection logic for multiple resources in an application
<a name="ddos-event-detection-multiple-resources"></a>

This page explains how event detection works for multiple resources in an application. 

You can use AWS Shield Advanced protection groups to create collections of protected resources that are part of the same application. You can choose which protected resources to place in a group or indicate that all resources of the same type should be treated as one group. For example, you might create a group of all Application Load Balancers. When you create a protection group, Shield Advanced detection aggregates all traffic for the protected resources within the group. This is useful if you have many resources that each have a small amount of traffic, but with a large aggregated volume. You can also use protection groups to preserve application baselines, for the case of blue-green deployments where traffic is transferred between protected resources. 

You can choose to aggregate the traffic in your protection group in one of the following ways: 
+ **Sum** – This aggregation combines all traffic across resources in the protection group. You can use this aggregation to ensure that newly created resources have an existing baseline and to reduce detection sensitivity, which can help prevent false positives.
+ **Mean** – This aggregation uses the average of all traffic across the protection group. You can use this aggregation for applications where traffic across resources is uniform, like load balancers.
+ **Max** – This aggregation uses the highest traffic of any resource in the protection group. You can use this aggregation when there are multiple tiers of an application in a protection group. For example, you may have a protection group that includes a CloudFront distribution, its Application Load Balancer origin, and the Application Load Balancer’s Amazon EC2 instance targets.

You can also use protection groups to improve the speed at which Shield Advanced places mitigations, for attacks that targets multiple internet-facing Elastic IPs or AWS Global Accelerator standard accelerators. When one resource in a protection group is targeted, Shield Advanced establishes confidence for the other resources in the group. This places Shield Advanced detection on alert and can reduce the time required to create additional mitigations.

To learn more about protection groups, see [Grouping your AWS Shield Advanced protections](ddos-protection-groups.md).

# How AWS Shield mitigates events
<a name="ddos-event-mitigation"></a>

This page introduces how AWS Shield event mitigation works. 

The mitigation logic that protects your application can vary depending on your application architecture. When you protect a web application with Amazon CloudFront and Amazon Route 53, you benefit from mitigations that are specific to web and DNS use cases and that protect all traffic for the services. When your application's entry point is a resource that runs in an AWS Region, the mitigation logic varies depending on the service, the resource type, and your use of AWS Shield Advanced. 

AWS DDoS mitigation systems are developed by Shield engineers and they're closely integrated with AWS services. The engineers take into account aspects of your architecture such as the capacity and health of targeted resources. Shield engineers continually monitor the efficacy and performance of DDoS mitigation systems and are able to respond quickly when new threats are discovered or anticipated. 

You can architect your application to scale in response to elevated traffic or load, to help ensure that it's not affected by smaller request floods. If you use Shield Advanced to protect your resources, you receive coverage against unexpected increases in your cloud bill that might occur as the result of a DDoS attack. 

**Infrastructure mitigations**  
For infrastructure layer attacks, AWS Shield DDoS mitigation systems are present at the AWS network border and at AWS edge locations. The placement of multiple levels of security controls throughout the AWS infrastructure provides defense-in-depth to your cloud applications. 

Shield maintains DDoS mitigation systems at all points of ingress from the internet. When Shield detects a DDoS attack, for each point of ingress, it reroutes the traffic through the DDoS mitigation systems in the same location. This doesn’t introduce any observable additional latency, and provides a mitigation capacity of more than 100 TeraBits Per Second (Tbps) across all AWS Regions and all edge locations. Shield protects your resource availability without rerouting traffic to external or remote scrubbing centers, which could increase latency. 
+ At the AWS network border, for any AWS service or resource, DDoS mitigation systems mitigate infrastructure layer attacks coming from the internet. The systems perform their mitigations when signaled by Shield detection or by an engineer on the Shield Response Team (SRT). 
+ At AWS edge locations, DDoS mitigation systems continuously inspect every packet that's forwarded to Amazon CloudFront distributions and Amazon Route 53 hosted zones, regardless of their origin. When needed, the systems apply mitigations that are specifically designed for web and DNS traffic. An added benefit of using Amazon CloudFront and Amazon Route 53 to protect your web applications is that DDoS attacks are immediately mitigated, without requiring a signal from Shield detection. 

**Application layer mitigations**  
Shield Advanced provides web application layer mitigations for the Amazon CloudFront distributions and Application Load Balancers where you've enabled Shield Advanced protections. When you enable protection, you associate an AWS WAF web ACL with the resource, to enable web application layer detection. Additionally, you have the option of enabling automatic application layer mitigation, which instructs Shield Advanced to manage protections for you during a DDoS attack. 

Shield only provides custom mitigations for application layer attacks on resources for which you've enabled Shield Advanced and automatic application layer mitigation. With automatic mitigation, Shield Advanced enforces AWS WAF rate limiting on requests from known DDoS sources, and it automatically adds and manages custom AWS WAF protections in response to detected DDoS attacks. For detailed information about mitigations of this type, see [How Shield Advanced manages automatic mitigation](ddos-automatic-app-layer-response-behavior.md). 

A rate-based rule in your web ACL, whether added by you or added by the Shield Advanced automatic application layer mitigation feature, can mitigate an attack before it reaches a detectable level. For more information about detection, see [Shield Advanced detection logic for application layer threats (layer 7)](ddos-event-detection-application.md).

**Topics**
+ [List of AWS Shield DDoS mitigation features](ddos-event-mitigation-features.md)
+ [AWS Shield mitigation logic for CloudFront and Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield mitigation logic for AWS Regions](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield mitigation logic for AWS Global Accelerator standard accelerators](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced mitigation logic for Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced mitigation logic for web applications](ddos-event-mitigation-logic-adv-web-app.md)

# List of AWS Shield DDoS mitigation features
<a name="ddos-event-mitigation-features"></a>

The main features of AWS Shield DDoS mitigation are the following:
+ **Packet validation** – This ensures that every inspected packet conforms to an expected structure and is valid for its protocol. Supported protocol validations include IP, TCP (including header and options), UDP, ICMP, DNS, and NTP.
+ **Access Control Lists (ACLs) and shapers** – An ACL evaluates traffic against specific attributes and either drops matching traffic or maps it to a shaper. The shaper limits the packet rate for the matching traffic, dropping excess packets in order to contain the volume that reaches the destination. AWS Shield detection and Shield Response Team (SRT) engineers can provide dedicated rate allocations to expected traffic and more restrictive rate allocations to traffic with attributes that match known DDoS attack vectors. The attributes that an ACL can match include the port, protocol, TCP flags, destination address, source country, and arbitrary patterns in the packet payload. 
+ **Suspicion scoring** – This uses the knowledge that Shield has of expected traffic to apply a score to every packet. Packets that more closely adhere to patterns of known good traffic are assigned a lower suspicion score. Observation of known bad traffic attributes can increase the suspicion score for a packet. When it's necessary to rate limit packets, Shield drops packets with higher suspicion scores first. This helps Shield to mitigate both known and zero-day DDoS attacks while avoiding false positives.
+ **TCP SYN proxy** – This provides protection against TCP SYN floods by sending TCP SYN cookies to challenge new connections before allowing them to pass to the protected service. The TCP SYN proxy provided by Shield DDoS mitigation is stateless, which allows it to mitigate the largest known TCP SYN flood attacks without reaching state exhaustion. This is achieved by integrating with AWS services to hand off connection state instead of maintaining a continuous proxy between the client and the protected service. TCP SYN proxy is currently available on Amazon CloudFront and Amazon Route 53. 
+ **Rate distribution** – This continuously adjusts per-location shaper values based on the ingress pattern of traffic toward a protected resource. This prevents rate limiting of customer traffic that might not enter the AWS network evenly.

# AWS Shield mitigation logic for CloudFront and Route 53
<a name="ddos-event-mitigation-logic-continuous-inspection"></a>

This page explains how Shield DDoS mitigation continually inspects traffic for CloudFront and Route 53. These services operate from a globally distributed network of AWS edge locations that provide you with broad access to Shield’s DDoS mitigation capacity and deliver your application from infrastructure that's closer to your end users. 

**Important**  
AWS Shield Advanced doesn’t support CloudFront tenants.
+ **CloudFront** – Shield DDoS mitigations only allow traffic that's valid for web applications to pass through to the service. This provides automatic protection against many common DDoS vectors, like UDP reflection attacks. 

  CloudFront maintains persistent connections to your application origin, TCP SYN floods are automatically mitigated through integration with the Shield TCP SYN proxy feature, and Transport Layer Security (TLS) is terminated at the edge. These combined features ensure that your application origin only receives well-formed web requests and that it's protected against lower-layer DDoS attacks, connection floods, and TLS abuse.

  CloudFront uses a combination of DNS traffic direction and anycast routing. These techniques improve the resilience of your application by mitigating attacks close to the source, providing fault isolation, and ensuring access to capacity to mitigate the largest known attacks. 
+ **Route 53** – Shield mitigations only allow valid DNS requests to reach the service. Shield mitigates DNS query floods using suspicion scoring that prioritizes known good queries and deprioritizes queries that contain suspicious or known DDoS attack attributes. 

  Route 53 uses shuffle sharding to provide a unique set of four resolver IP addresses to every hosted zone, for both IPv4 and IPv6. Each IP address corresponds to a different subset of Route 53 locations. Each location subset consists of authoritative DNS servers that only partially overlap with infrastructure in any other subset. This ensures that if a user query fails for any reason, it will be successfully served on retry.

  Route 53 uses anycast routing to direct DNS queries to the nearest edge location, based on network proximity. Anycast also fans out DDoS traffic to many edge locations, which prevents attacks from focusing on a single location. 

In addition to the speed of mitigation, CloudFront and Route 53 provide broad access to the globally distributed capacity of Shield. To take advantage of these capabilities, use these services as the entry point of your dynamic or static web applications. 

To learn more about using CloudFront and Route 53 to protect web applications, see [How to Help Protect Dynamic Web Applications Against DDoS Attacks by Using Amazon CloudFront and Amazon Route 53](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/). To learn more about fault isolation on Route 53, see [A Case Study in Global Fault Isolation](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/).

# AWS Shield mitigation logic for AWS Regions
<a name="ddos-event-mitigation-logic-regions"></a>

This page explains how Shield event mitigation logic works in AWS Regions.

Resources that are launched in AWS Regions are protected by AWS Shield DDoS mitigation systems placed by Shield resource-level detection. Regional resources include Elastic IPs (EIPs), Classic Load Balancers, and Application Load Balancers.

Prior to placing a mitigation, Shield identifies the targeted resource and its capacity. Shield uses the capacity to determine the maximum total traffic that its mitigations should allow to be forwarded to the resource. Access control lists (ACLs) and other shapers within the mitigation might decrease the allowed volumes for some traffic, for example traffic that matches known DDoS attack vectors or that isn't expected to come in large volume. This further limits the amount of traffic that the mitigations allow for UDP reflection attacks or for TCP traffic that has TCP SYN or FIN flags.

Shield determines capacity and places mitigations differently for each resource type. 
+ For an Amazon EC2 instance, or an EIP that's attached to an Amazon EC2 instance, Shield calculates the capacity based on the instance type and other instance attributes, such as whether the instance has enhanced networking enabled. 
+ For an Application Load Balancer or Classic Load Balancer, Shield calculates capacity individually for each targeted node of the load balancer. DDoS attack mitigations for these resources are provided by a combination of Shield DDoS mitigations and automatic scaling by the load balancer. When the Shield Response Team (SRT) is engaged on an attack against an Application Load Balancer or Classic Load Balancer resource, they might accelerate scaling as an additional protection measure. 
+ Shield calculates capacity for some AWS resources is based on the available capacity of the underlying AWS infrastructure. These resource types include Network Load Balancers (NLBs) and resources that route traffic through Gateway Load Balancers or AWS Network Firewall.

**Note**  
Protect your Network Load Balancers by attaching EIPs that are protected by Shield Advanced. You can work with SRT to build custom mitigations that are based on the expected traffic and capacity of the underlying application. 

When Shield places a mitigation, the initial rate limits that Shield defines in the mitigation logic are applied equally to every Shield DDoS mitigation system. For example, if Shield places a mitigation with a 100,000 packets per second (pps) limit, it will initially allow 100,000 pps at every location. Then, Shield continuously aggregates mitigation metrics to determine the actual ratio of traffic, and uses the ratio to adapt the rate limit for each location. This prevents false positives and ensures that the mitigations are not overly permissive. 

# AWS Shield mitigation logic for AWS Global Accelerator standard accelerators
<a name="ddos-event-mitigation-logic-gax"></a>

This page explains how Shield event mitigation logic works for AWS Global Accelerator standard accelerators. Shield mitigations only allow valid traffic to reach the listener endpoints of a Global Accelerator standard accelerator.

Standard accelerators are deployed globally, and they provide you with IP addresses that you can use to route traffic to AWS resources in any AWS Region. The rate limits that Shield enforces for a Global Accelerator mitigation are based on the capacities of the resources to which the standard accelerator routes traffic. Shield places mitigations when the total traffic exceeds the determined rate, and also when a fraction of that rate is exceeded for known DDoS vectors. 

When you configure a standard accelerator, you define endpoint groups for each AWS Region where you'll route traffic for your application. When Shield places a mitigation, it calculates the capacity of each endpoint group and updates rate limits at each Shield DDoS mitigation system accordingly. The rate varies for each location, based on assumptions made by Shield about how traffic will route from the internet to your AWS resources. The capacity for an endpoint group is calculated as the number of resources in the group multiplied by the lowest capacity for any resource in the group. At regular intervals, Shield recalculates the capacity for your application and updates the rate limits as needed. 

**Note**  
Using traffic dials to change the percentage of traffic that's directed to an endpoint group doesn't change how Shield calculates or distributes rate limits to its DDoS mitigation systems. If you use traffic dials, configure your endpoint groups to mirror one another in terms of resource type and quantity. This helps ensure that the capacity calculated by Shield is representative of the resources that are serving traffic for your application.

For more information about endpoint groups and traffic dials in Global Accelerator, see [Endpoint groups in AWS Global Accelerator standard accelerators](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups.html).

# AWS Shield Advanced mitigation logic for Elastic IPs
<a name="ddos-event-mitigation-logic-adv-eip"></a>

This page explains how Shield event mitigation logic works for Elastic IPs with AWS Shield Advanced. When you protect an Elastic IP (EIP) with AWS Shield Advanced, Shield Advanced enhances the mitigations that Shield places during a DDoS event.

Shield Advanced DDoS mitigation systems replicate the Network ACL (NACL) configuration for the public subnet to which the EIP is associated. For example, if your NACL is configured to block all UDP traffic, Shield Advanced merges that rule into the mitigations that Shield places. 

This additional functionality can help you to avoid availability risks due to traffic that's not valid for your application. You can also use NACLs to block individual source IP addresses or source IP address CIDR ranges. This can be a useful mitigation tool for DDoS attacks that aren't distributed. It also lets you easily manage your own allow lists or to block IP addresses that shouldn't communicate with your application, without relying on intervention by AWS engineers.

# AWS Shield Advanced mitigation logic for web applications
<a name="ddos-event-mitigation-logic-adv-web-app"></a>

AWS Shield Advanced uses AWS WAF to mitigate web application layer attacks. AWS WAF is included with Shield Advanced at no additional cost. 

**Standard application layer protection**  
When you protect an Amazon CloudFront distribution or Application Load Balancer with Shield Advanced, you can use Shield Advanced to associate an AWS WAF web ACL with your protected resource, if you don't already have one associated. If you haven't already configured a web ACL, you can use the Shield Advanced console wizard to create one and add a rate-based rule to it. A rate-based rule limits the number of requests per five minute time window for each IP address, providing basic protections against web application layer request floods. You can configure the rate, starting as low as 10. For more information, see [Protecting the application layer with AWS WAF web ACLs and Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).

You can also use the AWS WAF service to manage the web ACL. Through AWS WAF, you can expand the web ACL configuration to do things such as inspect specific web request components for string matches or patterns, add custom request and response handling, and match against the geolocation of the request origin. For more information about AWS WAF rules, see [AWS WAF rules](waf-rules.md). 

**Automatic application layer mitigation**  
For enhanced protection, enable Shield Advanced automatic application layer mitigation. With this option, Shield Advanced maintains an AWS WAF rate limiting rule for requests from known DDoS sources and it provides custom mitigations for detected DDoS attacks. 

When Shield Advanced detects an attack on a protected resource, it attempts to identify an attack signature that isolates the attack traffic from the normal traffic to your application. Shield Advanced 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.

If Shield Advanced determines that the attack signature isolates only the traffic that's involved in the DDoS attack, it implements the signature in AWS WAF rules inside the associated web ACL. You can instruct Shield Advanced to place mitigations that only count the traffic that they match against, or that block it, and you can change the setting at any time. When Shield Advanced determines that its mitigating rules are no longer needed, it removes them from the web ACL. For more information about application layer event mitigation, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md). 

For more information about Shield Advanced application layer mitigations, see [Protecting the application layer (layer 7) with AWS Shield Advanced and AWS WAF](ddos-app-layer-protections.md). 

# Building basic DDoS resilient architectures with Shield Advanced
<a name="ddos-resiliency"></a>

This page explains Distributed Denial of Service (DDoS) resiliency and introduces two example architectures.

DDoS resiliency is the ability of your application architecture to withstand DDoS attacks while continuing to serve legitimate end users. An application that is highly resilient can remain available during an attack with minimal impact on performance metrics such as errors or latency. This section shows some common example architectures and describes how to use the DDoS detection and mitigation capabilities that are provided by AWS and Shield Advanced to increase their DDoS resiliency. 

The example architectures in this section highlight the AWS services that provide the greatest DDoS resiliency benefits for your deployed applications. The benefits of the highlighted services include the following:
+ **Access to globally distributed network capacity** – The services Amazon CloudFront, AWS Global Accelerator, and Amazon Route 53 provide you with access to internet and DDoS mitigation capacity across the AWS global edge network. This is useful in mitigating larger volumetric attacks, which can reach terabits in scale. You can run your application in any AWS Region and use these services to protect availability and optimize performance for your legitimate users.
+ **Protection against web application layer DDoS attack vectors** – Web application layer DDoS attacks are best mitigated using a combination of application scale and a web application firewall (WAF). Shield Advanced uses web request inspection logs from AWS WAF to detect anomalies that can be mitigated either automatically or via engagement with the AWS Shield Response Team (SRT). Automatic mitigation is available through deployed AWS WAF rate-based rules and also through the Shield Advanced automatic application layer DDoS mitigation.

In addition to reviewing these examples, review and follow the applicable best practices at [AWS Best Practices for DDoS Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency).

**Topics**
+ [Example Shield Advanced DDoS resiliency architecture for common web applications](ddos-resiliency-example-web.md)
+ [Example Shield Advanced DDoS resiliency architecture for TCP and UDP applications](ddos-resiliency-example-tcp-udp.md)

# Example Shield Advanced DDoS resiliency architecture for common web applications
<a name="ddos-resiliency-example-web"></a>

This page provides an example architecture for maximizing resiliency against DDoS attacks with AWS web applications. 

You can build a web application in any AWS Region and receive automatic DDoS protection from the detection and mitigation capabilities that AWS provides in the Region. 

This example is for architectures that route users to a web application using resources like Classic Load Balancers, Application Load Balancers, Network Load Balancers, AWS Marketplace solutions, or your own proxy layer. You can improve DDoS resiliency by inserting Amazon Route 53 hosted zones, Amazon CloudFront distributions, and AWS WAF web ACLs between these web application resources and your users. These insertions can obfuscate the application origin, serve requests closer to your end users, and detect and mitigate application layer request floods. Applications that serve static or dynamic content to your users with CloudFront and Route 53 are protected by an integrated, fully inline DDoS mitigation system that mitigates infrastructure layer attacks in real time.

With these architectural improvements in place, you can then protect your Route 53 hosted zones and your CloudFront distributions with Shield Advanced. When you protect CloudFront distributions, Shield Advanced prompts you to associate AWS WAF web ACLs and create rate-based rules for them, and gives you the option of enabling automatic application layer DDoS mitigation or proactive engagement. Proactive engagement and automatic application layer DDoS mitigation use Route 53 health checks that you associate with the resource. To learn more about these options, see [Resource protections in AWS Shield Advanced](ddos-resource-protections.md). 

The following reference diagram depicts this DDoS resilient architecture for a web application.

![\[The diagram shows a rectangle titled AWS cloud, with a group of users to its left. Inside the cloud rectangle are two other rectangles, side by side. The left rectangle is titled AWS Shield Advanced and the right rectangle is titled VPC. The left, AWS Shield Advanced triangle contains three AWS icons, stacked vertically. From top to bottom, the icons are Amazon Route 53, Amazon CloudFront, and AWS WAF. The icon for CloudFront has arrows that go to and from the icon for AWS WAF. The user group has an arrow coming out horizontally to its right that splits to point to the icons for Route 53 and CloudFront. To the right of the Shield Advanced rectangle, the VPC rectangle contains two icons that are side by side. From left to right, these icons are Elastic Load Balancing and Amazon Elastic Compute Cloud. The CloudFront icon has an arrow coming out horizontally to its right that goes to the Elastic Load Balancing icon. The Elastic Load Balancing icon has an arrow coming out horizontally to its right that goes to the Amazon EC2 icon. So user requests are sent to Route 53 and CloudFront. CloudFront interacts with AWS WAF and also sends requests on to the load balancer, which in turn sends requests on the Amazon EC2.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-resilient-web-app-arch.png)


The benefits that this approach provides to your web application include the following:
+ Protection against frequently used infrastructure layer (layer 3 and layer 4) DDoS attacks, without detection delay. In addition, if a resource is frequently targeted, Shield Advanced places mitigations for longer periods of time. Shield Advanced also uses application context inferred from Network ACLs (NACLs) to block unwanted traffic further upstream. This isolates failures closer to their source, minimizing the effect on legitimate users. 
+ Protection against TCP SYN floods. The DDoS mitigation systems that are integrated with CloudFront, Route 53, and AWS Global Accelerator provide a TCP SYN proxy capability that challenges new connection attempts and only serves legitimate users.
+ Protection against DNS application layer attacks, because Route 53 is responsible for serving authoritative DNS responses. 
+ Protection against web application layer request floods. The rate-based rule that you configure in your AWS WAF web ACL blocks source IPs when they are sending more requests than the rule allows. 
+ Automatic application layer DDoS mitigation for your CloudFront distributions, if you choose to enable this option. With automatic DDoS mitigation, Shield Advanced maintains a rate-based rule in the distribution's associated AWS WAF web ACL that limits the volume of requests from known DDoS sources. Additionally, when Shield Advanced detects an event that affects the health of your application, it automatically creates, tests, and manages mitigating rules in web ACL. 
+ Proactive engagement with the Shield Response Team (SRT), if you choose to enable this option. When Shield Advanced detects an event that affects the health of your application, the SRT responds and proactively engages with your security or operations teams using the contact information that you provide. The SRT analyzes patterns in your traffic and can update your AWS WAF rules to block the attack.

# Example Shield Advanced DDoS resiliency architecture for TCP and UDP applications
<a name="ddos-resiliency-example-tcp-udp"></a>

This example shows a DDoS resilient architecture for TCP and UDP applications in an AWS Region that uses Amazon Elastic Compute Cloud (Amazon EC2) instances or Elastic IP (EIP) addresses. 

You can follow this general example to improve DDoS resiliency for the following application types: 
+ TCP or UDP applications. For example, applications used for gaming, IoT, and voice over IP.
+ Web applications that require static IP addresses or that use protocols that Amazon CloudFront doesn't support. For example, your application might require IP addresses that your users can add to their firewall allow lists, and that aren't used by any other AWS customers.

You can improve DDoS resiliency for these application types by introducing Amazon Route 53 and AWS Global Accelerator. These services can route users to your application and they can provide your application with static IP addresses that are anycast routed across the AWS global edge network. Global Accelerator standard accelerators can improve user latency by up to 60%. If you have a web application, you can detect and mitigate web application layer request floods by running the application on an Application Load Balancer, and then protecting the Application Load Balancer with an AWS WAF web ACL.

After you've built your application, protect your Route 53 hosted zones, Global Accelerator standard accelerators, and any Application Load Balancers with Shield Advanced. When you protect your Application Load Balancers, you can associate AWS WAF web ACLs and create rate-based rules for them. You can configure proactive engagement with the SRT for both your Global Accelerator standard accelerators and your Application Load Balancers by associating new or existing Route 53 health checks. To learn more about the options, see [Resource protections in AWS Shield Advanced](ddos-resource-protections.md). 

The following reference diagram depicts an example DDoS resilient architecture for TCP and UDP applications.

![\[The diagram shows users connected to Route 53 and to an AWS Global Accelerator. The accelerator is connected to an Elastic Load Balancing icon that's protected by AWS Shield Advanced and AWS WAF. The Elastic Load Balancing is itself connected to an Amazon EC2 instance. This Elastic Load Balancing instance and the Amazon EC2 instance are in Region 1. The AWS Global Accelerator is also directly connected to another Amazon EC2 instance, which isn't behind a protected Elastic Load Balancing intsance. This second Amazon EC2 instance is in Region n.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-resilient-tcp-udp-app-arch.png)


The benefits that this approach provides to your application include the following:
+ Protection against the largest known infrastructure layer (layer 3 and layer 4) DDoS attacks. If the volume of an attack causes congestion upstream from AWS, the failure will be isolated closer to its source and will have a minimized effect on your legitimate users.
+ Protection against DNS application layer attacks, because Route 53 is responsible for serving authoritative DNS responses. 
+ If you have a web application, this approach provides protection against web application layer request floods. The rate-based rule that you configure in your AWS WAF web ACL blocks source IPs while they are sending more requests than the rule allows. 
+ Proactive engagement with the Shield Response Team (SRT), if you choose to enable this option for eligible resources. When Shield Advanced detects an event that affects the health of your application, the SRT responds and proactively engages with your security or operations teams using the contact information that you provide. 

# Combining Shield Advanced with other AWS services
<a name="aws-shield-use-case"></a>

You can use Shield Advanced to protect your resources in many types of scenarios. However, in some cases you should use other services or combine other services with Shield Advanced to offer the best protection. Following are examples of how to use Shield Advanced or other AWS services to help protect your resources.


| Goal | Suggested services | Related service documentation | 
| --- | --- | --- | 
| Protect a web application and RESTful APIs against a DDoS attack | Shield Advanced protecting an Amazon CloudFront distribution and an Application Load Balancer | [Elastic Load Balancing documentation](https://docs.aws.amazon.com/elasticloadbalancing/), [Amazon CloudFront Documentation](https://docs.aws.amazon.com/cloudfront/) | 
| Protect a TCP-based application against a DDoS attack | Shield Advanced protecting an AWS Global Accelerator standard accelerator; attached to an Elastic IP address | [AWS Global Accelerator Documentation](https://docs.aws.amazon.com/global-accelerator/), [Elastic Load Balancing documentation](https://docs.aws.amazon.com/elasticloadbalancing/) | 
| Protect a UDP-based game server against a DDoS attack | Shield Advanced protecting an Amazon EC2 instance attached to an Elastic IP address | [Amazon Elastic Compute Cloud Documentation](https://docs.aws.amazon.com/ec2/) | 

For example, if you use Shield Advanced to protect an Elastic IP address, Shield Advanced protects whatever resource is associated with it. 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. If the network interface attached to your Amazon EC2 instance can process up to 10 Gbps, volumes over 10 Gbps 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). 

# Setting up AWS Shield Advanced
<a name="getting-started-ddos"></a>

This tutorial walks you through getting started with AWS Shield Advanced using the Shield Advanced console. 

**Note**  
Shield Advanced requires a subscription, while AWS Shield Standard does not. The protections provided by Shield Standard are available free of charge to all AWS customers.

Shield Advanced provides advanced DDoS detection and mitigation protection for network layer (layer 3), transport layer (layer 4), and application layer (layer 7) attacks. For more information about Shield Advanced, see [AWS Shield Advanced overview](ddos-advanced-summary.md).

The AWS technical community has published an example of an automated process for configuring Shield Advanced using the infrastructure as code (IaC) tools, AWS CloudFormation and Terraform. You can use AWS Firewall Manager with this solution if your accounts are part of an organization in AWS Organizations and if you're protecting any resource types except for Amazon Route 53 or AWS Global Accelerator. To explore this option, see the code repository at [aws-samples / aws-shield-advanced-one-click-deployment](https://github.com/aws-samples/aws-shield-advanced-one-click-deployment) and the tutorial at [One-click deployment of Shield Advanced](https://youtu.be/LCA3FwMk_QE). 

**Note**  
It's important that you fully configure Shield Advanced prior to a Distributed Denial of Service (DDoS) event. Complete the configuration to help ensure that your application is protected and that you are ready to respond if your application is affected by a DDoS attack.

Perform the following steps in sequence to get started using Shield Advanced. 

**Contents**
+ [Subscribing to AWS Shield Advanced](enable-ddos-prem.md)
+ [Adding and configuring resource protections with Shield Advanced](ddos-choose-resources.md)
  + [Configuring application layer (layer 7) DDoS protections with AWS WAF](ddos-get-started-web-acl-rbr.md)
  + [Configuring health-based detection for your protections with Shield Advanced and Route 53](ddos-get-started-health-checks.md)
  + [Configuring alarms and notifications with Shield Advanced and Amazon SNS](ddos-get-started-create-alarms.md)
  + [Reviewing and finishing your protection configuration in Shield Advanced](ddos-get-started-review-and-configure.md)
+ [Setting up AWS Shield Response Team (SRT) support for DDoS event response](authorize-srt.md)
+ [Creating a DDoS dashboard in CloudWatch and setting CloudWatch alarms](deploy-waf-dashboard.md)

# Subscribing to AWS Shield Advanced
<a name="enable-ddos-prem"></a>

This page explains how to subscribe your accounts to Shield Advanced, to start using the service.

You must subscribe to Shield Advanced for each AWS account that you want to protect. You do not need to subscribe to Shield Standard.

**Shield Advanced subscription billing**  
If you’re an AWS Channel Reseller, talk to your account team for information and guidance. This billing information is for customers that are not AWS Channel Resellers. 

For all others, the following subscription and billing guidelines apply:
+ For accounts that are members of an AWS Organizations organization, AWS bills the Shield Advanced subscriptions against the payer account for the organization, regardless of whether the payer account itself is subscribed. 
+ When you subscribe multiple accounts that are in the same [AWS Organizations consolidated billing account family](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), one subscription price covers all subscribed accounts in the family. The organization must own all of the AWS accounts and all of their resources. 
+ When you subscribe multiple accounts for multiple organizations, you can still pay one subscription fee across all of the organizations, accounts, and resources providing you own all of them. Contact your account manager or AWS support and request a fee waiver on the AWS Shield Advanced subscription charges for all but one of the organizations. 

For detailed pricing information and examples, see [AWS Shield Pricing](https://aws.amazon.com/shield/pricing/). 

**Consider simplifying subscriptions with AWS Firewall Manager**  
If your accounts are part of an organization, we recommend that you use AWS Firewall Manager if you can, to automate your subscriptions and protections for the organization. Firewall Manager supports all protected resource types except for Amazon Route 53 and AWS Global Accelerator. To use Firewall Manager, see [AWS Firewall Manager](fms-chapter.md) and [Setting up AWS Firewall Manager​ AWS Shield Advanced policies](getting-started-fms-shield.md). 

If you don't use Firewall Manager, for each account with resources to protect, subscribe and add protections using the following procedures. 

**To subscribe an account to AWS Shield Advanced**

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 bar, choose **Getting started**. Choose **Subscribe to Shield Advanced**. 

1. In the **Subscribe to Shield Advanced** page, read each term of the agreement, and then select all of the check boxes to indicate that you accept the terms. For accounts in a consolidated billing family, you must agree to the terms for each account. 
**Important**  
When you are subscribed, to unsubscribe you must contact [AWS Support](https://console.aws.amazon.com/support).   
To disable autorenewal for your subscription, you must use the Shield API operation [UpdateSubscription](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_UpdateSubscription.html) or the CLI command [update-subscription](https://docs.aws.amazon.com/cli/latest/reference/shield/update-subscription.html).

   Choose **Subscribe to Shield Advanced**. This subscribes your account to Shield Advanced and activates the service.

Your account is subscribed. Continue through the following steps to protect your account's resources with Shield Advanced. 

**Note**  
Shield Advanced doesn't automatically protect your resources after you subscribe. You must specify the resources you want Shield Advanced to protect. 

# Adding and configuring resource protections with Shield Advanced
<a name="ddos-choose-resources"></a>

This page provides instructions for adding and configuring protections for your resources. 

Shield Advanced only protects the resources that you specify, either through Shield Advanced or in a Firewall Manager Shield Advanced policy. It doesn't automatically protect the resources of a subscribed account. 

**Note**  
If you use an AWS Firewall Manager Shield Advanced policy for your protections, you don't need to do this step. You configure the policy with the types of resource to protect, and Firewall Manager automatically adds protections to resources that are within scope of the policy. 

If you don't use Firewall Manager, go through the following procedures for each account that has resources to protect.

**To choose the resources to protect using Shield Advanced**

1. Choose **Add resources to protect** from the subscription confirmation page of the prior procedure, or from the **Protected resources** or **Overview** page. 

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.

Continue through the console wizard screens to complete the configuration of your resource protections. 

**Topics**
+ [Configuring application layer (layer 7) DDoS protections with AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Configuring health-based detection for your protections with Shield Advanced and Route 53](ddos-get-started-health-checks.md)
+ [Configuring alarms and notifications with Shield Advanced and Amazon SNS](ddos-get-started-create-alarms.md)
+ [Reviewing and finishing your protection configuration in Shield Advanced](ddos-get-started-review-and-configure.md)

# Configuring application layer (layer 7) DDoS protections with AWS WAF
<a name="ddos-get-started-web-acl-rbr"></a>

This page provides instructions for configuring application layer protections with AWS WAF web ACLs. 

To protect an application layer resource, Shield Advanced uses an AWS WAF web ACL with a rate-based rule as a starting point. 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. A rate-based rule limits the volume of traffic based on your request aggregation criteria, providing basic DDoS protection to your application. For more information, see [How AWS WAF works](how-aws-waf-works.md) and [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md).

You can also optionally enable Shield Advanced automatic application layer DDoS mitigation, to have Shield Advanced rate limit requests from known DDoS sources and automatically provide incident-specific protections for you. 

**Important**  
If you manage your Shield Advanced protections through AWS Firewall Manager using a Shield Advanced policy, you can't manage application layer protections here. You must manage them in your Firewall Manager Shield Advanced policy.

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

**To configure layer 7 DDoS protections for a Region**

Shield Advanced gives you the option to configure layer 7 DDoS mitigation for each Region where your chosen resources are located. If you're adding protections in multiple regions, the wizard walks you through the following procedure for each Region. 

1. The **Configure layer 7 DDoS protections** page lists each resource that isn't yet associated with a web ACL. For each of these, either choose an existing web ACL or create a new web ACL. For any resource that already has an associated web ACL, you can change web ACLs by first disassociating the current one through AWS WAF. For more information, see [Associating or disassociating protection with an AWS resource](web-acl-associating-aws-resource.md).

   For web ACLs that don't already have a rate-based rule, the configuration wizard prompts you to add one. A rate-based rule limits traffic from IP addresses when they are sending a high volume of requests. Rate-based rules help protect your application against web request floods and can provide alerts about sudden spikes in traffic that might indicate a potential DDoS attack. Add a rate-based rule to a web ACL by choosing **Add rate limit rule** and then providing a rate limit and rule action. You can configure additional protections in the web ACL through AWS WAF. 

   For information about using web ACLs and rate-based rules in your Shield Advanced protections, including additional configuration options for rate-based rules, see [Protecting the application layer with AWS WAF web ACLs and Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).

1. For **Automatic application layer DDoS mitigation**, if you want to have Shield Advanced automatically mitigate DDoS attacks against your application layer resources, choose **Enable** and then select the AWS WAF rule action that you want Shield Advanced to use in its custom rules. This setting applies to all of the web ACLs for the resources that you are managing in this wizard session. 

   With automatic application layer DDoS mitigation, Shield Advanced maintains a rate-based rule in the resource's AWS WAF web ACL that limits the volume of requests from known DDoS sources. Additionally, Shield Advanced compares current traffic patterns against historic traffic baselines to detect deviations that might indicate a DDoS attack. When Shield Advanced detects a DDoS attack, it responds by creating, evaluating, and deploying custom AWS WAF rules to respond. You specify whether the custom rules count or block attacks on your behalf. 
**Note**  
Automatic application layer DDoS mitigation works only with protection packs (web ACLs) that were created using the latest version of AWS WAF (v2). 

   For more information about Shield Advanced automatic application layer DDoS mitigation, including caveats and best practices for using this feature, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md).

1. Choose **Next**. The console wizard advances to the health-based detection page. 

# Configuring health-based detection for your protections with Shield Advanced and Route 53
<a name="ddos-get-started-health-checks"></a>

This page provides instructions for configuring Shield Advanced to use health-based detection. This can help improve responsiveness and accuracy in attack detection and mitigation.

Well-configured health checks are essential for accurate detection of events. You can configure health-based detection for any resource type except for Route 53 hosted zones. 

To use health-based detection, define a health check for your resource in Route 53, and then associate the health check with your Shield Advanced protection. It's important that the health check that you configure accurately reflect the health of the resource. For information and examples for configuring health checks to use with Shield Advanced, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md). 

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

**Note**  
Health checks must be reporting healthy when you associate them with your Shield Advanced protections.

**To configure health-based detection**

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. Choose **Next**. The console wizard advances to the alarms and notifications page. 

# Configuring alarms and notifications with Shield Advanced and Amazon SNS
<a name="ddos-get-started-create-alarms"></a>

This page provides instructions to optionally configure Amazon Simple Notification Service notifications for detected Amazon CloudWatch alarms and rate-based rule activity. You can use these to receive notification when Shield detects an event on a protected resource or when a rate-limit configured in a rate-based rule is exceeded. 

For information about Shield Advanced CloudWatch metrics, see [AWS Shield Advanced metrics](shield-metrics.md). For information about Amazon SNS, see the [Amazon Simple Notification Service Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/). 

**To configure alarms and notifications**

1. Select the Amazon SNS topics that you want notification for. You can use a single Amazon SNS topic for all protected resources and rate-based rules, or you can choose different topics, customized to your organization. For example, you can create an SNS topic for each team that's responsible for incident response for a specific set of resources.

1. Choose **Next**. The console wizard advances to the resource protection review page.

# Reviewing and finishing your protection configuration in Shield Advanced
<a name="ddos-get-started-review-and-configure"></a>

**To review and finish your settings**

1. In the **Review and configure DDoS mitigation and visibility** page, review your settings. To make modifications, choose **Edit** in the area that you want to modify. This takes you back to the associated page in the console wizard. Make your changes, then choose **Next** in the subsequent pages until you return to the **Review and configure DDoS mitigation and visibility** page.

1. Choose **Finish configuration**. The **Protected resources** page lists your newly protected resources.

# Setting up AWS Shield Response Team (SRT) support for DDoS event response
<a name="authorize-srt"></a>

This page provides instructions for setting up Shield Response Team (SRT) support.

The SRT includes security engineers who specialize in DDoS event response. You can optionally add permissions that allow the SRT to manage resources on your behalf during a DDoS event. In addition, you can configure the SRT to proactively engage with you if the Route 53 health checks associated with your protected resources are unhealthy during a detected event. Both of these additions to your protections enable quicker responses to DDoS events. 

**Note**  
To use the services of the Shield Response Team (SRT), you must be subscribed to the [Business Support plan](https://aws.amazon.com/premiumsupport/business-support/) or the [Enterprise Support plan](https://aws.amazon.com/premiumsupport/enterprise-support/). 

The SRT can monitor AWS WAF request data and logs during application layer events to identify anomalous traffic. They can help craft custom AWS WAF rules to mitigate offending traffic sources. As needed, the SRT might make architectural recommendations to help you better align your resources with AWS recommendations. 

For more information about the SRT, see [Managed DDoS event response with Shield Response Team (SRT) support](ddos-srt-support.md).

**To grant permissions to the SRT**

1. In the AWS Shield console **Overview** page, under **Configure AWS SRT support**, choose **Edit SRT access**. The **Edit AWS Shield Response Team (SRT) access** page opens.

1. For **SRT access setting** select one of the options: 
   + **Do not grant the SRT access to my account** – Shield removes any permissions you previously gave to the SRT to access your account and resources.
   + **Create a new role for the SRT to access my account** – Shield creates a role that trusts the service principal `drt.shield.amazonaws.com`, which represents the SRT, and attaches the managed policy `AWSShieldDRTAccessPolicy` to it. The managed policy allows the SRT to make AWS Shield Advanced and AWS WAF API calls on your behalf and to access your AWS WAF logs. For more information about the managed policy, see [AWS managed policy: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
   + **Choose an existing role for the SRT to access my accounts** – For this option, you must modify the configuration of the role in AWS Identity and Access Management (IAM) as follows: 
     + Attach the managed policy `AWSShieldDRTAccessPolicy` to the role. This managed policy allows the SRT to make AWS Shield Advanced and AWS WAF API calls on your behalf and to access your AWS WAF logs. For more information about the managed policy, see [AWS managed policy: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). For information about attaching the managed policy to your role, see [Attaching and Detaching IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). 
     + Modify the role to trust the service principal `drt.shield.amazonaws.com`. This is the service principal that represents the SRT. For more information, see [IAM JSON Policy Elements: Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). 

1. Choose **Save** to save your changes. 

For more information about giving the SRT access to your protections and data, see [Granting access for the SRT](ddos-srt-access.md). 

**To enable SRT proactive engagement**

1. In the AWS Shield console **Overview** page, under **Proactive engagement and contacts**, in the contacts area, choose **Edit**.

   In the **Edit contacts** page, provide the contact information for the people that you want the SRT to contact for proactive engagement. 

   If you provide more than one contact, in the **Notes**, indicate the circumstances under which each contact should be used. Include primary and secondary contact designations, and provide the hours of availability and time zones for each contact. 

   Example contact notes: 
   + This is a hotline that's staffed 24x7x365. Please work with the responding analyst and they will get the appropriate person on the call. 
   + Please contact me if the hotline doesn't respond within 5 minutes.

1. Choose **Save**. 

   The **Overview** page reflects the updated contact information.

1. Choose **Edit proactive engagement feature**, choose **Enable**, and then choose **Save** to enable proactive engagement. 

For more information about proactive engagement, see [Setting up proactive engagement for the SRT to contact you directly](ddos-srt-proactive-engagement.md).

# Creating a DDoS dashboard in CloudWatch and setting CloudWatch alarms
<a name="deploy-waf-dashboard"></a>

This page provides instructions for creating a DDoS dashboard in CloudWatch and setting CloudWatch alarms.

You can monitor potential DDoS activity using Amazon CloudWatch, which collects raw data from Shield Advanced and processes it into readable, near real-time metrics. You can use statistics in CloudWatch to gain a perspective on how your web application or service is performing. For more information about using CloudWatch, see [What is CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) in the *Amazon CloudWatch User Guide*.
+ For instructions for creating a CloudWatch dashboard, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md). 
+ For descriptions of the Shield Advanced metrics that you can add to your dashboard, see [AWS Shield Advanced metrics](shield-metrics.md). 

Shield Advanced reports resource metrics to CloudWatch more frequently during DDoS events than while no events are underway. Shield Advanced reports metrics once a minute during an event, and then once right after the event ends. While no events are underway, Shield Advanced reports metrics once a day, at a time assigned to the resource. This periodic report keeps the metrics active and available for use in your custom CloudWatch alarms. 

This completes the tutorial for getting started with Shield Advanced. To take full advantage of the protections you've chosen, continue exploring the features and options of Shield Advanced. To start, familiarize yourself with your options for viewing and responding to events at [Visibility into DDoS events with Shield Advanced](ddos-viewing-events.md) and [Responding to DDoS events in AWS](ddos-responding.md).

# Managed DDoS event response with Shield Response Team (SRT) support
<a name="ddos-srt-support"></a>

This page describes the function of the Shield Response Team (SRT).

The SRT provides added support for Shield Advanced customers. The SRT are security engineers who specialize in DDoS event response. As an additional layer of support to your AWS Support plan, you can work directly with the SRT, leveraging their expertise as part of your event response workflow. For information about the options and for configuration guidance, see the topics that follow.

**Note**  
To use the services of the Shield Response Team (SRT), you must be subscribed to the [Business Support plan](https://aws.amazon.com/premiumsupport/business-support/) or the [Enterprise Support plan](https://aws.amazon.com/premiumsupport/enterprise-support/).
Shield Response Team (SRT) provides services in regions where Shield Advanced is available, and for customers in GovCloud regions, AWS GovCloud (US-East) and AWS GovCloud (US-West).

**SRT support activities**  
The primary goal in an engagement with the SRT is to protect the availability and performance of your application. Depending on the type of DDoS event and the architecture of your application, the SRT may take one or more of the following actions: 
+ **AWS WAF log analysis and rules** – For resources that use an AWS WAF web ACL, the SRT can analyze your AWS WAF logs to identify attack characteristics in your application web requests. With your approval during engagement, the SRT can apply changes to your web ACL to block the attacks that they've identified. 
+ **Build custom network mitigations** – The SRT can write custom mitigations for you for infrastructure layer attacks. The SRT can work with you to understand traffic that's expected for your application, to block unexpected traffic, and to optimize packet per second rate limits. For more information, see [Setting up custom mitigations against DDoS attacks with the SRT](ddos-srt-custom-mitigations.md).
+ **Network traffic engineering** – The SRT works closely with AWS networking teams to protect Shield Advanced customers. When required, AWS can change how internet traffic arrives on the AWS network in order to allocate more mitigation capacity to your application. 
+ **Architectural recommendations** – The SRT may determine that the best mitigation for an attack requires architectural changes to better align with the AWS best practices, and they will help support your implementation of these practices. For information, see [AWS Best Practices for DDoS Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency). 

The following sections provide instructions for engaging with the SRT

**Topics**
+ [Granting access for the SRT](ddos-srt-access.md)
+ [Setting up proactive engagement for the SRT to contact you directly](ddos-srt-proactive-engagement.md)
+ [Contacting the SRT for help with a suspected DDoS event](ddos-srt-contacting.md)
+ [Setting up custom mitigations against DDoS attacks with the SRT](ddos-srt-custom-mitigations.md)

# Granting access for the SRT
<a name="ddos-srt-access"></a>

This page provides instructions for granting permission to the SRT to act on your behalf, so that they can access your AWS WAF logs and make calls to the AWS Shield Advanced and AWS WAF APIs to manage protections. 

 During application layer DDoS events, the SRT can monitor AWS WAF requests to identify anomalous traffic and help craft custom AWS WAF rules to mitigate offending traffic sources. 

Additionally, you can grant the SRT access to other data that you have stored in Amazon S3 buckets, such as packet captures or logs from an Application Load Balancer, Amazon CloudFront, or from third party sources.

**Note**  
To use the services of the Shield Response Team (SRT), you must be subscribed to the [Business Support plan](https://aws.amazon.com/premiumsupport/business-support/) or the [Enterprise Support plan](https://aws.amazon.com/premiumsupport/enterprise-support/). 

**To manage permissions for the SRT**

1. In the AWS Shield console **Overview** page, under **Configure AWS SRT support**, choose **Edit SRT access**. The **Edit AWS Shield Response Team (SRT) access** page opens.

1. For **SRT access setting** select one of the options: 
   + **Do not grant the SRT access to my account** – Shield removes any permissions you previously gave to the SRT to access your account and resources.
   + **Create a new role for the SRT to access my account** – Shield creates a role that trusts the service principal `drt.shield.amazonaws.com`, which represents the SRT, and attaches the managed policy `AWSShieldDRTAccessPolicy` to it. The managed policy allows the SRT to make AWS Shield Advanced and AWS WAF API calls on your behalf and to access your AWS WAF logs. For more information about the managed policy, see [AWS managed policy: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
   + **Choose an existing role for the SRT to access my accounts** – For this option, you must modify the configuration of the role in AWS Identity and Access Management (IAM) as follows: 
     + Attach the managed policy `AWSShieldDRTAccessPolicy` to the role. This managed policy allows the SRT to make AWS Shield Advanced and AWS WAF API calls on your behalf and to access your AWS WAF logs. For more information about the managed policy, see [AWS managed policy: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). For information about attaching the managed policy to your role, see [Attaching and Detaching IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). 
     + Modify the role to trust the service principal `drt.shield.amazonaws.com`. This is the service principal that represents the SRT. For more information, see [IAM JSON Policy Elements: Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). 

1. For **(Optional): Grant SRT access to an Amazon S3 bucket**, if you need to share data that isn't in your AWS WAF web ACL logs, configure this. For example, Application Load Balancer access logs, Amazon CloudFront logs, or logs from third party sources. 
**Note**  
You don't need to do this for your AWS WAF web ACL logs. The SRT gains access to those when you grant access to your account. 

   1. Configure the Amazon S3 buckets according to the following guidelines: 
      + The bucket locations must be in the same AWS account as the one you gave the SRT general access to, in the prior step **AWS Shield Response Team (SRT) access**. 
      + The buckets can be either plaintext or SSE-S3 encrypted. For more information about Amazon S3 SSE-S3 encryption, see [Protecting Data Using Server-Side Encryption with Amazon S3-Managed Encryption Keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) in the Amazon S3 User Guide.

        The SRT cannot view or process logs that are stored in buckets that are encrypted with keys stored in AWS Key Management Service (AWS KMS). 

   1. In the Shield Advanced **(Optional): Grant SRT access to an Amazon S3 bucket** section, for each Amazon S3 bucket where your data or logs are stored, enter the name of the bucket and choose **Add Bucket**. You can add up to 10 buckets.

      This grants the SRT the following permissions on each bucket: `s3:GetBucketLocation`, `s3:GetObject`, and `s3:ListBucket`.

      If you want to give the SRT permission to access more than 10 buckets, you can do this by editing the additional bucket policies and manually granting the permissions listed here for the SRT.

      The following shows an example policy listing.

      ```
      {
          "Sid": "AWSDDoSResponseTeamAccessS3Bucket",
          "Effect": "Allow",
          "Principal": {
              "Service": "drt.shield.amazonaws.com"
          },
          "Action": [
              "s3:GetBucketLocation",
              "s3:GetObject",
              "s3:ListBucket"
          ],
          "Resource": [
              "arn:aws:s3:::bucket-name",
              "arn:aws:s3:::bucket-name/*"
          ]
      }
      ```

1. Choose **Save** to save your changes.

You can also authorize the SRT through the API by creating an IAM role, attaching the policy AWSShieldDRTAccessPolicy to it, and then passing the role to the operation [AssociateDRTRole](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_AssociateDRTRole.html). 

# Setting up proactive engagement for the SRT to contact you directly
<a name="ddos-srt-proactive-engagement"></a>

This page provides instructions for setting up proactive engagement with the SRT.

With proactive engagement, the SRT contacts you directly when the availability or performance of your application is affected because of a possible attack. We recommend this engagement model because it provides the quickest SRT response and it allows the SRT to begin troubleshooting even before they've established contact with you. 

Proactive engagement is available for network-layer and transport-layer events on Elastic IP addresses and AWS Global Accelerator standard accelerators, and for web request floods on Amazon CloudFront distributions and Application Load Balancers. Proactive engagement is available only for Shield Advanced resource protections that have an associated Amazon Route 53 health check. For information about managing and using health checks, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md).

During an event that's detected by Shield Advanced, the SRT uses the state of your health checks to determine whether the event qualifies for proactive engagement. If so, the SRT will contact you according to the contact guidance that you provide in your proactive engagement configuration. 

You can configure up to ten contacts for proactive engagement, and you can provide notes to guide the SRT in reaching out to you. Your proactive engagement contacts should be available to engage with the SRT during events. If you don't have a 24/7 operations center, you can provide a pager contact and indicate this contact preference in your contact notes.

Proactive engagement requires you to do the following: 
+ You must be subscribed to the [Business Support plan](https://aws.amazon.com/premiumsupport/business-support/) or the [Enterprise Support plan](https://aws.amazon.com/premiumsupport/enterprise-support/).
+ You must associate an Amazon Route 53 health check with any resource that you want to protect with proactive engagement. The SRT uses the status of your health checks to help determine whether an event requires proactive engagement, so it's important that your health checks accurately reflect the state of your protected resources. For more information and guidance, see [Health-based detection using health checks with Shield Advanced and Route 53](ddos-advanced-health-checks.md).
+ For a resource that has an AWS WAF web ACL associated, you must create the web ACL using AWS WAF (v2), which is the latest version of AWS WAF. 
+ You must provide at least one contact for the SRT to use for proactive engagement during an event. Keep your contact information complete and up to date. 

**To enable SRT proactive engagement**

1. In the AWS Shield console **Overview** page, under **Proactive engagement and contacts**, in the contacts area, choose **Edit**.

   In the **Edit contacts** page, provide the contact information for the people that you want the SRT to contact for proactive engagement. 

   If you provide more than one contact, in the **Notes**, indicate the circumstances under which each contact should be used. Include primary and secondary contact designations, and provide the hours of availability and time zones for each contact. 

   Example contact notes: 
   + This is a hotline that's staffed 24x7x365. Please work with the responding analyst and they will get the appropriate person on the call. 
   + Please contact me if the hotline doesn't respond within 5 minutes.

1. Choose **Save**. 

   The **Overview** page reflects the updated contact information.

1. Choose **Edit proactive engagement feature**, choose **Enable**, and then choose **Save** to enable proactive engagement. 

# Contacting the SRT for help with a suspected DDoS event
<a name="ddos-srt-contacting"></a>

You can contact the SRT in one of the following ways: 

**Support case**  
You can open a case under **AWS Shield** in the **AWS Support Center** console. 

For guidance on creating a support case, see [AWS Support Center](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html). 

Select the severity appropriate to your situation and provide your contact details. In the description, provide as much detail as possible. Provide information about any protected resources that you think might be affected, and the current state of your end-user experience. For example, if your user experience is degraded or parts of your application are currently unavailable, provide that information.
+ **For suspected DDoS attacks** – If the availability or performance of your application is currently affected by a possible DDoS attack, choose the following severity and contact options: 
  + For severity, choose the highest severity available for your support plan:
    + For Business support this is **Production system down: < 1 hour**. 
    + For Enterprise support this is **Business-critical system down: < 15 minutes**. 
  + For contact option, select either **Phone** or **Chat** and provide your details. Using a live contact method provides the fastest response.

**Proactive engagement**  
With AWS Shield Advanced proactive engagement, the SRT contacts you directly if the Amazon Route 53 health check associated with your protected resource becomes unhealthy during a detected event. For more information about this option, see [Setting up proactive engagement for the SRT to contact you directly](ddos-srt-proactive-engagement.md).

# Setting up custom mitigations against DDoS attacks with the SRT
<a name="ddos-srt-custom-mitigations"></a>

This page provides instructions for working with the SRT to build custom mitigations against DDoS attacks.

For your Elastic IPs (EIPs) and your AWS Global Accelerator standard accelerators, you can work with the SRT to configure custom mitigations. This is useful in case you know of specific logic that should be enforced when a mitigation is placed. For example, you may wish to only allow traffic from certain countries, enforce specific rate limits, configure optional validations, disallow fragments, or only allow traffic that matches a specific pattern in the packet payload. 

Examples of common custom mitigations include the following:
+ **Pattern matching** – If you operate a service that interacts with client-side applications, you can choose to match on known patterns that are unique to those applications. For example, you may operate a gaming or communications service that requires the end-user to install specific software that you distribute. You can include a magic number in every packet sent by the application to your service. You can match on up to 128 bytes (separate or contiguous) of a non-fragmented TCP or UDP packet payload and headers. The match can be expressed in hexadecimal notation as a specific offset from the beginning of the packet payload or a dynamic offset following a known value. For example, the mitigation can look for the byte `0x01` and then expect `0x12345678` as the next four bytes.
+ **DNS specific** – If you operate your own authoritative DNS service using services like Global Accelerator or Amazon Elastic Compute Cloud (Amazon EC2), you can request a custom mitigation that validates packets to ensure that they are valid DNS queries and apply suspicion scoring that evaluates attributes that are specific to DNS traffic. 

To inquire about working with SRT to build custom mitigations, create a support case under AWS Shield. To learn more about creating AWS Support cases, see [Getting started with AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html). 

# Resource protections in AWS Shield Advanced
<a name="ddos-resource-protections"></a>

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
<a name="ddos-protections-by-resource-type"></a>

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
<a name="ddos-protections-ec2-nlb"></a>

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
<a name="ddos-app-layer-protections"></a>

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
<a name="ddos-app-layer-detection-mitigation"></a>

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
<a name="ddos-app-layer-web-ACL-and-rbr"></a>

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
<a name="ddos-app-layer-rbr"></a>

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
<a name="ddos-automatic-app-layer-response"></a>

**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
<a name="ddos-automatic-app-layer-response-caveats"></a>

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
<a name="ddos-automatic-app-layer-response-bp"></a>

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
<a name="ddos-automatic-app-layer-response-config"></a>

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
<a name="ddos-automatic-app-layer-response-enable"></a>

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
<a name="ddos-automatic-app-layer-response-behavior"></a>

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
<a name="ddos-automatic-app-layer-response-ddos-attack"></a>

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
<a name="ddos-automatic-app-layer-response-rule-action"></a>

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
<a name="ddos-automatic-app-layer-response-after-attack"></a>

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
<a name="ddos-automatic-app-layer-response-disable"></a>

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
<a name="ddos-automatic-app-layer-response-rg"></a>

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
<a name="view-automatic-app-layer-response-configuration"></a>

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
<a name="enable-disable-automatic-app-layer-response"></a>

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
<a name="change-action-of-automatic-app-layer-response"></a>

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
<a name="manage-automatic-mitigation-in-cfn"></a>

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
<a name="ddos-advanced-health-checks"></a>

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
<a name="health-checks-best-practices"></a>

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
<a name="health-checks-metrics"></a>

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
<a name="health-checks-metrics-common"></a>


| 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
<a name="health-checks-protected-resource-metrics"></a>

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
<a name="associate-health-check"></a>

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
<a name="disassociate-health-check"></a>

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
<a name="health-check-association-status"></a>

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
<a name="health-checks-examples"></a>

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
<a name="health-checks-example-cloudfront"></a>

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
<a name="health-checks-example-load-balancer"></a>

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)
<a name="health-checks-example-elastic-ip"></a>

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
<a name="configure-new-protection"></a>

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
<a name="manage-protection"></a>

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
<a name="configure-app-layer-protection"></a>

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
<a name="add-alarm-ddos"></a>

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
<a name="remove-protection"></a>

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
<a name="remove-cloudwatch-ddos"></a>

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
<a name="ddos-protection-groups"></a>

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
<a name="protection-group-creating"></a>

**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
<a name="protection-group-updating"></a>

**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
<a name="protection-group-deleting"></a>

**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
<a name="ddos-add-config"></a>

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.

# Visibility into DDoS events with Shield Advanced
<a name="ddos-viewing-events"></a>

AWS Shield provides visibility into the following categories of events and event activities: 
+ **Global** – All customers can access an aggregated view of global threat activity over the last two weeks. You can see this information under the **Getting Started** and **Global threat dashboard** pages of the AWS Shield console. For more information, see [Viewing AWS Shield global and account activity](ddos-standard-event-visibility.md).
+ **Account** – All customers can access a summary of the events for their account over the prior year. You can see this information under the **Getting Started** page of the AWS Shield console. For more information, see [Viewing AWS Shield global and account activity](ddos-standard-event-visibility.md).

When you subscribe to Shield Advanced and add protections to your resources, you gain access to additional information about the events and DDoS attacks on the protected resources:
+ **Events on protected resources** – Shield Advanced provides detailed information for each event through the **Events** page of the AWS Shield console. For more information, see [Viewing AWS Shield Advanced events](ddos-events.md).
+ **Event metrics for protected resources** – Shield Advanced publishes detection, mitigation, and top contributor Amazon CloudWatch metrics for all resources that it protects. You can use these metrics to configure CloudWatch dashboards and alarms. For more information, see [AWS Shield Advanced metrics](shield-metrics.md).
+ **Cross-account event visibility for protected resources** – If you use AWS Firewall Manager to manage your Shield Advanced protections, you can enable visibility into protections across multiple accounts by using Firewall Manager combined with AWS Security Hub CSPM. For more information, see [Viewing Shield Advanced events across multiple AWS accounts with AWS Firewall Manager and AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md).

If you enable automatic application layer DDoS mitigation for an application layer protection, Shield Advanced adds a rule group to your protection pack (web ACL) that it uses to manage automated protections. This 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.md). 

**Topics**
+ [Viewing AWS Shield global and account activity](ddos-standard-event-visibility.md)
+ [Viewing AWS Shield Advanced events](ddos-events.md)
+ [Viewing Shield Advanced events across multiple AWS accounts with AWS Firewall Manager and AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)

# Viewing AWS Shield global and account activity
<a name="ddos-standard-event-visibility"></a>

This page provides instructions for accessing an aggregated view of global threat activity and a per-account event summary in the AWS Shield console **Getting Started** and **Global threat dashboard** pages. 

The following screenshot shows an example **Getting Started** page. 

![\[The AWS Shield console shows the Getting started page, containing the global threat and account event summary panes.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-global-account.png)


**To access the AWS Shield console**
+ 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/). 

You don't need a subscription to Shield Advanced to access global activity and account event summary information. 

**Global activity**  
 This information is available through the AWS Shield console **Global threat dashboard** and **Getting Started** pages. The following screenshot shows an example of the global activity pane. 

![\[A AWS Shield console pane titled Global activity detected by Shield shows a world map superimposed by heatmap markings for areas where global threats have been detected in the last two weeks.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-global-activity.png)


Global activity describes DDoS events observed across all AWS customers. Once per hour, AWS updates the information for the prior two weeks. In the console pane, you can see the results, partitioned by AWS Region and displayed on a world heat map. Next to the map, Shield displays summary information such as the largest packet attack, largest bit rate, most common vector, total number of attacks, and threat level. The threat level is an assessment of the current global activity compared to what AWS typically observes. The default threat level value is **Normal**. AWS automatically updates the value to **High** for elevated DDoS activity. 

The **Global threat dashboard** also provides time-series metrics and gives you the ability to change between time durations. To view the history of significant DDoS attacks, you can customize the dashboard for views from the last day to the last two weeks. Time-series metrics provide a view of the largest bit rate, packet rate, or request rate for all events detected by AWS Shield for applications running on AWS during the time window that you select. 

**Account activity**  
This information is available in the AWS Shield console **Getting Started** page. 

The following screenshot shows an example account activity pane. 

![\[A AWS Shield console pane titled Account activity detected by Shield lists a summary of events for the past year, with information like the total number of events and the largest packet rate and request rate.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-account-activity.png)


Account activity describes DDoS events that Shield detected for your resources that are eligible for protection by Shield Advanced. Each day, Shield creates summary metrics for the year ending at 00:00 UTC the prior day, and then displays total events, largest bit rate, largest packet rate, and largest request rate. 
+ The total events metric reflects every time that Shield observed suspicious attributes in traffic that was destined to your application. Suspicious attributes can include traffic that is at a higher than normal volume, traffic that does not match your application’s historical profile, or traffic that does not match heuristics that are defined by Shield for valid application traffic. 
+ Largest bit rate and largest packet rate statistics are available for every resource. 
+ The largest request rate statistic is available only for Amazon CloudFront distributions and Application Load Balancers that have an associated AWS WAF web ACL.

**Note**  
You can also access the account level event summary through the AWS Shield API operation [DescribeAttackStatistics](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_DescribeAttack.html).

# Viewing AWS Shield Advanced events
<a name="ddos-events"></a>

This page provides instructions for accessing information about events in Shield Advanced.

When you subscribe to Shield Advanced, and protect your resources, you gain access to additional visibility features for the resources. These include near real-time notification of events that are detected by Shield Advanced and additional information about detected events and mitigations. 

**Note**  
Your event information in the Shield Advanced console is based on Shield Advanced metrics. For information about Shield Advanced metrics, see [AWS Shield Advanced metrics](shield-metrics.md) 

AWS Shield evaluates traffic to your protected resource along multiple dimensions. When an anomaly is detected, Shield Advanced creates a separate event for each resource that's affected. 

You can access event summaries and details through the **Events** page of the Shield console. The top level **Events** page provides an overview of current and past events. 

The following screenshot shows an example **Events** page with a single ongoing event. This active event is also flagged in the left navigation pane. 

![\[The AWS Shield console left navigation pane has the Events selection highlighted in red, with a numeral 1 beside it, inside a red circle. The Events page is open, and shows a single row in the events list. The row lists an AWS resource of type CloudFront distribution. The Current status field contains a triangular red icon next to the words Mitigation in progress. The Attack vectors status field contains UDP traffic. The Start time field contains Sep 16th 2020, 2:43:00 pm SAST. The Duration field contains 6 minutes.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-event-summary1.png)


Shield Advanced might also automatically place mitigations against attacks, depending on the traffic type and on your configured protections. These mitigations can protect your resource from receiving excess traffic or traffic that matches a known DDoS attack signature.

The following screenshot shows an example **Events** listing where all events have been mitigated by Shield Advanced or have subsided on their own. 

![\[A AWS Shield console page titled Events lists events that have been detected recently and their current status.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-events.png)


**Protect your resources before an event**  
Improve the accuracy of event detection by protecting resources with Shield Advanced while they are receiving the normal expected traffic, before they are subject to a DDoS attack.

In order to accurately report events for a protected resource, Shield Advanced must first establish a baseline of expected traffic patterns for it.
+ Shield Advanced reports infrastructure layer events for resources after they've been protected for at least 15 minutes.
+ Shield Advanced reports web application layer events for resources after they've been protected for at least 24 hours. The accuracy of detection for application layer events is best after Shield Advanced has observed expected traffic for 30 days. 

**To access events information in the AWS Shield console**

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 **Events**. The console shows the **Events** page. 

1. From the **Events** page, you can select any event in the list to see additional summary information and details for the event. 

**Topics**
+ [List of fields in AWS Shield Advanced event summaries](ddos-event-summaries.md)
+ [Viewing AWS Shield Advanced event details](ddos-event-details.md)

# List of fields in AWS Shield Advanced event summaries
<a name="ddos-event-summaries"></a>

This page lists and defines the fields in Shield Advanced event summaries.

You can view summary and detail information for an event in the event's console page. To open the page for an event, select its AWS resource name from the **Events** page list. 

The following screenshot shows an example event summary for a network layer event. 

![\[The summary pane of the AWS Shield console event page lists information for an event and includes the affected AWS resource, attack vectors, start and end times, and mitigation and status information.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-event-summary2.png)


The event page summary information includes the following. 
+ **Current status** – Values that indicate the state of the event and the actions that Shield Advanced has taken on the event. Status values apply to infrastructure layer (layer 3 or 4) and application layer (layer 7) events. 
  + **Identified (ongoing)** and **Identified (subsided)** – These indicate that Shield Advanced detected an event, but has taken no action on it so far. **Identified (subsided)** indicates that the suspicious traffic that Shield detected has stopped without intervention. 
  + **Mitigation in progress** and **Mitigated** – These indicate that Shield Advanced detected an event and has taken action on it. **Mitigated** is also used when the targeted resource is an Amazon CloudFront distribution or Amazon Route 53 hosted zone, which have their own automatic inline mitigations.
+ **Attack vectors** – DDoS attack vectors like TCP SYN floods and Shield Advanced detection heuristics like request flood. These can be indicators of a DDoS attack. 
+ **Start time** – The date and time that the first anomalous traffic data point was detected. 
+ **Duration or end time** – Indicates the time elapsed between the event start time and the last observed anomalous data point that Shield Advanced observed. While an event is ongoing, these values will continue to increase.
+ **Protection** – Names the Shield Advanced protection that's in associated with the resource, and provides a link to its protection page. This is available in the individual event's page.
+ **Automatic application layer DDoS mitigation** – Used for application layer protections, to indicate whether the Shield Advanced automatic application layer DDoS mitigation is enabled for the resource. If it is enabled, this provides a link to access and manage the configuration. This is available in the individual event's page.
+ **Network layer automatic mitigation** – Indicates whether the resource has automatic mitigation at the network layer. If a resource has a network layer component, it will have this enabled. This information is available in the individual event's page.

For resources that are frequently targeted, Shield may leave mitigations in place after excess traffic has subsided, to prevent further recurring events. 

**Note**  
You can also access event summaries for protected resources through the AWS Shield API operation [ListAttacks](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_ListAttacks.html).

# Viewing AWS Shield Advanced event details
<a name="ddos-event-details"></a>

You can see details about an event's detection, mitigation, and top contributors in the bottom section of the console page for the event. This section can include a mix of legitimate and potentially unwanted traffic, and may represent both traffic that was passed to your protected resource and traffic that was blocked by Shield mitigations.
+ **Detection and mitigation** – Provides information about the observed event and any applied mitigations against it. For information about event mitigation, see [Responding to DDoS events in AWS](ddos-responding.md).
+ **Top contributors** – Categorizes the traffic that's involved in the event, and lists the primary sources of traffic that Shield has identified for each category. For application layer events, use the top contributors information to get a general idea of the nature of an event, but use the AWS WAF logs for your security decisions. For more information, see the sections that follow.

Your event information in the Shield Advanced console is based on Shield Advanced metrics. For information about Shield Advanced metrics, see [AWS Shield Advanced metrics](shield-metrics.md) 

Mitigation metrics aren't included for Amazon CloudFront or Amazon Route 53 resources, because these services are protected by a mitigation system that's always enabled and doesn't require mitigations for individual resources. 

The details sections vary according to whether the information is for an infrastructure layer or application layer event. 

**Topics**
+ [Viewing application layer (layer 7) event details in Shield Advanced](ddos-event-details-application-layer.md)
+ [Viewing infrastructure layer (layer 3 or 4) event details in Shield Advanced](ddos-event-details-infrastructure-layer.md)

# Viewing application layer (layer 7) event details in Shield Advanced
<a name="ddos-event-details-application-layer"></a>

You can see details about an application layer event's detection, mitigation, and top contributors in the bottom section of the console page for the event. This section can include a mix of legitimate and potentially unwanted traffic, and may represent both traffic that was passed to your protected resource and traffic that was blocked by Shield Advanced mitigations. 

The mitigation details are for any rules in the web ACL that's associated with the resource, including rules that are deployed specifically in response to an attack and rate-based rules that are defined in the web ACL. If you enable automatic application layer DDoS mitigation for an application, the mitigation metrics include metrics for those additional rules. For information about these application layer protections, see [Protecting the application layer (layer 7) with AWS Shield Advanced and AWS WAF](ddos-app-layer-protections.md).

## Detection and mitigation
<a name="ddos-event-details-application-layer-detection-mitigation"></a>

For an application layer (layer 7) event, the **Detection and mitigation** tab shows detection metrics that are based on information obtained from the AWS WAF logs. Mitigation metrics are based on AWS WAF rules in the associated web ACL that are configured to block the unwanted traffic. 

For Amazon CloudFront distributions, you can configure Shield Advanced to apply automatic mitigations for you. With any application layer resources, you can choose to define your own mitigating rules in your web ACL and you can request help from the Shield Response Team (SRT). For information about these options, see [Responding to DDoS events in AWS](ddos-responding.md).

The following screenshot shows an example of the detection metrics for an application layer event that subsided after a number of hours. 

![\[A detection metrics graph shows detection of request flood traffic from 11:30 until it subsides at 16:00.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-app-detection-metrics.png)


Event traffic that subsides before a mitigating rule takes effect isn't represented in mitigation metrics. This can result in a difference between the web request traffic shown in the detection graphs and the allow and block metrics shown in the mitigation graphs. 

## Top contributors
<a name="ddos-event-details-application-layer-top-contributors"></a>

The **Top contributors** tab for application layer events displays the top 5 contributors that Shield has identified for the event, based on the AWS WAF logs that it has retrieved. Shield categorizes the top contributors information by dimensions such as source IP, source country, and destination URL.

**Note**  
For the most accurate information about the traffic that's contributing to an application layer event, use the AWS WAF logs. 

Use the Shield application layer top contributors information only to get a general idea of the nature of an attack, and do not base your security decisions on it. For application layer events, the AWS WAF logs are the best source of information for understanding the contributors to an attack and for devising your mitigation strategies. 

The Shield top contributors information doesn't always completely reflect the data in the AWS WAF logs. When it ingests the logs, Shield prioritizes reducing the impact to system performance over retrieving the complete set of data from the logs. This can result in a loss of granularity in the data that's available to Shield for analysis. In most cases, the majority of the information is available, but it's possible for the top contributor data to be skewed to some degree for any attack. 

The following screenshot shows an example **Top contributors** tab for an application layer event. 

![\[The top contributors tab for an application layer event describes the top 5 contributors for a number of web request characteristics. The screen shows the top 5 source IP addresses, top 5 destination URLs, top 5 source countries, and top 5 user agents.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-app-event-top-contributors.png)


Contributor information is based on requests for both legitimate and potentially unwanted traffic. Larger volume events and events where the request sources aren't highly distributed are more likely to have identifiable top contributors. A significantly distributed attack could have any number of sources, making it hard to identify top contributors to the attack. If Shield Advanced doesn't identify significant contributors for a specific category, it displays the data as unavailable. 

# Viewing infrastructure layer (layer 3 or 4) event details in Shield Advanced
<a name="ddos-event-details-infrastructure-layer"></a>

You can see details about an infrastructure layer event's detection, mitigation, and top contributors in the bottom section of the console page for the event. This section can include a mix of legitimate and potentially unwanted traffic, and may represent both traffic that was passed to your protected resource and traffic that was blocked by Shield mitigations. 

## Detection and mitigation
<a name="ddos-event-details-infrastructure-layer-detection-mitigation"></a>

For an infrastructure layer (layer 3 or 4) event, the **Detection and mitigation** tab shows detection metrics that are based on sampled network flows and mitigation metrics that are based on traffic observed by the mitigation systems. Mitigation metrics are a more precise measurement of the traffic into your resource. 

Shield automatically creates a mitigation for the protected resource types Elastic IP (EIP), Classic Load Balancer (CLB), Application Load Balancer (ALB), and AWS Global Accelerator standard accelerator. Mitigation metrics for EIP addresses and AWS Global Accelerator standard accelerators indicate the number of passed and dropped packets. 

The following screenshot shows an example **Detection and mitigation** tab for an infrastructure layer event. 

![\[The detection and mitigation graphs for a network event show increasing SYN flood and packet flood traffic in the detection metrics, matched by a an increase in mitigations that drop traffic a few seconds later, in the mitigation metrics. After about thirty seconds of increased mitigations, the traffic floods stop.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-network-event-detection-mitigation.png)


Event traffic that subsides before Shield places a mitigation isn't represented in the mitigation metrics. This can result in a difference between the traffic shown in the detection graphs and the pass and drop metrics shown in the mitigation graphs. 

## Top contributors
<a name="ddos-event-details-infrastructure-layer-top-contributors"></a>

The **Top contributors** tab for infrastructure layer events lists metrics for up to 100 top contributors on several traffic dimensions. The details include network layer properties for any dimension where at least five significant sources of traffic could be identified. Examples of sources of traffic are source IP and source ASN. 

The following screenshot shows an example **Top contributors** tab for an infrastructure layer event. 

![\[The top contributors tab for a network event shows the categories of traffic that contributed the most to the event. The categories in this case include volume by protocol, volume by protocol and destination port, volume by protocol and source ASN, and volume by TCP flags.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-network-event-top-contributors.png)


Contributor metrics are based on sampled network flows for both legitimate and potentially unwanted traffic. Larger volume events and events where the traffic sources aren't highly distributed are more likely to have identifiable top contributors. A significantly distributed attack could have any number of sources, making it hard to identify top contributors to the attack. If Shield doesn't identify any significant contributors for a specific metric or category, it displays the data as unavailable. 

In an infrastructure layer DDoS attack, traffic sources might be spoofed or reflected. A spoofed source is intentionally forged by the attacker. A reflected source is the real source of detected traffic, but it's not a willing participant in the attack. For example, an attacker might generate a large, amplified flood of traffic to a target by reflecting the attack off of services on the internet that are usually legitimate. In this case, the source information might be valid while it's not the actual source of the attack. These factors can limit the viability of mitigation techniques that block sources based on packet headers.

# Viewing Shield Advanced events across multiple AWS accounts with AWS Firewall Manager and AWS Security Hub CSPM
<a name="ddos-viewing-multiple-accounts"></a>

You can use AWS Firewall Manager and AWS Security Hub CSPM to manage and monitor AWS Shield Advanced protected resources across multiple accounts. 

With Firewall Manager, you can create a Shield Advanced security policy that reports and enforces DDoS protection compliance across all of your accounts. Firewall Manager monitors your protected resources, including adding protections to new resources that come into scope of the Shield Advanced policy. 

You can integrate Firewall Manager with AWS Security Hub CSPM to get a single dashboard that reports DDoS events that are detected by Shield Advanced and Firewall Manager compliance findings, when Firewall Manager identifies a resource that's out of compliance with your Shield Advanced security policy. 

The following figure depicts a typical architecture for monitoring Shield Advanced protected resources with Firewall Manager and Security Hub CSPM. 

![\[At the top of the figure is an AWS Organizations icon. It has an arrow pointing down that splits to point to two icons that are side by side. The left icon has the title Production OU and the right icon has the title Security OU. Below these icons sit three icons, titled from left to right: AWS Shield Advanced, AWS Firewall Manager, and AWS Security Hub CSPM. The production OU icon has an arrow pointing down to the Shield Advanced icon. The security OU icon has an arrow pointing down that splits to point to the Firewall Manager and Security Hub CSPM icons. The Shield Advanced icon has an arrow pointing down to a rectangle with the title Shield Advanced protected resources. Inside the rectangle are icons for Application Load Balancer, CloudFront distribution, and Elastic IP address. The Firewall Manager icon also has an arrow pointing down to the Shield Advanced protected resources rectangle, and it's labeled Enforces compliance of protected resources. The Shield Advanced icon has a horizontal arrow pointing to the Firewall Manager icon that's labeled DDoS alarm. The Firewall Manager icon has a horizontal arrow pointing to its right, to the Security Hub CSPM icon that's labeled DDoS alarm and compliance findings.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-arch-fms-ash-integration.png)


When you integrate Firewall Manager with Security Hub CSPM, you can view security findings in a single place, alongside other alerts and compliance status information for the applications that you run on AWS. 

The following screenshot highlights the information that you can see for a Shield Advanced event inside the Security Hub CSPM console when you have an integration of this type. 

![\[The screenshot shows the Security Hub CSPM console Findings page, subtitled A finding is a security issue or a failed security check.. The section has red outlines highlighting the strings: Title EQUALS Shield Advanced detected attack against monitored resource and Product name EQUAL Firewall Manager. The screen shows a set of details about the specific attack and its status.\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/shield-console-security-hub-event.png)


To learn how to integrate Firewall Manager and Security Hub CSPM with Shield Advanced to centralize event and compliance monitoring across your protected accounts, see the AWS security blog [Set up centralized monitoring for DDoS events and auto-remediate noncompliant resources](https://aws.amazon.com/blogs/security/set-up-centralized-monitoring-for-ddos-events-and-auto-remediate-noncompliant-resources/). 

# Responding to DDoS events in AWS
<a name="ddos-responding"></a>

This page explains how AWS responds to DDoS attacks, and provides options for how you can further respond.

AWS automatically mitigates network and transport layer (layer 3 and layer 4) DDoS attacks. If you use Shield Advanced to protect your Amazon EC2 instances, during an attack Shield Advanced automatically deploys your Amazon VPC network ACLs to the border of the AWS network. This allows Shield Advanced to provide protection against larger DDoS events. For more information about network ACLs, see [Network ACLs](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).

For application layer (layer 7) DDoS attacks, AWS attempts to detect and notify AWS Shield Advanced customers through CloudWatch alarms. By default, it doesn't automatically apply mitigations, to avoid inadvertently blocking valid user traffic. 

For application layer (layer 7) resources, you have the following options available for responding to an attack. 
+ **Provide your own mitigations** – You can investigate and mitigate the attack on your own. For information, see [Manually mitigating an application layer DDoS attack](ddos-responding-manual.md). 
+ **Contact support** – If you're a Shield Advanced customer, you can contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/) to get help with mitigations. Critical and urgent cases are routed directly to DDoS experts. For information, see [Contacting the support center during an application layer DDoS attack](ddos-responding-contact-support.md). 

Additionally, before an attack occurs, you can proactively enable the following mitigation options: 
+ **Automatic mitigations on Amazon CloudFront distributions** – With this option, Shield Advanced defines and manages mitigating rules for you in your web ACL. For information about automatic application layer mitigation, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md). 
+ **Proactive engagement** – When AWS Shield Advanced detects a large application layer attack against one of your applications, the SRT can proactively contact you. The SRT triages the DDoS event and creates AWS WAF mitigations. The SRT contacts you and, with your consent, can apply the AWS WAF rules. For more information about this option, see [Setting up proactive engagement for the SRT to contact you directly](ddos-srt-proactive-engagement.md).

# Contacting the support center during an application layer DDoS attack
<a name="ddos-responding-contact-support"></a>

This page provides instructions for contacting the support center during an application layer DDoS attack.

If you're an AWS Shield Advanced customer, you can contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/) to get help with mitigations. Critical and urgent cases are routed directly to DDoS experts. With AWS Shield Advanced, complex cases can be escalated to the AWS Shield Response Team (SRT), which has deep experience in protecting AWS, Amazon.com, and its subsidiaries. For more information about the SRT, see [Managed DDoS event response with Shield Response Team (SRT) support](ddos-srt-support.md).

To get Shield Response Team (SRT) support, contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/). The response time for your case depends on the severity that you select and the response times, which are documented on the [AWS Support Plans](https://aws.amazon.com/premiumsupport/compare-plans/) page.

Select the following options:
+ Case type: Technical Support
+ Service: Distributed Denial of Service (DDoS)
+ Category: Inbound to AWS
+ Severity: *Choose an appropriate option*

When discussing with our representative, explain that you're an AWS Shield Advanced customer experiencing a possible DDoS attack. Our representative will direct your call to the appropriate DDoS experts. If you open a case with the [AWS Support Center](https://console.aws.amazon.com/support/home#/) using the **Distributed Denial of Service (DDoS)** service type, you can speak directly with a DDoS expert by chat or telephone. DDoS support engineers can help you identify attacks, recommend improvements to your AWS architecture, and provide guidance in the use of AWS services for DDoS attack mitigation.

For application layer attacks, the SRT can help you analyze the suspicious activity. If you have automatic mitigation enabled for your resource, the SRT can review the mitigations that Shield Advanced is automatically placing against the attack. In any case, the SRT can assist you to review and mitigate the issue. Mitigations that the SRT recommends often require the SRT to create or update AWS WAF web access control lists (web ACLs) in your account. The SRT will need your permission to do this work. 

**Important**  
We recommend that as part of enabling AWS Shield Advanced, you follow the steps in [Granting access for the SRT](ddos-srt-access.md) to proactively provide the SRT with the permissions that they need to assist you during an attack. Providing permission ahead of time helps to prevent any delays in the event of an actual attack.

The SRT helps you triage the DDoS attack to identify attack signatures and patterns. With your consent, the SRT creates and deploys AWS WAF rules to mitigate the attack.

You can also contact the SRT before or during a possible attack to review mitigations and to develop and deploy custom mitigations. For example, if you're running a web application and need only ports 80 and 443 open, you can work with the SRT to preconfigure a web ACL to "allow" only ports 80 and 443.

You authorize and contact the SRT at the account level. That is, if you use Shield Advanced within a Firewall Manager Shield Advanced policy, the account owner, not the Firewall Manager administrator, must contact the SRT for support. The Firewall Manager administrator can contact the SRT only for accounts that they own.

# Manually mitigating an application layer DDoS attack
<a name="ddos-responding-manual"></a>

This page provides instructions for manually mitigating an application layer DDoS attack.

If you determine that the activity in the events page for your resource represents a DDoS attack, you can create your own AWS WAF rules in your web ACL to mitigate the attack. This is the only option available if you aren't a Shield Advanced customer. AWS WAF is included with AWS Shield Advanced at no additional cost. For information about creating rules in your web ACL, see [Configuring protection in AWS WAF](web-acl.md).

If you use AWS Firewall Manager, you can add your AWS WAF rules to a Firewall Manager AWS WAF policy.

**To manually mitigate a potential application layer DDoS attack**

1. Create rule statements in your web ACL with criteria that matches the unusual behavior. To start with, configure them to count matching requests. For information about configuring your web ACL and rule statements, see [Using protection packs (web ACLs) with rules and rule groups in AWS WAF](web-acl-processing.md) and [Testing and tuning your AWS WAF protections](web-acl-testing.md).
**Note**  
Always test your rules first by initially using the rule action Count instead of Block. After you're comfortable that your new rules are identifying the correct requests, you can modify them to block the requests. 

1. Monitor the request counts to determine whether you want to block the matching requests. If the volume of requests continues to be unusually high and you're confident that your rules are capturing the requests that are causing the high volume, change the rules in your web ACL to block the requests. 

1. Continue monitoring the events page to ensure that your traffic is being handled as you want it to be. 

AWS provides preconfigured templates to get you started quickly. The templates include a set of AWS WAF rules that you can customize and use to block common web-based attacks. For more information, see [AWS WAF Security Automations](https://aws.amazon.com/solutions/aws-waf-security-automations/).

# Requesting a credit in AWS Shield Advanced after an attack
<a name="ddos-request-service-credit"></a>

If you're subscribed to AWS Shield Advanced and you experience a DDoS attack that increases utilization of a Shield Advanced protected resource, you can request a Shield Advanced service credit for charges related to the increased utilization, to the extent that it is not mitigated by Shield Advanced. 

**Note**  
You can apply any credits received through this process only to Shield Advanced usage. Shield Advanced credits are not available for use with other services.

Credits are available only for the following types of charges: 
+ Shield Advanced data transfer out 
+ Amazon CloudFront HTTP/HTTPS requests 
+ CloudFront data transfer out 
+ Amazon Route 53 queries 
+ AWS Global Accelerator standard accelerator data transfer 
+ Load balancer capacity units for Application Load Balancer 
+ Instance costs for protected Amazon Elastic Compute Cloud (Amazon EC2) instances that were created by an auto-scaling policy in response to the attack

**Prerequisites for requesting a credit**  
To be eligible to receive a credit, before the attack began, you must have done the following: 
+ You must have added Shield Advanced protection to the resources for which you want to request a credit. Protected resources added during an attack are not eligible for cost protection. 
**Note**  
Enabling Shield Advanced on your AWS account does not automatically enable Shield Advanced protection for individual resources. 

  For more information about how to protect AWS resources using Shield Advanced, see [Adding AWS Shield Advanced protection to AWS resources](configure-new-protection.md).
+ For applicable CloudFront and Application Load Balancer protected resources, you must have associated an AWS WAF web ACL and implemented a rate-based rule in the web ACL in Block mode. For information about AWS WAF rate-based rules, see [Using rate-based rule statements in AWS WAF](waf-rule-statement-type-rate-based.md). For information about how to associate web ACLs with AWS resources, see [Configuring protection in AWS WAF](web-acl.md). 
+ You must have implemented the appropriate best practices in [AWS Best Practices for DDoS Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency) to configure your application in a way that minimizes cost during a DDoS attack. 

**How to apply for a credit**  
To be eligible for a credit, you must submit your credit request within the 15 day period immediately following the billing month in which the attack occurred.

To apply for a credit, submit a billing case through the [AWS Support Center](https://console.aws.amazon.com/support/home#/). Include the following in your request: 
+ The words "DDoS Concession" in the subject line
+ The dates and times of each event or availability interruption for which you're requesting a credit
+ The AWS services and specific resources that were affected 

After you submit a request, the AWS Shield Response Team (SRT) will validate whether a DDoS attack occurred and, if so, whether any protected resources scaled to absorb the DDoS attack. If AWS determines that protected resources scaled to absorb the DDoS attack, AWS will issue a credit for that portion of traffic that AWS determines was caused by the DDoS attack. Credits are valid for 12 months.

# Security in your use of the AWS Shield service
<a name="shd-security"></a>

This section explains how the shared responsibility model applies to AWS Shield.

Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.

**Note**  
This section provides standard AWS security guidance for your use of the AWS Shield service and its AWS resources, such as Shield Advanced protections.   
For information about protecting your AWS resources using Shield and Shield Advanced, see the rest of the AWS Shield guide. 

Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. The effectiveness of our security is regularly tested and verified by third-party auditors as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Shield, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your organization’s requirements, and applicable laws and regulations. 

This documentation helps you understand how to apply the shared responsibility model when using Shield. The following topics show you how to configure Shield to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Shield resources. 

**Topics**
+ [Protecting your data in Shield](shd-data-protection.md)
+ [Using IAM with AWS Shield](shd-security-iam.md)
+ [Logging and monitoring in Shield](shd-incident-response.md)
+ [Validating compliance in Shield](shd-security-compliance.md)
+ [Building for resilience in Shield](shd-disaster-recovery-resiliency.md)
+ [Infrastructure security in AWS Shield](shd-infrastructure-security.md)

# Protecting your data in Shield
<a name="shd-data-protection"></a>

This section explains how the AWS shared responsibility model applies to data protection in Shield.

The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Shield. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.

For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).

We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Shield or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.

Shield entities—such as protections—are encrypted at rest, except in certain Regions where encryption is not available, including China (Beijing) and China (Ningxia). Unique encryption keys are used for each Region. 

# Using IAM with AWS Shield
<a name="shd-security-iam"></a>

This section explains how to use IAM with AWS Shield.



AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Shield resources. IAM is an AWS service that you can use with no additional charge.

**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](#security_iam_authentication)
+ [Managing access using policies](#security_iam_access-manage)
+ [How AWS Shield works with IAM](shd-security_iam_service-with-iam.md)
+ [Identity-based policy examples for AWS Shield](shd-security_iam_id-based-policy-examples.md)
+ [AWS managed policies for AWS Shield](shd-security-iam-awsmanpol.md)
+ [Troubleshooting AWS Shield identity and access](shd-security_iam_troubleshoot.md)
+ [Using service-linked roles for Shield Advanced](shd-using-service-linked-roles.md)

## Audience
<a name="security_iam_audience"></a>

How you use AWS Identity and Access Management (IAM) differs, depending on the work that you do in Shield.

**Service user** – If you use the Shield service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more Shield features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in Shield, see [Troubleshooting AWS Shield identity and access](shd-security_iam_troubleshoot.md).

**Service administrator** – If you're in charge of Shield resources at your company, you probably have full access to Shield. It's your job to determine which Shield features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with Shield, see [How AWS Shield works with IAM](shd-security_iam_service-with-iam.md).

**IAM administrator** – If you're an IAM administrator, you might want to learn details about how you can write policies to manage access to Shield. To view example Shield identity-based policies that you can use in IAM, see [Identity-based policy examples for AWS Shield](shd-security_iam_id-based-policy-examples.md).

## Authenticating with identities
<a name="security_iam_authentication"></a>

Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.

You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.

### AWS account root user
<a name="security_iam_authentication-rootuser"></a>

 When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. 

### Federated identity
<a name="security_iam_authentication-federated"></a>

As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.

A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.

For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.

### IAM users and groups
<a name="security_iam_authentication-iamuser"></a>

An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.

An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.

### IAM roles
<a name="security_iam_authentication-iamrole"></a>

An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.

IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.

## Managing access using policies
<a name="security_iam_access-manage"></a>

You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.

Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.

By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.

### Identity-based policies
<a name="security_iam_access-manage-id-based-policies"></a>

Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.

Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.

### Resource-based policies
<a name="security_iam_access-manage-resource-based-policies"></a>

Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy.

Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.

### Access control lists (ACLs)
<a name="security_iam_access-manage-acl"></a>

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.

### Other policy types
<a name="security_iam_access-manage-other-policies"></a>

AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.

### Multiple policy types
<a name="security_iam_access-manage-multiple-policies"></a>

When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.

# How AWS Shield works with IAM
<a name="shd-security_iam_service-with-iam"></a>

This section explains how to use the features of IAM with AWS Shield.

Before you use IAM to manage access to Shield, learn what IAM features are available to use with Shield.






**IAM features you can use with AWS Shield**  

| IAM feature | Shield support | 
| --- | --- | 
|  [Identity-based policies](#shd-security_iam_service-with-iam-id-based-policies)  |   Yes  | 
|  [Resource-based policies](#shd-security_iam_service-with-iam-resource-based-policies)  |   No   | 
|  [Policy actions](#shd-security_iam_service-with-iam-id-based-policies-actions)  |   Yes  | 
|  [Policy resources](#shd-security_iam_service-with-iam-id-based-policies-resources)  |   Yes  | 
|  [Policy condition keys (service-specific)](#shd-security_iam_service-with-iam-id-based-policies-conditionkeys)  |   Yes  | 
|  [ACLs](#shd-security_iam_service-with-iam-acls)  |   No   | 
|  [ABAC (tags in policies)](#shd-security_iam_service-with-iam-tags)  |   Partial  | 
|  [Temporary credentials](#shd-security_iam_service-with-iam-roles-tempcreds)  |   Yes  | 
|  [Forward access sessions (FAS)](#shd-security_iam_service-with-iam-principal-permissions)  |   Yes  | 
|  [Service roles](#shd-security_iam_service-with-iam-roles-service)  |   Yes  | 
|  [Service-linked roles](#shd-security_iam_service-with-iam-roles-service-linked)  |   Yes  | 

To get a high-level view of how Shield and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.

## Identity-based policies for Shield
<a name="shd-security_iam_service-with-iam-id-based-policies"></a>

This section provides identity-based policy examples for AWS Shield.

**Supports identity-based policies:** Yes

Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.

With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.

To view examples of Shield identity-based policies, see [Identity-based policy examples for AWS Shield](shd-security_iam_id-based-policy-examples.md).

## Resource-based policies within Shield
<a name="shd-security_iam_service-with-iam-resource-based-policies"></a>

**Supports resource-based policies:** No 

Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.

To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.

## Policy actions for Shield
<a name="shd-security_iam_service-with-iam-id-based-policies-actions"></a>

**Supports policy actions:** Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.

The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.



To see a list of Shield actions, see [Actions defined by AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions) in the *Service Authorization Reference*.

Policy actions in Shield use the following prefix before the action:

```
shield
```

To specify multiple actions in a single statement, separate them with commas.

```
"Action": [
      "shield:action1",
      "shield:action2"
         ]
```



You can specify multiple actions using wildcards (\$1). For example, to specify all actions in Shield that begin with `List`, include the following action:

```
"Action": "shield:List*"
```

To view examples of Shield identity-based policies, see [Identity-based policy examples for AWS Shield](shd-security_iam_id-based-policy-examples.md).

## Policy resources for Shield
<a name="shd-security_iam_service-with-iam-id-based-policies-resources"></a>

**Supports policy resources:** Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.

The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.

```
"Resource": "*"
```

To see the list of Shield resource types and their ARNs, see [Resources defined by AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions). To allow or deny access to a subset of Shield resources, include the ARN of the resource in the `resource` element of your policy.

In AWS Shield, the resources are *protections* and *attacks*. These resources have unique Amazon Resource Names (ARNs) associated with them, as shown in the following table. 


****  

| Name in AWS Shield Console | Name in AWS Shield SDK/CLI | ARN Format  | 
| --- | --- | --- | 
| Event or attack | AttackDetail |  `arn:aws:shield::account:attack/ID`  | 
| Protection | Protection |  `arn:aws:shield::account:protection/ID`  | 

To allow or deny access to a subset of Shield resources, include the ARN of the resource in the `resource` element of your policy. The ARNs for Shield have the following format:

```
arn:partition:shield::account:resource/ID
```

Replace the *account*, *resource*, and *ID* variables with valid values. Valid values can be the following:
+ *account*: The ID of your AWS account. You must specify a value.
+ *resource*: The type of Shield resource, either `attack` or `protection`. 
+ *ID*: The ID of the Shield resource, or a wildcard (`*`) to indicate all resources of the specified type that are associated with the specified AWS account.

For example, the following ARN specifies all protections for the account `111122223333`:

```
arn:aws:shield::111122223333:protection/*
```

The ARNs of Shield resources have the following format:

```
arn:partition:shield:region:account-id:scope/resource-type/resource-name/resource-id
```

For general information about ARN specifications, see [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) in the Amazon Web Services General Reference. 

The following lists requirements that are specific to the ARNs of `wafv2` resources: 
+ *region*: For Shield resources that you use to protect Amazon CloudFront distributions, set this to `us-east-1`. Otherwise, set this to the Region you're using with your protected regional resources. 
+ *scope*: Set the scope to `global` for use with an Amazon CloudFront distribution or `regional` for use with any of the regional resources that AWS WAF supports. The regional resources are an Amazon API Gateway REST API, an Application Load Balancer, an AWS AppSync GraphQL API, an Amazon Cognito user pool, an AWS App Runner service, and an AWS Verified Access instance. 
+ *resource-type*: Specify one of the following values: `attack` for events or attacks, `protection` for protections. 
+ *resource-name*: Specify the name that you gave the Shield resource, or specify a wildcard (`*`) to indicate all resources that satisfy the other specifications in the ARN. You must either specify the resource name and resource ID or specify a wildcard for both. 
+ *resource-id*: Specify the ID of the Shield resource, or specify a wildcard (`*`) to indicate all resources that satisfy the other specifications in the ARN. You must either specify the resource name and resource ID or specify a wildcard for both.

For example, the following ARN specifies all web ACLs with regional scope for the account `111122223333` in Region `us-west-1`:

```
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
```

The following ARN specifies the rule group named `MyIPManagementRuleGroup` with global scope for the account `111122223333` in Region `us-east-1`:

```
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
```

To view examples of Shield identity-based policies, see [Identity-based policy examples for AWS Shield](shd-security_iam_id-based-policy-examples.md).

## Policy condition keys for Shield
<a name="shd-security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

**Supports service-specific policy condition keys:** Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.

The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.

To see a list of Shield condition keys, see [Condition keys for AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions).

To view examples of Shield identity-based policies, see [Identity-based policy examples for AWS Shield](shd-security_iam_id-based-policy-examples.md).

## ACLs in Shield
<a name="shd-security_iam_service-with-iam-acls"></a>

**Supports ACLs:** No 

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

## ABAC with Shield
<a name="shd-security_iam_service-with-iam-tags"></a>

**Supports ABAC (tags in policies):** Partial

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.

To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.

If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.

For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.

## Using temporary credentials with Shield
<a name="shd-security_iam_service-with-iam-roles-tempcreds"></a>

**Supports temporary credentials:** Yes

Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.

## Forward access sessions for Shield
<a name="shd-security_iam_service-with-iam-principal-permissions"></a>

**Supports forward access sessions (FAS):** Yes

 Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). 

## Service roles for Shield
<a name="shd-security_iam_service-with-iam-roles-service"></a>

**Supports service roles:** Yes

 A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. 

**Warning**  
Changing the permissions for a service role might break Shield functionality. Edit service roles only when Shield provides guidance to do so.

## Service-linked roles for Shield
<a name="shd-security_iam_service-with-iam-roles-service-linked"></a>

**Supports service-linked roles:** Yes

 A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. 

For details about creating or managing Shield service-linked roles, see [Using service-linked roles for Shield Advanced](shd-using-service-linked-roles.md).

# Identity-based policy examples for AWS Shield
<a name="shd-security_iam_id-based-policy-examples"></a>

By default, users and roles don't have permission to create or modify Shield resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies.

To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*.

For details about actions and resource types defined by Shield, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition keys for AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html) in the *Service Authorization Reference*.

**Topics**
+ [Policy best practices](#shd-security_iam_service-with-iam-policy-best-practices)
+ [Using the Shield console](#shd-security_iam_id-based-policy-examples-console)
+ [Allow users to view their own permissions](#shd-security_iam_id-based-policy-examples-view-own-permissions)
+ [Grant read access to your Shield Advanced protections](#shd-example0)
+ [Grant read-only access to Shield, CloudFront, and CloudWatch](#shd-example1)
+ [Grant full access to Shield, CloudFront, and CloudWatch](#shd-example2)

## Policy best practices
<a name="shd-security_iam_service-with-iam-policy-best-practices"></a>

Identity-based policies determine whether someone can create, access, or delete Shield resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.

For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.

## Using the Shield console
<a name="shd-security_iam_id-based-policy-examples-console"></a>

To access the AWS Shield console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Shield resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.

You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform.

Users who can access and use the AWS console can also access the AWS Shield console. No additional permissions are required.

### Console-only APIs
<a name="shd-serucity_iam_id-based-policy-examples-console-ddos"></a>

You can access the following Distributed Denial of Service (DDoS) attack information in the console. Specify the following API permissions in an IAM policy to allow or deny specific actions.


| Action | Description | 
| --- | --- | 
| DescribeAttackContributors |  Grants permission to get detailed information about the contributors to a specific DDoS attack.  | 
| ListMitigations |  Grants permission to retrieve a list of mitigation actions that have been applied during DDoS attacks.  | 
| GetGlobalThreatData |  Grants permission to retrieve global threat intelligence data and trends from AWS Shield's threat monitoring systems.  | 

This example shows how you might create a policy that allows you to see DDoS attack information in the console.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "shield:DescribeAttackContributors"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "shield:ListMitigations"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "shield:GetGlobalThreatData"
            ],
            "Resource": "*"
        }
    ]
}
```

------

## Allow users to view their own permissions
<a name="shd-security_iam_id-based-policy-examples-view-own-permissions"></a>

This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```

## Grant read access to your Shield Advanced protections
<a name="shd-example0"></a>

AWS Shield allows cross-account resource access, but it doesn't allow you to create cross-account resource protections. You can only create protections for resources from within the account that owns those resources. 

The following is an example policy that grants permissions for the `shield:ListProtections` action on all resources. Shield doesn't support identifying specific resources using the resource ARNs (also referred to as resource-level permissions) for some of the API actions, so you specify a wildcard character (\$1). This only permits access to the resources that you can retrieve through the action `ListProtections`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ListProtections",
            "Effect": "Allow",
            "Action": [
                "shield:ListProtections"
            ],
            "Resource": "*"
        }
    ]
}
```

------

## Grant read-only access to Shield, CloudFront, and CloudWatch
<a name="shd-example1"></a>

The following policy grants users read-only access to Shield and associated resources, including Amazon CloudFront resources, and Amazon CloudWatch metrics. It's useful for users who need permission to view the settings in Shield protections and attacks and to monitor metrics in CloudWatch. These users can't create, update, or delete Shield resources.

------
#### [ JSON ]

****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "ProtectedResourcesReadAccess",
                "Effect": "Allow",
                "Action": [
                    "cloudfront:List*",
                    "route53:List*",
                    "cloudfront:Describe*",
                    "elasticloadbalancing:Describe*",
                    "cloudwatch:Describe*",
                    "cloudwatch:Get*",
                    "cloudwatch:List*",
                    "cloudfront:GetDistribution*",
                    "globalaccelerator:ListAccelerators",
                    "globalaccelerator:DescribeAccelerator"
                ],
                "Resource": [
                    "arn:aws:elasticloadbalancing:*:*:*",
                    "arn:aws:cloudfront::*:*",
                    "arn:aws:route53:::hostedzone/*",
                    "arn:aws:cloudwatch:*:*:*:*",
                    "arn:aws:globalaccelerator::*:*"
                ]
            },
            {
                "Sid": "ShieldReadOnly",
                "Effect": "Allow",
                "Action": [
                    "shield:List*",
                    "shield:Describe*",
                    "shield:Get*"
                ],
                "Resource": "*"
            }
     ]
}
```

------

## Grant full access to Shield, CloudFront, and CloudWatch
<a name="shd-example2"></a>

The following policy lets users perform any Shield operation, perform any operation on CloudFront web distributions, and monitor metrics and a sample of requests in CloudWatch. It's useful for users who are Shield administrators.

------
#### [ JSON ]

****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "ProtectedResourcesReadAccess",
                "Effect": "Allow",
                "Action": [
                    "cloudfront:List*",
                    "route53:List*",
                    "cloudfront:Describe*",
                    "elasticloadbalancing:Describe*",
                    "cloudwatch:Describe*",
                    "cloudwatch:Get*",
                    "cloudwatch:List*",
                    "cloudfront:GetDistribution*",
                    "globalaccelerator:ListAccelerators",
                    "globalaccelerator:DescribeAccelerator"
                ],
                "Resource": [
                    "arn:aws:elasticloadbalancing:*:*:*",
                    "arn:aws:cloudfront::*:*",
                    "arn:aws:route53:::hostedzone/*",
                    "arn:aws:cloudwatch:*:*:*:*",
                    "arn:aws:globalaccelerator::*:*"
                ]
            },
            {
                "Sid": "ShieldFullAccess",
                "Effect": "Allow",
                "Action": [
                    "shield:*"
                ],
                "Resource": "*"
            }
      ]
}
```

------

We strongly recommend that you configure multi-factor authentication (MFA) for users who have administrative permissions. For more information, see [Using Multi-Factor Authentication (MFA) Devices with AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html) in the *IAM User Guide*. 







# AWS managed policies for AWS Shield
<a name="shd-security-iam-awsmanpol"></a>

An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.

Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.

You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.

For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.

## AWS managed policy: AWSShieldDRTAccessPolicy
<a name="shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy"></a>

This section explains how to use AWS managed policies for Shield.

AWS Shield uses this managed policy when you grant permission to the Shield Response Team (SRT) to act on your behalf. This policy gives the SRT limited access to your AWS account, to assist with DDoS attack mitigation during high-severity events. This policy allows the SRT to manage your AWS WAF rules and Shield Advanced protections and to access your AWS WAF logs. 

For information about granting permission to the SRT to operate on your behalf, see [Granting access for the SRT](ddos-srt-access.md).

For details about this policy, see [AWSShieldDRTAccessPolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy) in the IAM console.

## AWS managed policy: AWSShieldServiceRolePolicy
<a name="shd-security-iam-awsmanpol-AWSShieldServiceRolePolicy"></a>

Shield Advanced uses this managed policy when you enable automatic application layer DDoS mitigation, to set the permissions it needs to manage resources for your account. This policy allows Shield Advanced to create and apply AWS WAF rules and rule groups in the web ACLs that you've associated with your protected resources, to automatically respond to DDoS attacks. 

You can't attach AWSShieldServiceRolePolicy to your IAM entities. Shield attaches this policy to the service-linked role `AWSServiceRoleForAWSShield` to allow Shield to perform actions on your behalf. 

Shield Advanced enables the use of this policy when you enable automatic application layer DDoS mitigation. For more information about the use for this policy, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md). 

For information about the service-linked role AWSServiceRoleForAWSShield that uses this policy, see [Using service-linked roles for Shield Advanced](shd-using-service-linked-roles.md)

For details about this policy, see [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) in the IAM console.

## Shield updates to AWS managed policies
<a name="shd-security-iam-awsmanpol-updates"></a>



View details about updates to AWS managed policies for Shield since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the Shield document history page at [Document history](doc-history.md).




| Policy | Description of change | Date | 
| --- | --- | --- | 
|  `AWSShieldServiceRolePolicy` This policy allows Shield to access and manage AWS resources in order to automatically respond to application layer DDoS attacks on your behalf.  Details in IAM console: [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) The service-linked role `AWSServiceRoleForAWSShield` uses this policy. For information, see [Using service-linked roles for Shield Advanced](shd-using-service-linked-roles.md).  |  Added this policy to provide Shield Advanced with the permissions required for the automatic application layer DDoS mitigation functionality. For information about this feature, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md).  | December 1, 2021 | 
|  Shield started tracking changes  |  Shield started tracking changes for its AWS managed policies.  | March 3, 2021 | 

# Troubleshooting AWS Shield identity and access
<a name="shd-security_iam_troubleshoot"></a>

Use the following information to help you diagnose and fix common issues that you might encounter when working with Shield and IAM.

**Topics**
+ [I am not authorized to perform an action in Shield](#shd-security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#shd-security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my Shield resources](#shd-security_iam_troubleshoot-cross-account-access)

## I am not authorized to perform an action in Shield
<a name="shd-security_iam_troubleshoot-no-permissions"></a>

If you receive an error that you're not authorized to perform an action, your policies must be updated to allow you to perform the action.

The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a fictional `my-example-widget` resource but doesn't have the fictional `shield:GetWidget` permissions.

```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: shield:GetWidget on resource: my-example-widget
```

In this case, the policy for the `mateojackson` user must be updated to allow access to the `my-example-widget` resource by using the `shield:GetWidget` action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

## I am not authorized to perform iam:PassRole
<a name="shd-security_iam_troubleshoot-passrole"></a>

If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Shield.

Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.

The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Shield. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.

```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```

In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

## I want to allow people outside of my AWS account to access my Shield resources
<a name="shd-security_iam_troubleshoot-cross-account-access"></a>

You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.

To learn more, consult the following:
+ To learn whether Shield supports these features, see [How AWS Shield works with IAM](shd-security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.

# Using service-linked roles for Shield Advanced
<a name="shd-using-service-linked-roles"></a>

This section explains how to use service-linked roles to give Shield Advanced access to resources in your AWS account.

AWS Shield Advanced uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Shield Advanced. Service-linked roles are predefined by Shield Advanced and include all the permissions that the service requires to call other AWS services on your behalf. 

A service-linked role makes setting up Shield Advanced easier because you don’t have to manually add the necessary permissions. Shield Advanced defines the permissions of its service-linked roles, and unless defined otherwise, only Shield Advanced can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.

You can delete a service-linked role only after first deleting their related resources. This protects your Shield Advanced resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.

## Service-Linked Role Permissions for Shield Advanced
<a name="shd-slr-permissions"></a>

Shield Advanced uses the service-linked role named **AWSServiceRoleForAWSShield**. This role allows Shield Advanced to access and manage AWS resources in order to automatically respond to application layer DDoS attacks on your behalf. For more information about this functionality, see [Automating application layer DDoS mitigation with Shield Advanced](ddos-automatic-app-layer-response.md). 

The AWSServiceRoleForAWSShield service-linked role trusts the following services to assume the role:
+ `shield.amazonaws.com`

The role permissions policy named AWSShieldServiceRolePolicy allows Shield Advanced to complete the following actions on all AWS resources:
+ `wafv2:GetWebACL`
+ `wafv2:UpdateWebACL`
+ `wafv2:GetWebACLForResource`
+ `wafv2:ListResourcesForWebACL`
+ `cloudfront:ListDistributions`
+ `cloudfront:GetDistribution`

When actions are permitted on all AWS resources, this is indicated in the policy as `"Resource": "*"`. This only means that the service-linked role can take each indicated action on all AWS resources *that the action supports*. For example, the action `wafv2:GetWebACL` is supported only for `wafv2` web ACL resources. 

Shield Advanced only makes resource-level API calls for protected resources for which you've enabled the application layer protections feature and for web ACLs that are associated with those protected resources. 

You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.

## Creating a Service-Linked Role for Shield Advanced
<a name="shd-create-slr"></a>

You don't need to manually create a service-linked role. When you enable automatic application layer DDoS mitigation for a resource in the AWS Management Console, the AWS CLI, or the AWS API, Shield Advanced creates the service-linked role for you. 

If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you enable automatic application layer DDoS mitigation for a resource, Shield Advanced creates the service-linked role for you again. 

## Editing a Service-Linked Role for Shield Advanced
<a name="shd-edit-slr"></a>

Shield Advanced does not allow you to edit the AWSServiceRoleForAWSShield service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.

## Deleting a Service-Linked Role for Shield Advanced
<a name="shd-delete-slr"></a>

If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for your service-linked role before you can manually delete it.

**Note**  
If Shield Advanced is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.

**To delete the Shield Advanced resources that are used by the AWSServiceRoleForAWSShield**

For all of your resources that have application layer DDoS protections configured, disable automatic application layer DDoS mitigation. For console instructions, see [Configure application layer DDoS protections](manage-protection.md#configure-app-layer-protection). 

**To manually delete the service-linked role using IAM**

Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAWSShield service-linked role. For more information, see [Deleting a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.

## Supported Regions for Shield Advanced Service-Linked Roles
<a name="shd-slr-regions"></a>

Shield Advanced supports using service-linked roles in all of the Regions where the service is available. For more information, see [Shield Advanced endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/shield.html).

# Logging and monitoring in Shield
<a name="shd-incident-response"></a>

This section explains how to use AWS tools for monitoring and responding to events in AWS Shield.

Monitoring is an important part of maintaining the reliability, availability, and performance of Shield and your AWS solutions. You should collect monitoring data from all parts of your AWS solution so that you can more easily debug a multi-point failure if one occurs. AWS provides several tools for monitoring your Shield resources and responding to potential events:

**Amazon CloudWatch Alarms**  
Using CloudWatch alarms, you watch a single metric over a time period that you specify. If the metric exceeds a given threshold, CloudWatch sends a notification to an Amazon SNS topic or AWS Auto Scaling policy. For more information, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md).

**AWS CloudTrail Logs**  
CloudTrail provides a record of actions taken by a user, role, or an AWS service in Shield. Using the information collected by CloudTrail, you can determine the request that was made to Shield, the IP address from which the request was made, who made the request, when it was made, and additional details. For more information, see [Logging API calls with AWS CloudTrail](logging-using-cloudtrail.md).

# Validating compliance in Shield
<a name="shd-security-compliance"></a>

This section explains your compliance responsibility when using AWS Shield.

To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).

You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).

Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).

# Building for resilience in Shield
<a name="shd-disaster-recovery-resiliency"></a>

This section explains how AWS architecture supports data redundancy for AWS Shield.

The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. 

For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

# Infrastructure security in AWS Shield
<a name="shd-infrastructure-security"></a>

This section explains how AWS Shield isolates service traffic.

As a managed service, AWS Shield is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.

You use AWS published API calls to access Shield through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.

# AWS Shield Advanced quotas
<a name="shield-limits"></a>

AWS Shield Advanced has default quotas on the number of entities per Region. You can [request an increase](https://console.aws.amazon.com/servicequotas/home/services/shield/quotas) in these quotas.


| Resource | Default quota | 
| --- | --- | 
|  Maximum number of protected resources for each resource type that AWS Shield Advanced offers protection for, per account.   |  1,000  | 
|  Maximum number of protection groups, per account.   |  100  | 
|  Maximum number of individual protected resources that you can specifically include in a protection group. In the API, this applies to the `Members` that you specify when you set the protection group `Pattern` to `ARBITRARY`. In the console, this applies to the resources that you select for the protection grouping **Choose from protected resources**.  |  1,000  |