WAF、Shield 與網路防護服務

AWS WAF、Shield 與網路防護，是 SOA-C02 中 Domain 5（網路與內容交付）與 Domain 4（安全與合規）交集最密集的區塊。Task Statement 5.1 明確點名「設定 AWS 網路防護服務（例如 AWS WAF、AWS Shield）」，而這個考試的靈魂在於運維視角——這正是它與 SAA-C03 最大的分野。Solutions Architect 被問的是「該推薦哪一層防護」；SysOps 工程師被問的是「凌晨 11 點行銷活動剛上線、流量暴增 400%、WAF rate-based rule 開始擋真實用戶，你有 15 分鐘在不解除防護的前提下修好它——怎麼做？」

本指南帶你走過 AWS WAF、Shield、Firewall Manager、Network Firewall 與 GuardDuty 網路相關 findings 的完整運維生命週期——從建立 Web ACL 和選擇受管規則群組，到解讀 WAF 日誌找出誤判、依 aggregate key 類型調整 rate-based rule、在 Shield Standard 與 Shield Advanced 之間做出有成本意識的抉擇、透過 Firewall Manager 將 WAF 與 Shield 政策推送到整個 AWS Organizations、區分 AWS Network Firewall 與 AWS WAF（Layer 3/4 vs Layer 7——這是長青陷阱），以及回應 GuardDuty 網路 findings（port scan、偵察、資料滲漏）。你也會看到 SOA-C02 反覆出現的情境題型：rate-based rule 過激擋住合法用戶、Shield Advanced 告警時 DDoS 正在進行中、Firewall Manager 因為沒啟用 Organizations 而拒絕部署。

為什麼 WAF、Shield 與網路防護在 SOA-C02 至關重要

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 5.1 下列出三項技能：設定 VPC、設定私有連線，以及設定 AWS 網路防護服務。第三項正是本主題的核心領域。AWS WAF 與 AWS Shield 是 AWS 上 Layer 7 與 Layer 3/4 的標準防護服務，而 SysOps Administrator 就是每天實際操作這些服務的工程師——向 Web ACL 新增規則、依觀測到的流量調整速率門檻、在事故中審查 WAF 抽樣請求、在攻擊期間請求 Shield Response Team 介入，以及推送一個 Firewall Manager 政策，強制組織裡每個帳號都套用基準 WAF Web ACL。

在 SysOps 層級，題目幾乎不會是「架構師應該選 WAF 嗎？」——那是 SAA 的範疇。SOA-C02 的問法是：「WAF rate-based rule 設定在每 5 分鐘 100 個請求，閃購期間客戶回報 403，on-call 需要在保留 DDoS 防護的前提下停止擋住真實用戶——正確的組合調整是什麼？」要答對這題，必須理解規則 action（Allow、Block、Count、CAPTCHA、Challenge）、rate-based rule 的 aggregate key 類型（IP、forwarded IP、header、cookie）、規則優先順序與評估流程、WAF 日誌與抽樣請求，以及 Web ACL capacity units（WCU）。本主題與 Domain 1（WAF metrics 的 CloudWatch alarms 與 dashboards）、Domain 4（Firewall Manager 作為 Organizations 策略的一環，以及 GuardDuty 作為資料保護 findings 審查的一部分）、Domain 5（CloudFront 與 ALB 作為 Web ACL 附加點）緊密相連。

白話文解釋 WAF、Shield 與網路防護

術語密度很高——Web ACL、WCU、aggregate key type、SRT、AWS managed rule groups。三個類比能讓這些概念變得具體好記。

類比一：門市保全的進場審查

AWS WAF 是百貨公司入口的保全人員。每位顧客走進來（每個 HTTP 請求），都會依照店長交給保全的審查手冊進行核對。Rules 是保全的個別檢查項目——「黑名單上的 ID 一律拒絕」（IP set match）、「衣服上印有特定字樣者不得入場」（SQL injection 模式的字串比對）、「同一地址 5 分鐘內來了超過 100 組人就封鎖」（rate-based rule per IP）。Rule groups 是總公司發下來的標準作業手冊——AWS Managed Rule Groups 就像全國連鎖店的標準安全規範（涵蓋 OWASP Top 10、已知惡意輸入、Amazon IP 信譽清單），而自訂 rule groups 則是各門市自訂的規定（「VIP 會員限定週五入場」）。Rule action 是保全的處置選項：Allow（歡迎光臨）、Block（請離開）、Count（放行但記錄在觀察本上，讓店長事後審查——純觀察模式）、CAPTCHA（請先完成一道圖形驗證題，確認是真人）、Challenge（靜默執行瀏覽器指紋驗證，機器人會失敗）。Rule priority 是手冊上的檢查順序——數字越小越先執行，第一條命中且具有終止性 action 的規則獲勝（Allow 或 Block 結束評估；Count 繼續往下走）。

AWS Shield Standard 是商場外圍的基本保全，負責處理明顯的暴力衝撞——有人試圖用大型機具衝開大門（volumetric DDoS），或一千人同時湧入堵住入口（SYN flood）。它永遠開啟、免費、無感——每個 AWS 帳號都自動擁有。AWS Shield Advanced 是委託外包的 24 小時駐點特勤隊——他們有一支隨時可電話聯絡的Shield Response Team（SRT），在攻擊期間即時撰寫 WAF 規則，出事造成的加班費也由 AWS 補貼（DDoS 費用保護），並運用全 AWS 的威脅情報提早偵測攻擊。代價是：合約費每月 $3,000，且需簽訂一年。

類比二：企業級垃圾郵件過濾器

AWS WAF managed rule groups 的運作方式，與企業級垃圾郵件過濾系統如出一轍。Core Rule Set 是預設垃圾郵件過濾——涵蓋 OWASP Top 10 分類（注入、XSS、身分驗證缺陷），就像預設過濾器涵蓋明顯的釣魚信樣板。Amazon IP Reputation List 是共用信譽資料庫——被其他 AWS 客戶舉報過的 IP 進入同一份黑名單保護你。Known Bad Inputs 清單是病毒特徵碼定義，隨新 CVE 出現由 AWS 持續更新。Bot Control 是機器人偵測外掛模組，在垃圾郵件過濾之上疊加指紋辨識——區分真實的郵件用戶端與偽裝成它的腳本。Count action 是標記為垃圾但仍然投遞的模式：非常適合剛啟用新規則時，先觀察會不會誤判正常郵件，再正式啟用隔離。考試關鍵洞察：永遠先 Count、觀察 WAF 日誌、再升級為 Block——就像郵件管理員在新垃圾郵件規則開隔離前先評估跑一週。

類比三：古城的多層防禦體系

古代城池採用縱深防禦，AWS 網路防護的結構與之完全對應。AWS Shield Standard 是外城牆——每座城都有，永遠存在，擋住明顯的攻城器械（volumetric 攻擊），無需任何人操作。AWS WAF 是吊橋邊的守門官——對每個進城者（HTTP 請求）檢查通行證（headers、body、query string），依規則冊決定誰能過橋。AWS Network Firewall 是城內的巡邏隊——在石板路上（Layer 3/4 封包層）檢查每輛馬車與旅人，能做 stateful 連線深度檢測，與吊橋守門官的職責完全不同。AWS Firewall Manager 是王國的安全委員會——坐鎮首都（AWS Organizations 的管理帳號），起草安全法令，並向王國每座城堡發布，讓各地總督無法單方面解散城內巡邏或擅改守門官的規則手冊。GuardDuty 網路 findings 是城外的斥候騎兵，持續回報：「有人在掃描城牆找弱點」（port scan）、「已知強盜的馬匹靠近城門」（與惡意 IP 通訊）、「深夜有馬車載著貴重物資偷偷出城往外邦方向去」（資料滲漏）。每一層偵測的事物不同，SOA-C02 完整答案通常需要多層聯合運作。

