WAF、Shield 與網路防護服務

AWS WAF, Shield, and Network Protection sits at the busiest intersection of Domain 5 — Networking and Content Delivery — and Domain 4 — Security and Compliance — on SOA-C02. Task Statement 5.1 explicitly calls out "Configure AWS network protection services (for example, AWS WAF, AWS Shield)", and the operational angle is what separates this exam from SAA-C03. Where the Solutions Architect is asked which protection layer to recommend, the SysOps engineer is asked how to debug a false positive at 11pm on Friday night when a marketing campaign just went live, traffic legitimately spiked 400 percent, the WAF rate-based rule started blocking real customers, and the on-call has 15 minutes to fix it without disabling protection altogether.

This guide walks through the operational lifecycle of AWS WAF, Shield, Firewall Manager, Network Firewall, and the network-related GuardDuty findings — from creating a Web ACL and choosing the right managed rule group, to interpreting WAF logs to spot false positives, tuning rate-based rules per aggregate key type, choosing between Shield Standard and Shield Advanced (and the cost commitment that comes with the latter), wiring Firewall Manager into AWS Organizations for org-wide WAF and Shield policies, distinguishing AWS Network Firewall from AWS WAF (Layer 3/4 vs Layer 7 — a perennial trap), and responding to GuardDuty network findings such as port scans, reconnaissance, and exfiltration. You will also see the recurring SOA-C02 scenario shapes: legitimate users blocked by an over-aggressive rate-based rule, Shield Advanced alert during an in-progress DDoS, and Firewall Manager refusing to deploy because Organizations was never enabled.

Why WAF, Shield, and Network Protection Matter on SOA-C02

The official SOA-C02 Exam Guide v2.3 lists three skills under Task Statement 5.1: configure a VPC, configure private connectivity, and configure AWS network protection services. The third skill is exactly the territory of this topic. AWS WAF and AWS Shield are the canonical Layer 7 and Layer 3/4 protection services on AWS, and the SysOps Administrator is the engineer who runs them day-to-day — adding rules to a Web ACL, tuning rate thresholds based on observed traffic, reviewing WAF sampled requests during an incident, requesting Shield Response Team engagement during an attack, and pushing a Firewall Manager policy that enforces a baseline WAF Web ACL across every account in the organization.

At the SysOps tier the questions are almost never "should the architect choose WAF?" — that is SAA territory. The SOA-C02 questions are "the WAF rate-based rule is set at 100 requests per 5 minutes, customers are reporting 403s during a flash sale, the on-call needs to keep DDoS protection but stop blocking real users — what is the right combination of changes?" The answer requires understanding rule actions (Allow, Block, Count, CAPTCHA, Challenge), rate-based rule aggregate key types (IP, forwarded IP, header, cookie), rule priority and evaluation order, WAF logs and sampled requests, and Web ACL capacity units (WCU). This topic plugs into Domain 1 (CloudWatch alarms and dashboards for WAF metrics), Domain 4 (Firewall Manager as part of Organizations strategy and GuardDuty as part of data protection findings review), and Domain 5 (CloudFront and ALB integrations for the Web ACL attachment point).

白話文解釋 WAF, Shield, and Network Protection

The vocabulary is dense — Web ACL, WCU, aggregate key type, SRT, AWS managed rule groups. Three analogies make the constructs stick.

Analogy 1: The Nightclub Bouncer With an ID Check

AWS WAF is the nightclub bouncer at the front door. Every customer who walks up (every HTTP request) gets evaluated against a rulebook the manager handed the bouncer. Rules are the bouncer's individual checks — "no one with an ID matching this banned-list" (IP set match), "no one wearing a t-shirt with these specific words" (string match for SQL injection patterns), "no group of more than 100 people from the same address arriving in 5 minutes" (rate-based rule per IP). Rule groups are pre-printed checklists the head office distributes — the AWS Managed Rule Groups are like the city's standard nightclub security checklist (covers OWASP Top 10, known bad inputs, Amazon IP reputation list), while custom rule groups are the club-specific rules ("members only on Friday"). Rule actions are the bouncer's options: Allow (welcome in), Block (turn away), Count (let in but write down on the clipboard for the manager to review later — pure observation mode), CAPTCHA (make them solve a puzzle to prove they are human), and Challenge (silently run a browser fingerprint test that bots will fail). Rule priority is the order on the bouncer's checklist — lower number means evaluated first, and the first matching rule with a terminating action wins (Allow or Block ends the evaluation; Count keeps going).

AWS Shield Standard is the club's basic security guard outside the front door who handles obvious crowd-control problems — somebody trying to ram the door open with a battering ram (volumetric DDoS), or a coordinated rush of 1,000 people trying to flood the entrance (SYN flood). It is always on, free, and invisible — every AWS customer gets it automatically. AWS Shield Advanced is the upgraded private security firm with a 24/7 incident hotline — they have a dedicated Shield Response Team (SRT) you can phone during an attack, they help you write custom WAF rules in real time, they refund the bouncer overtime cost (DDoS cost protection), and they use the entire AWS-wide threat intelligence network to spot attacks early. The catch: the contract costs $3,000 per month with a one-year commitment.

Analogy 2: The Anti-Spam Mail Filter

AWS WAF managed rule groups behave exactly like an enterprise anti-spam mail filter. The Core Rule Set is the default spam filter — covers the OWASP Top 10 categories (injection, XSS, broken auth) the way a default spam filter covers the obvious phishing patterns. The Amazon IP Reputation List is the shared reputation database — IPs that have been seen sending malware to other AWS customers go into the same blocklist that protects you. The Known Bad Inputs list is virus signature definitions updated by AWS as new attack patterns emerge. Bot Control is the bot-detection plugin that adds a fingerprint-based check on top of the spam filter — distinguishing a real Outlook client from a script pretending to be one. Count action is flag-as-spam-but-still-deliver mode: useful when you have just turned on a new rule and want to see whether it would flag legitimate mail before you turn on actual blocking. The exam-key insight from this analogy: always Count first, observe the WAF logs, then promote to Block — exactly like how a mail admin runs a new spam rule in evaluation mode for a week before turning on quarantine.

Analogy 3: The Fortress Wall + Watchtower + Patrol

