AWS WAF and Shield: Web Application Firewall and DDoS Protection

Last Black Friday, a major e-commerce platform lost $2M in 30 minutes because their WAF rules were too permissive and a simple SQL injection bypassed their backend. Don't let that be you. AWS WAF and Shield aren't just checkboxes for compliance—they're your first line of defense against the constant barrage of automated attacks and DDoS floods that target every public endpoint. The problem is, most teams either over-configure (blocking legitimate traffic) or under-configure (leaving gaping holes). This article cuts through the noise: you'll learn exactly what WAF and Shield do, when to use each, and how to avoid the production pitfalls that cost real money.

Why AWS WAF and Shield Are Non-Negotiable for Production Workloads

Every public-facing application is a target. Layer 7 attacks like SQL injection, cross-site scripting (XSS), and HTTP floods can bypass traditional network firewalls. AWS WAF gives you granular control over HTTP(S) traffic, while AWS Shield Advanced provides always-on DDoS detection and mitigation. In production, you need both: WAF for application-layer threats, Shield for volumetric attacks. Without them, you're one botnet away from a $100k+ bill or a full outage. I've seen teams rely solely on CloudFront's default protections and get burned by a slow loris attack that exhausted origin connections. Don't be that team.

aws shield create-protection \
  --name "prod-api-protection" \
  --resource-arn "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7" \
  --region us-east-1

WAF Web ACLs: The Core of Your Application Security

A Web ACL is a set of rules that inspect incoming HTTP(S) requests. You attach it to a CloudFront distribution, ALB, API Gateway, or AppSync. Each rule has a priority, a condition (e.g., IP match, SQL injection match), and an action (allow, block, count). In production, you must order rules carefully: allow rules first (e.g., health checks), then rate-based rules, then threat detection rules, and finally a default deny. I've seen teams put a 'block all except whitelist' rule first and break their own monitoring. Always test with 'count' action before switching to 'block'.

{
  "Name": "prod-web-acl",
  "Scope": "CLOUDFRONT",
  "DefaultAction": {
    "Block": {}
  },
  "Rules": [
    {
      "Name": "AWS-AWSManagedRulesCommonRuleSet",
      "Priority": 0,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet"
        }
      },
      "OverrideAction": {
        "Count": {}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWS-AWSManagedRulesCommonRuleSet"
      }
    }
  ],
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "prod-web-acl"
  }
}

Managed Rule Groups: The Fastest Path to Production Security

AWS provides pre-built rule groups for common threats: SQL injection, XSS, LFI/RFI, size constraints, and more. The AWS Managed Rules for WAF include the Common Rule Set, SQL Database, Linux OS, and POSIX OS groups. In production, enable the Common Rule Set and SQL Database groups at minimum. But beware: these rules can have false positives. For example, the SQLi rule may block legitimate requests containing the word 'select' in a query parameter. You must create exceptions (allow rules) for known good patterns. I've seen a team disable the entire SQLi rule because of false positives – that's a terrible idea. Instead, add a custom rule with a higher priority to allow specific patterns.

{
  "Name": "prod-web-acl",
  "Scope": "CLOUDFRONT",
  "DefaultAction": {
    "Block": {}
  },
  "Rules": [
    {
      "Name": "Allow-health-check",
      "Priority": 0,
      "Statement": {
        "IPSetReferenceStatement": {
          "ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/health-check-ips/abc123"
        }
      },
      "Action": {
        "Allow": {}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "Allow-health-check"
      }
    },
    {
      "Name": "AWS-AWSManagedRulesCommonRuleSet",
      "Priority": 1,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet",
          "ExcludedRules": [
            {
              "Name": "NoUserAgent_HEADER"
            }
          ]
        }
      },
      "OverrideAction": {
        "None": {}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWS-AWSManagedRulesCommonRuleSet"
      }
    }
  ],
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "prod-web-acl"
  }
}

Custom Rules: When Managed Rules Aren't Enough

Managed rules are great, but they can't cover every scenario. You need custom rules for business logic: block requests from specific countries, allow only certain HTTP methods, enforce header presence, or implement rate limiting. Custom rules use match conditions: IP sets, regex patterns, string matches, size constraints, and geo-match. In production, I always add a geo-block rule for countries where we don't do business – it reduces attack surface significantly. Also, block requests with no User-Agent or with suspicious headers. But be careful: custom rules can become a maintenance nightmare if not documented. Use descriptive names and tags.

{
  "Name": "BlockNonBusinessCountries",
  "Priority": 2,
  "Statement": {
    "NotStatement": {
      "Statement": {
        "GeoMatchStatement": {
          "CountryCodes": ["US", "CA", "GB", "DE", "JP", "AU"]
        }
      }
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlockNonBusinessCountries"
  }
}

Rate-Based Rules: The First Line of Defense Against DDoS

Rate-based rules limit the number of requests from a single IP within a 5-minute window. They are essential for mitigating HTTP floods and brute-force attacks. In production, set a rate limit that is slightly above your peak legitimate traffic. For example, if your API handles 1000 requests per second from a single IP, set the limit to 2000. But beware: rate-based rules can block legitimate users behind a NAT (e.g., corporate offices). Use the 'aggregate' option to group by IP or by a custom key like a session cookie. I've seen a team set a rate limit of 100 requests per 5 minutes and block their own CI/CD pipeline. Always monitor and adjust.

{
  "Name": "RateLimit-1000",
  "Priority": 3,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 1000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimit-1000"
  }
}

