AWS Shield, in depth: Standard vs Advanced, how DDoS detection and mitigation work at the edge, WAF Anti-DDoS rules, health-based detection, the SRT and an operational runbook

DDoS attacks by layer

Defences differ by layer.

Shield Standard covers the first two rows for all AWS resources. The application layer is different: an HTTP flood from a botnet uses valid TCP connections and well-formed requests, so it looks like traffic. Stopping it needs knowledge of your normal request patterns, which is why L7 protection depends on WAF and your configuration.

Reference architecture

AWS's DDoS resilience guidance comes down to three ideas. Absorb at the edge: put internet-facing entry points on services that run on AWS's globally distributed edge, such as CloudFront for HTTP, Route 53 for DNS and Global Accelerator for non-HTTP TCP and UDP. Their anycast addressing spreads attack traffic across many locations, as explained in how anycast works. Minimise attack surface: the origin load balancer should accept traffic only from the edge, using the CloudFront managed prefix list in its security group, and instances should sit in private subnets. Filter requests before they cost anything: a WAF web ACL on the edge blocks HTTP floods before they reach the origin. For the vendor-neutral version of these patterns, see cloud DDoS protection architecture.

What Shield Standard does

Shield Standard is always on and needs no configuration. It inspects traffic entering AWS for known network and transport attack signatures and malformed packets and mitigates them inline, so most reflection and SYN floods are dropped without you noticing.

What Standard does not give you: per-resource attack detection and metrics, application-layer response, any human help during an event, or financial protection when an attack scales your infrastructure.

What Shield Advanced adds

• Explicit protections. You choose resources to protect: CloudFront distributions, Route 53 hosted zones, Global Accelerator standard accelerators, Elastic IP addresses (and through them EC2 instances and Network Load Balancers), Application Load Balancers and Classic Load Balancers. Nothing is protected until you add it, either directly or through an AWS Firewall Manager Shield Advanced policy.
• Resource-specific detection. Shield Advanced builds traffic baselines per protected resource, so it can detect smaller attacks relative to that resource's normal traffic.
• Health-based detection. Associating a Route 53 health check with a protection lets Shield use your application's health to decide whether unusual traffic is an attack, which improves detection accuracy and speed.
• Visibility. Event history in the console and CloudWatch metrics in the AWS/DDoSProtection namespace.
• Shield Response Team (SRT). AWS DDoS specialists who can analyse WAF logs, write web ACL rules with your approval and build custom network mitigations. Using the SRT requires the Business or Enterprise Support plan.
• Cost protection. Service credits for scaling charges on protected resources caused by a DDoS attack, requested through support.
• WAF included. For protected resources, standard WAF charges are covered up to documented limits, including up to 50 billion requests per month per subscribed payer. Extra-cost WAF features such as Bot Control and CAPTCHA are not covered.

Pricing at the time of checking is 3,000 USD per month per organization payer with a one-year commitment, plus data transfer out usage fees on protected resources. That fee covers all accounts in a consolidated billing family. A small site behind CloudFront with sensible WAF rules is often well served by Standard alone.

Turning on Shield Advanced: commands

The Shield API is global; use us-east-1 for the CLI. The commands below subscribe, protect an ALB and a CloudFront distribution, attach health checks, group them and grant the SRT access.

# Subscribe (starts the one-year commitment)
aws shield create-subscription --region us-east-1

# Protect resources
aws shield create-protection --region us-east-1 --name shop-alb \
  --resource-arn arn:aws:elasticloadbalancing:eu-west-1:111122223333:loadbalancer/app/shop/abc123
aws shield create-protection --region us-east-1 --name shop-cdn \
  --resource-arn arn:aws:cloudfront::111122223333:distribution/E2EXAMPLE

# Health-based detection: point Shield at a Route 53 health check
aws shield associate-health-check --region us-east-1 \
  --protection-id <protection-id-from-create-protection> \
  --health-check-arn arn:aws:route53:::healthcheck/<health-check-id>

