Visibility - AWS Best Practices for DDoS Resiliency

Visibility

When a key operational metric deviates substantially from the expected value, an attacker may be attempting to target your application’s availability. If you’re familiar with the normal behavior of your application, you can more quickly take action when you detect an anomaly.

By using Amazon CloudWatch, you can monitor applications that you run on AWS. For example, you can collect and track metrics, collect and monitor log files, set alarms, and automatically respond to changes in your AWS resources.

If you have architected your application by following the DDoS-resilient reference architecture, common infrastructure layer attacks will be blocked before reaching your application. If you are subscribed to AWS Shield Advanced, you have access to a number of CloudWatch metrics that can indicate that your application is being targeted. For example, you can configure alarms to notify you when there is a DDoS attack in progress, so you can check your application’s health and decide whether to engage DRT. You can configure the DDoSDetected metric to tell you if an attack has been detected. If you want to be alerted based on the attack volume, you can also use the DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond, or DDoSAttackRequestsPerSecond metrics. You can monitor these metrics by integrating Amazon CloudWatch with your own tools or by using tools provided by third-parties, such as Slack or PagerDuty.

An application layer attack can elevate many Amazon CloudWatch metrics. If you’re using AWS WAF, you can use CloudWatch to monitor and alarm on increases in requests that you’ve set in WAF to be allowed, counted, or blocked. This allows you to receive a notification if the level of traffic exceeds what your application can handle. You can also use Amazon CloudFront, Amazon Route 53, ALB, NLB, Amazon EC2, and Auto Scaling metrics that are tracked in CloudWatch to detect changes that can indicate a DDoS attack.

For a description of Amazon CloudWatch metrics that are commonly used to detect and react to DDoS attacks, see Table 3.

Table 3: Recommended Amazon CloudWatch Metrics

Topic Metric Description

AWS Shield Advanced

DDoSDetected

Indicates a DDoS event for a specific Amazon Resource Name (ARN).

AWS Shield Advanced

DDoSAttackBitsPerSecond

The number of bytes observed during a DDoS event for a specific Amazon Resource Name (ARN). This metric is only available for layer 3/4 DDoS events.

AWS Shield Advanced

DDoSAttackPacketsPerSecond

The number of packets observed during a DDoS event for a specific Amazon Resource Name (ARN). This metric is only available for layer 3/4 DDoS events.

AWS Shield Advanced

DDoSAttackRequestsPerSecond

The number of requests observed during a DDoS event for a specific Amazon Resource Name (ARN). This metric is only available for layer 7 DDoS events and is only reported for the most significant layer 7 events.

AWS WAF

AllowedRequests

The number of allowed web requests.

AWS WAF

BlockedRequests

The number of blocked web requests.

AWS WAF

CountedRequests

The number of counted web requests.

Amazon CloudFront

Requests

The number of HTTP/S requests

Amazon CloudFront

TotalErrorRate

The percentage of all requests for which the HTTP status code is 4xx or 5xx.

Amazon Route 53

HealthCheckStatus

The status of the health check endpoint.

ALB

ActiveConnectionCount

The total number of concurrent TCP connections that are active from clients to the load balancer, and from the load balancer to targets.

ALB

ConsumedLCUs

The number of load balancer capacity units (LCU) used by your load balancer.

ALB

HTTPCode_ELB_4XX_Count HTTPCode_ELB_5XX_Count

The number of HTTP 4xx or 5xx client error codes generated by the load balancer.

ALB

NewConnectionCount

The total number of new TCP connections established from clients to the load balancer, and from the load balancer to targets.

ALB

ProcessedBytes

The total number of bytes processed by the load balancer.

ALB

RejectedConnectionCount

The number of connections that were rejected because the load balancer had reached its maximum number of connections.

ALB

RequestCount

The number of requests that were processed.

ALB

TargetConnectionErrorCount

The number of connections that were not successfully established between the load balancer and the target.

ALB

TargetResponseTime

The time elapsed, in seconds, after the request left the load balancer until a response from the target was received.

ALB

UnHealthyHostCount

The number of targets that are considered unhealthy.

NLB

ActiveFlowCount

The total number of concurrent TCP flows (or connections) from clients to targets.

NLB

ConsumedLCUs

The number of load balancer capacity units (LCU) used by your load balancer.

NLB

NewFlowCount

The total number of new TCP flows (or connections) established from clients to targets in the time period.

NLB

ProcessedBytes

The total number of bytes processed by the load balancer, including TCP/IP headers.

Auto Scaling

GroupMaxSize

The maximum size of the Auto Scaling group.

Amazon EC2

CPUUtilization

The percentage of allocated EC2 compute units that are currently in use.

Amazon EC2

NetworkIn

The number of bytes received by the instance on all network interfaces.

To learn more about using Amazon CloudWatch to detect DDoS attacks on your application, see Getting Started with Amazon CloudWatch.

AWS includes several additional metrics and alarms to notify you about an attack and to help you monitor your application’s resources. The AWS Shield console or API provide a summary and details about attacks that have been detected. In addition, the Global Threat Environment Dashboard provides summary information about all DDoS attacks that have been detected by AWS. This information may be useful to better understand DDoS threats across a larger population of applications as well as attack trends, and comparing with attacks that you may have observed.

Another tool that can help you gain visibility into traffic that is targeting your application is VPC Flow Logs. On a traditional network, you might use network flow logs to troubleshoot connectivity and security issues, and to make sure that network access rules are working as expected. By using VPC Flow Logs, you can capture information about the IP traffic that is going to and from network interfaces in your VPC.

Each flow log record includes the following: source and destination IP addresses, source and destination ports, protocol, and the number of packets and bytes transferred during the capture window. You can use this information to help identify anomalies in network traffic and to identify a specific attack vector. For example, most UDP reflection attacks have specific source ports, such as source port 53 for DNS reflection. This is a clear signature that you can identify in the flow log record. In response, you might choose to block the specific source port at the instance level or create a NACL rule to block the entire protocol if your application doesn’t require it.

To learn more about using VPC Flow Logs to identify network anomalies and DDoS attack vectors, see VPC Flow Logs and VPC Flow Logs – Log and View Network Traffic Flows.