AWS WAF Web ACL 基礎：Scope 與附加點

Web ACL 是你實際附加到受保護資源的 WAF 物件。它包含以優先順序排列的規則與 rule group，若沒有任何規則產生終止性 action，則套用預設的 Allow 或 Block。

Scope：CLOUDFRONT vs REGIONAL

AWS WAF 有兩種 scope，scope 的選擇是最常被考到的運維陷阱之一：

• CLOUDFRONT scope — Web ACL 是全球性的，必須在 us-east-1（N. Virginia）建立，無論 CloudFront distribution 服務哪些地區的流量。CloudFront 是全球服務，其設定平面位於 us-east-1，因此它的 WAF 也必須在那裡。試圖從其他 region 將 CLOUDFRONT scope 的 Web ACL 附加到 CloudFront distribution 會失敗。
• REGIONAL scope — Web ACL 存在於特定 AWS region，並附加到同一 region 的 regional 資源：Application Load Balancer、API Gateway REST/HTTP API、AWS AppSync GraphQL API、Amazon Cognito user pool、AWS App Runner service、AWS Verified Access instance。

常見的考生錯誤：因為 origin 在 us-west-2，就在那裡建立 regional Web ACL 來保護 CloudFront distribution。那個 Web ACL 無法附加到 CloudFront。解法永遠是：CloudFront → 在 us-east-1 建立 CLOUDFRONT scope。如果需要縱深防禦，CloudFront 後面的 ALB 可以有自己的 regional Web ACL。

附加點與各自的防護範圍

單一 Web ACL 可附加到同一 region 中同一 scope 的多個資源（例如 ap-southeast-1 的每個 ALB 共用一個 Web ACL）。這正是 Firewall Manager 在組織規模下強制執行的運維模式。

預設 action 與規則評估流程

Web ACL 有一個預設 action——Allow 或 Block——當沒有任何規則產生終止性 action 時套用。規則依優先順序評估（數字越小 = 優先順序越高）。對每條規則：

1. 針對請求評估規則 statement。
2. 若 statement 匹配且 action 為 Allow 或 Block，評估停止——請求被允許或封鎖。
3. 若 action 為 Count，評估繼續到下一條規則，但匹配結果會記錄在 metrics 與日誌中。
4. 若 action 為 CAPTCHA 或 Challenge，評估可能暫停以呈現驗證；成功後請求繼續；失敗則被封鎖。
5. 若沒有規則產生終止性 action，Web ACL 的預設 action 生效。

Web ACL Capacity Units（WCU）

每條 WAF 規則依其複雜度有對應的 WCU 成本——簡單的 IP set match 是 1 WCU，regex 模式比對是 25–35 WCU，managed rule group 有固定的 WCU 宣告成本（通常 25–700，視群組而定）。Web ACL 預設硬性上限為 1,500 WCU，透過配額調升申請可提升至 5,000 WCU。若新增規則會使總量超過上限，API 會拒絕該變更。

對 SysOps 而言，規則設計因此至關重要。三個各 700 WCU 的 managed rule group 放不進同一個 Web ACL。運維模式是：選一個核心 managed rule group，加上針對你的應用程式的特定自訂規則，其餘預算留給 rate-based rule 與 IP 允許/拒絕清單。

Managed Rule Groups——AWS Managed 與 Marketplace

Managed rule group 是由 AWS 或 AWS Marketplace 賣家維護的預建規則集合。它讓 SysOps 工程師不必從頭撰寫 SQL injection 或跨站腳本規則，並由發布者隨新威脅出現自動更新。

AWS Managed Rule Groups——核心基準

AWS 在 WAF 主控台以 AWS 廠商名稱發布免費與付費的 managed rule groups。考試最相關的幾個：

• Core rule set（AWSManagedRulesCommonRuleSet）——OWASP Top 10 基準，涵蓋跨站腳本、本地檔案包含、通用惡意輸入等廣泛類別。WCU: 700。多數運維人員第一個加入的 managed rule group。
• Known bad inputs（AWSManagedRulesKnownBadInputsRuleSet）——針對真實漏洞利用觀察到的模式（Log4Shell、Spring4Shell 等）。WCU: 200。隨新 CVE 出現頻繁更新。
• Amazon IP reputation list（AWSManagedRulesAmazonIpReputationList）——Amazon 威脅情報觀察到攻擊其他 AWS 客戶的 IP。WCU: 25。成本低、信號強，幾乎永遠值得加入。
• Anonymous IP list（AWSManagedRulesAnonymousIpList）——Tor 出口節點、公開代理、通常不應出現在一般網站的主機供應商 IP。WCU: 50。適合消費者應用；對 B2B 有風險，因為合法客戶可能確實使用主機供應商 IP。
• SQL database（AWSManagedRulesSQLiRuleSet）——Core rule set 以外更專注的 SQL injection 模式。WCU: 200。
• Linux operating system（AWSManagedRulesLinuxRuleSet）——本地檔案包含與指令注入模式。WCU: 200。
• POSIX operating system（AWSManagedRulesUnixRuleSet）——POSIX 風格指令注入。WCU: 100。
• Windows operating system（AWSManagedRulesWindowsRuleSet）——PowerShell 與 Windows 特定模式。WCU: 200。
• PHP application（AWSManagedRulesPHPRuleSet）——PHP 特定漏洞利用。WCU: 100。
• WordPress application（AWSManagedRulesWordPressRuleSet）——WordPress 特定路徑。WCU: 100。
• Bot Control（AWSManagedRulesBotControlRuleSet）——付費 managed rule group；見下方 Bot Control 章節。WCU: 50（Common）或 500（Targeted）。
• ATP — Account Takeover Prevention（AWSManagedRulesATPRuleSet）——付費；保護登入端點免受憑證填充攻擊。WCU: 50。
• ACFP — Account Creation Fraud Prevention（AWSManagedRulesACFPRuleSet）——付費；保護註冊端點免受假帳號建立攻擊。WCU: 50。

Marketplace rule groups

AWS Marketplace 賣家（Fortinet、F5、Imperva、Cyber Security Cloud 等）以各自廠商名稱發布 managed rule groups。計費方式為每個 Web ACL 每月固定費加上每請求費用。SOA-C02 不考特定 Marketplace 廠商，但確實預期你知道它們作為 AWS 受管與客戶自建規則之外的替代選項而存在。

部署策略——永遠先 Count

任何新 managed rule group 的考試關鍵運維模式：

1. 將群組以 Count 模式加入 Web ACL（對群組內每條規則的 action 覆寫為 Count）。
2. 跑過幾天具代表性的流量，包含週末，確保涵蓋完整流量分布。
3. 在 WAF 日誌與主控台的抽樣請求分頁中，找出會被封鎖的合法流量。
4. 加入 scope-down statement 或規則覆寫以排除誤判。
5. 將群組升級為預設 action（Block）。

跳過 Count 階段是生產事故最常見的根源之一——全新的 managed rule group 因某個路徑符合某條規則而封鎖了公司自己的後台，客服整個下午都在接投訴電話。

規則 Action——Allow、Block、Count、CAPTCHA、Challenge

WAF 規則可以採取的五種 action 在運維上各有不同含義，SOA-C02 逐一考測。

Allow

