AWS WAF and Shield Guide: Managed Rules, Rate Limits and DDoS Response

AWS WAF and AWS Shield sit in front of most internet-facing AWS workloads, yet many deployments run managed rules in count mode for years, rate limits that never trigger, and a Shield Advanced subscription whose response team has no way into the account. AWS WAF inspects HTTP requests to CloudFront distributions, Application Load Balancers, API Gateway REST APIs and other resources against a web ACL; Shield adds network and transport layer DDoS protection and, with Shield Advanced, detection, response support and automatic application layer mitigation. This guide covers who should control web ACLs and Shield, the roles and service principals involved, logging and detection, and a hardening baseline with real rule group names, rate-based rule settings and Shield Advanced configuration. It is for cloud security and platform engineers running AWS edge protection. Vendor-neutral WAF concepts are in the Web Application Firewall Guide and attack-level DDoS planning is in the DDoS Protection Guide; this page stays on the AWS specifics, using the AWS WAF Developer Guide and the WAFV2 and Shield API references as checked in October 2026.

Key takeaways

• A web ACL is only as strong as its default action and rule order. Each web ACL has a default action (allow or block) for requests no rule matches, and rules run in priority order with Count, Allow, Block, CAPTCHA and Challenge actions. Review both, not just the list of rule groups.
• Managed rules are a baseline, not a finished policy. The Core rule set (AWSManagedRulesCommonRuleSet, 700 WCU) and Known bad inputs (AWSManagedRulesKnownBadInputsRuleSet, 200 WCU) cover common exploits, but body-inspecting rules stop at 8 KB on ALB and 16 KB by default on CloudFront and API Gateway.
• Rate-based rules need a realistic limit and the right key. The minimum limit is 10 requests per evaluation window of 60, 120, 300 or 600 seconds (300 by default), and WAF checks about every 10 seconds. Aggregating on the wrong IP behind a proxy rate limits your own CDN.
• Shield Advanced only helps if it is wired up. Protections must be created per resource, health checks associated for health-based detection, proactive engagement contacts set, and the Shield Response Team (SRT) role associated before an attack.
• Edge controls are identity controls too. Whoever can edit a web ACL can disable your perimeter, and the SRT role grants a third party write access to WAF. Treat both as privileged access with change control and alerting.

How identity and access work in AWS WAF and Shield

Both services are controlled by AWS IAM. Actions sit under the wafv2: and shield: prefixes, and resources are identified by ARNs for web ACLs, rule groups, IP sets and regex pattern sets. WAF has two scopes: REGIONAL for resources in a Region, and CLOUDFRONT for global resources, which must be managed through the US East (N. Virginia) endpoint (--scope=CLOUDFRONT --region=us-east-1). Policies that restrict WAF changes by Region must allow us-east-1 for CloudFront web ACLs, or administrators will be unable to change them.

Raising the body inspection limit above 16 KB costs extra, so many teams leave it. That is a real gap: an attacker who pads a request body past the limit avoids body-inspecting rules, because the baseline rules use the Continue option for oversize content. Add an explicit size constraint rule that blocks oversized bodies on endpoints that never receive large payloads.

Admin roles and privileged access

Edge controls are a high-value target for an attacker who already has some access: switching a web ACL's default action to allow, setting a rule group override to count, or disassociating a web ACL removes protection without touching the application. Separate the duties.

• Use Firewall Manager for estates with many accounts: a Firewall Manager WAF policy places pre-process and post-process rule groups in every web ACL it manages, and account teams cannot alter them. Web ACLs and logging configurations created by Firewall Manager can only be changed by Firewall Manager. See the AWS Organizations and SCPs Guide.
• Deny the dangerous calls by SCP: restrict wafv2:DeleteWebACL, wafv2:DisassociateWebACL, wafv2:DeleteLoggingConfiguration, shield:DeleteProtection and shield:DeleteSubscription to the edge security role.
• Version pinning is a privileged decision: a managed rule group without a fixed Version follows the vendor's default version as it changes. Pinning gives change control but means you can fall behind on new protections, such as new Known bad inputs rules for recent remote code execution CVEs.

