WAF, Shield, and DDoS Protection Architecture

Why WAF, Shield, and DDoS Protection Matter for ANS-C01

DDoS protection sits at the boundary between Domain 1 (Network Design — edge architecture) and Domain 4 (Network Security). The ANS-C01 exam tests both layers because every Specialty-level architect must be able to design a layered defense for a public-facing workload. Roughly one in six Domain 4 questions involves WAF rule architecture, Shield tier selection, or DDoS layered defense, and a similar density of Domain 1 questions involves choosing between CloudFront, Global Accelerator, ALB, and Route 53 as the edge entry point.

This note is a Specialty-depth walk through AWS WAF and AWS Shield with a tight focus on what ANS-C01 tests. We cover Web ACL architecture and scope (REGIONAL vs CLOUDFRONT), managed rule groups, custom rules and rate-based rules, Bot Control and ATP/ACFP, CAPTCHA and Challenge actions, the difference between Shield Standard (free, automatic, L3/L4) and Shield Advanced (paid, proactive, L7), the Shield Response Team engagement model, the cost-protection mechanism, layered DDoS defense patterns, AWS Firewall Manager for organization-wide WAF policies, and the operational integration with CloudFront, ALB, API Gateway, and Global Accelerator.

We close with FAQ, scenario walkthroughs, and Mandarin trap callouts. Read this once cover to cover, and the ANS-C01 questions on WAF, Shield, and DDoS protection become pattern-matching against a fixed playbook.

AWS WAF Architecture: Web ACL, Rules, and Scope

AWS WAF is a Layer 7 web application firewall that inspects HTTP and HTTPS requests against a configurable rule set. The top-level policy object is the Web ACL (Web Access Control List). A Web ACL contains an ordered list of rules, a default action (Allow or Block), a CloudWatch metric name, optional logging configuration, and optional CAPTCHA / Challenge configurations. Rules are evaluated in priority order until a terminating action fires; if no rule matches, the default action applies.

Web ACL scope: CLOUDFRONT vs REGIONAL

A Web ACL scope is determined at creation and cannot be changed. The CLOUDFRONT scope is global and the Web ACL must be created in us-east-1 regardless of where you operate. CLOUDFRONT-scoped Web ACLs can only be associated with CloudFront distributions. The REGIONAL scope is per-region and can be associated with regional resources (ALB, API Gateway, AppSync, Cognito user pool, App Runner service, Verified Access instance).

You cannot share a single Web ACL across CLOUDFRONT and REGIONAL scopes. To enforce identical WAF policies on both a CloudFront distribution and a regional ALB, you build two Web ACLs and use AWS Firewall Manager to keep them synchronized.

Rule statements and actions

Each WAF rule has a statement (the match condition) and an action. Statements include byte-match (substring match), regex pattern set, SQLi attack, XSS attack, size constraint, geo-match, IP set, label match, rate-based, and managed rule group reference. Statements can be combined with logical AND, OR, NOT for complex matching.

Actions include Allow (permit and stop evaluating), Block (deny and stop evaluating), Count (record but continue evaluating), CAPTCHA (present a puzzle), and Challenge (silent JavaScript proof-of-work). CAPTCHA and Challenge create token cookies that are valid for a configurable immunity time (default 300 seconds for CAPTCHA, 300 seconds for Challenge).

Rule priority and evaluation order

Rules are evaluated in ascending priority order. The first rule with a terminating action (Allow, Block, CAPTCHA, Challenge) ends the evaluation. A Count action does not terminate — it records the match and proceeds to the next rule. This is the foundation of label-driven rule pipelines: an early rule labels the request, later rules match on the label.

AWS Managed Rule Groups

AWS Managed Rules are curated rule groups maintained by the AWS Threat Research Team. They are the fastest way to deploy production-grade WAF protection without writing custom rules. The most ANS-C01-relevant managed rule groups:

