WAF、Shield 與 DDoS 防護架構

為什麼 WAF、Shield 與 DDoS 防護對 ANS-C01 至關重要

DDoS 防護位於網域 1 (網路設計 — 邊緣架構) 與 網域 4 (網路安全) 的交界處。ANS-C01 考試會測試這兩個層面，因為每位 Specialty 等級的架構師都必須具備為面向公眾的工作負載設計分層防禦的能力。網域 4 中大約六分之一的問題涉及 WAF 規則架構、Shield 級別選擇或 DDoS 分層防禦，而網域 1 則有類似比例的問題涉及在 CloudFront、Global Accelerator、ALB 與 Route 53 之間選擇合適的邊緣入口點。

這份筆記是針對 ANS-C01 考試重點的 AWS WAF 與 AWS Shield 深層解析。我們涵蓋了 Web ACL 架構與範圍 (REGIONAL vs CLOUDFRONT)、受管規則群組、自訂規則與速率限制規則、Bot Control 與 ATP/ACFP、CAPTCHA 與 Challenge 動作、Shield Standard (免費、自動、L3/L4) 與 Shield Advanced (付費、主動、L7) 的區別、Shield Response Team (SRT) 的介入模式、成本保護機制、分層 DDoS 防禦模式、用於全組織 WAF 策略的 AWS Firewall Manager，以及與 CloudFront、ALB、API Gateway 與 Global Accelerator 的營運整合。

我們在結尾提供常見問題 (FAQ)、情境演練以及中文陷阱提醒。請完整閱讀一遍，關於 WAF、Shield 與 DDoS 防護的 ANS-C01 問題將變為針對固定操作手冊的模式匹配。

AWS WAF 架構：Web ACL、規則與範圍

AWS WAF 是第 7 層網頁應用程式防火牆，可根據可配置的規則集檢測 HTTP 與 HTTPS 請求。頂層策略物件是 Web ACL (Web Access Control List)。Web ACL 包含排序過的規則清單、預設動作 (允許或封鎖)、CloudWatch 指標名稱、選用的日誌配置以及選用的 CAPTCHA / Challenge 配置。規則按優先順序評估，直到觸發終止動作為止；如果沒有規則匹配，則套用預設動作。

Web ACL 範圍：CLOUDFRONT vs REGIONAL

Web ACL 的範圍在建立時決定，且無法更改。CLOUDFRONT 範圍是全球性的，且無論你在何處營運，都必須在 us-east-1 建立該 Web ACL。CLOUDFRONT 範圍的 Web ACL 只能與 CloudFront 分發相關聯。REGIONAL 範圍是按區域劃分的，可以與區域資源 (ALB、API Gateway、AppSync、Cognito 使用者集區、App Runner 服務、Verified Access 執行個體) 相關聯。

你無法在 CLOUDFRONT 與 REGIONAL 範圍之間共用單個 Web ACL。要在 CloudFront 分發和區域 ALB 上強制執行相同的 WAF 策略，你必須建立兩個 Web ACL 並使用 AWS Firewall Manager 保持同步。

規則陳述式與動作

每條 WAF 規則都有一個陳述式 (比對條件) 和一個動作。陳述式包括位元組比對 (子字串比對)、正則表達式 (regex) 模式集、SQLi 攻擊、XSS 攻擊、大小限制、地理位置比對、IP 集、標籤比對、速率限制以及受管規則群組參考。陳述式可以透過邏輯 AND、OR、NOT 組合進行複雜的比對。

動作包括允許 (Allow, 允許並停止評估)、封鎖 (Block, 拒絕並停止評估)、計數 (Count, 記錄但繼續評估)、CAPTCHA (呈現拼圖測驗) 以及 Challenge (隱形 JavaScript 工作證明)。CAPTCHA 和 Challenge 會建立權杖 Cookie，在可配置的免疫時間 (CAPTCHA 預設 300 秒，Challenge 預設 300 秒) 內有效。