Integrations, API tokens and service accounts

• Shield Response Team access: AssociateDRTRole lets the SRT inspect your WAF configuration and create or update WAF rules and web ACLs during an attack. Only one role ARN can be associated per subscription, it must carry AWSShieldDRTAccessPolicy, and it must trust drt.shield.amazonaws.com. If the SRT needs to read logs in S3, AssociateDRTLogBucket grants access to named buckets. Review these as you would any third-party access.
• Logging service roles: when you enable logging with PutLoggingConfiguration, WAF creates the role or resource policy it needs to write to the destination. Destinations are a CloudWatch Logs log group, an S3 bucket or a Kinesis Data Firehose stream, and the name must start with aws-waf-logs-. One destination is allowed per web ACL.
• Automation identities: pipelines that update IP sets from threat intelligence, or deploy web ACLs with CloudFormation or Terraform, need narrow permissions on the specific IP set or web ACL ARNs. A pipeline role with wafv2:* is a perimeter bypass waiting to happen. See the AWS IAM Policies and Roles Guide.
• Tokens issued by WAF: CAPTCHA and Challenge actions issue a token to the client; TokenDomains lets one token work across several protected domains. Keep that list to domains you control, because a token accepted across domains widens the effect of a solved challenge.
• Fraud rule groups and credentials: the account takeover prevention group (AWSManagedRulesATPRuleSet) needs your login path and username and password fields; the account creation fraud group (AWSManagedRulesACFPRuleSet) needs registration paths. Use data protection or RedactedFields so that passwords submitted to those pages do not land in WAF logs.

Logging and detection

Enable logging on every web ACL and send it to a central account. Use LoggingFilter to drop high-volume allowed traffic if cost is an issue, but keep all Block, CAPTCHA, Challenge and Count records, because count-mode matches are how you tune and how you spot probing. Each web ACL also publishes CloudWatch metrics through its VisibilityConfig and keeps sampled requests. For the log pipeline, see the Cloud Logging and Audit Trail Guide.

CloudTrail records WAF and Shield management API calls. The most useful configuration detections are a web ACL default action changed to allow, a managed rule group's override action changed to count, a rule action override on a specific rule, a web ACL disassociated from a production resource, logging deleted, and a Shield protection deleted. Feed these into AWS Config or Security Hub checks as well; see the AWS CloudTrail Guide and the AWS Security Hub Guide.

Measure whether it is working:

• Coverage: share of internet-facing CloudFront, ALB and API Gateway resources with a web ACL and logging enabled (target 100%).
• Enforcement: share of managed rule groups in block rather than count, and age of any rule still in count.
• Shield readiness: share of critical resources with a Shield Advanced protection, a health check and automatic application layer mitigation where supported.
• False positives: legitimate requests blocked per week, from support tickets matched to log labels.
• Response: time from attack detection to mitigation, from Shield events and the incident record.

Hardening baseline

Web ACL rules

Rate-based rule settings

• Limit and window: minimum limit 10; windows 60, 120, 300 (default) or 600 seconds. Changing a rule in use resets its counts and can pause rate limiting for up to a minute, so do not tune during an attack unless you must.
• Aggregation key: IP, FORWARDED_IP, CONSTANT or CUSTOM_KEYS. Custom keys include header, cookie, query argument, query string, HTTP method, label namespace, URI path, JA3 and JA4 fingerprints and ASN; each custom key adds 30 WCU.
• Forwarded IP: only use ForwardedIPConfig when a trusted proxy sets the header; if the header is missing, WAF does not apply the rule at all, and a client-supplied X-Forwarded-For is trivially spoofed.
• Scope-down: use a scope-down statement to apply a tight limit only to paths such as /login or /api/.

Shield