• AWSManagedRulesCommonRuleSet (CRS): covers OWASP Top 10 categories — SQLi, XSS, Local File Inclusion, generic remote code execution.
• AWSManagedRulesSQLiRuleSet: deeper SQL injection coverage with body, header, and URI inspection.
• AWSManagedRulesKnownBadInputsRuleSet: payloads matching well-known exploits like Log4Shell, Spring4Shell, and remote code execution against common vulnerabilities.
• AWSManagedRulesAmazonIpReputationList: IPs known to AWS as bots, scanners, and threat actors.
• AWSManagedRulesAnonymousIpList: VPN, proxy, Tor exit nodes, and hosting provider IPs.
• AWSManagedRulesBotControlRuleSet: Bot Control common feature for scraping bots, SEO crawlers, security scanners.
• AWSManagedRulesATPRuleSet: Account Takeover Prevention for login endpoints with credential stuffing detection.
• AWSManagedRulesACFPRuleSet: Account Creation Fraud Prevention for sign-up forms.

CRS, KBI, IP Reputation, and Anonymous IP are free. Bot Control, ATP, and ACFP are paid (per-request fees). All managed rule groups support action overrides (change a specific rule's action without forking the rule group) and scope-down statements (limit the rule group to a subset of traffic).

Rate-Based Rules: 5-Minute Window and Aggregate Keys

Rate-based rules count requests over a rolling 5-minute window per aggregate key. The default key is the source IP (or forwarded IP when CloudFront is in front). You can also aggregate by header value, query argument, label, country, or a composite key combining multiple attributes.

A rate-based rule with a limit of 2,000 means: if a single aggregate key exceeds 2,000 requests in the trailing 5 minutes, the rule fires (Block, CAPTCHA, Challenge, or Count). The rule does not fire at exactly request 2,001 — there is a detection lag of roughly 30 seconds to 1 minute, which the exam may use as a distractor.

Composite aggregate keys

Composite keys let you express rules like "more than 100 requests in 5 minutes from the same IP+header combination." This is the canonical pattern for API key abuse: rate-limit per Authorization header, not per source IP, because legitimate users behind a corporate NAT share an IP. The composite key option supports up to 5 attributes per rate-based rule.

Scope-down statements

A scope-down statement narrows where a rate-based rule applies. For example, a rate-based rule with limit 100 only on /login (not on /static/*). The scope-down is a regular WAF statement (URI match, method match, header match) that pre-filters traffic before the rate calculation.

Without a scope-down, rate-based rules count all traffic — including static asset requests — which often exceeds limits during normal operation and causes false positives. Always pair rate-based rules with scope-down statements for endpoint-specific limits.

Bot Control, ATP, and ACFP

Bot Control is the AWS WAF managed feature that detects and categorizes automated traffic. It has two tiers: Common and Targeted.

• Common Bot Control detects well-known bot categories (search engines, scrapers, SEO tools, security scanners) and emits labels like awswaf:managed:aws:bot-control:bot:category:scraping_framework.
• Targeted Bot Control adds machine-learning-based detection of advanced bots that mimic human behavior, with browser fingerprinting and challenge injection.

Account Takeover Prevention (ATP) is a managed rule group specifically for login endpoints. It detects credential stuffing, password spraying, and credential phishing. ATP requires you to configure the login endpoint URI and the request format (JSON or form-encoded) so it can extract credentials.

Account Creation Fraud Prevention (ACFP) is the equivalent for sign-up endpoints. It detects automated account creation by analyzing form submissions for bot-like patterns and previously-seen credentials.

All three are paid managed rule groups with per-request fees. They emit labels that can drive subsequent rules — for example, "if Bot Control labels the request as automated AND the URI is /api/checkout, then CAPTCHA."

CAPTCHA and Challenge Actions

CAPTCHA presents a visual puzzle when triggered; the user solves it once per immunity period (default 300 seconds, configurable up to 24 hours). Successful solutions create a CAPTCHA token cookie. Subsequent requests within the immunity time bypass the CAPTCHA.

Challenge is a silent JavaScript proof-of-work. The browser executes a small JavaScript challenge that is trivial for browsers but expensive for headless bots. The challenge runs invisibly; users notice nothing. Successful challenges create a Challenge token. Challenge is the right action for API endpoints and back-end calls where human friction would break the user experience.

AWS Shield: Standard vs Advanced

AWS Shield is the DDoS protection service. Two tiers; the exam tests them constantly.

Shield Standard

Shield Standard is automatic, free, and on by default for every AWS account. It protects against common L3 and L4 DDoS attacks: SYN floods, UDP reflection, and amplification attacks. Shield Standard is integrated into Route 53, CloudFront, Global Accelerator, and ELB. You cannot turn it off, you cannot configure it, and you cannot view its detailed metrics. It is the baseline.

Shield Advanced

Shield Advanced is a paid subscription at $3,000 per month per organization (with a 1-year commitment), plus per-resource protection. It adds:

• L3, L4, and L7 protection (the latter via tight integration with AWS WAF).
• Application-layer DDoS detection backed by health-check-based detection on protected resources.
• Access to the AWS Shield Response Team (SRT), the human operators who can write or modify Web ACL rules during an attack with your approval.
• Cost protection: refund of scaling costs (CloudFront data transfer, ALB capacity units, Route 53 queries, EC2 hours) attributable to a DDoS event.
• Global Threat Dashboard with attack pattern visualization.
• Automatic application-layer DDoS mitigation, which can auto-create rate-based rules in your Web ACL during an event.
• Health-check-based detection with custom CloudWatch alarms.
• Coverage for Elastic IPs on EC2/NLB, AWS Global Accelerator, CloudFront, Route 53 hosted zones, ALB, and Classic Load Balancers.

When to choose Shield Advanced

Shield Advanced is justified when at least two of these are true:

• The workload is public-facing and revenue-critical (e-commerce, SaaS, ad-tech).
• The customer requires 24x7 SRT engagement during attacks.
• The customer needs cost protection against scaling charges incurred during a DDoS event.
• The customer must centralize DDoS protection across an AWS Organization with Firewall Manager.

If only one of those is true, Shield Standard plus AWS WAF rate-based rules is usually sufficient and significantly cheaper.

Layered DDoS Defense Architecture

A real-world DDoS playbook combines multiple layers. ANS-C01 expects you to articulate the stack:

Client
  │
  ▼
Route 53 (DNS, Anycast, DDoS-resilient)
  │
  ▼
CloudFront / Global Accelerator (edge absorption, anycast IPs)
  │
  ▼
AWS Shield Standard (automatic L3/L4 mitigation)
  │
  ▼
AWS WAF (managed rules, rate-based, Bot Control, CAPTCHA)
  │
  ▼
AWS Shield Advanced (L7 detection, SRT, cost protection)
  │
  ▼
ALB / NLB / API Gateway (regional, health-check-driven)
  │
  ▼
Auto Scaling Group / Lambda / Fargate (compute)

Each layer has a job:

• L3/L4 volumetric (UDP flood, SYN flood): Shield Standard absorbs at the edge automatically. CloudFront, Global Accelerator, and Route 53 are anycast networks with massive aggregate capacity that absorb hundreds of gigabits per second.
• L7 HTTP flood (GET flood): CloudFront caches absorb cacheable requests; AWS WAF rate-based rules block uncacheable hot keys; Bot Control labels organized bot fleets.
• L7 sophisticated (slowloris, low-and-slow): Shield Advanced application-layer mitigation, plus ALB connection idle-timeout tuning.
• Reflection and amplification: Shield Standard at the network border blocks at the AWS edge.

Shield Advanced for Different Resource Types

Shield Advanced protects different resource types differently. Memorize this table:

Note: AWS WAF does not attach directly to NLB or to EC2/EIP. To get L7 WAF protection for those resource types, place CloudFront in front of NLB or EC2.

Firewall Manager for WAF and Shield

AWS Firewall Manager applies WAF Web ACLs and Shield Advanced protections across an AWS Organization. Two Firewall Manager policy types matter for this domain:

• WAF policy: deploys a Web ACL configuration (managed rule groups + custom rules) to in-scope resources (CloudFront distributions, ALBs, API Gateways) across accounts. Continuously remediates non-compliant resources (e.g., a new ALB without the policy).
• Shield Advanced policy: ensures Shield Advanced is enabled on in-scope resources (CloudFront, ALB, NLB, EIP, Global Accelerator, Route 53 hosted zones) across accounts.

Firewall Manager requires AWS Organizations with all features enabled, AWS Config enabled in member accounts, and a delegated administrator. Without these, the answer "use Firewall Manager" is wrong.

The exam loves "enforce WAF rate-based rules across 200 ALBs in 12 accounts" — the answer is a Firewall Manager WAF policy. Manual Web ACL deployment per account does not scale and inevitably drifts.

WAF Logging and Visibility

AWS WAF can log to three destinations: an Amazon S3 bucket (via Kinesis Data Firehose, the most common for compliance retention), Amazon CloudWatch Logs, or Kinesis Data Firehose to a custom destination (Splunk, Datadog, etc.). Log lines include the timestamp, matched rule ID, action, labels, and the (truncated) request.

Sampled requests in the WAF console are NOT the same as full logs — sampled requests are a sample for diagnostic purposes only, with up to 5 minutes of latency. For complete visibility, enable full logging.

For SCS-style alerting, send logs to CloudWatch Logs and create metric filters that detect attack patterns (e.g., spike in BLOCK actions for the SQLi managed rule). EventBridge rules on Shield Advanced events trigger automated incident response.

Edge Architecture Choices

The ANS-C01 exam tests where to place WAF and Shield based on the edge architecture. The decision tree:

• HTTP/HTTPS workload, global latency-sensitive, cacheable content: CloudFront in front, WAF on CloudFront, Shield Advanced on CloudFront.
• TCP/UDP workload (gaming, VoIP), global latency-sensitive: Global Accelerator in front, Shield Advanced on Global Accelerator (no WAF — Global Accelerator is L4).
• Regional HTTP/HTTPS workload, no global requirement: ALB in front, WAF on ALB, Shield Advanced on ALB.
• API workload, low-latency requirement: API Gateway with WAF, optionally Shield Advanced.
• NLB-fronted workload (TLS passthrough): CloudFront in front of NLB if WAF L7 inspection is required; otherwise just NLB with Shield Advanced on EIPs.

Scenario Walkthroughs

Scenario A: L7 HTTP flood attack against ALB

Requirement: an e-commerce ALB receives a sudden 100x spike in traffic. The application starts timing out. Customer needs to mitigate within minutes.

Correct architecture (already in place before the attack):

• CloudFront distribution in front of ALB with caching configured.
• WAF on CloudFront with AWS Managed CRS, IP Reputation, Anonymous IP, Bot Control.
• Rate-based rule (limit 2,000 per IP, 5-minute window) on /checkout/*.
• Shield Advanced subscription with the ALB as a protected resource.

During attack:

• WAF rate-based rule blocks high-volume IPs.
• Bot Control labels organized scraping fleet, scope-down rule blocks them.
• Shield Advanced application-layer detection auto-creates additional rate-based rules.
• SRT engaged via AWS Support if attack signature is novel.
• Cost protection refunds the CloudFront and ALB scaling costs.

Incorrect answers: pure NACL deny rules (cannot match HTTP attributes), Network Firewall (L7 detection limited compared to WAF), Shield Standard alone (no WAF integration on ALB at L7).

Scenario B: Global UDP-based gaming workload DDoS protection

Requirement: a multiplayer game uses UDP for client-server traffic. Players are global. A DDoS attacker floods the entry points.

Correct architecture:

• AWS Global Accelerator with anycast IPs as the global entry point.
• NLB endpoints in multiple Regions, attached to Global Accelerator.
• Shield Advanced subscription with Global Accelerator as the protected resource.
• No WAF (CloudFront and WAF do not handle UDP).

Why not CloudFront: CloudFront does not support UDP, only HTTP/HTTPS over TCP. Global Accelerator supports both TCP and UDP and is the right L4 anycast entry point.

Operational Best Practices

1. Deploy rate-based rules with Count action first, observe for a week, validate no false positives, then switch to Block. This is the canonical "shadow mode" pattern for WAF tuning.

2. Always pair rate-based rules with scope-down statements so that static asset traffic does not consume the rate budget.

3. Enable WAF logging from day one to S3 via Kinesis Firehose for compliance retention and to CloudWatch Logs for real-time alerting.

4. Use Firewall Manager for organization-wide consistency — manual per-account WAF deployment drifts within 90 days.

5. Set up CloudWatch alarms on Shield Advanced metrics (DDoSDetected, AttackBitsPerSecond) and route to PagerDuty / OpsGenie.

6. Test failover scenarios quarterly — simulate origin failure and confirm CloudFront origin failover, ALB target group failover, and Shield Advanced detection.

7. Pre-configure SRT contacts in AWS Support so engagement during an actual attack is not delayed by paperwork.

Common Exam Traps

Other anti-patterns:

• Forgetting that WAF on CloudFront uses CLOUDFRONT scope; WAF on regional ALB/API Gateway uses REGIONAL scope.
• Putting an ACM certificate for CloudFront in any Region other than us-east-1.
• Using Shield Standard alone for L7 protection — it is L3/L4 only.
• Not enabling AWS WAF on API Gateway REST API stages (HTTP API does not support WAF directly; HTTP API uses Lambda authorizer).
• Forgetting that rate-based rules need a key — without aggregate-key configuration, the rule defaults to source IP, which fails when CloudFront is in front (always X-Forwarded-For).
• Not setting CAPTCHA / Challenge immunity time appropriately — too short causes user friction; too long weakens security.

FAQ

Q1: When should I choose Shield Advanced over Shield Standard?

Shield Advanced is justified when at least two of these are true: the workload is revenue-critical, the customer requires 24x7 SRT engagement, the customer needs cost protection against scaling charges during a DDoS, or the customer must centralize protections across an AWS Organization. The $3,000-per-month list price plus required Business or Enterprise Support means Shield Advanced rarely makes sense for non-revenue or internal workloads.

Q2: Where should I enforce geo-restriction — CloudFront or AWS WAF?

CloudFront distribution-level geo-restriction is best for blanket country blocks of the entire distribution — it is free, simple, and returns 403. AWS WAF geo-match rules are better when geography must combine with path, method, or header, or when you need different actions per country (Allow, Block, CAPTCHA, Challenge, Count).

Q3: How do rate-based rules behave when CloudFront is in front?

When CloudFront is in front, the source IP that WAF sees is CloudFront's IP, not the client's. To get correct rate limiting, configure the rate-based rule with aggregate-key of forwarded-IP and reference the X-Forwarded-For header. CloudFront automatically populates X-Forwarded-For with the original client IP.

Q4: Can I share one Web ACL between a CloudFront distribution and an ALB?

No. Web ACL scope is binary — CLOUDFRONT-scoped Web ACL only attaches to CloudFront distributions; REGIONAL-scoped Web ACL only attaches to regional resources (ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access). Use AWS Firewall Manager to deploy two parallel Web ACLs with the same rule configuration.

Q5: What is the difference between AWS WAF and AWS Network Firewall?

AWS WAF is L7 web application firewall, attached to HTTP/HTTPS-fronting services (CloudFront, ALB, API Gateway). AWS Network Firewall is L3-7 stateful firewall, attached to VPC routing paths for east-west and north-south inspection. They are complementary — most architectures use both: WAF at the edge in front of the load balancer, Network Firewall on the VPC boundary.

Q6: How does Shield Advanced cost protection work in practice?

When AWS Shield detects a DDoS event against a protected resource and that event causes scaling-related cost increases (CloudFront data-out, Route 53 queries, ALB capacity units, EC2 hours), you can submit a credit request via AWS Support. AWS reviews the attack signature in their detection systems and issues service credits for the incremental cost attributable to the attack. Cost protection requires Business or Enterprise Support and an active Shield Advanced subscription on the resource at the time of the event.

Q7: Can WAF protect against Layer 3/4 DDoS?

No, AWS WAF is L7 only. L3/L4 DDoS protection is the job of AWS Shield (Standard or Advanced). The two are designed to work together: Shield handles volumetric and protocol-layer attacks at the network edge, WAF handles application-layer attacks at the HTTP layer.

Q8: Is AWS WAF logging the same as CloudFront access logging?

No. AWS WAF logs record per-request inspection results — matched rule, action, labels, request fields. CloudFront access logs record every viewer request to the distribution — what was served, status code, bytes. For complete edge security visibility, enable both. WAF logs go to S3 (via Firehose), CloudWatch Logs, or a custom Firehose destination. CloudFront standard logs go to S3 directly; real-time logs go to Kinesis Data Streams.

Q9: What is the AWS Shield Response Team's actual scope?

The Shield Response Team (SRT) is a group of AWS engineers available 24x7 to assist Shield Advanced subscribers during DDoS events. With your prior approval (recorded in AWS Support), SRT can review your Web ACL during an attack, propose new rules, and apply rules to mitigate the attack on your behalf. SRT engagement requires Business or Enterprise Support.

Q10: Does Shield Advanced require enabling on every protected resource?

Yes. Subscribing to Shield Advanced at the organization level enables Advanced features, but each resource (CloudFront distribution, ALB, NLB, Global Accelerator, EIP, Route 53 hosted zone) must be explicitly added as a protected resource. Firewall Manager Shield Advanced policies automate this for new resources.

Summary: WAF, Shield, DDoS Answer Patterns

When you read an ANS-C01 question on WAF, Shield, or DDoS, run through this checklist:

• Is there public HTTP/HTTPS traffic? → CloudFront + WAF.
• Is there public UDP traffic? → Global Accelerator + Shield Advanced.
• Is L7 inspection required (SQLi, XSS, OWASP)? → AWS WAF with managed rules.
• Is the workload revenue-critical with 24x7 SLO? → Shield Advanced.
• Is rate limiting required? → WAF rate-based rules with scope-down and proper aggregate key.
• Is bot abuse a concern? → Bot Control + ATP/ACFP for high-value endpoints.
• Is centralization across accounts required? → Firewall Manager.
• Is the question about NLB protection? → CloudFront in front of NLB; WAF cannot attach to NLB.
• Is the question about cost during attack? → Shield Advanced cost protection (requires Business/Enterprise Support).

Master the layered defense stack, the WAF rule evaluation order, the Shield tier selection criteria, and the integration constraints (CLOUDFRONT vs REGIONAL scope, NLB cannot have WAF, ACM cert in us-east-1 for CloudFront), and the ANS-C01 questions become predictable.

常考陷阱

• WAF 不能掛 NLB — NLB 是 L4，WAF 是 L7；要 L7 防護就用 CloudFront 在前面。
• Web ACL scope 不能改 — CLOUDFRONT 跟 REGIONAL 二選一，建好不能切換。
• CLOUDFRONT-scope Web ACL 必須在 us-east-1 建 — 不管 CloudFront origin 在哪。
• Shield Standard 免費自動，Shield Advanced 一個月 $3,000 — 還需要 Business/Enterprise Support 才能用 cost protection 跟 SRT。
• Rate-based rule 用 5 分鐘滑動視窗 — 不是 per-second、不是 per-hour，且觸發有 30 秒到 1 分鐘的延遲。
• CloudFront 在前面時 rate-based 要用 forwarded-IP — 不然 source IP 看到的全是 CloudFront 的 IP。
• Bot Control / ATP / ACFP 收費 — 不是免費的 managed rule group。
• CAPTCHA 跟 Challenge 不一樣 — CAPTCHA 是看得見的測驗，Challenge 是隱形的 JS proof-of-work。
• Firewall Manager 需要 AWS Organizations + Config + 委派管理員 — 缺一不可。
• Global Accelerator 不支援 HTTP caching — 它是 L4 anycast，不是 CDN；要 cache 用 CloudFront。