AWS WAF Security Best Practices

AWS WAF (Web Application Firewall) is your first line of defense against application-layer attacks. It inspects every HTTP/HTTPS request hitting your internet-facing resources and decides whether to allow, block, count, or challenge each one. Without WAF, your applications are directly exposed to SQL injection, cross-site scripting (XSS), credential stuffing, bot scraping, and volumetric DDoS attacks.

In 2025, Cloudflare reported that automated bot traffic accounted for over 30% of all internet traffic, with malicious bots responsible for credential stuffing, inventory hoarding, and content scraping at industrial scale. AWS WAF v2, combined with Bot Control and Fraud Control managed rule groups, provides a layered defense that adapts to these evolving threats. Getting WAF right can mean the difference between a secure application and a costly breach.

This guide covers 12 battle-tested AWS WAF best practices, each with real AWS CLI commands, audit procedures, and the latest 2025-2026 updates from AWS.

1. Deploy WAF on All Internet-Facing Resources

AWS WAF can protect Amazon CloudFront distributions, Application Load Balancers (ALBs), Amazon API Gateway REST APIs, AWS AppSync GraphQL APIs, Amazon Cognito user pools, AWS App Runner services, and AWS Amplify Hosting apps. Every internet-facing resource without a WAF web ACL is an unprotected entry point.

Implementation

• Create a web ACL for each resource type. CloudFront web ACLs must be created in us-east-1; regional resources use the resource's own region.
• Set the default action to Allow. Then add deny/block rules for known bad traffic. This is the recommended deny-list approach for most applications.
• Associate the web ACL with every exposed resource. Unassociated web ACLs provide zero protection.

# Create a web ACL for a regional resource (ALB, API Gateway)
aws wafv2 create-web-acl   --name "production-web-acl"   --scope REGIONAL   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --region eu-west-1

# Associate the web ACL with an ALB
aws wafv2 associate-web-acl   --web-acl-arn arn:aws:wafv2:eu-west-1:123456789012:regional/webacl/production-web-acl/EXAMPLE-ID   --resource-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/my-alb/EXAMPLE

# List all resources associated with a web ACL
aws wafv2 list-resources-for-web-acl   --web-acl-arn arn:aws:wafv2:eu-west-1:123456789012:regional/webacl/production-web-acl/EXAMPLE-ID   --resource-type APPLICATION_LOAD_BALANCER

Security Hub Control: [WAF.10] AWS WAF web ACLs should have at least one rule or rule group. An empty web ACL with no rules provides a false sense of security.

2. Enable AWS Managed Rules -- Core Rule Set and Known Bad Inputs

AWS Managed Rules are pre-built rule groups maintained by the AWS Threat Research Team. They provide immediate protection against OWASP Top 10 vulnerabilities without requiring you to write custom rules.

Essential Managed Rule Groups

• AWSManagedRulesCommonRuleSet (CRS): Protects against OWASP Top 10 including XSS, SQL injection, path traversal, and remote file inclusion. This is the baseline every web ACL should include.
• AWSManagedRulesKnownBadInputsRuleSet: Blocks request patterns known to be malicious, including Log4j/Log4Shell exploit patterns (CVE-2021-44228).
• AWSManagedRulesSQLiRuleSet: Additional SQL injection detection using advanced inspection of request bodies, query strings, and headers.
• AWSManagedRulesAdminProtectionRuleSet: Blocks access to administrative pages and endpoints commonly targeted by attackers.
• AWSManagedRulesAmazonIpReputationList: Filters traffic from IP addresses with poor reputation, including known botnets and threat actors.

# Add the Core Rule Set to an existing web ACL
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "AWS-AWSManagedRulesCommonRuleSet",
      "Priority": 1,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet"
        }
      },
      "OverrideAction": {"None": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWSManagedRulesCommonRuleSet"
      }
    },
    {
      "Name": "AWS-AWSManagedRulesKnownBadInputsRuleSet",
      "Priority": 2,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesKnownBadInputsRuleSet"
        }
      },
      "OverrideAction": {"None": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWSManagedRulesKnownBadInputsRuleSet"
      }
    }
  ]'   --region eu-west-1

Best practice: Deploy managed rules in Count mode first. Monitor the CloudWatch metrics and sampled requests for 24-72 hours to identify false positives before switching to Block mode. Subscribe to the SNS topic for each managed rule group to receive version update notifications.