Allow 是終止性的——評估立即停止。用於信任的合作夥伴 IP（支付處理商的 IP 範圍）、已知的合法爬蟲（Google、Bing）讓它們繞過 managed rules，或只從你的辦公室存取的後台工具端點。

Block

Block 是終止性的——評估停止，請求以 HTTP 403 拒絕（或可自訂的回應）。用於確認的惡意流量——已知惡意 IP、符合 managed rule 特徵的請求，或超過速率限制的來源。

Count

Count 是非終止性的——匹配結果記錄在 CloudWatch metrics 與 WAF 日誌，但請求繼續評估。用於任何升級為 Block 前需要評估的規則，或用於永久性的可觀測性規則（「統計沒有 User-Agent header 的請求數量」作為可繪圖的 metric）。對 managed rule group 設定 Count 覆寫，可將群組內所有規則不論其預設 action 全部置入 Count 模式。

CAPTCHA

CAPTCHA 呈現視覺謎題讓用戶證明是真人。成功後，免疫 token 以 cookie 形式設定，在可設定的時間內（預設 5 分鐘，最長 11 小時）讓後續請求繞過 CAPTCHA。失敗或 token 不存在時，請求被封鎖。適用於對機器人有價值但人類偶爾完成也能接受的流程——登入頁面、註冊頁面、聯絡表單。

Challenge

Challenge 是 CAPTCHA 的靜默版本：在用戶瀏覽器中執行基於 JavaScript 的瀏覽器指紋檢查並產生 token。用戶完全看不到任何謎題。真實瀏覽器自動通過；無頭爬蟲與 HTTP 函式庫通常失敗。Challenge 比 CAPTCHA 對用戶更友善，但只對低複雜度機器人有效。同樣的免疫 token 機制適用。

Rate-Based Rules——IP 與 Aggregate Key 類型

Rate-based rule 在 5 分鐘滑動視窗內依 aggregation key 追蹤請求計數，對超過設定門檻的 key 執行動作（Block、Count、CAPTCHA、Challenge）。門檻是每個 aggregation key 每 5 分鐘允許的最大請求數。

Aggregate key 類型

• IP — 依 WAF 看到的來源 IP 聚合（請求者的公開 IP，或連接的 CDN/load balancer 的 IP）。
• Forwarded IP — 依 HTTP header 中的 IP 聚合（通常是 X-Forwarded-For），適用於流量通過受信任代理、真實客戶端 IP 在 header 中的情況。若 header 不存在，需設定 IP fallback behavior。
• HTTP header — 依任何 header 的值聚合（User-Agent、Authorization、自訂 header）。
• HTTP method — 依 HTTP verb 聚合。
• Query string / query argument — 依整個 query string 或單一參數聚合。
• Cookie — 依 cookie 值聚合（例如 session cookie）。
• Label namespace — 依 Web ACL 中較早的規則產生的 label 聚合。
• Custom keys（組合） — 組合上述最多五個成為複合 key（forwarded IP + URI path，實現每 IP 每端點的速率限制）。

選擇正確的 aggregate key

• 無身分驗證的公開網站：IP 或 Forwarded IP。門檻依典型瀏覽速率調整（人類 5 分鐘瀏覽 10–30 頁；5 分鐘 2,000+ 幾乎肯定是腳本）。
• 以 API key 保護的 API Gateway：HTTP header（x-api-key）或 Authorization header——依 API key 速率限制而非依 IP，因為合法客戶端常共用 NAT。
• 登入端點：Forwarded IP，門檻設低（登入頁 5 分鐘 100 個請求已經足夠；1,000 個就是憑證填充）。
• Load balancer 後的行動應用：Cookie 或自訂 header，因為企業 NAT 或電信商 CGNAT 可能讓數千個合法用戶共用同一個 IP。

Scope-down statements

Rate-based rule 可以包含一個 scope-down statement，限制哪些請求才納入計數器。常見模式：

• 「只對 /login 的 POST 請求進行速率限制」（URI path AND method scope-down）。
• 「只對缺少 API key header 的請求進行速率限制」（header 不存在的 scope-down）。
• 「只對辦公室 IP 範圍以外的請求進行速率限制」（NOT IP set scope-down）。

Scope-down 對於讓 rate-based rule 足夠精準、使門檻對目標流量具有意義，是不可或缺的。

運維調整

Rate-based rule 的首次部署應永遠以 Count 模式運行至少一週。觀察 CloudWatch 的 CountedRequests metric，找出合法流量的峰值，將門檻設在峰值的 2 到 3 倍，之後才升級為 Block。SOA-C02 反覆考測這個流程。

Bot Control——緩解自動化流量

AWS WAF Bot Control 是付費的 AWS managed rule group，將傳入請求分類為人類或機器人，並對每個請求加上機器人類別的 label。它是 SOA-C02 中關於爬蟲、掃描器與憑證填充攻擊問題的正確答案。

兩種防護等級

• Common（預設）——使用請求特徵分析（User-Agent、header 順序、JA3 TLS fingerprint、行為信號）辨識並標記常見機器人。WCU: 50。適合多數公開網站。
• Targeted——加入主動挑戰（靜默瀏覽器指紋加免疫 token）以偵測仿冒真實瀏覽器的複雜機器人。WCU: 500。適用於處於機器人攻擊壓力下的高價值流程（登入、註冊、結帳）。

機器人類別

Bot Control 以類別 label 標記請求，WAF 規則可據此執行動作：

• bot:category:search_engine——Google、Bing 等，透過反向 DNS 與 AS 號碼驗證。通常 Allow。
• bot:category:social_media——Facebook、Twitter 預覽爬蟲。通常 Allow。
• bot:category:monitoring——Pingdom、Datadog 合成監控。通常 Allow。
• bot:category:scraping_framework——Scrapy、Puppeteer、Playwright。通常 Block 或 Challenge。
• bot:category:http_library——curl、wget、requests、axios。通常 Block 或 Challenge。
• bot:category:ai_crawler——OpenAI GPTBot、Anthropic ClaudeBot 等。依政策 Allow 或 Block。
• bot:unverified——宣稱是已驗證機器人但驗證失敗。Block。
• bot:name:<specific>——特定機器人名稱的 label。

運維模式

將 Bot Control managed rule group 加入 Web ACL。將群組預設 action 設為 Count 跑一週。審查流量中出現哪些機器人類別。決定哪些允許（搜尋引擎、社群媒體、監控工具）、哪些挑戰（AI 爬蟲、未驗證）、哪些封鎖（爬蟲框架、HTTP 函式庫、已知惡意）。再依類別覆寫 action 並升級。

AWS Shield Standard——永遠開啟的 L3/L4 防護

AWS Shield Standard 是每個 AWS 客戶免費、自動獲得的永遠開啟 Layer 3 與 Layer 4 DDoS 防護。

Shield Standard 涵蓋範圍

• 網路層（Layer 3）攻擊——UDP 反射、NTP 放大、DNS 放大、ICMP flood。
• 傳輸層（Layer 4）攻擊——SYN flood、ACK flood、TCP reset flood、碎片封包。
• 常見 volumetric 攻擊——Shield 在 AWS 網路邊緣吸收流量，在抵達你的 origin 之前緩解。

Shield Standard 的運作位置

Shield Standard 的緩解機制運行在 AWS 邊緣（CloudFront、Route 53 邊緣節點、AWS Global Accelerator）。它也保護 EC2 上的 elastic IP 地址，以及 ALB/NLB/CLB 的 regional 邊界。Shield Standard 不需要任何操作——預設對每個帳號開啟。

Shield Standard 不涵蓋的範圍

