AWS WAF & AWS Shield

Overview

AWS WAF (Web Application Firewall) and AWS Shield are managed security services that protect your web applications from common web exploits and DDoS attacks. Understanding how these services work together is essential for designing secure, resilient architectures on AWS.

AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect availability, compromise security, or consume excessive resources. WAF gives you control over which traffic to allow or block by defining customizable web security rules.

AWS Shield is a managed DDoS protection service that safeguards applications running on AWS. Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency.

For the exam, you must understand when to use each service, how they integrate with other AWS services, and the differences between Shield Standard and Shield Advanced.

Key Concepts

AWS WAF Components

Web ACL (Access Control List)

The core component of AWS WAF. A Web ACL contains rules that define what traffic to allow, block, or count.

• Attached to: CloudFront, ALB, API Gateway, AppSync, Cognito User Pool
• Scope: Regional (for ALB, API Gateway) or Global (for CloudFront)
• Default action: Allow or Block (applied if no rules match)

Rules

Conditions that WAF evaluates against incoming requests.

Rule Types:

Rule Groups

Reusable collections of rules that you can add to multiple Web ACLs.

• AWS Managed Rule Groups: Pre-built by AWS (Core Rule Set, SQL Database, etc.)
• Marketplace Rule Groups: Third-party managed rules
• Custom Rule Groups: Your own reusable rule collections

AWS WAF Rule Matching

Web ACL evaluates rules in PRIORITY ORDER (lowest number first):

Priority 1: AWS Managed - Known Bad Inputs    → BLOCK if match
Priority 2: Rate limit (2000 requests/5min)   → BLOCK if exceeded
Priority 3: Block specific countries          → BLOCK if match
Priority 4: SQL Injection rule               → BLOCK if match
Priority 5: XSS rule                         → BLOCK if match
Default Action: ALLOW (if no rules match)

Rule Actions:

• ALLOW: Let the request through
• BLOCK: Return 403 Forbidden
• COUNT: Count but don't block (for testing)
• CAPTCHA: Challenge with CAPTCHA
• Challenge: Silent browser verification

AWS Shield Standard vs Advanced

Shield Advanced Features

DDoS Response Team (DRT)

• 24/7 access to AWS DDoS experts
• Proactive engagement during attacks
• Can write WAF rules on your behalf

Cost Protection

• Credits for scaling charges during DDoS attacks
• Covers EC2, ELB, CloudFront, Route 53, Global Accelerator

Advanced Metrics

• Near real-time visibility into attacks
• Attack forensics and reports
• CloudWatch dashboards

How It Works

WAF Integration Points

WAF can be attached to:

1. Amazon CloudFront (Global)

   • Inspects traffic at edge locations
   • Lowest latency for blocking attacks
   • Best for global applications

2. Application Load Balancer (Regional)

   • Inspects traffic at the ALB
   • Protects applications within VPC
   • Use for internal applications

3. Amazon API Gateway (Regional)

   • Protects REST APIs
   • Rate limiting for APIs
   • Bot protection

4. AWS AppSync (Regional)

   • Protects GraphQL APIs
   • Same rule capabilities

5. Amazon Cognito User Pool (Regional)

   • Protects authentication endpoints
   • Blocks credential stuffing

Shield Protection Flow

Attack → AWS Edge Network → Shield Standard
                              ↓
                    Layer 3/4 attacks blocked
                    (SYN floods, UDP reflection)
                              ↓
                    Traffic flows to your resources

Attack → AWS Edge Network → Shield Advanced
                              ↓
                    Layer 3/4 attacks blocked
                              ↓
                    Layer 7 attacks detected
                              ↓
                    DRT engagement (if needed)
                              ↓
                    WAF rules auto-applied
                              ↓
                    Attack metrics to CloudWatch

Common WAF Rules

{
  "AWSManagedRulesCommonRuleSet": {
    "description": "Core rules for common vulnerabilities",
    "blocks": ["XSS", "Local file inclusion", "Path traversal"]
  },
  "AWSManagedRulesSQLiRuleSet": {
    "description": "SQL injection patterns",
    "blocks": ["SQL injection attempts"]
  },
  "AWSManagedRulesKnownBadInputsRuleSet": {
    "description": "Known malicious patterns",
    "blocks": ["Log4j exploits", "Bad bots"]
  },
  "AWSManagedRulesAmazonIpReputationList": {
    "description": "Known malicious IPs",
    "blocks": ["Bots", "Reconnaissance"]
  },
  "AWSManagedRulesBotControlRuleSet": {
    "description": "Bot management",
    "blocks": ["Scrapers", "Crawlers"]
  }
}

Use Cases

Use Case 1: Protect Web Application from OWASP Top 10