3. Implement Bot Control for Automated Threat Management

AWS WAF Bot Control identifies and manages bot traffic at two levels: Common (included with WAF) and Targeted (advanced, additional cost). Bots account for a significant share of internet traffic, and without Bot Control, your applications serve scrapers, credential stuffers, and inventory hoarders as if they were legitimate users.

Common vs. Targeted Bot Control

• Common level: Identifies self-identifying bots (search engines, social media crawlers) and blocks known malicious bots. Detects bots using HTTP request characteristics.
• Targeted level: Uses browser fingerprinting, JavaScript challenges, and behavioral analysis to detect sophisticated bots that mimic human behavior. Includes dynamic rate limiting per client session.

# Add Bot Control (targeted level) with scope-down statement
# Only inspect requests to sensitive endpoints to optimize cost
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "AWS-AWSManagedRulesBotControlRuleSet",
      "Priority": 3,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesBotControlRuleSet",
          "ManagedRuleGroupConfigs": [
            {
              "AWSManagedRulesBotControlRuleSet": {
                "InspectionLevel": "TARGETED"
              }
            }
          ],
          "ScopeDownStatement": {
            "ByteMatchStatement": {
              "SearchString": "/api/",
              "FieldToMatch": {"UriPath": {}},
              "TextTransformations": [{"Priority": 0, "Type": "NONE"}],
              "PositionalConstraint": "STARTS_WITH"
            }
          }
        }
      },
      "OverrideAction": {"None": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWSManagedRulesBotControlRuleSet"
      }
    }
  ]'   --region eu-west-1

Cost optimization: Use scope-down statements to limit Bot Control evaluation to sensitive paths (login, checkout, APIs). You are only charged for requests inspected by the rule group, not those excluded by the scope-down statement. AWS recommends running Bot Control before ATP and ACFP to keep costs down.

4. Configure Rate-Based Rules for DDoS and Brute Force Protection

Rate-based rules automatically block IP addresses that exceed a defined request threshold within a 5-minute window. They are your primary defense against HTTP flood DDoS attacks and brute force login attempts.

Implementation

• Global rate limit: Set a blanket rate limit (e.g., 2000 requests per 5 minutes per IP) as a safety net.
• Login endpoint protection: Apply a stricter rate limit (e.g., 100 requests per 5 minutes) scoped to /login or /auth paths.
• Custom keys: Rate-limit by forwarded IP (for CloudFront/proxy architectures), by specific header values, or by query string parameters.

# Create a rate-based rule that blocks IPs exceeding 2000 requests in 5 minutes
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "RateLimitGlobal",
      "Priority": 0,
      "Statement": {
        "RateBasedStatement": {
          "Limit": 2000,
          "AggregateKeyType": "IP"
        }
      },
      "Action": {"Block": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "RateLimitGlobal"
      }
    },
    {
      "Name": "RateLimitLogin",
      "Priority": 1,
      "Statement": {
        "RateBasedStatement": {
          "Limit": 100,
          "AggregateKeyType": "IP",
          "ScopeDownStatement": {
            "ByteMatchStatement": {
              "SearchString": "/login",
              "FieldToMatch": {"UriPath": {}},
              "TextTransformations": [{"Priority": 0, "Type": "LOWERCASE"}],
              "PositionalConstraint": "STARTS_WITH"
            }
          }
        }
      },
      "Action": {"Block": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "RateLimitLogin"
      }
    }
  ]'   --region eu-west-1

2025 Update: AWS WAF now supports additional aggregation keys beyond IP, including forwarded IP, custom header, query argument, cookie, and label namespace. You can combine up to five aggregation keys for fine-grained rate limiting (e.g., rate-limit per IP per URI path).

5. Enable Fraud Control -- ATP and ACFP

AWS WAF Fraud Control provides two specialized managed rule groups that go far beyond traditional WAF rules:

• Account Takeover Prevention (ATP): Inspects login requests against a stolen credentials database, detects credential stuffing patterns, and identifies distributed login attempts across multiple IPs.
• Account Creation Fraud Prevention (ACFP): Analyzes account sign-up requests for fake email addresses, disposable domains, phone number fraud, and bot-driven registration patterns.

ATP Configuration