Shield Standard 不緩解 Layer 7（應用層）攻擊——HTTP flood、slowloris、應用邏輯濫用。針對這些需要 AWS WAF（自行設定 rate-based rule 與 managed rule groups）或 AWS Shield Advanced。

AWS Shield Advanced——付費防護加 SRT

AWS Shield Advanced 是選擇性加入的付費層，增加 Layer 7 防護、Shield Response Team、DDoS 費用保護，以及詳細的可視性——費用為每個 AWS 組織每月 $3,000，須承諾一年，加上受保護資源的資料傳輸費。

受保護資源類型

你需要明確將資源登錄到 Shield Advanced 防護中。可登錄的資源類型：

• Amazon CloudFront distributions
• Amazon Route 53 hosted zones
• AWS Global Accelerator standard accelerators
• Application Load Balancers
• Classic Load Balancers
• Elastic IP addresses（保護 EC2、NLB）

常見的 SOA-C02 題型框架：「公司需要對 ALB 前置的應用程式提供 DDoS 防護；Shield Advanced 已批准預算」——設定步驟是將 ALB 登錄為 Shield Advanced 受保護資源（透過 Shield 主控台或 Firewall Manager Shield 政策）。

Shield Response Team（SRT）

Shield Response Team（前身為 DDoS Response Team / DRT）是 24/7 的 AWS 工程師團隊，你可以在主動攻擊期間請求介入：

• 開立 Shield 支援案件（需要 Business 或 Enterprise 支援計畫才能請求 SRT 介入）。
• SRT 可在攻擊期間直接在你的 Web ACL 中撰寫自訂 WAF 規則。
• SRT 可就架構變更（快取政策、origin shielding、地理限制）提供建議，緩解複雜攻擊。
• 你透過一個 IAM role 預先授權 SRT 存取你的 AWS WAF 與 Shield Advanced 設定。

DDoS 費用保護

當 Shield Advanced 受保護資源遭受 DDoS 攻擊並因此產生擴展相關費用（CloudFront 資料輸出、EC2/ALB 擴展、Route 53 查詢量），AWS 退還那些費用。退款在 SRT 驗證事件確為 DDoS 後核發。對高流量網站而言，光這個好處往往就能合理化每月 $3,000 的費用。

健康偵測

Shield Advanced 可以使用 Route 53 health checks 將應用程式健康狀態納入偵測演算法。失敗的 health check 告訴 Shield「應用程式現在不健康」，降低宣告攻擊的偵測門檻，減少臨界事件的誤報並縮短回應時間。

Layer 7 自動緩解

對 CloudFront 與 ALB，Shield Advanced 可在 Layer 7 DDoS 攻擊期間自動產生 WAF 規則——觀察攻擊模式並產生封鎖規則，無需操作者介入。你可以每個受保護資源各別啟用此功能，並審查/核准每條產生的規則。

AWS Firewall Manager——跨組織政策強制執行

AWS Firewall Manager 是整合 Organizations 的集中管理平面，用於管理 WAF、Shield Advanced、security groups、Network Firewall 與 DNS Firewall。它的存在是因為在一個 50 個帳號的 AWS Organization 中，確保每個帳號都有相同基準 WAF Web ACL 在操作上是不可能依靠手動完成的。

先決條件

Firewall Manager 有嚴格的先決條件——每位 SOA-C02 考生都必須背熟：

1. AWS Organizations 已啟用，且開啟所有功能（不是只有 consolidated billing）。
2. 指定一個 Firewall Manager 管理員帳號（可以是 management account，但 AWS 建議使用 delegated admin）。
3. AWS Config 在每個 member account 的每個目標 region 中啟用，Firewall Manager 才能在那裡運作。
4. 若要建立 Shield Advanced 政策，管理員帳號必須訂閱 AWS Shield Advanced。
5. 對 Network Firewall 與 DNS Firewall 政策，那些服務必須在目標 region 中可用。

若缺少任何先決條件，Firewall Manager 不是拒絕建立政策，就是對不符合的帳號靜默地不套用政策。

政策類型

• WAF 政策——定義含受管與自訂規則的 Web ACL；Firewall Manager 在每個涵蓋範圍的帳號/region 建立 Web ACL，並附加到指定資源（CloudFront、ALB、API Gateway 等）。
• WAF Classic 政策——舊版；新部署不要使用。
• Shield Advanced 政策——跨組織將指定資源類型登錄為 Shield Advanced 受保護資源。
• Security group 政策——三種子類型：
  • Common 政策——將基準 security group 推送到每個 VPC。
  • Audit 政策——標記不合規的 security group 規則但不修改。
  • Usage audit 政策——標記未使用或重複的 security groups。
• Network Firewall 政策——將含指定規則集的 AWS Network Firewall 部署到每個涵蓋範圍的 VPC。
• DNS Firewall 政策——將 Route 53 Resolver DNS Firewall rule groups 套用到每個涵蓋範圍的 VPC。
• Palo Alto Networks Cloud NGFW 政策——第三方整合。

範圍與排除

政策指定其範圍——哪些帳號（組織內全部、特定 OU，或排除特定帳號）以及那些帳號內的哪些資源（依 tag、資源類型或全部）。常見模式：

• 「將這個 Web ACL 套用到 production OU 的每個 ALB，但排除標記 Environment=Sandbox 的帳號。」
• 「將這個 Shield Advanced 政策套用到任何帳號的每個 CloudFront distribution。」
• 「將這個基準 security group 套用到 Audit OU 每個帳號的每個 VPC。」

自動補救

Firewall Manager 政策可設定為自動補救——當偵測到不合規資源（例如沒有所需 Web ACL 的新 ALB），Firewall Manager 自動附加 Web ACL。或者，政策可在僅審計模式下運行，向操作者呈現不合規狀況但不修改設定。

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

這是本主題最重要的概念區分，SOA-C02 在每次考試中至少直接考一題。

AWS WAF——僅限 Layer 7 網路流量

AWS WAF 檢查 HTTP 與 HTTPS 請求——URL、headers、body、query string。它附加到支援 Layer 7 的 AWS 服務——CloudFront、ALB、API Gateway、AppSync、Cognito、App Runner、Verified Access。它不檢查非 HTTP 協定、原始 TCP/UDP 封包，或 VPC 內部流量。

AWS Network Firewall——VPC 流量的 Layer 3/4（及有限 L7）

AWS Network Firewall 是部署在 VPC 內的 stateful 防火牆服務。流量透過每個 Availability Zone 中專用的 firewall subnet 路由（通常插在 internet gateway / Transit Gateway 與工作負載 subnet 之間，透過路由表設定）。它檢查：

• Layer 3——來源/目的 IP、協定。
• Layer 4——TCP/UDP 埠、連線狀態。
• Layer 7（有限）——Suricata 相容規則可比對 HTTP method、URI、TLS SNI，以及應用層協定的子集。

Network Firewall 是正確選擇，當你需要 east-west VPC 檢查、非 HTTP 協定過濾、合規要求的出站 URL/網域允許清單，或針對出站流量的 TLS SNI 過濾。

決策矩陣——各運維需求對應的正確服務

Amazon GuardDuty——網路 Findings

Amazon GuardDuty 是帳號層級的威脅偵測服務，持續分析 VPC Flow Logs、DNS 查詢日誌、CloudTrail 事件、EKS audit logs 與 S3 資料事件，找出威脅。在其數十種 finding 類型中，與本主題直接相關的是網路類的 findings。

網路 Finding 類別