# Treat the shop's entry points as one unit for detection
aws shield create-protection-group --region us-east-1 \
  --protection-group-id shop --aggregation MAX --pattern ARBITRARY \
  --members <alb-arn> <cloudfront-arn>

# Let the SRT act on your WAF configuration during an event
aws shield associate-drt-role --region us-east-1 \
  --role-arn arn:aws:iam::111122223333:role/ShieldSRTAccess

The SRT role should trust drt.shield.amazonaws.com and carry the AWS managed policy AWSShieldDRTAccessPolicy. Protection groups let Shield detect an attack across resources that serve one application. MAX fits a distribution and its origin, which see the same requests in series; SUM fits resources that share load, such as Elastic IPs behind DNS.

Design the health check carefully. It should go unhealthy when users are hurt: high error rates, high latency or a failing synthetic transaction, typically a calculated health check over CloudWatch alarms. A TCP-only check stays green while the database melts.

Application-layer floods: WAF Anti-DDoS rules and rate limits

Since 26 March 2026 AWS documents the Anti-DDoS managed rule group, AWSManagedRulesAntiDDoSRuleSet (50 WCU), as the default protection against HTTP request floods. It replaces the earlier Shield Advanced automatic application-layer mitigation, which used a 150-WCU Shield-managed rule group. Existing customers can keep the legacy feature; new Shield Advanced customers need AWS Support to get it. The two sources differ on cost: the rule-group page says it carries extra WAF fees, while the Shield Advanced overview says the subscription includes access to it. Check your bill for which applies.

The rule group baselines traffic per protected resource, labels every request during a detected event, and assigns suspicion levels to likely attack sources. Its three rules use those labels. ChallengeAllDuringEvent sends a silent browser challenge to every challengeable request while an event is underway. ChallengeDDoSRequests challenges only requests at or above your challenge sensitivity, and is evaluated only if the first rule is set to Count. DDoSRequests blocks requests at or above your block sensitivity. Low sensitivity matches only high-suspicion requests; high matches all three levels.

Two details decide whether it helps or hurts. First, a challenge works only for clients that expect HTML. API clients, mobile apps and webhooks cannot solve it, so list their paths in the exempt-URI regular expressions; those requests can then only be blocked by DDoSRequests. Second, AWS advises against a scope-down statement on this rule group and recommends placing it after your explicit Allow rules and before everything else, so it sees as much traffic as possible for its baseline.

Keep a rate-based rule as a backstop. It caps requests per client IP over a window regardless of whether an event is detected, which is the same idea as the limiters in rate limiting design. Rule group labels enable custom handling:

[
  {
    "Name": "rate-cap-per-ip",
    "Priority": 20,
    "Statement": {
      "RateBasedStatement": { "Limit": 2000, "EvaluationWindowSec": 300, "AggregateKeyType": "IP" }
    },
    "Action": { "Block": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true,
                          "MetricName": "rate-cap-per-ip" }
  },
  {
    "Name": "count-ddos-suspects-on-api",
    "Priority": 30,
    "Statement": { "AndStatement": { "Statements": [
      { "LabelMatchStatement": { "Scope": "LABEL",
                                 "Key": "awswaf:managed:aws:anti-ddos:medium-suspicion-ddos-request" } },
      { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH",
                                "SearchString": "/api/", "TextTransformations": [{ "Priority": 0, "Type": "NONE" }] } }
    ] } },
    "Action": { "Count": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true,
                          "MetricName": "ddos-suspects-api" }
  }
]

Choose the rate limit from data: look at the 99.9th percentile of requests per IP per five minutes in your WAF logs, remember that NAT and corporate proxies put many users behind one address, and start in Count mode. The label rule above starts in Count so you can see how many API requests would be affected before switching it to Block. Caching protects you too: every request CloudFront serves from cache never reaches the origin, so random query strings that bust the cache are a classic HTTP flood technique. Normalise or ignore query parameters you do not use in the cache key.

Monitoring and response