{
  "Name": "AWS-AWSManagedRulesATPRuleSet",
  "Priority": 5,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesATPRuleSet",
      "ManagedRuleGroupConfigs": [
        {
          "AWSManagedRulesATPRuleSet": {
            "LoginPath": "/api/auth/login",
            "RequestInspection": {
              "PayloadType": "JSON",
              "UsernameField": {"Identifier": "/username"},
              "PasswordField": {"Identifier": "/password"}
            },
            "ResponseInspection": {
              "StatusCode": {
                "SuccessCodes": [200],
                "FailureCodes": [401, 403]
              }
            }
          }
        }
      ]
    }
  },
  "OverrideAction": {"None": {}},
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "AWSManagedRulesATPRuleSet"
  }
}

Best practice: Integrate the AWS WAF JavaScript SDK into your login and registration pages. The SDK generates a token that ATP and ACFP use to correlate requests with browser sessions, dramatically improving detection accuracy. Without the SDK, these rule groups rely solely on request-level inspection and miss session-level attack patterns.

Cost optimization: Use scope-down statements to limit ATP evaluation to your login path and ACFP to your registration path. Run Bot Control before ATP/ACFP in your rule priority order, as Bot Control filters out obvious bots at a lower per-request cost.

6. Use CAPTCHA and Challenge Actions for Browser Verification

AWS WAF CAPTCHA and Challenge actions verify that requests come from real browsers operated by humans, not from scripts or automated tools.

• Challenge: A silent JavaScript challenge that runs without user interaction. It verifies the client has a real browser environment and generates a WAF token. Use this for broad, low-friction verification.
• CAPTCHA: Presents an interactive puzzle the user must solve. Use this for high-risk actions like login, password reset, or checkout.

Configuration Best Practices

• Apply CAPTCHA and Challenge only to GET text/html requests. They cannot run on POST, OPTIONS (CORS preflight), or non-HTML responses.
• Require HTTPS. Browser clients must be in a secure context to acquire WAF tokens.
• Tune immunity times. A solved CAPTCHA generates a token valid for a configurable period (default 300 seconds). Set this long enough that normal user flows do not trigger repeated puzzles.
• Use Challenge for API protection. Require a valid token (obtained from a prior Challenge on an HTML page) before allowing API calls to sensitive endpoints.

# Create a rule that applies CAPTCHA to login page
# Then the token protects subsequent API calls
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --captcha-config ImmunityTimeProperty={ImmunityTime=300}   --challenge-config ImmunityTimeProperty={ImmunityTime=300}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "CaptchaLogin",
      "Priority": 4,
      "Statement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "TextTransformations": [{"Priority": 0, "Type": "LOWERCASE"}],
          "PositionalConstraint": "STARTS_WITH"
        }
      },
      "Action": {"Captcha": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "CaptchaLogin"
      }
    }
  ]'   --region eu-west-1

2025-2026 Update: AWS WAF now supports configuring token domains for multi-domain applications, allowing a single CAPTCHA or Challenge token to be valid across multiple domains (e.g., example.com and api.example.com).

7. Write Custom Rules with Regex Patterns

While managed rules cover common attack patterns, every application has unique endpoints, parameters, and business logic that require custom rules. AWS WAF supports regex pattern sets, string match conditions, size constraints, and geographic match statements.

Common Custom Rule Patterns

• Block suspicious User-Agent strings: Filter out known attack tools (sqlmap, nikto, Havij).
• Enforce required headers: Block requests missing expected headers like Content-Type or custom API keys.
• Limit request body size: Prevent oversized payloads that could exploit buffer overflows or consume resources.
• Path traversal protection: Block URI paths containing ../ or encoded variants beyond what the CRS catches.

# Create a regex pattern set for blocking attack tools
aws wafv2 create-regex-pattern-set   --name "BlockedUserAgents"   --scope REGIONAL   --regular-expression-list '[
    {"RegexString": "(?i)(sqlmap|nikto|havij|nessus|masscan|zgrab)"},
    {"RegexString": "(?i)(python-requests|go-http-client|java\/[0-9])"}
  ]'   --region eu-west-1

# Use the regex pattern set in a rule
# Reference the ARN returned from the create command above
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "BlockAttackTools",
      "Priority": 6,
      "Statement": {
        "RegexPatternSetReferenceStatement": {
          "ARN": "arn:aws:wafv2:eu-west-1:123456789012:regional/regexpatternset/BlockedUserAgents/EXAMPLE-ID",
          "FieldToMatch": {"SingleHeader": {"Name": "user-agent"}},
          "TextTransformations": [{"Priority": 0, "Type": "NONE"}]
        }
      },
      "Action": {"Block": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "BlockAttackTools"
      }
    }
  ]'   --region eu-west-1