• Recon:EC2/Portscan——一個 EC2 instance 正在對另一個主機的廣泛埠進行掃描。表示該 instance 可能遭入侵後在掃描網際網路，或在掃描你自己的 VPC。
• Recon:EC2/PortProbeUnprotectedPort——已知惡意行為者探測了 EC2 instance 上未受保護的埠。突顯對網際網路暴露非預期埠的 instances。
• UnauthorizedAccess:EC2/SSHBruteForce——某個 IP 反覆進行失敗的 SSH 登入嘗試。標準處置是收緊 security group、改用 Session Manager，或套用 Shield/WAF/Network Firewall 封鎖。
• UnauthorizedAccess:EC2/RDPBruteForce——Windows RDP 的相同模式。
• Backdoor:EC2/C&CActivity.B!DNS——EC2 instance 的 DNS 查詢符合已知 command-and-control 網域。入侵的強烈信號。
• CryptoCurrency:EC2/BitcoinTool.B!DNS——EC2 instance 正在查詢已知加密貨幣挖礦池的 DNS。
• Trojan:EC2/DNSDataExfiltration——含有大型編碼 payload 的 DNS 查詢，暗示透過 DNS 進行資料滲漏。
• UnauthorizedAccess:EC2/MaliciousIPCaller.Custom——EC2 instance 正在與你上傳的自訂威脅清單上的 IP 通訊。
• Impact:EC2/PortSweep——EC2 instance 跨多台主機掃描了許多遠端埠。

運維回應

SOA-C02 對高嚴重性 GuardDuty 網路 finding 的標準回應模式：

1. 隔離——對受影響的 instance 套用「拒絕所有」的 security group，阻止進一步通訊。
2. 快照——擷取 EBS 快照用於數位鑑識。
3. 調查——審查 VPC Flow Logs、CloudTrail，以及 instance 的 Systems Manager 清單。
4. 補救——終止受入侵的 instance 並從乾淨的 AMI 替換；輪換任何憑證。
5. 追蹤——在 VPC Flow Logs 中搜尋其他 instances 的類似活動。

這個回應可透過 EventBridge rule on aws.guardduty finding event source → Lambda 或 Systems Manager Automation 自動化，立即執行步驟 1 與 2，同時通知資安團隊進行調查。

WAF 日誌——S3、CloudWatch Logs 與 Firehose

WAF 可將每個被檢查的請求記錄到三個目的地之一，SOA-C02 考測各情境下的正確選擇。

目的地

• Amazon S3 bucket——低成本的長期儲存；使用 Athena 進行臨時查詢。最適合合規保留。
• Amazon CloudWatch Logs——透過 Logs Insights 進行互動式查詢；對 metric filters 設 alarm。最適合即時運維與 dashboards。
• Amazon Kinesis Data Firehose——串流到 Splunk、Datadog、OpenSearch 或任何第三方 SIEM。最適合 SIEM 整合。

每個 Web ACL 只能選擇一個目的地（或使用 Firehose 分發到多個）。日誌包含命中的規則、採取的 action（Allow/Block/Count/CAPTCHA/Challenge）、來源 IP、請求 URI、headers 與 labels。

常見日誌分析模式

• 識別誤判：過濾 action=BLOCK 的日誌，依 terminatingRuleId 分組，找出 managed rule 封鎖合法路徑的情況。
• 被封鎖最多的 IP：在 action=BLOCK 下依 httpRequest.clientIp 聚合。
• Bot Control 類別分布：依含 bot:category:* 的 labels 聚合。
• Rate-based rule 效果：統計 rate-based rule 的 action=BLOCK 次數並與門檻比較繪圖。

抽樣請求

即使未啟用完整日誌記錄，WAF 主控台也提供抽樣請求——每條規則被檢查的請求在 5 分鐘內隨機抽樣，直接顯示在介面中。適合快速疑難排解，但在事故回應期間無法取代完整日誌。

AWS Global Accelerator 與 DDoS 防護

AWS Global Accelerator 使用 AWS 全球網路與兩個靜態 anycast IP 地址，將用戶流量路由到最近的 AWS 邊緣節點，再到你的 origins。它自動包含 Shield Standard，並可作為受保護資源整合 Shield Advanced。

Global Accelerator 為何有助於 DDoS 態勢

• 流量在最近的邊緣節點進入 AWS 網路，Shield Standard 在那裡吸收 volumetric 攻擊。
• 兩個靜態 anycast IP 跨 region 與跨 origin failover 保持穩定，簡化客戶防火牆允許清單的維護。
• Global Accelerator 的 health checks 在 origins 之間自動 failover，隔離 regional 事故。
• 自然與 Shield Advanced 配對，獲得 L7 偵測加 DDoS 費用保護。

對 SOA-C02，Global Accelerator 是正確答案，當情境要求「客戶可以允許清單的靜態 IP、多 region failover，以及邊緣 DDoS 防護」——特別是對無法使用 CloudFront 的非 HTTP 工作負載（遊戲伺服器、IoT）。

情境題型：合法用戶被 Rate-Based Rule 封鎖

這是 SOA-C02 最典型的誤判情境。標準處置流程：

1. 在 WAF 日誌中確認封鎖。 對 WAF log group 執行 Logs Insights 查詢，過濾該用戶 IP 與近期時間範圍。識別 terminatingRuleId——應該是 rate-based rule。
2. 找出根本原因。 確認用戶是否在企業 NAT 後面（一個 IP、多位用戶）或電信商 CGNAT。
3. 選擇正確的解法：
   • 若應用程式在設定了 X-Forwarded-For 的 CDN 或 load balancer 後面，改用 Forwarded IP 作為 aggregate key。
   • 為合作夥伴的 IP 範圍加入比 rate-based rule 更高優先順序的 Allow rule——讓已知安全的來源繞過速率限制。
   • 改用 session cookie 或 API key 作為 aggregate key，依用戶而非依 IP 速率限制。
   • 加入 scope-down statement 將 rate-based rule 縮限到特定 URI 路徑（例如只有 /login），讓一般瀏覽不被計入。
   • 依規則的 CloudWatch CountedRequests metric 觀察到的新流量基準提高門檻。
4. 驗證修正。 重放用戶的流量模式，確認沒有 Block。將任何新的 Allow rule 升級到生產環境。
5. 不要完全停用規則。 Rate-based rule 是 DDoS 防護——停用它會移除那個防護。永遠是調整，而非刪除。

考試上的錯誤答案通常是「移除 rate-based rule」或「將門檻設為 1,000,000」。正確答案是調整聚合方式、scope 或優先順序。

情境題型：Shield Advanced 告警——DDoS 進行中

on-call 在凌晨 2 點收到 Shield Advanced 告警：「CloudFront distribution dXXX 上偵測到 DDoS」。標準處置流程：

1. 開啟 Shield Advanced 主控台。「Events」分頁顯示攻擊向量（UDP 反射、TCP SYN、HTTP flood）、峰值頻寬/RPS，以及受保護資源。
2. 確認應用程式健康狀態。 ALB target 回應時間、5xx 比率與 CloudFront cache hit ratio 的 CloudWatch dashboard。若 origin 已達飽和，擴展（Auto Scaling）並暫時提高 CloudFront cache TTL。
3. 聯繫 Shield Response Team。 開立 Shield 支援案件（需要 Business 或 Enterprise 支援）。SRT 可在攻擊期間即時撰寫 WAF 規則。
4. 套用緩解措施：
   • L3/L4：Shield Standard/Advanced 自動吸收 volumetric 攻擊。
   • L7 HTTP flood：WAF rate-based rule（暫時降低門檻）、Bot Control Targeted、地理封鎖已知攻擊者 region。
   • 憑證填充式 L7：在登入端點套用 WAF Challenge action。