規則優先順序與評估順序

規則按優先順序從小到大評估。第一條觸發終止動作 (Allow, Block, CAPTCHA, Challenge) 的規則會結束評估。Count 動作不會終止評估 — 它記錄比對結果並繼續處理下一條規則。這是標籤驅動規則管道 (label-driven rule pipelines) 的基礎：前期的規則為請求標記標籤，後期的規則根據該標籤進行比對。

AWS 受管規則群組

AWS 受管規則是由 AWS 威脅研究團隊維護的精選規則群組。它們是在不編寫自訂規則的情況下部署生產級 WAF 防護的最快方式。與 ANS-C01 最相關的受管規則群組包括：

• AWSManagedRulesCommonRuleSet (CRS)：涵蓋 OWASP Top 10 類別 — SQLi、XSS、本地檔案包含 (LFI)、通用遠端程式碼執行 (RCE)。
• AWSManagedRulesSQLiRuleSet：更深層的 SQL 注入涵蓋，包含 Body、Header 與 URI 檢測。
• AWSManagedRulesKnownBadInputsRuleSet：針對已知漏洞 (如 Log4Shell、Spring4Shell) 的 Payload 比對，以及針對常見漏洞的遠端程式碼執行。
• AWSManagedRulesAmazonIpReputationList：AWS 已知為機器人 (bots)、掃描器與威脅來源的 IP。
• AWSManagedRulesAnonymousIpList：VPN、代理伺服器、Tor 出口節點以及託管提供商的 IP。
• AWSManagedRulesBotControlRuleSet：針對爬蟲機器人、SEO 爬蟲、安全掃描器的 Bot Control 通用功能。
• AWSManagedRulesATPRuleSet：針對登入端點的帳戶接管防護 (Account Takeover Prevention)，具有憑證填充 (credential stuffing) 偵測功能。
• AWSManagedRulesACFPRuleSet：針對註冊表單的帳戶建立詐欺防護 (Account Creation Fraud Prevention)。

CRS、KBI、IP Reputation 與 Anonymous IP 是免費的。Bot Control、ATP 與 ACFP 是付費的 (按請求收費)。所有受管規則群組都支援動作覆蓋 (在不分叉規則群組的情況下更改特定規則的動作) 以及縮減範圍陳述式 (scope-down statements) (將規則群組限制在流量的子集)。

速率限制規則：5 分鐘視窗與彙總索引鍵

速率限制規則 (Rate-based rules) 在每彙總索引鍵 (aggregate key) 的滑動 5 分鐘視窗內計算請求數。預設索引鍵是來源 IP (當 CloudFront 在前端時則是轉發 IP)。你也可以按 Header 值、查詢參數、標籤、國家/地區或結合多個屬性的複合索引鍵進行彙總。

限制為 2,000 的速率限制規則意味著：如果單個彙總索引鍵在過去 5 分鐘內超過 2,000 個請求，規則就會觸發 (Block, CAPTCHA, Challenge 或 Count)。規則並非正好在第 2,001 個請求時觸發 — 會有大約 30 秒到 1 分鐘的偵測延遲，考試可能會利用這一點作為干擾項。

複合彙總索引鍵 (Composite aggregate keys)

複合索引鍵讓你能夠表達如「5 分鐘內來自相同 IP+Header 組合的請求超過 100 個」之類的規則。這是防止 API 金鑰濫用的標準模式：按 Authorization Header 而非按來源 IP 進行速率限制，因為位於企業 NAT 後方的合法使用者會共用同一個 IP。複合索引鍵選項支援每條速率限制規則最多 5 個屬性。

縮減範圍陳述式 (Scope-down statements)