Best practice: Use text transformations (URL_DECODE, HTML_ENTITY_DECODE, LOWERCASE, COMPRESS_WHITE_SPACE) to normalize input before matching. Attackers routinely use encoding tricks to bypass pattern matching.

8. IP Reputation Lists and Geo-Blocking

Combine AWS-managed IP reputation lists with custom IP sets and geographic restrictions to filter traffic before it reaches your application logic.

Layered IP Filtering

• AWSManagedRulesAmazonIpReputationList: Blocks IPs from AWS threat intelligence, including known command-and-control servers and botnets.
• AWSManagedRulesAnonymousIpList: Identifies requests from VPNs, Tor exit nodes, hosting providers, and anonymous proxies.
• Custom IP sets: Allowlist trusted partners or block specific ranges identified during incident response.
• Geographic restrictions: Block or allow traffic from specific countries based on your business requirements and compliance needs.

# Create a custom IP set for blocking
aws wafv2 create-ip-set   --name "BlockedIPs"   --scope REGIONAL   --ip-address-version IPV4   --addresses '["203.0.113.0/24", "198.51.100.0/24"]'   --region eu-west-1

# Create a geo-blocking rule (block traffic from specific countries)
# Use this as a rule statement in your web ACL
# GeoMatchStatement with CountryCodes: ["CN", "RU", "KP"]
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "GeoBlockRule",
      "Priority": 7,
      "Statement": {
        "GeoMatchStatement": {
          "CountryCodes": ["CN", "RU", "KP"]
        }
      },
      "Action": {"Block": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "GeoBlockRule"
      }
    }
  ]'   --region eu-west-1

Caveat: Geo-blocking is not a security measure on its own -- attackers use VPNs and compromised hosts in any country. Use it as one layer in defense-in-depth, combined with the Anonymous IP List managed rule group for more robust coverage.

9. Enable Comprehensive Logging and Monitoring

Without logging, you cannot detect attacks, investigate incidents, tune rules, or prove compliance. AWS WAF supports three logging destinations: Amazon CloudWatch Logs, Amazon S3, and Amazon Kinesis Data Firehose.

Logging Configuration

• CloudWatch Logs: Best for real-time alerting and small-to-medium traffic volumes. Create CloudWatch alarms on blocked request counts.
• Amazon S3: Best for long-term retention and compliance. Pair with Amazon Athena for ad-hoc query analysis of WAF logs.
• Kinesis Data Firehose: Best for high-volume, real-time streaming to SIEM tools, OpenSearch, or Splunk.

# Enable WAF logging to CloudWatch Logs
aws wafv2 put-logging-configuration   --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:eu-west-1:123456789012:regional/webacl/production-web-acl/EXAMPLE-ID",
    "LogDestinationConfigs": [
      "arn:aws:logs:eu-west-1:123456789012:log-group:aws-waf-logs-production"
    ],
    "RedactedFields": [
      {"SingleHeader": {"Name": "authorization"}},
      {"SingleHeader": {"Name": "cookie"}}
    ]
  }'

# Create CloudWatch alarm for high block rate
aws cloudwatch put-metric-alarm   --alarm-name "WAF-HighBlockRate"   --metric-name BlockedRequests   --namespace AWS/WAFV2   --statistic Sum   --period 300   --threshold 1000   --comparison-operator GreaterThanThreshold   --evaluation-periods 1   --alarm-actions arn:aws:sns:eu-west-1:123456789012:security-alerts   --dimensions Name=WebACL,Value=production-web-acl Name=Rule,Value=ALL Name=Region,Value=eu-west-1

# Verify logging is enabled
aws wafv2 get-logging-configuration   --resource-arn arn:aws:wafv2:eu-west-1:123456789012:regional/webacl/production-web-acl/EXAMPLE-ID

Security Hub Control: [WAF.11] AWS WAF web ACL logging should be enabled. [WAF.12] AWS WAF rules should have CloudWatch metrics enabled. Both are critical for visibility and incident response.

Best practice: Redact sensitive fields (Authorization headers, cookies, custom tokens) from logs to avoid storing credentials in plain text. Use log filter expressions to reduce log volume by excluding known-good traffic patterns.

10. Centralize WAF Management with AWS Firewall Manager