5. 啟用 Shield Advanced 自動 L7 緩解（若尚未啟用）——Shield 會在攻擊期間自動產生 WAF 規則。
6. 監控 DDoS 費用保護——退款在 SRT 驗證事件後出現在 AWS 帳單上。
7. 事後： 審查 Shield 事件報告，記錄緩解過程，更新 runbook，可能永久調整 rate-based rule 門檻。

常見陷阱：WAF Scope CLOUDFRONT 必須在 us-east-1

SOA-C02 的典型陷阱。ap-southeast-1 的一個團隊在該 region 建立了 WAF Web ACL，試圖附加到 CloudFront distribution。主控台拒絕。解法永遠是：CloudFront scope 的 Web ACL 存在於 us-east-1。Web ACL 本身是全球性的（規則評估在全球每個 CloudFront 邊緣節點執行），但設定平面在 us-east-1。其他 region 的 regional Web ACL 只能附加到同一 region 的 regional 資源（ALB、API Gateway 等）。

若架構需要兩者——CloudFront 防護和 ALB 防護——需建立兩個 Web ACL：一個 CLOUDFRONT scope 在 us-east-1 附加到 CloudFront，一個 REGIONAL scope 在 ALB 所在 region 附加到 ALB。它們可以共用自訂 rule groups，但 Web ACL 本身無法共用。Firewall Manager 可用兩個獨立的 WAF 政策（每個 scope 各一個）管理兩者。

常見陷阱：Shield Advanced 每月 $3,000——推薦前先合理化費用

Shield Advanced 每個 AWS 組織每月 $3,000（不是每帳號、不是每資源），且須承諾一年。SOA-C02 有時將 Shield Advanced 作為所有 DDoS 情境的「明顯」答案，但正確答案往往是「WAF rate-based rules + AWS Managed Rule Groups」，因為 Shield Standard 已經免費涵蓋 L3/L4。

Shield Advanced 是正確答案的情況：

• 應用程式是任務關鍵等級，停機成本超過 $36,000/年。
• DDoS 費用保護的經濟效益可自行支付訂閱費（高 CloudFront 資料輸出或高 Route 53 查詢量）。
• 客戶需要攻擊期間的 SRT 介入（SOC 團隊缺乏 24/7 DDoS 回應專業能力）。
• 多個資源可受益於跨組織訂閱（CloudFront + ALB + Route 53）。

Shield Advanced 不必要的情況：

• 應用程式是內部或低重要性服務。
• Shield Standard + WAF + Bot Control 已滿足威脅模型。
• 預算受限且 DDoS 風險低。

常見陷阱：Firewall Manager 需要 Organizations

Firewall Manager 只在啟用所有功能的 AWS Organizations 下運作。獨立帳號無法使用 Firewall Manager。只有 consolidated billing（舊模式）的 Organizations 無法使用 Firewall Manager。管理員帳號的指定必須明確完成。AWS Config 必須在每個 member account 的每個目標 region 中啟用。

若 SOA-C02 情境說「我們想對 50 個獨立 AWS 帳號部署基準 WAF Web ACL」——正確答案是「先將它們移入 AWS Organization，再啟用 Firewall Manager」。這個先決條件無法繞過。

常見陷阱：AWS Network Firewall 不是 AWS WAF

這個陷阱在決策矩陣中已涵蓋，但值得單獨列出：考生常在情境需要 AWS WAF 時選了 AWS Network Firewall，反之亦然，因為兩者名稱都含有「firewall」。

• AWS WAF：Layer 7 網路流量，附加到 AWS 受管端點（CloudFront、ALB、API Gateway）。僅限 HTTP/HTTPS。
• AWS Network Firewall：Layer 3/4（含有限 L7）用於 VPC 流量，部署在有明確路由設定的 firewall subnet。支援所有協定。

若情境提到檢查 HTTP 請求 body 或依用戶速率限制，那是 WAF。若情境提到過濾出站 DNS、封鎖特定 TLS SNI 值，或檢查 east-west VPC 流量，那是 Network Firewall。

SOA-C02 vs SAA-C03：運維視角的差異

SAA-C03 與 SOA-C02 都考 WAF、Shield 與網路防護，但框架有明顯差異。

SAA 考生選擇服務與架構；SOA 考生設定、疑難排解並運維——誤判、規則調整、攻擊回應與政策強制執行缺口。

考試信號——如何辨識 TS 5.1 WAF/Shield 題目

SOA-C02 上的 Domain 5 Task Statement 5.1 題目，一旦見過就認得出固定的形狀。

• 「合法用戶被封鎖」——誤判調整。看 scope-down、aggregate key 類型、更高優先順序的 Allow rules，以及 Count 模式推出策略。
• 「DDoS 進行中 / 偵測到攻擊」——Shield Advanced runbook，含 SRT、自動 L7 緩解，以及攻擊期間 CloudFront cache 被清空。
• 「需要在每個帳號強制相同 WAF」——Firewall Manager WAF 政策。永遠確認情境中提到 Organizations + Config 先決條件。
• 「檢查 EC2 到特定網域的出站流量」——AWS Network Firewall，不是 AWS WAF。TLS SNI / HTTP Host 的 Layer 7 檢查是 Network Firewall 的 stateful Suricata 規則。
• 「減緩登入端點的憑證填充攻擊」——WAF Bot Control Targeted，在登入端點套用 Challenge 或 CAPTCHA，加上 forwarded IP 低門檻的 rate-based rule。
• 「跨所有帳號封鎖已知惡意 IP」——Firewall Manager WAF 政策，包含 AWSManagedRulesAmazonIpReputationList 加自訂 IP set。
• 「偵測受入侵 EC2 instance」——GuardDuty 網路 finding（C&C、port scan、滲漏）+ EventBridge → Lambda 隔離工作流程。
• 「已新增 WAF 規則但未影響流量」——確認 Web ACL 已關聯到資源、確認 scope（CLOUDFRONT vs REGIONAL）、確認規則優先順序（某條更早的規則可能在新規則觸發前就 Allow 了）、確認規則不在 Count 模式。

決策矩陣——各 SysOps 目標對應的網路防護構件

考試時當作查詢表使用。

常見陷阱彙整——WAF、Shield 與網路防護

每次 SOA-C02 考試都會遇到以下幾個誘導選項。

陷阱 1：CloudFront WAF 建在錯誤的 region

CloudFront scope 的 Web ACL 只能存在於 us-east-1。永遠如此。

陷阱 2：Shield Advanced 作為預設的 DDoS 答案

Shield Standard（免費）已涵蓋 L3/L4。Shield Advanced 每月 $3,000 且須承諾一年——需以 SRT 需求、DDoS 費用保護經濟效益或關鍵等級停機成本來合理化。

陷阱 3：Network Firewall 不是 WAF，WAF 也不是 Network Firewall

不同的層級、不同的部署模型、不同的使用情境。閱讀情境中的 HTTP vs 非 HTTP，以及邊緣 vs VPC。

陷阱 4：沒有 Organizations 就使用 Firewall Manager

Firewall Manager 需要 AWS Organizations 的所有功能 + 每個 member account 的 AWS Config + 指定的管理員帳號。獨立帳號無法使用 Firewall Manager。

陷阱 5：Rate-based rule 封鎖企業 NAT

一個 IP 可能代表數千名用戶。改用 forwarded IP、header 或 cookie 聚合；加入 scope-down 縮限規則；或為已知合作夥伴加入 Allow rule。

陷阱 6：規則優先順序理解錯誤

