Alarming on DDoS Events with the AWS WAF Anti-DDoS Rule Group

When you add the AWSManagedRulesAntiDDoSRuleSet managed rule group to your web ACL, AWS WAF publishes a DDoSAttackRequests metric to CloudWatch during detected layer 7 DDoS events. This metric lets you create alarms that notify you when the rule group is actively detecting and mitigating an attack — even if you are not a Shield Advanced subscriber.

This article walks through creating a CloudWatch alarm for the DDoSAttackRequests metric using the AWS CLI, the CloudWatch console, and CloudFormation. It also compares this metric with the Shield Advanced DDoSDetected metric and discusses additional observability you should consider.

---

Understanding the DDoSAttackRequests Metric

Property	Value
Namespace	AWS/WAFV2
Metric name	DDoSAttackRequests
Description	The number of requests observed during a DDoS event for a particular resource ARN. Available only for Anti-DDoS Managed Rules (AMR) events.
Units	Requests
Behaviour	Has a non-zero value during a detected event; zero (or absent) otherwise.
Dimensions	Resource (the ARN of the protected resource), ResourceType (e.g. ALB, CF, APIGW)

This metric is published in the AWS/WAFV2 namespace — not AWS/DDoSProtection — because it is emitted by the WAF rule group itself, not by Shield Advanced. It is available to all customers using the anti-DDoS managed rule group, regardless of Shield Advanced subscription status.

---

Creating the Alarm with the AWS CLI

The following command creates a CloudWatch alarm that triggers when the anti-DDoS rule group detects an event against an Application Load Balancer:

aws cloudwatch put-metric-alarm \
  --alarm-name 'L7AMRDDoSDetected_for_my-alb' \
  --alarm-description 'Alarm when the AWS WAF Anti-DDoS rule group detects a layer 7 DDoS event against the ALB' \
  --actions-enabled \
  --alarm-actions 'arn:aws:sns:ap-south-1:999999999999:ddos-alerts' \
  --metric-name 'DDoSAttackRequests' \
  --namespace 'AWS/WAFV2' \
  --statistic 'Sum' \
  --dimensions '[
    {
      "Name": "Resource",
      "Value": "arn:aws:elasticloadbalancing:ap-south-1:999999999999:loadbalancer/app/my-alb/2f855f0c06799999"
    },
    {
      "Name": "ResourceType",
      "Value": "ALB"
    }
  ]' \
  --period 60 \
  --evaluation-periods 1 \
  --datapoints-to-alarm 1 \
  --threshold 1 \
  --comparison-operator 'GreaterThanOrEqualToThreshold' \
  --treat-missing-data 'missing'

Key parameter choices explained

Parameter	Value	Why
--statistic Sum	Sums all requests observed during the period.	The metric counts individual requests, so Sum gives the total volume per period.
--period 60	1-minute evaluation period.	Provides near-real-time alerting.
--threshold 1	Alarm on any non-zero value.	Any value ≥ 1 means the rule group has detected an event.
--evaluation-periods 1 / --datapoints-to-alarm 1	Alarm on the first breaching datapoint.	Prioritises speed of notification over noise reduction. If you want to reduce noise from very brief spikes, increase --evaluation-periods to 2 or 3.
--treat-missing-data missing	Missing data does not trigger or clear the alarm.	The metric is only published during events, so missing data is the normal state. Using notBreaching is also a valid choice — it would return the alarm to OK when data stops arriving.
--alarm-actions	An SNS topic ARN.	Replace with your own SNS topic to receive email, SMS, PagerDuty, or Lambda notifications. You can also add --ok-actions with the same SNS topic to be notified when the event ends.

---

Creating the Alarm via the CloudWatch Console

1. Open the CloudWatch console in the region where your resource is located.
2. In the left navigation, choose All alarms, then Create alarm.
3. Choose Select metric → WAFV2 → Resource, ResourceType.
4. Filter for DDoSAttackRequests and select the row matching your resource ARN and resource type (e.g. ALB).
5. Configure the metric:
   • Statistic: Sum
   • Period: 1 minute
6. Configure the alarm condition:
   • Threshold type: Static
   • Whenever DDoSAttackRequests is: Greater/Equal than 1
   • Datapoints to alarm: 1 out of 1
   • Missing data treatment: Treat missing data as missing
7. Configure the notification action (SNS topic).
8. Name the alarm and create it.

---

Creating the Alarm with CloudFormation

Resources:
  AntiDDoSAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: L7AMRDDoSDetected_for_my-alb
      AlarmDescription: >-
        Alarm when the AWS WAF Anti-DDoS rule group detects a layer 7
        DDoS event against the ALB.
      Namespace: AWS/WAFV2
      MetricName: DDoSAttackRequests
      Statistic: Sum
      Period: 60
      EvaluationPeriods: 1
      DatapointsToAlarm: 1
      Threshold: 1
      ComparisonOperator: GreaterThanOrEqualToThreshold
      TreatMissingData: missing
      Dimensions:
        - Name: Resource
          Value: arn:aws:elasticloadbalancing:ap-south-1:999999999999:loadbalancer/app/my-alb/2f855f0c06799999
        - Name: ResourceType
          Value: ALB
      AlarmActions:
        - !Ref DDoSAlertsTopic

  DDoSAlertsTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: ddos-alerts