A medieval fortress used layered defenses, and AWS network protection mirrors them precisely. AWS Shield Standard is the outer fortress wall — every fortress has one, it is always there, it stops obvious siege engines (volumetric attacks) without anyone needing to operate it. AWS WAF is the gatekeeper at the drawbridge — inspects every visitor's papers (HTTP headers, body, query string) against the rulebook and decides who crosses. AWS Network Firewall is the inner-city patrol on the cobbled streets — checks every cart and traveler at the Layer 3/4 packet level, can do deep packet inspection of stateful connections, distinct from the Layer 7 gatekeeper at the drawbridge. AWS Firewall Manager is the kingdom's security council — sits in the capital (the management account in AWS Organizations), drafts the security ordinances, and dispatches them to every fortress in the realm so that no governor can disable the inner patrol or change the gatekeeper's rulebook unilaterally. GuardDuty network findings are the scouts on horseback patrolling outside the fortress reporting back: "I saw someone scanning the walls for weak points" (port scan), "a known bandit's horse approached the gate" (known-malicious IP communication), "wagons were leaving the fortress at 3am with valuable cargo headed to a foreign land" (data exfiltration). Each layer detects different things, and a complete operational answer on SOA-C02 usually involves more than one layer working together.

AWS WAF Web ACL Fundamentals — Scope and Attachment Points

A Web ACL is the WAF object you actually attach to a protected resource. It contains rules and rule groups, evaluated in priority order, with a default action of Allow or Block at the end if no rule terminates the evaluation.

Scope: CLOUDFRONT vs REGIONAL

AWS WAF has two scopes, and the choice of scope is one of the most-tested operational gotchas:

• CLOUDFRONT scope — the Web ACL is global and must be created in us-east-1 (N. Virginia), regardless of where the CloudFront distribution serves traffic. CloudFront is a global service whose configuration plane lives in us-east-1, so its WAF lives there too. Attempting to attach a CLOUDFRONT-scope Web ACL to a CloudFront distribution from any other region fails.
• REGIONAL scope — the Web ACL lives in a specific AWS region and is attached to regional resources in that same region: Application Load Balancer, API Gateway REST/HTTP API, AWS AppSync GraphQL API, Amazon Cognito user pool, AWS App Runner service, AWS Verified Access instance.

A common candidate mistake: protecting a CloudFront distribution by creating a regional Web ACL in us-west-2 because that is where the origin lives. That Web ACL cannot attach to CloudFront. The fix is always: CloudFront → CLOUDFRONT scope in us-east-1. Origins behind the CloudFront distribution can have their own regional Web ACL on the ALB if defense-in-depth is required.

Attachment points and what each protects

A single Web ACL can be attached to multiple resources of the same scope in the same region (e.g., one Web ACL on every ALB in ap-southeast-1). That is the operational pattern Firewall Manager enforces at organization scale.

Default action and rule evaluation flow

A Web ACL has a default action — Allow or Block — that applies when no rule produces a terminating action. Rules are evaluated in priority order (lower number = higher priority). For each rule:

1. The rule statement is evaluated against the request.
2. If the statement matches and the action is Allow or Block, evaluation stops — the request is allowed or blocked.
3. If the action is Count, evaluation continues to the next rule but the match is recorded in metrics and logs.
4. If the action is CAPTCHA or Challenge, evaluation may be paused while the puzzle/silent challenge is presented; on success the request continues; on failure it is blocked.
5. If no rule matches a terminating action, the Web ACL's default action applies.

Web ACL Capacity Units (WCU)

Every WAF rule has a WCU cost based on its complexity — a simple IP-set match is 1 WCU, a regex pattern match is 25–35 WCU, a managed rule group declares a fixed WCU cost (typically 25–700 depending on the group). A Web ACL has a hard cap of 1,500 WCU by default, raisable to 5,000 WCU via a quota increase request. If you try to add a rule that pushes the total above the cap, the API rejects the change.

For SysOps, this means rule design matters. A Web ACL with three managed rule groups at 700 WCU each will not fit. The operational pattern is: pick one core managed rule group, add specific custom rules that target your application, and reserve the rest of the budget for rate-based rules and IP allow/deny lists.

Managed Rule Groups — AWS Managed and Marketplace

A managed rule group is a pre-built bundle of rules maintained by AWS or an AWS Marketplace seller. It saves the SysOps engineer from having to write SQL injection or cross-site scripting rules from scratch and is updated automatically by the publisher as new threats emerge.

AWS Managed Rule Groups — the core baseline

AWS publishes free and paid managed rule groups under the AWS vendor name in the WAF console. The most exam-relevant ones:

• Core rule set (AWSManagedRulesCommonRuleSet) — the OWASP Top 10 baseline. Covers cross-site scripting, local file inclusion, generic bad inputs, and similar broad categories. WCU: 700. The first managed rule group most operators add.
• Known bad inputs (AWSManagedRulesKnownBadInputsRuleSet) — patterns observed exploiting real vulnerabilities (Log4Shell, Spring4Shell, etc.). WCU: 200. Updated frequently as new CVEs surface.
• Amazon IP reputation list (AWSManagedRulesAmazonIpReputationList) — IPs Amazon's threat intel sees attacking other AWS customers. WCU: 25. Cheap and high-signal; almost always worth including.
• Anonymous IP list (AWSManagedRulesAnonymousIpList) — Tor exit nodes, public proxies, hosting-provider IPs that should not normally browse a public website. WCU: 50. Useful for consumer apps; risky for B2B that may legitimately have hosting-provider clients.
• SQL database (AWSManagedRulesSQLiRuleSet) — focused SQL injection patterns beyond the core set. WCU: 200.
• Linux operating system (AWSManagedRulesLinuxRuleSet) — local file inclusion and command injection patterns. WCU: 200.
• POSIX operating system (AWSManagedRulesUnixRuleSet) — POSIX-style command injection. WCU: 100.
• Windows operating system (AWSManagedRulesWindowsRuleSet) — PowerShell and Windows-specific patterns. WCU: 200.
• PHP application (AWSManagedRulesPHPRuleSet) — PHP-specific exploits. WCU: 100.
• WordPress application (AWSManagedRulesWordPressRuleSet) — WordPress-specific paths. WCU: 100.
• Bot Control (AWSManagedRulesBotControlRuleSet) — paid managed rule group; see Bot Control section below. WCU: 50 (Common) or 500 (Targeted).
• ATP — Account Takeover Prevention (AWSManagedRulesATPRuleSet) — paid; protects login endpoints from credential stuffing. WCU: 50.
• ACFP — Account Creation Fraud Prevention (AWSManagedRulesACFPRuleSet) — paid; protects sign-up endpoints from fake account creation. WCU: 50.

Marketplace rule groups

AWS Marketplace sellers (Fortinet, F5, Imperva, Cyber Security Cloud, etc.) publish their own managed rule groups under their vendor names. Pricing is per-Web-ACL per-month plus per-request charges. SOA-C02 does not test specific Marketplace vendors, but it does expect awareness that they exist as an alternative to AWS-managed and customer-managed rules.

Rollout strategy — always Count first

The exam-key operational pattern for any new managed rule group:

1. Add the group to the Web ACL in Count mode (override every rule action to Count).
2. Run for several days of representative traffic.
3. Review WAF logs and the WAF console's Sampled requests tab to identify legitimate traffic that would have been blocked.
4. Add scope-down statements or rule overrides to exclude false positives.
5. Promote the group to its default actions (Block).

Skipping the Count phase is a very common cause of production incidents — a brand-new managed rule group blocks the company's own admin panel because some path matches a rule, and customer support fields complaints all afternoon.

Rule Actions — Allow, Block, Count, CAPTCHA, Challenge

The five actions a WAF rule can take are operationally distinct, and SOA-C02 tests each one's behavior.

Allow

Allow is terminating — evaluation stops immediately. Use Allow for trusted partner IPs (a payment processor's IP range), known good crawlers (Google, Bing) that you want to bypass managed rules, or admin tooling endpoints accessed only from your office.

Block

Block is terminating — evaluation stops, the request is rejected with HTTP 403 (or a customizable response). Use Block for confirmed bad traffic — known malicious IPs, requests matching managed-rule signatures, or rate-limited sources.

Count

Count is non-terminating — the match is recorded in CloudWatch metrics and WAF logs but the request continues evaluation. Use Count for any rule under evaluation before promoting to Block, or for permanent observability rules ("count requests with no User-Agent header" as a metric to graph). A Count override on a managed rule group puts every rule in the group into Count mode regardless of its default action.

CAPTCHA

CAPTCHA presents the user with a visual puzzle to prove they are human. On success, an immunity token is set as a cookie that bypasses CAPTCHA on subsequent requests for a configurable duration (default 5 minutes, up to 11 hours). On failure or absence of the token, the request is blocked. Use CAPTCHA on flows that are valuable to bots but tolerable for humans to complete occasionally — login pages, sign-up pages, contact forms.

Challenge

Challenge is the silent cousin of CAPTCHA: a JavaScript-based browser fingerprint check runs in the user's browser and produces a token. The user never sees a puzzle. Real browsers pass automatically; headless scrapers and HTTP libraries usually fail. Challenge is more user-friendly than CAPTCHA but only effective against unsophisticated bots. The same immunity token mechanism applies.

Rate-Based Rules — IP and Aggregate Key Type

A rate-based rule tracks request counts per aggregation key over a 5-minute sliding window and applies an action (Block, Count, CAPTCHA, Challenge) to keys that exceed a configured threshold. The threshold is the maximum requests allowed in 5 minutes per aggregation key.

Aggregate key types

• IP — aggregates by source IP address as seen by the WAF (the public IP of the requester or the connecting CDN/load balancer).
• Forwarded IP — aggregates by an IP from an HTTP header (typically X-Forwarded-For), useful when traffic comes through a trusted proxy and the real client IP is in the header. Requires an IP fallback behavior if the header is absent.
• HTTP header — aggregates by the value of any header (User-Agent, Authorization, custom).
• HTTP method — aggregates by HTTP verb.
• Query string / query argument — aggregates by the entire query string or a single argument.
• Cookie — aggregates by cookie value (e.g., session cookie).
• Label namespace — aggregates by a label generated by another rule earlier in the Web ACL.
• Custom keys (combination) — combine up to five of the above into a composite key (forwarded IP + URI path to rate-limit per-IP-per-endpoint).

Choosing the right aggregate key

• Public website with no auth: IP or Forwarded IP. Threshold tuned to typical browsing rate (a human reads 10–30 pages in 5 minutes; 2,000+ in 5 minutes is almost certainly a script).
• API behind API Gateway with API keys: HTTP header (x-api-key) or Authorization header — rate-limit per API key, not per IP, because legitimate clients often share NAT.
• Login endpoint: Forwarded IP at a low threshold (100 requests in 5 minutes is plenty for a login page; 1,000 is credential stuffing).
• Mobile app behind load balancer: Cookie or custom header, because corporate NAT or carrier-grade NAT means thousands of legitimate users share an IP.

Scope-down statements

A rate-based rule can include a scope-down statement that limits which requests the counter sees. Common patterns:

• "Rate-limit only POST requests to /login" (URI path AND method scope-down).
• "Rate-limit only requests missing an API key header" (header absent scope-down).
• "Rate-limit only requests from outside our office IP range" (NOT IP set scope-down).

Scope-down is essential for keeping the rate-based rule narrow enough that its threshold makes sense for the targeted traffic.

Operational tuning

The first deployment of a rate-based rule should always be in Count mode for at least a week. Watch the CloudWatch CountedRequests metric, identify the legitimate traffic peak, set the threshold at 2x to 3x that peak, and only then promote to Block. SOA-C02 routinely tests this.

Bot Control — Mitigating Automated Traffic

AWS WAF Bot Control is a paid AWS managed rule group that classifies incoming requests as human or bot and labels each request with a bot category. It is the right tool for SOA-C02 questions about scrapers, scanners, and credential stuffing.

Two protection levels

• Common (default) — uses request signature analysis (User-Agent, header order, JA3 TLS fingerprint, behavioral signals) to identify and label common bots. WCU: 50. Suitable for most public web sites.
• Targeted — adds active challenges (silent browser fingerprint plus immunity tokens) to detect sophisticated bots that mimic real browsers. WCU: 500. Required for high-value flows under bot pressure (login, sign-up, checkout).

Bot categories

Bot Control labels requests with categories the WAF rule can act on:

• bot:category:search_engine — Google, Bing, etc. Verified by reverse DNS and AS number. Usually allowed.
• bot:category:social_media — Facebook, Twitter previewers. Usually allowed.
• bot:category:monitoring — Pingdom, Datadog synthetic monitors. Usually allowed.
• bot:category:scraping_framework — Scrapy, Puppeteer, Playwright. Usually blocked or challenged.
• bot:category:http_library — curl, wget, requests, axios. Usually blocked or challenged.
• bot:category:ai_crawler — OpenAI GPTBot, Anthropic ClaudeBot, etc. Allow or block based on policy.
• bot:unverified — claims to be a verified bot but failed verification. Block.
• bot:name:<specific> — labels for specific bot names.

Operational pattern

Add the Bot Control managed rule group to the Web ACL. Set the default group action to Count for a week. Review which bot categories appear in your traffic. Decide which to allow (search engines, social media, monitoring), which to challenge (AI crawlers, unverified), and which to block (scraping frameworks, http libraries, known-bad). Then override actions per category and promote.

AWS Shield Standard — Always-On L3/L4 Protection

AWS Shield Standard is the free, automatic, always-on Layer 3 and Layer 4 DDoS protection that every AWS customer gets at no charge.

What Shield Standard covers

• Network-layer (Layer 3) attacks — UDP reflection, NTP amplification, DNS amplification, ICMP flood.
• Transport-layer (Layer 4) attacks — SYN flood, ACK flood, TCP reset flood, fragmented packets.
• Common volumetric attacks — Shield's edge mitigation absorbs traffic at the AWS network perimeter before it reaches your origins.

Where Shield Standard runs

Shield Standard mitigations run at the AWS edge (CloudFront, Route 53 edge locations, AWS Global Accelerator). It also protects elastic IP addresses on EC2 and the regional perimeter for ALB/NLB/CLB. Shield Standard requires zero operator action — it is on by default for every account.

What Shield Standard does NOT cover

Shield Standard does not mitigate Layer 7 (application-layer) attacks — HTTP floods, slowloris, application logic abuse. For that you need either AWS WAF (DIY, with rate-based rules and managed rule groups) or AWS Shield Advanced.

AWS Shield Advanced — Paid Protection Plus the SRT

AWS Shield Advanced is the opt-in tier that adds Layer 7 protection, the Shield Response Team, DDoS cost protection, and detailed visibility — for $3,000 per month per AWS organization with a 1-year commitment, plus data transfer charges for protected resources.

Protected resource types

You explicitly enroll resources into Shield Advanced protection. Eligible resource types:

• Amazon CloudFront distributions
• Amazon Route 53 hosted zones
• AWS Global Accelerator standard accelerators
• Application Load Balancers
• Classic Load Balancers
• Elastic IP addresses (protecting EC2, NLB)

A common SOA-C02 framing: "the company needs DDoS protection for an ALB-fronted application; Shield Advanced is approved" — the configuration step is to enroll the ALB as a Shield Advanced protected resource (via the Shield console or via Firewall Manager Shield policy).

Shield Response Team (SRT)

The Shield Response Team (formerly DDoS Response Team / DRT) is a 24/7 AWS engineering team you can engage during an active attack:

• Open a Shield support case (Business or Enterprise support plan required for SRT engagement).
• The SRT can write custom WAF rules directly in your Web ACL during an attack.
• The SRT can advise on architecture changes (caching policy, origin shielding, geo restriction) to mitigate sophisticated attacks.
• You pre-authorize SRT access to your AWS WAF and Shield Advanced configuration via an IAM role.

DDoS Cost Protection

When a Shield Advanced protected resource is under DDoS attack and the attack causes scaling-related charges (CloudFront data transfer-out, EC2/ALB scale-out, Route 53 query volume), AWS credits those charges back. The credit is granted after the SRT validates the event was a DDoS. This benefit alone often justifies the $3,000/month for high-traffic sites.

Health-based detection

Shield Advanced can use Route 53 health checks to feed application health into its detection algorithm. A failing health check tells Shield "the application is unhealthy now" and lowers the detection threshold for declaring an attack, reducing false positives and improving response time on borderline events.

Layer 7 automatic mitigation

For CloudFront and ALB, Shield Advanced can automatically generate WAF rules during a Layer 7 DDoS attack — observing the attack pattern and producing rules to block it without operator intervention. You enable this per protected resource and review/approve each generated rule.

AWS Firewall Manager — Org-Wide Policy Enforcement

AWS Firewall Manager is the Organizations-integrated central management plane for WAF, Shield Advanced, security groups, Network Firewall, and DNS Firewall. It exists because in a 50-account AWS Organization, ensuring every account has the same baseline WAF Web ACL is operationally impossible without a control-plane service.

Prerequisites

Firewall Manager has strict prerequisites — every SOA-C02 candidate must memorize them:

1. AWS Organizations is enabled with all features (not consolidated billing only).
2. A Firewall Manager administrator account is designated (can be the management account, but AWS recommends a delegated admin).
3. AWS Config is enabled in every member account in every region where Firewall Manager will operate.
4. The administrator account is subscribed to AWS Shield Advanced if Shield Advanced policies will be created.
5. For Network Firewall and DNS Firewall policies, those services must be available in the target regions.

If any prerequisite is missing, Firewall Manager either refuses to create the policy or silently fails to apply it to non-compliant accounts.

Policy types

• WAF policy — defines a Web ACL with managed and custom rules; Firewall Manager creates the Web ACL in every in-scope account/region and attaches it to specified resources (CloudFront, ALB, API Gateway, etc.).
• WAF Classic policy — legacy; do not use for new deployments.
• Shield Advanced policy — enrolls specified resource types as Shield Advanced protected resources across the organization.
• Security group policy — three sub-types:
  • Common policy — pushes a baseline security group into every VPC.
  • Audit policy — flags non-compliant security group rules without modifying them.
  • Usage audit policy — flags unused or redundant security groups.
• Network Firewall policy — deploys an AWS Network Firewall with a specified rule set into every in-scope VPC.
• DNS Firewall policy — applies Route 53 Resolver DNS Firewall rule groups to every in-scope VPC.
• Palo Alto Networks Cloud NGFW policy — third-party integration.

Scope and exclusions

A policy specifies its scope — which accounts (all in the org, specific OUs, or excluding specific accounts) and which resources within those accounts (by tag, resource type, or all). Common patterns:

• "Apply this Web ACL to every ALB in production OUs, except accounts tagged Environment=Sandbox."
• "Apply this Shield Advanced policy to every CloudFront distribution in any account."
• "Apply this baseline security group to every VPC in every account in the Audit OU."

Auto-remediation

Firewall Manager policies can be configured for auto-remediation — when a non-compliant resource is detected (e.g., a new ALB without the required Web ACL), Firewall Manager automatically attaches the Web ACL. Alternatively, the policy can run in audit-only mode to surface non-compliance to operators without modifying configurations.

AWS Network Firewall vs AWS WAF — Layer 3/4 vs Layer 7

This is the single most important conceptual distinction in this topic, and SOA-C02 tests it directly with at least one question per attempt.

AWS WAF — Layer 7 web traffic only

AWS WAF inspects HTTP and HTTPS requests — the URL, headers, body, query string. It is attached to layer-7-aware AWS services — CloudFront, ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access. It does not inspect non-HTTP protocols, raw TCP/UDP packets, or VPC-internal traffic.

AWS Network Firewall — Layer 3/4 (and limited L7) for VPC traffic

AWS Network Firewall is a stateful firewall service deployed inside a VPC. Traffic is routed through a dedicated firewall subnet in each Availability Zone (typically inserted between an internet gateway / Transit Gateway and the workload subnets via routing). It inspects:

• Layer 3 — source/destination IP, protocol.
• Layer 4 — TCP/UDP ports, connection state.
• Layer 7 (limited) — Suricata-compatible rules can match on HTTP method, URI, TLS SNI, and a subset of application protocols.

Network Firewall is the right choice when you need east-west VPC inspection, non-HTTP protocol filtering, outbound URL/domain allow-listing for compliance, or TLS SNI-based filtering for outbound traffic.

Decision matrix — which service for which need

Amazon GuardDuty — Network Findings

Amazon GuardDuty is an account-wide threat detection service that continuously analyzes VPC Flow Logs, DNS query logs, CloudTrail events, EKS audit logs, and S3 data events to surface threats. Among its dozens of finding types, the network-related ones overlap directly with this topic.

Network finding categories

• Recon:EC2/Portscan — an EC2 instance is scanning a wide range of ports on another host. Indicates either a compromised instance scanning the internet or an instance scanning your own VPC.
• Recon:EC2/PortProbeUnprotectedPort — a known-malicious actor probed an unprotected port on an EC2 instance. Highlights instances exposing unintended ports to the internet.
• UnauthorizedAccess:EC2/SSHBruteForce — repeated failed SSH login attempts from an IP. The runbook is to harden the security group, switch to Session Manager, or apply Shield/WAF/Network Firewall blocks.
• UnauthorizedAccess:EC2/RDPBruteForce — same pattern for Windows RDP.
• Backdoor:EC2/C&CActivity.B!DNS — an EC2 instance's DNS queries match a known command-and-control domain. Strong signal of compromise.
• CryptoCurrency:EC2/BitcoinTool.B!DNS — an EC2 instance is querying DNS for known cryptocurrency mining pools.
• Trojan:EC2/DNSDataExfiltration — DNS queries with large encoded payloads, suggesting data exfiltration over DNS.
• UnauthorizedAccess:EC2/MaliciousIPCaller.Custom — an EC2 instance is communicating with an IP on a custom threat list you uploaded.
• Impact:EC2/PortSweep — an EC2 instance scanned many remote ports across many hosts.

Operational response

The standard SOA-C02 response pattern for a high-severity GuardDuty network finding:

1. Quarantine — apply a "deny all" security group to the affected instance to stop further communication.
2. Snapshot — capture an EBS snapshot for forensics.
3. Investigate — review VPC Flow Logs, CloudTrail, and the instance's Systems Manager inventory.
4. Remediate — terminate the instance and replace from a clean AMI; rotate any credentials.
5. Hunt — search VPC Flow Logs for similar activity from other instances.

This response can be automated with EventBridge rule on aws.guardduty finding event source → Lambda or Systems Manager Automation that performs steps 1 and 2 immediately, paging the security team while the SOC investigates.

WAF Logging — S3, CloudWatch Logs, and Firehose

WAF can log every inspected request to one of three destinations, and SOA-C02 tests the right pick for each operational need.

Destinations

• Amazon S3 bucket — cheap long-term storage; use Athena for ad-hoc queries. Best for compliance retention.
• Amazon CloudWatch Logs — interactive query via Logs Insights; alarm on metric filters. Best for real-time operations and dashboards.
• Amazon Kinesis Data Firehose — stream to Splunk, Datadog, OpenSearch, or any third-party SIEM. Best for SIEM integration.

You can pick exactly one destination per Web ACL (or use Firehose to fan out to multiple). Logs include rule that matched, action taken (Allow/Block/Count/CAPTCHA/Challenge), source IP, request URI, headers, and labels.

Common log analysis patterns

• Identify false positives: filter logs for action=BLOCK, group by terminatingRuleId, look for managed-rule blocks on legitimate paths.
• Top blocked IPs: aggregate by httpRequest.clientIp where action=BLOCK.
• Bot Control category breakdown: aggregate by labels containing bot:category:*.
• Rate-based rule effectiveness: count action=BLOCK for the rate-based rule and graph against the threshold.

Sampled requests

Even without full logging enabled, the WAF console offers sampled requests — a 5-minute random sample of requests inspected by each rule, displayed inline. Useful for quick troubleshooting but not a substitute for full logging during incident response.

AWS Global Accelerator and DDoS Protection

AWS Global Accelerator uses the AWS global network and two static anycast IP addresses to route user traffic into the nearest AWS edge location and onward to your origins. It includes Shield Standard automatically and integrates with Shield Advanced as a protected resource.

Why Global Accelerator helps DDoS posture

• Traffic enters the AWS network at the nearest edge, where Shield Standard absorbs volumetric attacks.
• The two static anycast IPs are stable across regions and across origin failover, simplifying customer firewall allow-lists.
• Global Accelerator's health checks fail over between origins automatically, isolating regional incidents.
• Pairs naturally with Shield Advanced for L7 detection plus DDoS cost protection.

For SOA-C02, Global Accelerator is the right answer when the scenario asks for "static IPs that customers can allow-list, multi-region failover, and DDoS protection at the edge" — particularly for non-HTTP workloads (game servers, IoT) that cannot use CloudFront.

Scenario Pattern: Legitimate User Blocked by Rate-Based Rule

This is the canonical SOA-C02 false-positive scenario. The runbook:

1. Confirm the block in WAF logs. Run a Logs Insights query against the WAF log group filtering by the user's IP and recent timeframe. Identify the terminatingRuleId — it should be the rate-based rule.
2. Identify the root cause. Check whether the user is behind corporate NAT (one IP, many users) or a residential ISP CGNAT.
3. Choose the right fix:
   • Switch aggregate key type to Forwarded IP if the application sits behind a CDN or load balancer that sets X-Forwarded-For.
   • Add an Allow rule for the partner's IP range at higher priority than the rate-based rule — bypasses rate limiting for known good sources.
   • Switch aggregate key to a session cookie or API key to rate-limit per user rather than per IP.
   • Add a scope-down statement to narrow the rate-based rule to specific URI paths (e.g., only /login) so general browsing is not counted.
   • Raise the threshold based on the new traffic baseline observed in the rule's CloudWatch CountedRequests metric.
4. Verify the fix. Replay the user's traffic pattern and confirm no Block. Promote any new Allow rules to production.
5. Do not disable the rule entirely. The rate-based rule is the DDoS protection — disabling it removes that protection. Always tune, never delete.

The wrong answers on the exam are usually "remove the rate-based rule" or "set the threshold to 1,000,000". The right answers tune the aggregation, scope, or priority.

Scenario Pattern: Shield Advanced Alert — DDoS in Progress

The on-call gets a Shield Advanced alarm at 2am: "DDoSDetected on CloudFront distribution dXXX". The runbook:

1. Open the Shield Advanced console. The "Events" tab shows attack vectors (UDP reflection, TCP SYN, HTTP flood), peak bandwidth/RPS, and the protected resource.
2. Check application health. CloudWatch dashboard for ALB target response time, 5xx rate, and CloudFront cache hit ratio. If origin is saturated, scale out (Auto Scaling) and increase CloudFront cache TTL temporarily.
3. Engage the Shield Response Team. Open a Shield support case (Business or Enterprise support required). The SRT can write WAF rules in real time during the attack.
4. Apply mitigations:
   • For L3/L4: Shield Standard/Advanced absorb volumetric automatically.
   • For L7 HTTP flood: WAF rate-based rule (lower threshold temporarily), Bot Control Targeted, geo-block known attacker regions.
   • For credential-stuffing-style L7: WAF Challenge action on login endpoint.
5. Activate Shield Advanced automatic L7 mitigation if not already enabled — Shield will auto-generate WAF rules during the attack.
6. Monitor DDoS Cost Protection — the credit appears post-incident on the AWS bill after SRT validates the event.
7. Post-incident: review the Shield event report, document the mitigation, update the runbook, possibly upgrade rate-based rule thresholds permanently.

Common Trap: WAF Scope CLOUDFRONT Must Be us-east-1

A canonical SOA-C02 trap. A team in ap-southeast-1 builds a WAF Web ACL in their region and tries to attach it to a CloudFront distribution. The console refuses. The fix is always: CloudFront-scope Web ACLs live in us-east-1. The Web ACL itself is global (the rule evaluation happens at every CloudFront edge worldwide), but the configuration plane is us-east-1. Regional Web ACLs in any other region can attach only to regional resources (ALB, API Gateway, etc.) in the same region.

If the architecture needs both — CloudFront protection AND ALB protection — you create two Web ACLs: one CLOUDFRONT-scope in us-east-1 attached to CloudFront, and one REGIONAL-scope in the ALB's region attached to the ALB. They can share custom rule groups but not the Web ACL itself. Firewall Manager can manage both with two separate WAF policies (one for each scope).

Common Trap: Shield Advanced Costs $3,000/Month — Justify Before Recommending

Shield Advanced is $3,000 per month per AWS organization (not per account, not per resource), with a 1-year commitment. SOA-C02 questions sometimes recommend Shield Advanced as the "obvious" answer for any DDoS scenario, but the right answer often is "WAF rate-based rules + AWS Managed Rule Groups" because Shield Standard already covers L3/L4 for free.

Shield Advanced is the right answer when:

• The application is mission-critical and downtime cost exceeds $36,000/year.
• The DDoS Cost Protection benefit pays for the subscription on its own (high CloudFront data transfer or Route 53 query volume).
• The customer needs SRT engagement during attacks (SOC team without 24/7 DDoS expertise).
• Multiple resources will benefit from the org-wide subscription (CloudFront + ALB + Route 53).

Shield Advanced is NOT necessary when:

• The application is internal or low-criticality.
• Shield Standard + WAF + Bot Control already meets the threat model.
• Budget is constrained and DDoS risk is low.

Common Trap: Firewall Manager Requires Organizations

Firewall Manager only works under AWS Organizations with all features enabled. Standalone accounts cannot use Firewall Manager. Organizations with consolidated billing only (legacy mode) cannot use Firewall Manager. The administrator account designation must be done explicitly. AWS Config must be enabled in every member account in every target region.

If the SOA-C02 scenario says "we want to deploy a baseline WAF Web ACL to 50 standalone AWS accounts" — the correct answer is "first move them into an AWS Organization, then enable Firewall Manager". You cannot bypass this prerequisite.

Common Trap: AWS Network Firewall Is Not AWS WAF

This trap was covered in the decision matrix but deserves its own callout: candidates routinely choose AWS Network Firewall when the scenario calls for AWS WAF, and vice versa, because both contain "firewall" in the name.

• AWS WAF: Layer 7 web traffic, attached to managed AWS endpoints (CloudFront, ALB, API Gateway). HTTP/HTTPS only.
• AWS Network Firewall: Layer 3/4 (with limited L7) for VPC traffic, deployed in a firewall subnet with explicit routing. All protocols.

If the scenario mentions inspecting HTTP request bodies or rate-limiting per user, it is WAF. If the scenario mentions filtering outbound DNS, blocking specific TLS SNI values, or inspecting east-west VPC traffic, it is Network Firewall.

SOA-C02 vs SAA-C03: The Operational Lens

SAA-C03 and SOA-C02 both test WAF, Shield, and network protection, but the framing differs sharply.

The SAA candidate selects services and architectures; the SOA candidate configures, troubleshoots, and operates them — false positives, rule tuning, attack response, and policy enforcement gaps.

Exam Signal — How to Recognize a TS 5.1 WAF/Shield Question

Domain 5 Task Statement 5.1 questions on SOA-C02 follow predictable shapes once you have seen them.

• "Legitimate users are blocked" — false-positive tuning. Look at scope-down, aggregate key type, Allow rules at higher priority, and Count-mode rollout strategy.
• "DDoS in progress / attack detected" — Shield Advanced runbook with SRT, automatic L7 mitigation, and CloudFront cache-burning under attack.
• "Need to enforce same WAF on every account" — Firewall Manager WAF policy. Always verify Organizations + Config prerequisites are mentioned in the scenario.
• "Inspect outbound traffic from EC2 to specific domains" — AWS Network Firewall, not AWS WAF. The Layer 7 check on TLS SNI / HTTP Host is Network Firewall's stateful Suricata rules.
• "Slow down credential stuffing on login" — WAF Bot Control Targeted with Challenge or CAPTCHA on the login endpoint, plus rate-based rule on forwarded IP with a low threshold.
• "Block known-bad IPs across all accounts" — Firewall Manager WAF policy that includes AWSManagedRulesAmazonIpReputationList plus a custom IP set.
• "Detect a compromised EC2 instance" — GuardDuty network finding (C&C, port scan, exfiltration) + EventBridge → Lambda quarantine workflow.
• "WAF rules added but not affecting traffic" — verify the Web ACL is associated with the resource, verify scope (CLOUDFRONT vs REGIONAL), verify rule priority (something earlier may Allow before the new rule fires), verify rule is not in Count mode.

Decision Matrix — Network Protection Construct for Each SysOps Goal

Use this lookup during the exam.

Common Traps Recap — WAF, Shield, and Network Protection

Every SOA-C02 attempt encounters several of these distractors.

Trap 1: CloudFront WAF in the wrong region

CloudFront-scope Web ACLs live in us-east-1 only. Always.

Trap 2: Shield Advanced as the default DDoS answer

Shield Standard (free) covers L3/L4 already. Shield Advanced costs $3,000/month and a 1-year commitment — justify by SRT need, DDoS Cost Protection economics, or critical-tier downtime cost.

Trap 3: Network Firewall is not WAF, WAF is not Network Firewall

Different layers, different deployment models, different use cases. Read the scenario for HTTP vs non-HTTP and edge vs VPC.

Trap 4: Firewall Manager without Organizations

Firewall Manager requires AWS Organizations all features + AWS Config in every member account + a designated administrator account. Standalone accounts cannot use Firewall Manager.

Trap 5: Rate-based rule blocking corporate NAT

One IP can represent thousands of users. Switch to forwarded IP, header, or cookie aggregation; add scope-down to narrow the rule; or add an Allow rule for known partners.

Trap 6: Rule priority misunderstood

Lower number = higher priority. First terminating action (Allow or Block) wins. Count never terminates. Adding a new rule at priority 100 does not override an existing Allow at priority 10.

Trap 7: New managed rule group set to Block on day one

Always Count mode first. Run for a week. Review sampled requests and logs. Promote rule-by-rule.

Trap 8: Disabling a rule because of a false positive

Tune, do not disable. The disabled rule no longer blocks the actual attack tomorrow.

Trap 9: GuardDuty as a blocking layer

GuardDuty detects, it does not block. Pair with EventBridge → Lambda or SSM Automation for automated response.

Trap 10: WAF body inspection size limit

Default body inspection size is 8 KB on regional resources, 16 KB on CloudFront, raisable to 64 KB on CloudFront. Large payloads pass through uninspected unless you raise the limit (extra WCU cost). Sophisticated attackers know this and pad payloads to bypass.

Trap 11: WCU cap on Web ACL

1,500 WCU default, 5,000 with quota increase. A Web ACL with three large managed rule groups will not fit. Plan rule budget.

Trap 12: NLB cannot have WAF attached directly

WAF works on ALB, not NLB. To protect non-HTTP traffic on NLB, use Shield Standard/Advanced + Network Firewall + security groups + GuardDuty.

FAQ — WAF, Shield, and Network Protection

Q1: How do I roll out a new managed rule group without breaking production?

Always start in Count mode. When adding AWSManagedRulesCommonRuleSet to a Web ACL, set the override action on every rule in the group to Count. Run for at least one week of representative traffic — including a weekend so you cover the full traffic mix. Watch CloudWatch WAF metrics (CountedRequests per rule) and review WAF logs in Logs Insights. Identify any legitimate paths that match — typical false positives include admin endpoints with unusual query strings, file upload endpoints with multipart bodies, and webhook receivers from third parties. For each false positive, either add a scope-down statement to exclude the path, add a higher-priority Allow rule for the source, or override that specific rule to Count permanently. Only after the false-positive set is stable do you promote the group to its default Block actions, ideally rule-by-rule rather than group-wide. This rollout takes 2–4 weeks for a busy production app and is the operational standard expected on SOA-C02.

Q2: My rate-based rule is blocking real customers — how do I fix it without losing protection?

Do not disable the rule. The rate-based rule still defends against the actual DDoS attack. Instead, identify the false-positive root cause via WAF logs (filter by action=BLOCK and the terminatingRuleId of the rate-based rule) and apply one of four fixes. (a) Switch the aggregate key type from IP to FORWARDED_IP if traffic comes through a CDN/load balancer that sets X-Forwarded-For, so the per-NAT-IP false positives become per-real-client-IP. (b) Add a scope-down statement to narrow the rule — only count POST /login requests, not all browsing. (c) Add a high-priority Allow rule for the partner's IP range that bypasses the rate-based rule entirely. (d) Raise the threshold based on the new traffic baseline observed in the rule's CountedRequests metric. The most common SOA-C02 scenario favors (a) plus (b) together — switch to forwarded IP and narrow to the abused endpoint.

Q3: When should I choose Shield Advanced over WAF + Shield Standard?

Shield Advanced is justified when at least one of the following applies. Mission-critical downtime cost exceeds $36,000/year (the annual subscription cost), making Shield Advanced cheaper than the next outage. DDoS Cost Protection economics: applications with high CloudFront data transfer-out or large Route 53 query volumes get scaling-charge credits during attacks, often paying for the subscription. SRT engagement is required because the SOC lacks 24/7 DDoS response expertise. Layer 7 automatic mitigation is needed — Shield Advanced auto-generates WAF rules during attacks on protected CloudFront/ALB resources. Health-based detection is needed — Shield Advanced uses Route 53 health checks to lower detection thresholds during application stress. For everything else — internal apps, low-criticality services, budget-constrained teams — WAF rate-based rules + AWS Managed Rule Groups + Bot Control + Shield Standard (free) is the right answer. SOA-C02 frequently offers Shield Advanced as a tempting distractor; only choose it when the scenario explicitly calls out one of these justifications.

Q4: How does Firewall Manager differ from manually creating Web ACLs in each account?

Firewall Manager provides three things manual creation cannot. Centralized policy definition — one policy in the FM admin account becomes Web ACLs in 50 member accounts automatically; no per-account scripting. Continuous compliance enforcement — when a developer in a member account creates a new ALB without the required Web ACL, FM detects the non-compliant resource within hours and (with auto-remediation) attaches the policy-defined Web ACL. Audit visibility across the org — the FM console surfaces non-compliant resources by account/region, which manual creation cannot. The cost is the FM prerequisites: AWS Organizations all features, an FM administrator account, AWS Config in every member account in every target region, and per-policy charges from FM itself. For a 5-account org, manual creation may still be cheaper. For a 50+ account org, FM is operationally mandatory. SOA-C02 expects you to recommend FM whenever the scenario implies multi-account scope.

Q5: How do I tell whether to use AWS WAF or AWS Network Firewall for a given problem?

The deciding factor is layer and protocol. AWS WAF is a Layer 7 HTTP/HTTPS service attached to managed AWS endpoints — CloudFront, ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access. It inspects the URL, headers, body, and query string of HTTP requests. AWS Network Firewall is a Layer 3/4 (with limited Layer 7) all-protocol service deployed inside a VPC in a firewall subnet, with explicit routing through it. It inspects packets at IP/port/protocol level and supports stateful Suricata rules for limited application-layer matching (TLS SNI, HTTP Host header, DNS query patterns). If the scenario describes inspecting HTTP request bodies, rate-limiting per user, or attaching protection to an ALB, it is WAF. If the scenario describes filtering outbound DNS queries from EC2, allow-listing specific domains for compliance, inspecting east-west VPC traffic, or blocking non-HTTP protocols, it is Network Firewall. Many production architectures use both — WAF at the edge for HTTP, Network Firewall in the VPC for east-west and outbound — and SOA-C02 sometimes asks you to recognize that a complete answer requires both.

Q6: What is the difference between CAPTCHA and Challenge actions, and when do I use each?

Both actions present an immunity token mechanism: on success, a cookie is set that bypasses the action for a configurable duration (default 5 minutes, max 11 hours). The user-facing experience is what differs. CAPTCHA presents a visible puzzle — typically AWS's own picture-recognition puzzle. The user sees a popup and must complete it. CAPTCHA is effective against most bots including sophisticated ones, but creates noticeable user friction. Challenge runs a silent JavaScript browser fingerprint check. The user sees nothing — real browsers complete the challenge automatically and the request continues. Bots without a real JavaScript engine fail silently and the request is blocked. Challenge has zero user friction but is only effective against unsophisticated bots; sophisticated browser-automation tools like Playwright with stealth plugins can pass Challenge. The exam pattern: start with Challenge on flows where any user friction is unacceptable (homepage browsing, search). Promote to CAPTCHA on high-value flows under sophisticated bot pressure (login, sign-up, checkout). Reserve Block for confirmed-bad traffic where no human should ever appear.

Q7: How do I respond to a GuardDuty network finding indicating a compromised EC2 instance?

The standard runbook has five steps. (1) Quarantine — apply a security group with no inbound or outbound rules to the instance immediately. This stops further communication while preserving the instance for forensics. (2) Snapshot — capture an EBS snapshot of every volume on the instance for offline analysis. (3) Investigate — review VPC Flow Logs for the instance's traffic in the past 24 hours, CloudTrail for any IAM activity from the instance's role, and Systems Manager Inventory for installed software. Identify the initial access vector. (4) Remediate — terminate the compromised instance and replace from a clean AMI; rotate any credentials, access keys, or secrets the instance had access to. (5) Hunt — search VPC Flow Logs and GuardDuty findings across the rest of the fleet for similar IOCs (same C&C IP, same DNS query patterns) to find other compromised instances. The first two steps should be automated — an EventBridge rule on aws.guardduty events filtered to high-severity network findings triggers a Lambda or SSM Automation runbook that applies the quarantine SG and creates a snapshot, then pages the security team for steps 3–5. SOA-C02 favors this automated response over a manual checklist.

Q8: Why is my Firewall Manager policy not enforcing on three of my fifty member accounts?

Five things to check, in order. (1) AWS Config — Firewall Manager requires Config to be enabled in every target account in every target region. If Config is not enabled in the failing accounts (or in the policy's target regions within those accounts), FM cannot detect resources or enforce policy. Enable Config and wait for the inventory to populate. (2) Account exclusions — re-read the policy scope. The policy may be scoped to specific OUs and the failing accounts may not be in scope, or they may be explicitly excluded by tag or account ID. (3) Trusted access — Firewall Manager requires fms.amazonaws.com trusted access in AWS Organizations. If trusted access was disabled, FM cannot operate on member accounts. (4) Service-linked role — FM creates AWSServiceRoleForFMS in each member account; if it was deleted, FM operations fail. Recreate by re-running the FM enable step. (5) Region availability — for Network Firewall and DNS Firewall policies, the underlying service must be available in the target region; older or restricted regions may not support them. After fixing the prerequisite, force an FM policy refresh from the console; remediation typically completes within a few hours.

Q9: Where should I send WAF logs and what queries should I run during an incident?

Send WAF logs to two destinations in production. CloudWatch Logs for live querying via Logs Insights — the on-call's first tool during an incident — and S3 via Kinesis Data Firehose for long-term retention and Athena ad-hoc queries. Firehose can fan out to both. The on-call's first three Logs Insights queries during a "users blocked by WAF" incident: (a) fields @timestamp, httpRequest.clientIp, action, terminatingRuleId | filter action="BLOCK" and httpRequest.clientIp="<user IP>" | sort @timestamp desc | limit 50 — finds which rule blocked a specific user. (b) fields terminatingRuleId, count(*) as blocks | filter action="BLOCK" | stats count(*) by terminatingRuleId | sort blocks desc | limit 20 — finds the rules generating the most blocks (top false positives or top true positives). (c) fields httpRequest.clientIp, count(*) as requests | stats count(*) by httpRequest.clientIp | sort requests desc | limit 20 — finds the top request-source IPs (potential attackers or legitimate heavy users). These queries plus the WAF console's sampled-requests panel cover the vast majority of incident-response needs.

Q10: What is the cost-effective combination for a small team without Shield Advanced budget?

The pragmatic baseline for a budget-constrained team. AWS Shield Standard (free, automatic) for L3/L4 volumetric DDoS at the AWS edge — already on. AWS WAF Web ACL on CloudFront/ALB with three managed rule groups: AWSManagedRulesCommonRuleSet (OWASP Top 10 baseline), AWSManagedRulesKnownBadInputsRuleSet (recent CVE patterns), AWSManagedRulesAmazonIpReputationList (cheap, high-signal IP blocklist). Add a rate-based rule at the appropriate aggregation key for your traffic pattern — typically forwarded IP at 2,000 requests per 5 minutes for a public site, lower for sensitive endpoints. Enable WAF logging to CloudWatch Logs for live querying and to S3 for long-term storage. Configure CloudWatch alarms on WAF metrics — BlockedRequests spike, AllowedRequests drop. Add Bot Control Common if budget permits the additional managed-rule-group cost — modest fee, large benefit against scrapers and credential stuffing. This stack costs roughly $50–200/month depending on request volume and gives 80% of the protection of Shield Advanced for 5% of the cost. Upgrade to Shield Advanced only when downtime cost or DDoS Cost Protection economics justify the $3,000/month commitment.

Further Reading and Related Operational Patterns

• AWS WAF Developer Guide
• AWS WAF Web ACL Concepts
• AWS Managed Rule Groups Catalog
• Rate-Based Rule Statement Reference
• AWS WAF Bot Control
• WAF CAPTCHA and Challenge Actions
• Web ACL Capacity Units (WCU) Reference
• AWS WAF Logging
• AWS Shield Developer Guide
• Shield Standard and Shield Advanced Comparison
• Shield Response Team (SRT)
• AWS Firewall Manager Developer Guide
• Firewall Manager Prerequisites
• AWS Network Firewall Developer Guide
• Amazon GuardDuty Finding Types
• AWS Global Accelerator and DDoS Protection
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Once WAF, Shield, and network protection are in place, the next operational layers are: VPC Configuration and Connectivity for the underlying network plumbing that Network Firewall and VPC endpoints depend on, Route 53 DNS and CloudFront CDN for the edge layer where CloudFront-scope WAF lives and where Shield Advanced's L7 mitigation happens, VPC Network Troubleshooting for VPC Flow Log and ELB log analysis that complements WAF logs during incident response, and Data Protection: KMS, ACM, Secrets Manager, and Security Findings for the GuardDuty/Inspector/Security Hub layer that operates above Shield and WAF in the security-findings hierarchy.

• VPC Configuration, Subnets, NACLs, and Private Connectivity — SOA-C02 Study Notes
• Route 53 DNS, Routing Policies, and CloudFront CDN — SOA-C02 Study Notes
• Network Troubleshooting: VPC Flow Logs, ELB Logs, and Connectivity Diagnostics — SOA-C02 Study Notes
• Data Protection: KMS, ACM, Secrets Manager, and Security Findings — SOA-C02 Study Notes