1. Rely on Shield Standard as the floor. It applies automatically to AWS customers at no additional charge and covers common network and transport layer attacks on AWS edge services; it does not add response support or application layer mitigation.
2. Subscribe to Shield Advanced where downtime is costly. In an AWS Organization the subscription is billed to the payer account. Create a protection for each CloudFront distribution, Route 53 hosted zone, Global Accelerator, Elastic IP (for EC2 and Network Load Balancers), ALB or Classic Load Balancer that matters.
3. Add health-based detection. Define Route 53 health checks and associate them with each protection, which improves detection accuracy and responsiveness.
4. Group related resources. Protection groups let Shield treat resources as a collective, which improves detection and reduces false positives.
5. Enable automatic application layer mitigation on CloudFront and ALB protections. Shield creates, verifies and applies rules in a Shield rule group inside the associated web ACL; start in count mode and move to block after a review period.
6. Prepare the response path. Associate the SRT role, set proactive engagement contacts (at least one phone number), and enable proactive engagement. Rehearse with the DDoS Response Playbook.
7. Close the origin. Restrict ALB and origin security groups to CloudFront, and make sure origins cannot be reached directly; WAF on CloudFront is bypassed if the origin is public.

Rollout and rollback

1. Deploy new rule groups with override action count, and new custom rules with action Count.
2. Review two to four weeks of logs by rule label; add scope-down statements or rule action overrides for genuine false positives.
3. Switch to block one rule group at a time, starting with Known bad inputs and IP reputation.
4. Roll back by setting the rule group's override back to count, or by removing a single rule action override; keep the previous web ACL definition in source control for full rollback.

Framework mapping

Common misconfigurations

• Managed rules left in count: a deployment that never moved past tuning gives logs but no protection. Track the age of every count-mode rule.
• Rate limiting the CDN: a per-IP rate rule on an ALB behind CloudFront without forwarded IP handling sees CloudFront edge addresses, not clients. Put the rule on the CloudFront web ACL, or use a trusted forwarded IP header.
• Origin reachable directly: attackers who find the ALB or EC2 address skip WAF entirely. Restrict origins to CloudFront.
• Oversized bodies uninspected: at the 8 KB ALB limit, a padded body slips past body rules. Add a size constraint block where large bodies are not expected.
• WAF treated as the only SSRF control: the Core rule set's EC2 metadata SSRF rules help, but the server-side flaw and the role's permissions remain. In the Capital One Breach 2019, a misconfigured firewall was the route to cloud role credentials; enforce IMDSv2 and least-privilege instance roles alongside WAF.
• Shield Advanced bought, not configured: no health checks, no SRT role and no contacts means slower detection and a response team that cannot help. Check readiness quarterly.

Practitioner checklist

• Inventory every internet-facing CloudFront, ALB, API Gateway, AppSync and Cognito resource and confirm a web ACL is associated.
• Enable WAF logging to an aws-waf-logs- destination in a central account, with sensitive fields redacted.
• Apply IP reputation, Core rule set and Known bad inputs, then the use-case groups that match your stack; move each to block after a count period.
• Add a broad per-IP rate rule and scoped rules for login and expensive paths; test limits against real traffic peaks.
• Restrict web ACL deletion, disassociation and logging changes to the edge security role by SCP, and alert on them in CloudTrail.
• Use Firewall Manager policies where you have many accounts, from a delegated administrator account.
• For Shield Advanced, create protections, health checks, protection groups and automatic application layer mitigation, and associate the SRT role and contacts.
• Lock origins to CloudFront and enforce IMDSv2 on instances behind ALBs.
• Review metrics monthly: coverage, count-mode age, false positives and attack mitigation time.

Standards and references

• AWS: Baseline Managed Rule Groups
• AWS: AWS Managed Rules Rule Groups List
• AWS: Rate-Based Rule Statement
• AWS: WAFV2 API Model (botocore)
• AWS: Shield Advanced API Model (botocore)
• MITRE ATT&CK: Endpoint Denial of Service
• MITRE ATT&CK: Exploit Public-Facing Application
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Web Application Firewall Guide · DDoS Protection Guide · Bot Management Guide · AWS Security Guide