數字越小 = 優先順序越高。第一個終止性 action（Allow 或 Block）獲勝。Count 從不終止。在 priority 100 加入新規則不會覆蓋 priority 10 的現有 Allow。

陷阱 7：第一天就以 Block 模式啟用新 managed rule group

永遠先以 Count 模式啟動。跑一週。審查抽樣請求與日誌。逐條規則升級。

陷阱 8：因誤判而停用規則

調整，不要停用。被停用的規則明天就不會擋住真實攻擊了。

陷阱 9：GuardDuty 作為封鎖層

GuardDuty 偵測，它不封鎖。搭配 EventBridge → Lambda 或 SSM Automation 做自動回應。

陷阱 10：WAF body 檢查大小限制

Regional 資源預設 body 檢查大小 8 KB；CloudFront 16 KB，可調升至 64 KB。大型 payload 若未提高限制會在未被檢查的情況下通過。老練的攻擊者知道這點，會填充 payload 來繞過檢查。

陷阱 11：Web ACL 的 WCU 上限

預設 1,500 WCU，申請配額調升後為 5,000 WCU。含三個大型 managed rule groups 的 Web ACL 放不下。規劃規則預算。

陷阱 12：NLB 無法直接附加 WAF

WAF 可用於 ALB，不可用於 NLB。要保護 NLB 上的非 HTTP 流量，需使用 Shield Standard/Advanced + Network Firewall + security groups + GuardDuty。

FAQ——WAF、Shield 與網路防護

Q1：如何在不搞壞生產環境的情況下推出新的 managed rule group？

永遠先以 Count 模式啟動。將 AWSManagedRulesCommonRuleSet 加入 Web ACL 時，將群組內每條規則的覆寫 action 設為 Count。跑至少一週具代表性的流量——包含週末，確保涵蓋完整流量分布。觀察 CloudWatch WAF metrics（每條規則的 CountedRequests）並在 Logs Insights 中審查 WAF 日誌。找出任何命中的合法路徑——典型誤判包含帶有不尋常 query string 的後台端點、帶有 multipart body 的檔案上傳端點，以及來自第三方的 webhook 接收端。對每個誤判，加入 scope-down statement 排除該路徑、加入更高優先順序的 Allow rule 給該來源，或永久覆寫該特定規則為 Count。只有在誤判集合穩定之後，才以預設的 Block action 升級群組，理想上是逐條規則而非整個群組一次升級。這個推出流程對繁忙的生產應用需要 2–4 週，是 SOA-C02 預期的運維標準。

Q2：Rate-based rule 正在封鎖真實用戶——如何在不失去防護的情況下修正？

不要停用規則。Rate-based rule 仍在防禦真實的 DDoS 攻擊。改為透過 WAF 日誌（過濾 action=BLOCK 與 rate-based rule 的 terminatingRuleId）找出誤判根本原因，並套用以下四種修正之一。(a) 改變 aggregate key 類型——若流量來自設定了 X-Forwarded-For 的 CDN/load balancer，從 IP 改為 FORWARDED_IP，讓每個 NAT IP 的誤判變成每個真實客戶端 IP 的計算。(b) 加入 scope-down statement 縮限規則——只計算 POST /login 請求，而非所有瀏覽。(c) 加入高優先順序 Allow rule 給合作夥伴的 IP 範圍，讓其完全繞過 rate-based rule。(d) 提高門檻，依規則 CountedRequests metric 觀察到的新流量基準調整。SOA-C02 最常見的情境偏好 (a) 加 (b) 的組合——改用 forwarded IP 並縮限到被濫用的端點。

Q3：何時應選擇 Shield Advanced 而非 WAF + Shield Standard？

Shield Advanced 在以下至少一個條件成立時才合理。任務關鍵停機成本超過 $36,000/年（年訂閱費），讓 Shield Advanced 比下次停機更便宜。DDoS 費用保護經濟效益：有高 CloudFront 資料輸出或大量 Route 53 查詢的應用程式，在攻擊期間獲得擴展費用退款，往往可自行支付訂閱費。需要 SRT 介入——SOC 團隊缺乏 24/7 DDoS 回應專業能力。需要 Layer 7 自動緩解——Shield Advanced 在受保護的 CloudFront/ALB 資源受攻擊時自動產生 WAF 規則。需要健康偵測——Shield Advanced 使用 Route 53 health checks 在應用程式壓力下降低偵測門檻。其他情況——內部應用程式、低重要性服務、預算受限的團隊——WAF rate-based rules + AWS Managed Rule Groups + Bot Control + Shield Standard（免費）是正確答案。SOA-C02 常把 Shield Advanced 作為誘人的誘導選項；只在情境明確提出上述理由之一時才選擇它。

Q4：Firewall Manager 和在每個帳號手動建立 Web ACL 有何不同？

Firewall Manager 提供三件手動建立做不到的事。集中政策定義——FM 管理員帳號中的一個政策自動成為 50 個 member accounts 的 Web ACL，無需每帳號的腳本操作。持續合規強制執行——當 member account 的開發者在沒有所需 Web ACL 的情況下建立新的 ALB，FM 在數小時內偵測到不合規資源，並（在自動補救模式下）附加政策定義的 Web ACL。跨組織的審計可視性——FM 主控台依帳號/region 呈現不合規資源，手動建立做不到這點。代價是 FM 的先決條件：AWS Organizations 所有功能、FM 管理員帳號、每個 member account 在每個目標 region 中的 AWS Config，以及 FM 本身的每政策費用。對 5 個帳號的組織，手動建立可能仍然更便宜。對 50+ 個帳號的組織，FM 在運維上是必要的。SOA-C02 預期你在情境暗示多帳號範圍時推薦 FM。

Q5：如何判斷針對特定問題應使用 AWS WAF 還是 AWS Network Firewall？

決定因素是層級與協定。AWS WAF 是 Layer 7 HTTP/HTTPS 服務，附加到 AWS 受管端點——CloudFront、ALB、API Gateway、AppSync、Cognito、App Runner、Verified Access。它檢查 HTTP 請求的 URL、headers、body 與 query string。AWS Network Firewall 是Layer 3/4（含有限 Layer 7）全協定服務，部署在 VPC 的 firewall subnet 中，需要明確路由設定。它在 IP/埠/協定層級檢查封包，並支援 stateful Suricata 規則進行有限的應用層比對（TLS SNI、HTTP Host header、DNS 查詢模式）。若情境描述檢查 HTTP 請求 body、依用戶速率限制，或將防護附加到 ALB，那是 WAF。若情境描述過濾 EC2 出站 DNS 查詢、為合規允許清單特定網域、檢查 east-west VPC 流量，或封鎖非 HTTP 協定，那是 Network Firewall。許多生產架構同時使用兩者——邊緣使用 WAF 處理 HTTP，VPC 內使用 Network Firewall 處理 east-west 與出站流量——SOA-C02 有時要求你認識到完整答案需要兩者兼用。

Q6：CAPTCHA 與 Challenge action 有何不同，各自何時使用？

兩者都有免疫 token 機制：成功後以 cookie 設定 token，在可設定的時間內（預設 5 分鐘，最長 11 小時）讓後續請求繞過該 action。差別在用戶體驗。CAPTCHA 呈現可見謎題——通常是 AWS 自己的圖片辨識謎題，用戶看到彈出視窗並需完成它。CAPTCHA 對包含老練機器人在內的多數機器人有效，但造成明顯的用戶摩擦。Challenge 執行靜默的 JavaScript 瀏覽器指紋檢查，用戶什麼都看不到——真實瀏覽器自動完成挑戰後請求繼續，沒有真正 JavaScript 引擎的機器人靜默失敗並被封鎖。Challenge 對用戶零摩擦，但只對低複雜度機器人有效；帶有隱匿外掛的 Playwright 等老練瀏覽器自動化工具可以通過 Challenge。考試模式：先從 Challenge 開始，用於任何用戶摩擦都不可接受的流程（首頁瀏覽、搜尋）。升級為 CAPTCHA 用於處於老練機器人壓力下的高價值流程（登入、註冊、結帳）。將 Block 保留給確認惡意、從未應有真人出現的流量。