縮減範圍陳述式縮小了速率限制規則的適用範圍。例如，一條限制 100 且僅適用於 /login (而非 /static/*) 的速率限制規則。縮減範圍是一個常規的 WAF 陳述式 (URI 比對、方法比對、Header 比對)，它在速率計算之前對流量進行預過濾。

如果沒有縮減範圍陳述式，速率限制規則會計算所有流量 — 包括靜態資源請求 — 這在正常營運期間往往會超過限制並導致誤報。務必為特定端點的限制配對縮減範圍陳述式。

Bot Control、ATP 與 ACFP

Bot Control 是 AWS WAF 的受管功能，用於偵測並分類自動化流量。它有兩個級別：Common (通用) 與 Targeted (針對性)。

• Common Bot Control 偵測已知的機器人類別 (搜尋引擎、爬蟲、SEO 工具、安全掃描器) 並發出如 awswaf:managed:aws:bot-control:bot:category:scraping_framework 之類的標籤。
• Targeted Bot Control 增加基於機器學習的偵測，針對模仿人類行為的高級機器人，具備瀏覽器指紋識別與 Challenge 注入功能。

帳戶接管防護 (ATP) 是專門針對登入端點的受管規則群組。它偵測憑證填充、密碼噴灑 (password spraying) 與憑證釣魚。ATP 要求你配置登入端點的 URI 與請求格式 (JSON 或表單編碼)，以便其提取憑證。

帳戶建立詐欺防護 (ACFP) 是針對註冊端點的等效功能。它透過分析表單提交中的機器人特徵模式與先前見過的憑證來偵測自動化帳戶建立。

這三者都是按請求收費的付費受管規則群組。它們發出的標籤可以驅動後續規則 — 例如，「如果 Bot Control 將請求標記為自動化且 URI 為 /api/checkout，則執行 CAPTCHA」。

CAPTCHA 與 Challenge 動作

CAPTCHA 在觸發時呈現視覺拼圖；使用者在每個免疫期 (預設 300 秒，最高可配置為 24 小時) 內只需解決一次。成功解決會建立一個 CAPTCHA 權杖 Cookie。免疫時間內的後續請求將繞過 CAPTCHA。

Challenge 是隱形的 JavaScript 工作證明。瀏覽器執行一個小型 JavaScript 挑戰，這對瀏覽器而言微不足道，但對無頭機器人 (headless bots) 而言代價很高。挑戰是隱形運行的；使用者不會察覺。成功挑戰會建立一個 Challenge 權杖。Challenge 是適用於 API 端點與後端呼叫的正確動作，因為人類互動會破壞使用者體驗。

AWS Shield：Standard vs Advanced

AWS Shield 是 DDoS 防護服務。分為兩個級別；考試經常測試它們。

Shield Standard

Shield Standard 是自動的、免費的，且為每個 AWS 帳戶預設開啟。它防範常見的 L3 與 L4 DDoS 攻擊：SYN 洪水、UDP 反射與放大攻擊。Shield Standard 已整合到 Route 53、CloudFront、Global Accelerator 與 ELB 中。你無法關閉它，無法配置它，也無法查看其詳細指標。它是基準防護。

Shield Advanced

Shield Advanced 是付費訂閱服務，每個組織每月 3,000 美元 (需簽約 1 年)，外加按資源計費的防護費。它增加了：

• L3、L4 與 L7 防護 (後者透過與 AWS WAF 的緊密整合實現)。
• 應用層 DDoS 偵測，由受防護資源上的健康檢查偵測支援。
• 聯繫 AWS Shield Response Team (SRT) 的權限，在攻擊期間，SRT 人員可以在經你批准後編寫或修改 Web ACL 規則。
• 成本保護 (Cost protection)：退還因 DDoS 事件導致的擴展開銷 (CloudFront 資料傳輸、ALB 容量單位、Route 53 查詢、EC2 小時數)。
• 全球威脅儀表板，具備攻擊模式視覺化功能。
• 自動化應用層 DDoS 緩解，可在事件期間於你的 Web ACL 中自動建立速率限制規則。
• 基於健康檢查的偵測，具備自訂 CloudWatch 警示。
• 涵蓋範圍包括 EC2/NLB 上的彈性 IP、AWS Global Accelerator、CloudFront、Route 53 託管區域、ALB 以及 Classic Load Balancer。

何時選擇 Shield Advanced

當滿足以下至少兩項時，選擇 Shield Advanced 是合理的：

• 工作負載面向公眾且對營收至關重要 (電子商務、SaaS、廣告技術)。
• 客戶要求在攻擊期間獲得 SRT 24x7 的介入。
• 客戶需要成本保護，以抵消 DDoS 事件期間產生的擴展開銷。
• 客戶必須透過 Firewall Manager 在 AWS Organizations 中集中管理 DDoS 防護。

如果只滿足其中一項，Shield Standard 加上 AWS WAF 速率限制規則通常就足夠且明顯更便宜。

分層 DDoS 防禦架構

真實世界的 DDoS 應對手冊結合了多個層級。ANS-C01 期望你能清晰地說明這個堆疊：

用戶端 (Client)
  │
  ▼
Route 53 (DNS, Anycast, 具備 DDoS 彈性)
  │
  ▼
CloudFront / Global Accelerator (邊緣吸收, anycast IP)
  │
  ▼
AWS Shield Standard (自動 L3/L4 緩解)
  │
  ▼
AWS WAF (受管規則, 速率限制, Bot Control, CAPTCHA)
  │
  ▼
AWS Shield Advanced (L7 偵測, SRT, 成本保護)
  │
  ▼
ALB / NLB / API Gateway (區域級, 健康檢查驅動)
  │
  ▼
Auto Scaling Group / Lambda / Fargate (運算資源)

每一層都有其職責：

• L3/L4 磁碟區攻擊 (UDP 洪水, SYN 洪水)：Shield Standard 在邊緣自動吸收。CloudFront、Global Accelerator 與 Route 53 是具有龐大總容量的 Anycast 網路，可吸收每秒數百 Gb 的流量。
• L7 HTTP 洪水 (GET 洪水)：CloudFront 快取吸收可快取的請求；AWS WAF 速率限制規則封鎖不可快取的熱點索引鍵；Bot Control 標記組織化的機器人機群。
• L7 複雜攻擊 (Slowloris, 低速緩慢型)：Shield Advanced 應用層緩解，外加 ALB 連線閒置逾時調整。
• 反射與放大攻擊：網路邊界的 Shield Standard 在 AWS 邊緣進行封鎖。

不同資源類型的 Shield Advanced

Shield Advanced 對不同資源類型的防護方式不同。請記住這張表：

注意：AWS WAF 無法直接附加到 NLB 或 EC2/EIP。要為這些資源類型獲得 L7 WAF 防護，請在 NLB 或 EC2 前面部署 CloudFront。

用於 WAF 與 Shield 的 Firewall Manager

AWS Firewall Manager 可在 AWS Organizations 中套用 WAF Web ACL 與 Shield Advanced 防護。對於此網域，有兩種 Firewall Manager 策略類型至關重要：

• WAF 策略：將 Web ACL 配置 (受管規則群組 + 自訂規則) 部署到跨帳戶的範圍內資源 (CloudFront 分發、ALB、API Gateway)。持續修復不合規資源 (例如：沒有該策略的新 ALB)。
• Shield Advanced 策略：確保跨帳戶的範圍內資源 (CloudFront、ALB、NLB、EIP、Global Accelerator、Route 53 託管區域) 已啟用 Shield Advanced。

Firewall Manager 要求啟用 AWS Organizations 的所有功能、在成員帳戶中啟用 AWS Config，並設有委派管理員。如果沒有這些前提條件，即便需求匹配，「使用 Firewall Manager」這個答案也是錯誤的。

考試非常喜歡考「在 12 個帳戶的 200 個 ALB 上強制執行 WAF 速率限制規則」 — 答案是 Firewall Manager WAF 策略。手動在每個帳戶部署 Web ACL 無法擴展，且不可避免地會產生配置漂移。

WAF 日誌記錄與可見性

AWS WAF 可以記錄到三個目的地：Amazon S3 儲存貯體 (透過 Kinesis Data Firehose，最常用於合規保留)、Amazon CloudWatch Logs 或透過 Kinesis Data Firehose 到自訂目的地 (Splunk、Datadog 等)。日誌行包括時間戳記、匹配的規則 ID、動作、標籤以及 (截斷的) 請求內容。

WAF 主控台中的取樣請求 (Sampled requests) 與完整日誌不同 — 取樣請求僅用於診斷，最多有 5 分鐘的延遲。如需完整可見性，請啟用完整日誌記錄。

對於安全監控類的警示，將日誌發送到 CloudWatch Logs 並建立指標篩選條件，以偵測攻擊模式 (例如：針對 SQLi 受管規則的 BLOCK 動作激增)。Shield Advanced 事件上的 EventBridge 規則可觸發自動化事件回應。

邊緣架構選擇

ANS-C01 考試會根據邊緣架構測試 WAF 與 Shield 的放置位置。決策樹如下：

• HTTP/HTTPS 工作負載、全球延遲敏感、可快取內容：前面放 CloudFront，WAF 掛在 CloudFront 上，Shield Advanced 保障 CloudFront。
• TCP/UDP 工作負載 (遊戲、VoIP)、全球延遲敏感：前面放 Global Accelerator，Shield Advanced 保障 Global Accelerator (不掛 WAF — Global Accelerator 是 L4)。
• 區域性 HTTP/HTTPS 工作負載、無全球需求：前面放 ALB，WAF 掛在 ALB 上，Shield Advanced 保障 ALB。
• API 工作負載、低延遲要求：API Gateway 搭配 WAF，選用 Shield Advanced。
• 以 NLB 為前端的工作負載 (TLS 透傳)：如果需要 WAF L7 檢測，則在 NLB 前放 CloudFront；否則僅使用 NLB 並對 EIP 使用 Shield Advanced。

白話文解釋

WAF 跟 Shield 的關係用日常類比拆開來看：

類比一：銀行的多層保全（Layered Defense）

把你的應用想像成銀行金庫。一般小偷不會直接闖金庫，而是從外面一層一層進來：

• CloudFront / Global Accelerator = 銀行外圍的城牆與護城河（anycast network 的容量緩衝），把暴民（DDoS 流量）擋在城外。
• Shield Standard = 城牆上的監視塔自動偵測巨型炸彈（L3/L4 volumetric attack），免費且永遠開啟。
• AWS WAF = 大門口的安檢人員，看每位訪客的證件（HTTP request），對照黑名單（managed rules）跟規則手冊（custom rules）。
• Rate-based rule = 同一個人一小時來敲門五百次就直接拒絕（per-IP rate limit），或同一張信用卡一天刷五百次就鎖卡（per-Authorization-header）。
• Bot Control = 安檢人員手上有「機器人臉孔識別」的眼鏡，戴上去能看出哪些「人」其實是機器人（automated traffic）。
• CAPTCHA = 安檢人員偶爾要求訪客寫一行字證明你不是機器人（人會不耐煩但也會配合）。
• Challenge = 暗中監視訪客有沒有反射動作（JavaScript proof-of-work），訪客自己不知道在被測試。
• Shield Advanced = 24 小時待命的特勤組（Shield Response Team），出大事的時候直接打電話給你協助處置；還有「保險理賠」（cost protection）幫你付被攻擊期間的擴容費用。

類比二：高速公路收費站（Web ACL Rule Pipeline）

把每個 HTTP request 想像成一台車進高速公路，Web ACL 就是一連串收費站：

• 第 1 站（priority 100）：黑名單檢查（IP reputation）— 直接拒絕入境。
• 第 2 站（priority 200）：違禁品檢查（SQLi managed rule）— 後車廂有違禁品就攔下。
• 第 3 站（priority 300）：路費徵收（rate-based rule）— 同一台車一小時內過 100 次就攔下。
• 第 4 站（priority 400）：機器人辨識（Bot Control）— 自動駕駛車要求驗證碼（CAPTCHA）。
• 預設動作：以上都通過，放行。

每台車按 priority 順序檢查，第一個被攔的站就是終點站，後面的站不會再看。Count action 比較特別 — 它是「拍照記錄但放行」，這樣你可以先看流量的影響再決定要不要 block。

類比三：消防演習 vs 真火災（Shield Standard vs Advanced）

• Shield Standard = 大樓的自動撒水系統。火災發生（DDoS 攻擊）時自動啟動，免費，但你不知道它幹了什麼，也沒辦法調整。
• Shield Advanced = 大樓另外請的駐警隊 + 火災保險。
  • 駐警隊（SRT）會在火災時跟你確認對策，幫你寫即時規則。
  • 保險（cost protection）幫你付火災期間的損失（被打期間的擴容費）。
  • 但保險要先繳保費（$3,000/月）+ 必須有 Business Support 或 Enterprise Support。

對小公司而言，Shield Standard 加上自己寫的 rate-based rule 通常夠用；對銀行、電商、廣告平台這種被打就賠錢的，Shield Advanced 才划算。

情境演練

情境 A：針對 ALB 的 L7 HTTP 洪水攻擊

要求：一個電商 ALB 突然收到 100 倍的流量激增。應用程式開始逾時。客戶需要在幾分鐘內緩解。

正確架構 (攻擊發生前已就緒)：

• ALB 前方部署 CloudFront 分發並配置快取。
• CloudFront 上掛載 WAF，包含 AWS Managed CRS、IP Reputation、Anonymous IP、Bot Control。
• 對 /checkout/* 設定速率限制規則 (每 IP 限制 2,000，5 分鐘視窗)。
• 訂閱 Shield Advanced 並將 ALB 設定為受防護資源。

攻擊期間：

• WAF 速率限制規則封鎖高流量 IP。
• Bot Control 標記組織化的爬蟲機群，縮減範圍規則將其封鎖。
• Shield Advanced 應用層偵測自動建立額外的速率限制規則。
• 如果攻擊特徵是新型的，透過 AWS Support 聯繫 SRT。
• 成本保護退還 CloudFront 與 ALB 的擴容成本。

錯誤答案：純 NACL 拒絕規則 (無法比對 HTTP 屬性)、Network Firewall (L7 偵測能力與 WAF 相比有限)、僅使用 Shield Standard (ALB 在 L7 層級沒有 WAF 整合)。

情境 B：全球 UDP 遊戲工作負載的 DDoS 防護

要求：一款多玩家遊戲使用 UDP 進行客戶端與伺服器間的通訊。玩家遍布全球。DDoS 攻擊者對入口點進行洪水攻擊。

正確架構：

• 使用帶有 Anycast IP 的 AWS Global Accelerator 作為全球入口點。
• 多區域的 NLB 端點附加到 Global Accelerator。
• 訂閱 Shield Advanced 並將 Global Accelerator 設定為受防護資源。
• 不使用 WAF (CloudFront 與 WAF 不處理 UDP)。

為什麼不用 CloudFront：CloudFront 不支援 UDP，僅支援基於 TCP 的 HTTP/HTTPS。Global Accelerator 同時支援 TCP 與 UDP，是正確的 L4 Anycast 入口點。

營運最佳實踐

1. 先以 Count 動作部署速率限制規則，觀察一週，驗證沒有誤報後，再切換為 Block。這是 WAF 調優的規範化「影子模式」(shadow mode)。

2. 務必將速率限制規則與縮減範圍陳述式配對，以免靜態資源流量消耗速率配額。

3. 從第一天起就啟用 WAF 日誌記錄，透過 Kinesis Firehose 發送到 S3 以供合規保留，並發送到 CloudWatch Logs 以供即時警示。

4. 使用 Firewall Manager 確保全組織的一致性 — 手動按帳戶部署 WAF 在 90 天內就會產生漂移。

5. 在 Shield Advanced 指標 (DDoSDetected, AttackBitsPerSecond) 上設定 CloudWatch 警示，並路由到 PagerDuty / OpsGenie。

6. 每季測試容錯移轉案例 — 模擬源伺服器故障並確認 CloudFront 源容錯移轉、ALB 目標群組容錯移轉以及 Shield Advanced 偵測功能。

7. 預先在 AWS Support 中配置 SRT 聯絡人，以便在實際發生攻擊時不會因為文書流程而延誤介入。

常見考試陷阱

其他反模式：

• 忘記 CloudFront 上的 WAF 使用 CLOUDFRONT 範圍；區域 ALB/API Gateway 上的 WAF 使用 REGIONAL 範圍。
• 將用於 CloudFront 的 ACM 憑證放在 us-east-1 以外的任何區域。
• 僅使用 Shield Standard 進行 L7 防護 — 它僅限 L3/L4。
• 未在 API Gateway REST API 階段啟用 AWS WAF (HTTP API 不直接支援 WAF；HTTP API 使用 Lambda 授權方)。
• 忘記速率限制規則需要索引鍵 — 如果沒有配置彙總索引鍵，規則預設使用來源 IP，這在 CloudFront 位於前端時會失效 (因為來源 IP 總是 CloudFront 的，應改用 X-Forwarded-For)。
• 未適當設定 CAPTCHA / Challenge 的免疫時間 — 太短會造成使用者困擾；太長則會削弱安全性。

FAQ

Q1：我何時該選擇 Shield Advanced 而非 Shield Standard？

當滿足以下至少兩項時，選擇 Shield Advanced 是合理的：工作負載對營收至關重要、客戶要求 24x7 SRT 介入、客戶需要針對 DDoS 期間擴展開銷的成本保護，或客戶必須在 AWS 組織中集中管理防護。每月 3,000 美元的定價加上必須具備 Business 或 Enterprise Support，意味著 Shield Advanced 很少用於非營收或內部工作負載。

Q2：我該在哪裡執行地理位置限制 — CloudFront 還是 AWS WAF？

CloudFront 分發級別的地理位置限制最適合對整個分發進行地毯式的國家封鎖 — 它免費、簡單且返回 403。當地理位置必須與路徑、方法或 Header 結合使用，或者你需要為不同國家採取不同動作 (Allow, Block, CAPTCHA, Challenge, Count) 時，AWS WAF 的地理位置比對規則更合適。

Q3：當 CloudFront 位於前端時，速率限制規則如何運作？

當 CloudFront 位於前端時，WAF 看到的來源 IP 是 CloudFront 的 IP，而非客戶端的。為了獲得正確的速率限制，請將速率限制規則配置為 aggregate-key 為 forwarded-IP 並參考 X-Forwarded-For Header。CloudFront 會自動將原始客戶端 IP 填入 X-Forwarded-For。

Q4：我能否在 CloudFront 分發和 ALB 之間共用一個 Web ACL？

不能。Web ACL 的範圍是二元的 — CLOUDFRONT 範圍的 Web ACL 只能附加到 CloudFront 分發；REGIONAL 範圍的 Web ACL 只能附加到區域資源 (ALB、API Gateway、AppSync、Cognito、App Runner、Verified Access)。使用 AWS Firewall Manager 部署兩個具有相同規則配置的並行 Web ACL。

Q5：AWS WAF 與 AWS Network Firewall 有什麼區別？

AWS WAF 是 L7 網頁應用程式防火牆，附加到面向 HTTP/HTTPS 的服務 (CloudFront、ALB、API Gateway)。AWS Network Firewall 是 L3-7 有狀態防火牆，附加到 VPC 路由路徑，用於東西向與南北向檢測。它們是互補的 — 大多數架構會同時使用兩者：WAF 在邊緣位於負載平衡器前方，Network Firewall 位於 VPC 邊界。

Q6：Shield Advanced 成本保護在實踐中如何運作？

當 AWS Shield 偵測到針對受防護資源的 DDoS 事件，且該事件導致與擴展相關的成本增加 (CloudFront data-out、Route 53 查詢、ALB 容量單位、EC2 小時數) 時，你可以透過 AWS Support 提交點數請求。AWS 會在其偵測系統中審核攻擊特徵，並針對可歸因於攻擊的增量成本發放服務點數。成本保護需要 Business 或 Enterprise Support，且在事件發生時資源必須有活躍的 Shield Advanced 訂閱。

Q7：WAF 能防範 Layer 3/4 DDoS 嗎？

不能，AWS WAF 僅限 L7。L3/L4 DDoS 防護是 AWS Shield (Standard 或 Advanced) 的職責。這兩者旨在協同工作：Shield 在網路邊緣處理磁碟區攻擊與協定層攻擊，WAF 在 HTTP 層處理應用層攻擊。

Q8：AWS WAF 日誌與 CloudFront 存取日誌是一樣的嗎？

不一樣。AWS WAF 日誌記錄每請求的檢測結果 — 匹配的規則、動作、標籤、請求欄位。CloudFront 存取日誌記錄對分發的每個檢視器請求 — 服務了什麼內容、狀態碼、位元組數。為了獲得完整的邊緣安全可見性，請同時啟用兩者。WAF 日誌發送到 S3 (透過 Firehose)、CloudWatch Logs 或自訂 Firehose 目的地。CloudFront 標準日誌直接發送到 S3；即時日誌發送到 Kinesis Data Streams。

Q9：AWS Shield Response Team 的實際工作範圍是什麼？

Shield Response Team (SRT) 是一群 AWS 工程師，24x7 在 DDoS 事件期間為 Shield Advanced 訂閱者提供協助。經你事先批准 (記錄在 AWS Support 中)，SRT 可以在攻擊期間審核你的 Web ACL、提議新規則並代表你套用規則以緩解攻擊。聯繫 SRT 需要 Business 或 Enterprise Support。

Q10：Shield Advanced 是否需要在每個受防護資源上啟用？

是的。在組織層級訂閱 Shield Advanced 會啟用高級功能，但每個資源 (CloudFront 分發、ALB、NLB、Global Accelerator、EIP、Route 53 託管區域) 都必須顯示地添加為受防護資源。Firewall Manager 的 Shield Advanced 策略可為新資源自動完成此操作。

總結：WAF、Shield、DDoS 答案模式

當你在 ANS-C01 中讀到關於 WAF、Shield 或 DDoS 的問題時，請執行以下檢查表：

• 是否有公有 HTTP/HTTPS 流量？ → CloudFront + WAF。
• 是否有公有 UDP 流量？ → Global Accelerator + Shield Advanced。
• 是否需要 L7 檢測 (SQLi, XSS, OWASP)？ → 帶有受管規則的 AWS WAF。
• 工作負載是否對營收至關重要且有 24x7 SLO？ → Shield Advanced。
• 是否需要速率限制？ → 帶有縮減範圍與正確彙總索引鍵的 WAF 速率限制規則。
• 是否擔心機器人濫用？ → 針對高價值端點的 Bot Control + ATP/ACFP。
• 是否需要跨帳戶集中化管理？ → Firewall Manager。
• 問題是否關於 NLB 防護？ → NLB 前放 CloudFront；WAF 無法掛在 NLB 上。
• 問題是否關於攻擊期間的成本？ → Shield Advanced 成本保護 (需 Business/Enterprise Support)。

掌握分層防禦堆疊、WAF 規則評估順序、Shield 級別選擇標準以及整合約束 (CLOUDFRONT vs REGIONAL 範圍、NLB 不能有 WAF、CloudFront 的 ACM 憑證需在 us-east-1)，ANS-C01 的問題將變得有跡可循。

常考陷阱

• 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 分鐘滑動視窗 — 不是每秒、不是每小時，且觸發有 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。