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

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