Scenario: E-commerce application needs protection from SQL injection, XSS, and other common exploits.

Solution:

• Deploy AWS WAF on CloudFront distribution
• Enable AWS Managed Rules:
  • Core Rule Set (blocks XSS, file inclusion)
  • SQL Database Rule Set (blocks SQL injection)
  • Known Bad Inputs Rule Set (blocks Log4j, etc.)
• Add rate-based rule for brute force protection

Use Case 2: Block Traffic from Specific Countries

Scenario: Application should only be accessible from US and Canada.

Solution:

• Create geo-match rule in WAF
• Action: BLOCK for all countries except US, CA
• Attach Web ACL to CloudFront
• Note: Geo-blocking uses IP geolocation (not 100% accurate)

Use Case 3: DDoS Protection for Critical Application

Scenario: Financial services application requires maximum DDoS protection and guaranteed response times.

Solution:

• Enable Shield Advanced
• Resources: CloudFront, Route 53, ALB, Elastic IP
• Configure Route 53 health checks
• Enable proactive DRT engagement
• Set up CloudWatch dashboards for attack visibility

Use Case 4: API Rate Limiting

Scenario: REST API needs protection from abuse and brute force attacks.

Solution:

• Deploy WAF on API Gateway
• Create rate-based rule:
  • Threshold: 2000 requests per 5 minutes per IP
  • Action: BLOCK
• Add SQL injection and XSS rules
• Enable Amazon IP Reputation List

Best Practices

WAF Best Practices

1. Start with COUNT mode

   • Deploy new rules in COUNT mode first
   • Analyze CloudWatch logs for false positives
   • Switch to BLOCK after validation

2. Use AWS Managed Rules as baseline

   • Start with Core Rule Set and SQL Database rules
   • Add specific rules based on application needs
   • Override specific rules if false positives occur

3. Layer your defenses

   • CloudFront + WAF at edge
   • ALB + WAF for VPC traffic
   • Security Groups and NACLs for infrastructure

4. Enable logging

   • Send WAF logs to S3 or CloudWatch
   • Use Athena or CloudWatch Insights for analysis
   • Set up alerts for blocked requests

5. Use rate-based rules

   • Protect against brute force and DDoS
   • Threshold depends on normal traffic patterns
   • Minimum threshold: 100 requests/5 minutes

Shield Best Practices

1. Shield Standard is automatic

   • No configuration needed
   • All AWS resources protected at Layer 3/4
   • Review best practices for each service

2. Shield Advanced for critical workloads

   • Financial services, healthcare, e-commerce
   • When cost of downtime exceeds Shield cost
   • When you need DRT access

3. Configure Route 53 health checks

   • Shield Advanced uses health for detection
   • Proactive engagement when health degrades
   • Faster attack detection

4. Enable proactive engagement

   • DRT contacts you when attack detected
   • Faster response times
   • Requires Route 53 health checks

Common Exam Scenarios

Common Pitfalls

Pitfall 1: Wrong WAF Scope

Mistake: Creating Regional Web ACL for CloudFront distribution.

• Why it fails: CloudFront requires Global scope Web ACL (us-east-1)
• Correct approach: Create Web ACL in Global (CloudFront) scope, or select us-east-1 in console

Pitfall 2: Deploying Rules Without Testing

Mistake: Setting new rules to BLOCK immediately.

• Why it fails: May block legitimate traffic (false positives)
• Correct approach: Deploy with COUNT action first, analyze logs, then switch to BLOCK

Pitfall 3: Expecting Shield Standard for Layer 7

Mistake: Assuming Shield Standard protects against application-layer attacks.

• Why it fails: Shield Standard only covers Layer 3/4 (network/transport)
• Correct approach: Use Shield Advanced for Layer 7 protection, or use WAF

Pitfall 4: WAF Without Logging

Mistake: Not enabling WAF logging.

• Why it fails: Cannot troubleshoot blocked requests or detect attacks
• Correct approach: Enable logging to S3, CloudWatch, or Kinesis Firehose

Pitfall 5: Not Using Managed Rules

Mistake: Writing custom rules for common attacks.

• Why it fails: Reinventing the wheel, missing attack patterns
• Correct approach: Start with AWS Managed Rules, add custom rules as needed

Related Services

Quick Reference

WAF Pricing

Shield Advanced Protected Resources

• Amazon CloudFront distributions
• Amazon Route 53 hosted zones
• Application Load Balancers
• Network Load Balancers
• Elastic IP addresses
• AWS Global Accelerator accelerators

Quiz Questions

Further Reading

• AWS WAF Documentation
• AWS Shield Documentation
• AWS Managed Rules
• DDoS Best Practices Whitepaper
• Shield Advanced Pricing