AWS Shield Advanced: Beyond Basic DDoS Protection

AWS Shield Standard is free and protects against common DDoS attacks (SYN floods, UDP floods). Shield Advanced adds enhanced detection, mitigation, and cost protection. For production workloads, especially those with high traffic or sensitive data, Shield Advanced is worth the $3,000/month. It provides near real-time visibility via CloudWatch metrics, DDoS attack reports, and integration with WAF for automatic rule creation. The cost protection feature is a lifesaver: if your AWS bill spikes due to a DDoS attack, Shield Advanced covers the additional costs. I've seen a client get a $200k bill from a UDP flood on an ALB – Shield Advanced reimbursed them.

# Get DDoS attack summary for the last 24 hours
aws shield describe-attack \
  --attack-id "abc123-def456-ghi789" \
  --region us-east-1

Integrating WAF with CloudFront and ALB for Maximum Protection

WAF can be attached to CloudFront distributions, ALBs, API Gateway, and AppSync. For production, the best practice is to attach WAF to CloudFront (if you use it) and then also to the ALB behind it. This provides defense in depth: CloudFront WAF blocks attacks at the edge, and ALB WAF catches anything that slips through (e.g., attacks from trusted origins). However, this doubles your WAF costs (per Web ACL). An alternative is to attach WAF only to CloudFront and rely on its caching to reduce load on the origin. I prefer the dual approach for critical APIs. Also, ensure that your ALB's security group only allows traffic from CloudFront's IP ranges.

{
  "DistributionId": "E1A2B3C4D5E6F7",
  "WebACLId": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/prod-web-acl/abc123"
}

Logging, Monitoring, and Alerting for WAF and Shield

You can't secure what you can't see. Enable WAF logging to S3, CloudWatch Logs, or Firehose. Use CloudWatch metrics for each rule (SampledRequests, AllowedRequests, BlockedRequests). Set up alarms for spikes in blocked requests or high rate limiting. For Shield Advanced, enable DDoS attack alerts via SNS. In production, I recommend sending WAF logs to a SIEM (e.g., Splunk) for analysis. Also, use AWS Config to track changes to Web ACLs – a misconfiguration can open a hole. I've seen a team accidentally delete a critical rule and not notice for days because they had no alerts.

aws wafv2 put-logging-configuration \
  --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:us-east-1:123456789012:global/webacl/prod-web-acl/abc123",
    "LogDestinationConfigs": ["arn:aws:firehose:us-east-1:123456789012:deliverystream/aws-waf-logs-prod"],
    "RedactedFields": [
      {
        "SingleHeader": {
          "Name": "authorization"
        }
      }
    ]
  }'

Testing and Tuning WAF Rules in Production

WAF rules can have false positives that block legitimate traffic. The only way to catch them is to test. Use the 'count' action for new rules and monitor sampled requests. AWS WAF provides a 'sampled requests' view in the console – inspect them for false positives. Also, use AWS WAF's 'rule simulator' to test requests against your Web ACL. In production, I always have a 'canary' deployment: a small percentage of traffic goes to a Web ACL with new rules in count mode. After a week, if no false positives, I promote the rules to block mode. Never deploy new rules directly to block mode – you will break something.

# Simulate a request against your Web ACL
aws wafv2 check-capacity \
  --scope CLOUDFRONT \
  --rules file://test-rule.json

# Get sampled requests for a rule
aws wafv2 get-sampled-requests \
  --web-acl-arn "arn:aws:wafv2:us-east-1:123456789012:global/webacl/prod-web-acl/abc123" \
  --rule-metric-name "RateLimit-1000" \
  --scope CLOUDFRONT \
  --time-window 300

Cost Optimization: WAF and Shield Without Breaking the Bank

WAF costs are based on the number of Web ACLs, rules, and requests. Shield Advanced is $3,000/month. For cost optimization, use a single Web ACL for multiple resources if they have similar security requirements. Use managed rule groups instead of custom rules where possible (they are cheaper per rule). Also, use rate-based rules sparingly – each rule adds cost. For Shield Advanced, only protect critical resources. Consider using AWS WAF Security Automations (a solution from AWS) to automatically block bad IPs based on threat intelligence feeds – it's cost-effective. I've seen teams protect every ALB with Shield Advanced and wonder why their bill is $10k/month.

# Use AWS Pricing Calculator (manual step)
# Example: 1 Web ACL, 10 rules, 100M requests/month
# Cost = $5.00 (Web ACL) + $1.00 (per rule) * 10 + $0.60 per million requests * 100
# Total = $5 + $10 + $60 = $75/month