Shield Advanced publishes DDoSDetected per protected resource, plus DDoSAttackBitsPerSecond and DDoSAttackPacketsPerSecond for L3/L4 events and DDoSAttackRequestsPerSecond for the most significant L7 events. Metrics for CloudFront, Route 53 and protection groups are in us-east-1; other resources report in their own Region. Outside events, metrics are reported once a day; during an event, once a minute. Anti-DDoS rule group events report DDoSAttackRequests in the AWS/WAFV2 namespace instead.

aws cloudwatch put-metric-alarm --region us-east-1 \
  --alarm-name shield-ddos-shop-cdn \
  --namespace AWS/DDoSProtection --metric-name DDoSDetected \
  --dimensions Name=ResourceArn,Value=arn:aws:cloudfront::111122223333:distribution/E2EXAMPLE \
  --statistic Maximum --period 60 --evaluation-periods 1 \
  --threshold 0 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:oncall

A non-zero DDoSDetected does not always mean users are hurt; pair it with your own error-rate and latency alarms. For proactive engagement, where the SRT contacts you when a detected event coincides with failing health, you need the Business or Enterprise Support plan, a Route 53 health check on each protection, a WAF v2 web ACL where one applies, and up to ten contacts with notes on when to use each. Proactive engagement covers L3/L4 events on Elastic IPs and Global Accelerator and request floods on CloudFront and ALB, but not events detected only by the Anti-DDoS rule group; for those, alarm on the WAF metrics and open a support case.

Worked example: an HTTP flood on a shop

A retailer runs CloudFront in front of an ALB, with Shield Advanced on both, a calculated health check over 5xx rate and p99 latency, and the Anti-DDoS rule group with challenge enabled and the mobile API path exempted. At 20:00 requests to the product search page jump from 400 to 60,000 per second from tens of thousands of residential IPs, each using random query strings.

The rule group detects the deviation and labels all traffic as part of an event. Browsers get a silent challenge, pass it and continue; scripted clients cannot solve it and are dropped at the edge. The exempt mobile API path sees a smaller wave of high-suspicion requests, which DDoSRequests blocks. The per-IP rate rule catches the noisiest addresses. The on-call engineer gets the WAF metric alarm, confirms in sampled requests that blocked traffic is attack traffic, and adds a cache policy that ignores unknown query parameters for search. If legitimate customers had been blocked, the next step would be lowering block sensitivity and opening a support case to work with the SRT.

Failure modes

• Origin bypass. Attackers find the ALB's public DNS name or an instance IP and hit it directly, skipping CloudFront and WAF. Restrict origin security groups to the CloudFront prefix list and add a secret header check.
• Challenge breaks clients. APIs and apps receive challenge responses they cannot handle. Maintain the exempt-URI list and test it in Count mode.
• Unprotected entry points. A forgotten Elastic IP, test distribution or Region has no protection. Use Firewall Manager policies to apply protections across accounts automatically.
• Health checks that lie. Too shallow to detect harm, or too noisy to trust, which weakens health-based detection and proactive engagement.
• Rate limits that block real users. Many users behind shared IPs hit per-IP limits; prefer custom aggregation keys where you have a stable client identifier.
• No baseline. New resources and new web ACLs need time to establish normal traffic, so detection is weaker right after launch.

What to do next

1. Inventory every internet-facing endpoint, including DNS, Elastic IPs and test environments, and put HTTP behind CloudFront and DNS on Route 53.
2. Lock origins to the edge with the CloudFront managed prefix list and keep instances in private subnets.
3. Attach a WAF web ACL with a rate-based rule and the Anti-DDoS rule group in Count mode; review labels and sampled requests for a week before enforcing.
4. Decide on Shield Advanced from your outage cost and support needs; if you subscribe, protect resources, attach meaningful health checks and create protection groups.
5. Grant the SRT role, configure proactive engagement contacts and confirm your support plan qualifies.
6. Create alarms on DDoSDetected and the WAF DDoS metrics, and write a runbook that names who decides on sensitivity changes.
7. Run a game day against a staging stack using AWS's DDoS simulation testing policy before you need it for real.