Q7：GuardDuty 網路 finding 顯示 EC2 instance 受入侵時如何回應？

標準 runbook 有五個步驟。(1) 隔離——立即對 instance 套用沒有任何輸入/輸出規則的 security group。這在保留 instance 用於鑑識的同時停止進一步通訊。(2) 快照——對 instance 的每個 volume 擷取 EBS 快照以供離線分析。(3) 調查——審查過去 24 小時 instance 流量的 VPC Flow Logs、instance role 的 IAM activity 的 CloudTrail，以及 Systems Manager Inventory 中的已安裝軟體。找出初始存取向量。(4) 補救——終止受入侵的 instance 並從乾淨的 AMI 替換；輪換 instance 可存取的任何憑證、存取金鑰或 secrets。(5) 追蹤——在整個機群的 VPC Flow Logs 與 GuardDuty findings 中搜尋類似 IOC（相同的 C&C IP、相同的 DNS 查詢模式），找出其他受入侵的 instances。前兩個步驟應自動化——對 aws.guardduty 事件過濾高嚴重性網路 findings 的 EventBridge rule，觸發 Lambda 或 SSM Automation runbook 套用隔離 SG 並建立快照，然後通知資安團隊執行步驟 3–5。SOA-C02 偏好這個自動化回應而非手動清單。

Q8：為什麼我的 Firewall Manager 政策未在 50 個 member accounts 中的 3 個強制執行？

依序確認以下五件事。(1) AWS Config——Firewall Manager 需要在每個目標帳號的每個目標 region 中啟用 Config。若 Config 在失敗的帳號中（或在那些帳號的政策目標 region 中）未啟用，FM 無法偵測資源或強制政策。啟用 Config 並等待清單填充。(2) 帳號排除——重新閱讀政策範圍。政策可能被範圍限定在特定 OU，而失敗的帳號可能不在範圍內，或被 tag 或帳號 ID 明確排除。(3) 受信任存取——Firewall Manager 需要 AWS Organizations 中 fms.amazonaws.com 的受信任存取。若受信任存取被停用，FM 無法在 member accounts 上運作。(4) Service-linked role——FM 在每個 member account 中建立 AWSServiceRoleForFMS；若被刪除，FM 操作失敗。重新執行 FM 啟用步驟以重建。(5) Region 可用性——對 Network Firewall 與 DNS Firewall 政策，底層服務必須在目標 region 中可用；較舊或受限的 region 可能不支援。修正先決條件後，從主控台強制 FM 政策重新整理；補救通常在幾小時內完成。

Q9：WAF 日誌應傳送到哪裡，事故期間應執行哪些查詢？

在生產環境中傳送到兩個目的地。CloudWatch Logs，以供 Logs Insights 即時查詢——on-call 在事故期間的第一個工具——以及透過 Kinesis Data Firehose 傳送到 S3，用於長期保留與 Athena 臨時查詢。Firehose 可同時分發到兩處。「用戶被 WAF 封鎖」事故期間，on-call 的前三個 Logs Insights 查詢：(a) fields @timestamp, httpRequest.clientIp, action, terminatingRuleId | filter action="BLOCK" and httpRequest.clientIp="<user IP>" | sort @timestamp desc | limit 50——找出哪條規則封鎖了特定用戶。(b) fields terminatingRuleId, count(*) as blocks | filter action="BLOCK" | stats count(*) by terminatingRuleId | sort blocks desc | limit 20——找出產生最多封鎖的規則（頂部誤判或頂部真正判斷）。(c) fields httpRequest.clientIp, count(*) as requests | stats count(*) by httpRequest.clientIp | sort requests desc | limit 20——找出最多請求的來源 IP（潛在攻擊者或合法的重度用戶）。這些查詢加上 WAF 主控台的抽樣請求面板，涵蓋了絕大多數事故回應需求。

Q10：沒有 Shield Advanced 預算的小型團隊，最具成本效益的組合是什麼？

預算受限團隊的務實基準配置。AWS Shield Standard（免費、自動）保護 AWS 邊緣的 L3/L4 volumetric DDoS——已預設啟用。AWS WAF Web ACL on CloudFront/ALB，配上三個 managed rule groups：AWSManagedRulesCommonRuleSet（OWASP Top 10 基準）、AWSManagedRulesKnownBadInputsRuleSet（近期 CVE 模式）、AWSManagedRulesAmazonIpReputationList（低成本、高信號的 IP 黑名單）。加入一條 rate-based rule，使用適合你流量模式的 aggregation key——公開網站通常用 forwarded IP，每 5 分鐘 2,000 個請求；敏感端點設更低門檻。啟用 WAF 日誌到 CloudWatch Logs 供即時查詢，以及到 S3 做長期儲存。設定 CloudWatch alarms監控 WAF metrics——BlockedRequests 尖峰、AllowedRequests 驟降。加入 Bot Control Common（若預算許可）——額外的 managed rule group 費用不高，對爬蟲與憑證填充攻擊有顯著效果。這個配置依請求量每月約 $50–200，提供 Shield Advanced 約 80% 的防護，花費大約只有 5%。只有當停機成本或 DDoS 費用保護的經濟效益合理化每月 $3,000 的承諾時，才升級到 Shield Advanced。

延伸閱讀與相關運維模式

• AWS WAF Developer Guide
• AWS WAF Web ACL 概念
• AWS Managed Rule Groups 目錄
• Rate-Based Rule Statement 參考
• AWS WAF Bot Control
• WAF CAPTCHA and Challenge Actions
• Web ACL Capacity Units（WCU）參考
• AWS WAF 日誌記錄
• AWS Shield Developer Guide
• Shield Standard 與 Shield Advanced 比較
• Shield Response Team（SRT）
• AWS Firewall Manager Developer Guide
• Firewall Manager 先決條件
• AWS Network Firewall Developer Guide
• Amazon GuardDuty Finding Types
• AWS Global Accelerator 與 DDoS 防護
• AWS SOA-C02 Exam Guide v2.3（PDF）

WAF、Shield 與網路防護就位後，下一層運維重點是：VPC Configuration and Connectivity（Network Firewall 與 VPC endpoints 依賴的底層網路配管）、Route 53 DNS and CloudFront CDN（CloudFront scope WAF 所在的邊緣層，以及 Shield Advanced L7 緩解發生的地點）、VPC Network Troubleshooting（補充 WAF 日誌的 VPC Flow Log 與 ELB 日誌分析，用於事故回應）、以及 Data Protection: KMS, ACM, Secrets Manager, and Security Findings（在 Shield 與 WAF 之上運作的 GuardDuty/Inspector/Security Hub 資安 findings 層級）。

• VPC 設定、Subnets、NACLs 與私有連線 — SOA-C02 學習筆記
• Route 53 DNS、路由政策與 CloudFront CDN — SOA-C02 學習筆記
• 網路疑難排解：VPC Flow Logs、ELB 日誌與連線診斷 — SOA-C02 學習筆記
• 資料保護：KMS、ACM、Secrets Manager 與資安 Findings — SOA-C02 學習筆記