AWS Firewall Manager lets you define WAF policies once and automatically deploy them across all accounts in your AWS Organization. Without it, each team manages their own web ACLs -- leading to inconsistent rules, missed protections on new resources, and compliance gaps.

Key Capabilities

• Automatic deployment: New resources matching the policy scope automatically receive WAF protection. No manual association required.
• Centralized logging: Firewall Manager delivers WAF logs from all accounts to a single centralized destination.
• Compliance monitoring: Non-compliant resources are flagged in Security Hub. Firewall Manager can auto-remediate by associating the required web ACL.
• Cross-account visibility: View WAF metrics, Shield Advanced events, and compliance status across your entire organization.

# Create a Firewall Manager WAF policy
# Prerequisites: AWS Organizations, Firewall Manager admin account configured
aws fms put-policy   --policy '{
    "PolicyName": "OrgWideWAFPolicy",
    "SecurityServicePolicyData": {
      "Type": "WAFV2",
      "ManagedServiceData": "{"type":"WAFV2","preProcessRuleGroups":[{"ruleGroupArn":null,"overrideAction":{"type":"NONE"},"managedRuleGroupIdentifier":{"vendorName":"AWS","managedRuleGroupName":"AWSManagedRulesCommonRuleSet"},"ruleGroupType":"ManagedRuleGroup","excludeRules":[]}],"postProcessRuleGroups":[],"defaultAction":{"type":"ALLOW"}}"
    },
    "ResourceType": "AWS::ElasticLoadBalancingV2::LoadBalancer",
    "ResourceTags": [],
    "ExcludeResourceTags": false,
    "RemediationEnabled": true,
    "IncludeMap": {
      "ACCOUNT": ["123456789012", "987654321098"]
    }
  }'

# List compliance status across accounts
aws fms list-compliance-status   --policy-id EXAMPLE-POLICY-ID

Best practice: Use Firewall Manager with a "pre-process" rule group strategy. Define baseline security rules (IP reputation, Core Rule Set) in the Firewall Manager policy as pre-process rules. Allow individual teams to add custom rules after the baseline. This ensures organizational security standards while preserving team autonomy.

11. Integrate AWS Shield Advanced for DDoS Protection

AWS Shield Standard is automatically included with WAF at no extra cost and protects against common network-layer (L3/L4) DDoS attacks. Shield Advanced adds application-layer (L7) DDoS detection, the Shield Response Team (SRT), cost protection, and enhanced visibility.

Shield Advanced Benefits

• Automatic L7 DDoS mitigation: Shield Advanced monitors your application's traffic baseline and automatically creates, tests, and deploys WAF rules to mitigate application-layer attacks within seconds.
• Shield Response Team (SRT): 24/7 access to AWS DDoS experts who can analyze your WAF logs and apply mitigations during active attacks with your authorization.
• Cost protection: AWS credits your account for scaling charges (EC2, ELB, CloudFront, Route 53) caused by DDoS attacks.
• Health-based detection: Associate Route 53 health checks with Shield Advanced protections for more accurate, application-aware DDoS detection.

# Subscribe to Shield Advanced
aws shield create-subscription

# Create a Shield Advanced protection for an ALB
aws shield create-protection   --name "production-alb"   --resource-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/my-alb/EXAMPLE

# Enable automatic application-layer DDoS mitigation
aws shield enable-application-layer-automatic-response   --resource-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/my-alb/EXAMPLE   --action Block={}

# Associate a health check for health-based detection
aws shield associate-health-check   --protection-id EXAMPLE-PROTECTION-ID   --health-check-arn arn:aws:route53:::healthcheck/EXAMPLE-HEALTH-CHECK-ID

# Grant SRT access to your WAF and Shield resources
aws shield associate-drt-role   --role-arn arn:aws:iam::123456789012:role/AWSSRTAccess

Architecture best practice: Place CloudFront in front of your ALB and protect both with Shield Advanced. CloudFront absorbs volumetric attacks at the edge, while Shield Advanced on the ALB handles application-layer attacks that pass through. This layered approach is the architecture recommended by AWS for maximum DDoS resilience.

12. Continuously Test and Tune Your WAF Rules

A WAF that is deployed and never tuned will either block legitimate traffic (false positives) or miss real attacks (false negatives). Continuous testing and tuning is essential for maintaining both security and availability.

Testing Methodology