---

Creating the Alarm with Terraform

resource "aws_cloudwatch_metric_alarm" "anti_ddos_detected" {
  alarm_name          = "L7AMRDDoSDetected_for_my-alb"
  alarm_description   = "Alarm when the AWS WAF Anti-DDoS rule group detects a layer 7 DDoS event against the ALB."
  namespace           = "AWS/WAFV2"
  metric_name         = "DDoSAttackRequests"
  statistic           = "Sum"
  period              = 60
  evaluation_periods  = 1
  datapoints_to_alarm = 1
  threshold           = 1
  comparison_operator = "GreaterThanOrEqualToThreshold"
  treat_missing_data  = "missing"

  dimensions = {
    Resource     = "arn:aws:elasticloadbalancing:ap-south-1:999999999999:loadbalancer/app/my-alb/2f855f0c067ffb7c"
    ResourceType = "ALB"
  }

  alarm_actions = [aws_sns_topic.ddos_alerts.arn]
}

resource "aws_sns_topic" "ddos_alerts" {
  name = "ddos-alerts"
}

---

Comparison: DDoSAttackRequests vs DDoSDetected

Shield Advanced subscribers have access to the DDoSDetected metric in the AWS/DDoSProtection namespace. The following table compares the two metrics:

	DDoSAttackRequests	DDoSDetected
Namespace	AWS/WAFV2	AWS/DDoSProtection
Requires Shield Advanced	No	Yes
Scope	Layer 7 events detected by the Anti-DDoS managed rule group only	Layer 3, 4, and 7 events detected by Shield Advanced
Value during event	Count of requests observed	Non-zero indicator (typically 1)
Value outside event	Absent (no datapoints)	Reported once daily to keep the metric active
Dimensions	Resource, ResourceType	ResourceArn (no additional dimensions)
Companion volume metrics	N/A — use WAF BlockedRequests / ChallengeRequests metrics for the rule group	DDoSAttackBitsPerSecond (L3/4), DDoSAttackPacketsPerSecond (L3/4), DDoSAttackRequestsPerSecond (L7)
Cost	Included with the Anti-DDoS managed rule group. For Shield Advanced protected resources, the rule group charges are waived when total web ACL WCU ≤ 1,500 and account-wide WAF requests are under 50 billion/month (see pricing).	Requires Shield Advanced subscription ($3,000/month per organization)

Key differences to note

• DDoSDetected reports daily even when no event is occurring. This keeps the metric active in CloudWatch, which means an alarm set to treat-missing-data: missing will remain in its current state. The DDoSAttackRequests metric is only published during events, so missing data is the normal peacetime state.

• DDoSDetected covers all layers. It fires for network/transport (L3/4) attacks as well as application layer (L7) attacks. DDoSAttackRequests only covers L7 events detected by the WAF anti-DDoS rule group.

• DDoSDetected is a binary indicator; DDoSAttackRequests is a count. With DDoSAttackRequests you can alarm on volume thresholds (e.g. > 10,000 requests per minute) in addition to simple presence/absence. This can be useful for distinguishing minor detections from significant attacks.

• Shield Advanced subscribers get both. If you subscribe to Shield Advanced and also use the anti-DDoS managed rule group, both metrics are available. You can create a composite alarm that combines them with application health metrics for more nuanced alerting.

---

Additional Observability Recommendations

Alarm on WAF rule group actions

In addition to the DDoSAttackRequests detection metric, monitor the WAF actions the rule group is taking during an event. The standard AWS/WAFV2 metrics BlockedRequests and ChallengeRequests with the RuleGroup dimension set to the anti-DDoS rule group metric name will show you how many requests are being mitigated.

Monitor application health alongside DDoS metrics

A DDoS detection alarm alone doesn't tell you whether your application is impacted. Consider creating a composite alarm that combines:

• DDoSAttackRequests >= 1 (event detected)
• Origin 5xx error rate above baseline (e.g. ALB HTTPCode_ELB_5XX_Count or CloudFront 5xxErrorRate)
• Elevated latency (e.g. ALB TargetResponseTime p99)

This reduces noise from events that the rule group successfully mitigates without any impact to your users.

Use WAF logs for post-event analysis

Enable WAF logging to capture request-level detail during events. WAF logs include the labels applied by the anti-DDoS rule group, which can help you understand the attack profile and tune your configuration. Look for labels in the awswaf:managed:aws:anti-ddos: namespace.

Set up --ok-actions for event-end notification

Add --ok-actions to your alarm so you are notified when the event ends and the alarm returns to OK. This is useful for tracking event duration and coordinating incident response.

---

Further Reading

• AWS WAF Anti-DDoS managed rule group documentation
• AWS Shield Advanced metrics
• AWS WAF metrics and dimensions
• Introducing new application layer (L7) DDoS protections for AWS WAF and AWS Shield Advanced customers
• Configuring the AWS WAF Anti-DDoS managed rule group for your resources and clients
• AWS WAF Pricing