• Count mode deployment: Deploy all new rules in Count mode first. Analyze the CloudWatch metrics and sampled requests for at least 24-72 hours before switching to Block.
• Excluded rules: When a managed rule group produces false positives, use rule-level exclusions rather than disabling the entire group. Override specific rules to Count while keeping the rest in Block.
• Automated testing: Use tools like OWASP ZAP, Nuclei, or the AWS WAF Testing Framework to run known attack payloads against your WAF-protected endpoints and verify rules trigger correctly.
• Version management: Subscribe to AWS Managed Rule SNS topics. When AWS releases a new version, test it in a staging environment before updating production.

# Override a specific rule to Count (for false positive investigation)
# This overrides SizeRestrictions_BODY in the Common Rule Set
aws wafv2 update-web-acl   --name "production-web-acl"   --scope REGIONAL   --id EXAMPLE-WEB-ACL-ID   --lock-token EXAMPLE-LOCK-TOKEN   --default-action Allow={}   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL   --rules '[
    {
      "Name": "AWS-AWSManagedRulesCommonRuleSet",
      "Priority": 1,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet",
          "ExcludedRules": [
            {"Name": "SizeRestrictions_BODY"}
          ]
        }
      },
      "OverrideAction": {"None": {}},
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWSManagedRulesCommonRuleSet"
      }
    }
  ]'   --region eu-west-1

# Check sampled requests to analyze blocked traffic
aws wafv2 get-sampled-requests   --web-acl-arn arn:aws:wafv2:eu-west-1:123456789012:regional/webacl/production-web-acl/EXAMPLE-ID   --rule-metric-name AWSManagedRulesCommonRuleSet   --scope REGIONAL   --time-window StartTime=2026-03-01T00:00:00Z,EndTime=2026-03-02T00:00:00Z   --max-items 100

# Subscribe to managed rule group SNS topic for version updates
aws sns subscribe   --topic-arn arn:aws:sns:us-east-1:248400274283:aws-managed-waf-rule-notifications   --protocol email   --notification-endpoint security-team@example.com

2025-2026 Update: AWS WAF now offers a simplified console experience that reduces security configuration steps by up to 80%. Pre-configured protection packs incorporate AWS security expertise and are continuously updated to address emerging threats. The unified dashboard provides consolidated security metrics, threat detection, and rule performance data -- making ongoing tuning significantly easier.

---

Common Misconfigurations

Misconfiguration	Risk	Detection
Web ACL with no rules	All traffic passes through unfiltered	Security Hub: [WAF.10]
WAF logging disabled	No visibility into attacks or false positives	Security Hub: [WAF.11]
CloudWatch metrics disabled on rules	Cannot monitor rule effectiveness or trigger alarms	Security Hub: [WAF.12]
Rules deployed directly in Block mode	Legitimate traffic blocked, causing outages	Manual review of deployment process
No rate-based rules configured	Vulnerable to HTTP flood DDoS and brute force	Web ACL rule audit
Bot Control without JavaScript SDK	Reduced detection accuracy for sophisticated bots	Review application integration
Internet-facing ALBs without WAF	Direct exposure to application-layer attacks	AWS Config rule or Firewall Manager compliance

---

Quick Reference Checklist

#	Practice	Priority
1	Deploy WAF on all internet-facing resources	Critical
2	Enable AWS Managed Rules (CRS + Known Bad Inputs)	Critical
3	Implement Bot Control	High
4	Configure rate-based rules	Critical
5	Enable Fraud Control (ATP/ACFP)	High
6	Use CAPTCHA and Challenge actions	Medium
7	Write custom rules with regex patterns	Medium
8	IP reputation lists and geo-blocking	High
9	Enable comprehensive logging and monitoring	Critical
10	Centralize WAF with Firewall Manager	High
11	Integrate Shield Advanced for DDoS protection	High
12	Continuously test and tune WAF rules	Critical

---

Related Resources

• AWS WAF Security Card -- Quick-reference card with attack vectors and defenses
• AWS CloudFront Security Card -- CDN security and edge protection
• AWS ELB/ALB Security Card -- Load balancer security configuration
• API Gateway Security Card -- API authorization and throttling
• AWS CloudWatch Security Card -- Monitoring and alerting configuration
• AWS CloudTrail Security Card -- API audit logging for WAF changes
• AWS VPC Security Card -- Network-level security controls
• AWS Security Hub Security Card -- Centralized security findings and compliance