AWS Config 規則與一致性套件 (conformance packs) 是實現「持續合規」的核心機器，它能將「我們遵循 PCI-DSS」從簡報上的口號變成整個 AWS 組織中自動評估、自動修復並產生稽核證據的現實。在 DOP-C02 考試中，每當情境設定為「確保沒有 S3 儲存桶是公開的」、「自動修復任何未加密的 EBS 磁碟區」、「跨 50 個帳戶為 HIPAA 提供證據」或「不合規資源必須觸發 SNS 警示與 SSM 自動化回滾」時，AWS Config 規則與一致性套件就會出現在網域 6 任務 6.2 與 6.3 中。正確答案總是結合 Config 規則（用於偵測）、一致性套件（用於將規則分組到合規架構中）、Config 彙總器（用於多帳戶匯總）和修復動作（用於自我修復），形成一個閉環系統。
本深度指南將探討你在 DOP-C02 中會遇到的每個 AWS Config 規則與一致性套件原語：組態記錄器 (configuration recorder) 與交付通道機制、AWS 受管規則 vs 自訂 Lambda 規則 vs Guard 規則、帶參數的一致性套件 YAML 範本、組織規則 vs 基於 StackSet 的部署、多帳戶多區域彙總器、透過 Systems Manager 自動化執行手冊進行的自動修復、與 Security Hub 的關係、週期性 vs 組態變更觸發、成本模型，以及典型的專業情境 —— 具有自動修復與稽核證據的登陸區全域持續合規 —— 逐一拆解。
什麼是 AWS Config 規則與一致性套件？
AWS Config 是一項全受管服務，可持續記錄支援的 AWS 資源組態，並根據規則評估這些組態。Config 規則是評估邏輯 —— 受管規則由 AWS 提供，自訂規則以 Lambda 函數或 Guard 政策形式執行。一致性套件是 Config 規則與修復動作的集合，封裝為單個可部署單元，通常代表一個合規架構 (PCI-DSS, HIPAA, NIST 800-53, CIS, FedRAMP)。
為什麼 AWS Config 規則與一致性套件對 DOP-C02 很重要
DOP-C02 任務 6.2 和 6.3 明確要求將「AWS Config 規則」作為必備知識，並具備「在多帳戶與多區域環境中自動化安全控制應用」的能力。Config 也在任務 5.2（「根據事件實施組態變更」）中被引用。專業級情境涉及 50 個帳戶的組織，必須在機群中評估合規性，且不合規資源必須在無需人工干預的情況下自我修復。
五個組成部分
理解 AWS Config 規則與一致性套件需要掌握五個組件：組態記錄器 (configuration recorder) (記錄資源狀態)、交付通道 (delivery channel) (將快照寫入 S3 並將通知傳送到 SNS)、規則 (rules) (評估邏輯)、修復動作 (remediation actions) (不合規時叫用的 SSM 執行手冊) 以及彙總器 (aggregator) (多帳戶匯總)。在 DOP-C02 中，情境通常會隱藏發生故障的組件 —— 某個區域未啟用記錄器、交付通道的 S3 政策缺失、規則有在評估但未附加修復動作、彙總器未獲得成員帳戶授權等。
白話文解釋 AWS Config 規則與一致性套件
AWS Config 規則與一致性套件聽起來像是另一座縮寫詞大山，但三個日常類比可以讓你立即理解它們的結構。
類比 1 — 餐廳衛生稽查系統 (稽查 / 衛生署類比)
想像一個城市有 50 家餐廳分店（你的 AWS 帳戶），全由同一個連鎖集團擁有。AWS Config 是集團總部的衛生稽查計畫，而一致性套件則是稽查清單。
每家分店廚房裡的持續監控 CCTV，記錄冰箱溫度、洗手情況和食物儲存規範，這就是 Config 記錄器 —— 它不負責評判，只負責記錄每個狀態變更。稽查清單上的規則，如「冰箱必須低於 4°C」、「生肉必須放在最底層」、「員工必須每 30 分鐘洗手一次」，這就是 Config 規則。將 47 個獨立規則捆綁成一個品牌計畫 (例如「ServSafe 認證」) 且每家分店都必須遵守的全面食品安全架構，這就是一致性套件 —— Config 提供預建的套件如「PCI-DSS」、「HIPAA」、「NIST 800-53」。將所有 50 家分店的稽查結果匯總到一個監管儀表板的區域衛生局，這就是 Config 彙總器。自動糾正反應 —— 當系統偵測到冰箱超過 4°C 時，自動派遣冷凍維修工 —— 這就是透過 Systems Manager 自動化叫用的修復動作。交付給城市衛生局的年度稽核證據包是 Config 的 S3 快照串流加上一致性套件的合規報告。集團總部從不親自訪問每家分店；稽查持續且自動執行，並對已知違規進行自我修復。
類比 2 — 飛機起飛前與飛行中監控系統 (航空類比)
想像一家航空公司營運著 50 架飛機（你的 AWS 帳戶），每次飛行都必須遵守法規並自我修正偏差。
每秒捕捉每個參數（高度、燃油壓力、控制面位置）的黑盒子飛行資料記錄器，就是 Config 記錄器，它捕捉每個資源的每個組態變更。機長在起飛前執行的起飛前檢查清單 (「艙門已關閉、燃油充足、應答機已設定」)，對應到在組態變更時評估的 Config 規則 —— 每個新資源在「上線」前都會被評估。當機艙壓力下降或引擎振動超過閾值時提醒駕駛艙的持續飛行監控，這就是每 1, 3, 6, 12 或 24 小時執行一次的 Config 週期性觸發規則。將數百項獨立檢查捆綁成一項認證的法規架構包 (如 FAA Part 121 營運規範、EASA 合規、ICAO 標準)，這就是一致性套件。在一面螢幕上監控所有 50 架飛機並識別任何不合規飛行狀態的機群營運中心，這就是 Config 彙總器。當感測器偵測到偏差時調整配平的自動駕駛自我修正，這就是叫用 SSM 自動化執行手冊的 Config 修復動作。保留 7 年供監管檢查的維修日誌則是 S3 中的 Config 快照串流。就像航空業一樣，AWS Config 規則與一致性套件讓合規性變得持續化、機群化且具備自我修復能力。
類比 3 — 汽車製造組裝線品質門檻 (製造業類比)
想像一個擁有 50 條組裝線（你的 AWS 帳戶）並生產數千輛汽車的汽車工廠。AWS Config 規則與一致性套件就是品質門檻系統。
每個組裝站記錄每個扭矩設定、噴漆厚度、焊接參數的工站級相機與感測器，就是記錄資源狀態的 Config 記錄器。每個工站結束時檢查「扭矩在 35-40 Nm 內」、「噴漆厚度 80-100 微米」是否符合規格的檢查門檻，就是 Config 規則。將數百項獨立品質標準捆綁成一個面向客戶認證的完整車輛型式認證架構 (如 Euro NCAP 五星、IIHS 首選安全獎)，這就是一致性套件。顯示所有 50 條線實時合規情況的全廠 MES 儀表板，就是 Config 彙總器。任何未能通過門檻的車輛都會被自動引導進行修正的返修站，就是透過 SSM 自動化執行的 Config 修復動作。為應對 15 年責任期而保留的生產記錄，就是 Config 的 S3 快照保留。當一條生產線偏離規格時，系統會在下一輛車時就發現，而不是在發運 1,000 輛缺陷車之後。AWS Config 規則與一致性套件是將相同概念應用於雲端組態：檢查每一次變更、預先包裝多標準認證，並透過自我修復保持機群合規。
組態記錄器 — 持續合規的基石
組態記錄器 (Configuration recorder) 是在每個帳戶、每個區域中啟用的第一件事。沒有它，任何規則都無法評估任何內容。
記錄器機制
組態記錄器是每個區域、每個帳戶的代理程式 (由 AWS 管理，不需你安裝)，每當支援的資源發生變更時，它就會捕捉其組態。每個捕捉到的狀態稱為一個組態項目 (Configuration Item, CI) —— 這是一個包含資源中繼資料、組態、關聯性及狀態的 JSON 文件。記錄器將 CI 寫入交付通道並向 EventBridge 發出變更事件。
資源類型覆蓋範圍
記錄器可以記錄所有支援的資源類型，或是特定的子集。專業級合規性要求記錄所有資源 —— 窄範圍記錄會留下盲點。AWS Config 支援 200 多種資源類型，涵蓋了大多數 AWS 服務。新推出的服務可能需要幾週時間才會出現；請查看支援的資源頁面。
交付通道 — S3 與 SNS
交付通道 (Delivery channel) 將組態歷程記錄檔案 (記錄 6 小時視窗內的每一次變更) 和組態快照 (時間點庫存) 寫入 S3 儲存桶，並將組態變更通知與合規變更通知傳送到 SNS 主題。慣例：透過跨帳戶儲存桶政策寫入 Log Archive 帳戶儲存桶。儲存桶必須允許 config.amazonaws.com 以正確的金鑰前綴進行 PutObject。
組態歷程記錄 vs 組態快照
歷程記錄 (History) 是變更發生時的串流。快照 (Snapshot) 是週期性的完整庫存 (預設為每天)。對於稽核證據來說，兩者都有用 —— 歷程記錄顯示什麼時候改了什麼；快照證明了在已知時間點的世界狀態。兩者都以 JSON 格式存放在 S3 中。
記錄器成本模型
Config 按記錄的組態項目計費 (大多數區域每個 CI 0.003 美元)，外加按規則評估次數計費 (每次評估 0.001 美元)。高變動率環境 (CI/CD 管線頻繁啟動與刪除 EC2 機群) 每小時可能產生數千個 CI。成本控制：將記錄限制在與合規相關的資源類型，或是對低流量資源使用「連續記錄搭配每日記錄」模式 (較新功能)。
AWS Config 規則 — 受管、自訂 Lambda 與 Guard
規則是產生合規性發現結果的評估邏輯。
AWS 受管規則
AWS 提供 200 多種受管規則，涵蓋常見的合規檢查。DOP-C02 經常提到的範例包括：
s3-bucket-public-read-prohibited—— 如果任何 S3 儲存桶允許公開讀取則失敗。ec2-instance-no-public-ip—— 如果 EC2 執行個體具有不在允許清單中的公有 IP 則失敗。iam-password-policy—— 檢查密碼政策是否符合複雜度要求。encrypted-volumes—— 如果 EBS 磁碟區未加密則失敗。rds-storage-encrypted—— 如果 RDS 儲存未加密則失敗。cloudtrail-enabled—— 如果未啟用 CloudTrail 則失敗。restricted-ssh—— 如果任何安全群組在連接埠 22 上允許 0.0.0.0/0 則失敗。root-account-mfa-enabled—— 如果根使用者缺少 MFA 則失敗。
受管規則是免程式碼的，只需啟用並設定參數。
自訂 Lambda 規則
當受管規則無法涵蓋檢查需求時，編寫一個 Lambda 函數，接收 ConfigurationItem 事件，執行評估邏輯，並透過 Config API 回報 COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE。常見使用案例：標籤政策強制執行 (每個資源必須有 costCenter 標籤)、命名規範強制執行、自訂加密金鑰要求 (必須使用特定的 KMS CMK)。
自訂 Guard 規則
AWS CloudFormation Guard 是一種用於根據規則評估 JSON/YAML 的「政策即程式碼」語言。Config 支援將 Guard 規則作為 Lambda 的替代方案 —— 使用 Guard 語法編寫規則並部署為 Config 規則，無需維護 Lambda 函數。對於宣告式檢查，比 Lambda 規則更便宜且簡單。
觸發類型 — 組態變更 vs 週期性
規則的觸發方式有兩種：
- 組態變更 (Configuration changes)：當資源的 CI 發生變更時立即評估。最適合「任何新資源都必須合規」的情境。延遲通常在分鐘級以下。
- 週期性 (Periodic)：每 1, 3, 6, 12 或 24 小時評估範圍內的所有資源。最適合跨資源檢查 (例如：是否有任何 IAM 使用者擁有未使用的存取金鑰？ —— 這需要同時掃描所有使用者)。
規則範疇與參數
規則可以限定在特定的資源類型、標籤或資源 ID。參數用於自訂檢查 (例如：s3-bucket-public-read-prohibited 沒有參數；iam-password-policy 的參數可設定 MinimumPasswordLength, RequireSymbols, MaxPasswordAge)。同一個規則，不同的參數集 —— 構成不同風味的一致性套件。
在編寫自訂規則之前，務必先窮盡 AWS 受管規則。 受管規則無需維護程式碼，當 AWS 增加新的合規維度時會自動更新，且經過 AWS 的準確性審查。自訂 Lambda 規則會增加營運開銷 (Lambda 打包、IAM、CloudWatch Logs、執行階段升級、Lambda 成本)。僅在沒有受管規則能涵蓋組織特定政策 (如標籤規範、命名標準) 時才使用自訂規則。在 DOP-C02 中，如果存在受管規則，「部署受管規則」就是正確答案；只有在檢查確實是自訂的情況下，「編寫 Lambda」才是正確答案。
一致性套件 — 合規架構即程式碼
一致性套件 (Conformance packs) 將規則 + 修復動作 + 參數捆綁成一個單個可部署單元。
一致性套件結構
一致性套件是一個 YAML 格式且具備 CloudFormation 語法的範本，包含：
AWS::Config::ConfigRule資源清單- 選用的
AWS::Config::RemediationConfiguration資源 - 選用的用於按環境調整的參數 (Parameters)
- 選用的個別規則輸入參數 (InputParameters)
透過單次 API 呼叫 (PutConformancePack) 進行部署；所有規則與修復動作會原子性地套用。
AWS 範例一致性套件
AWS 發佈了對應常用架構的預建一致性套件：PCI-DSS, HIPAA, NIST 800-53 Rev 5, CIS AWS Foundations Benchmark, FedRAMP Moderate/High, AWS Foundational Security Best Practices, ISO 27001 等。可以從 conformance-packs GitHub 倉庫 瀏覽並複製。
自訂一致性套件
透過在 YAML 範本中結合受管規則與自訂規則來編寫你自己的套件。常見模式：複製 AWS PCI-DSS 套件，加入 5-10 個組織特有的標籤/加密規則，部署為公司的「Acme 生產基準」套件。
一致性套件合規評分
每個套件都會報告一個整體合規評分 (合規規則與資源的百分比)。Config 主控台中的套件級儀表板會顯示每個規則與資源的通過/失敗情況。利害關係人查看套件級評分；稽核員則查看單一資源的證據。
一致性套件是 Config 規則與修復動作的可部署捆綁包，通常代表一個合規架構 (PCI-DSS, HIPAA, NIST, CIS)。 套件範本使用 YAML CloudFormation 語法。AWS 為主要架構發佈了預建套件；客戶可以為組織特定的基準編寫自訂套件。部署是原子性的 —— 所有規則與修復同時套用。每個套件的合規評分會彙整成一個百分比，供利害關係人儀表板使用。在 DOP-C02 中，「在所有帳戶部署 PCI-DSS 控制項」是一致性套件的情境；「部署這一個規則」是 Config 規則情境；「部署完整的合規基準」是一致性套件。
多帳戶部署 — 組織規則與一致性套件
專業級合規性要求全機群部署。AWS Config 提供兩條路徑。
組織 Config 規則 (Organizational Config Rules)
從 Organizations 管理帳戶或 Config 委派管理員使用 PutOrganizationConfigRule 將規則部署到包含在組織中的每個區域、每個成員帳戶。當新帳戶加入時，規則會自動部署。限制：管理帳戶本身不會評估組織規則 —— 僅成員帳戶會評估。這要求中央帳戶本身需要使用另一個獨立部署的相同規則。
組織一致性套件 (Organizational Conformance Packs)
PutOrganizationConformancePack 將整個套件部署到所有成員帳戶。同樣具備新帳戶自動上線功能。同樣存在管理帳戶豁免的限制。
CloudFormation StackSets 替代方案
在組織規則出現之前，唯一的方法是使用 CloudFormation StackSets —— 編寫一個包含 AWS::Config::ConfigRule 資源的堆疊，並透過 StackSet 部署到 OU。StackSets 對於混合部署（規則 + 非 Config 資源在同一個堆疊中）仍然有用，但純粹的 Config 規則使用組織規則會更簡單。
委派管理員 (Delegated Admin)
指定一個成員帳戶（通常是 Audit/Security 帳戶）作為 Config 委派管理員。委派管理員可以在不使用管理帳戶的情況下管理組織規則與一致性套件。管理帳戶豁免於 SCP 且最好保持最小化 —— DOP-C02 的最佳實務是從委派管理員營運 Config。
多帳戶彙總器 — 單一視窗合規視圖
Config 彙總器 (Aggregator) 將來自多個帳戶與區域的資料收集到一個帳戶中，進行統一查詢。
彙總器設定
在 Audit/Security 帳戶中建立彙總器。從每個成員帳戶授權彙總器（每個帳戶/區域執行一次）或是使用基於 Organizations 的授權（自動授權每個成員）。彙總器會從所有來源提取合規發現結果、組態項目與資源庫存。
彙總器不能做什麼
彙總器不強制執行規則 —— 它僅彙整已在其他地方部署的規則所產生的結果。要部署規則，請使用組織規則或 StackSets。彙總器是唯讀的匯總。
跨帳戶進階查詢
Config 進階查詢 (SQL 語法) 針對彙總資料執行：「列出所有帳戶中 KeyName 為 null 的每個 EC2 執行個體」、「列出所有沒有版本控制的 S3 儲存桶」、「列出所有沒有加密的 RDS 執行個體」。這取代了逐一帳戶進行的臨時稽核。
彙總器 vs CloudTrail Lake
彙總器回答的是「現在存在什麼組態狀態？」CloudTrail Lake 回答的是「歷史上發生了哪些 API 行動？」兩者皆可查詢、支援多帳戶與多區域。彙總器用於狀態；CloudTrail Lake 用於事件。兩者應配合使用。
自動修復 — 透過 SSM 自動化完成閉環
沒有修復的偵測只是一個半完成的系統。DOP-C02 期望你完成這個閉環。
修復機制
將修復組態 (remediation configuration) 附加到 Config 規則。當規則回報資源為 NON_COMPLIANT 時，Config 會叫用一個 Systems Manager 自動化執行手冊，並將資源 ID 作為參數傳入。執行手冊執行修正行動 —— 停用公開 S3 存取、啟用 EBS 加密（可行時）、終止不合規的 EC2、附加缺失的標籤、重啟服務。
自動 vs 手動修復
修復可以是自動的（Config 在資源不合規時立即叫用）或手動的（合規團隊審查後在主控台點擊「修復」）。自動化是針對低風險修復（啟用加密、新增標籤）的目標；手動對於高影響行動（終止執行個體、更改生產 VPC 的安全群組）則更明智。
SSM 自動化執行手冊
AWS 發佈了 200 多個用於常見修復的執行手冊。範例：
AWS-DisableS3BucketPublicReadWrite—— 移除儲存桶的公開 ACL。AWS-EnableS3BucketEncryption—— 套用預設加密。AWS-EnableCloudTrail—— 重新啟用已停用的追蹤。AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules—— 從安全群組中移除 0.0.0.0/0 入站規則。
自訂執行手冊是 JSON/YAML 文件，包含叫用 AWS API、Lambda 或指令碼的步驟。請根據組織特定的修復邏輯編寫。
重試與失敗行為
修復具有可設定的重試次數 (預設為 5) 與速率限制 (每分鐘操作數)。失敗的修復會保持不合規狀態；可以透過重新評估規則來觸發重試。務必將修復叫用記錄傳送到 CloudWatch Logs 以便稽核。
陷阱：在未先在非生產帳戶試點的情況下，對會更改生產狀態的規則啟用自動修復。 一個帶有 AWS-StopEC2Instance 修復且評估 ec2-instance-no-public-ip 的規則，在部署那一刻會關停所有正當的面向公眾的 EC2。務必在沙箱帳戶試點修復，驗證執行手冊能處理邊緣情況，並將自動修復保留給低爆炸半徑的修正 (加密設定、ACL、標籤)。高影響的修復應設為手動，或由一個諮詢變更管理 API 的 EventBridge → Lambda 閘道函數控管。
Config 規則與 Security Hub — 避免重複覆蓋
Security Hub 也維護合規標準。請理解兩者的關係。
Security Hub 標準使用 Config 規則
Security Hub 的標準 (AWS Foundational Security Best Practices, CIS, PCI-DSS, NIST) 會在每個啟用的帳戶中部署底層的 Config 規則。當你啟用 Security Hub 標準時，Config 規則會自動出現在帳戶中。Security Hub 會將這些規則的結果彙總到跨帳戶儀表板。
何時使用哪一個
- Security Hub 標準：熱門架構的最簡單路徑。一鍵啟用、自動部署規則、自動彙整結果。
- Config 一致性套件：更高的靈活性 (自訂套件、自訂規則、自訂修復)。當 Security Hub 標準不符合預期基準或需要修復動作時使用。
兩者可以共存；只需避免重複部署規則（這會使 Config 評估成本翻倍）。DOP-C02 問題有時會測試是否知道兩條路徑皆存在；正確答案取決於情境強調的是「一鍵合規」還是「自訂修復」。
AWS Config 規則與一致性套件的成本控制
在變動率高的環境中，Config 可能會變得很昂貴。DOP-C02 期望考生對此有所認識。
成本驅動因素
- 記錄的組態項目 (一般每個 CI 0.003 美元)
- 作用中的規則評估 (一般每次評估 0.001 美元)
- 一致性套件評估 (按同樣的每次評估費率計算)
- S3 儲存組態歷程記錄與快照
- 自訂規則的 Lambda 調用
一個記錄所有資源類型且擁有 200 條作用中規則的 50 帳戶組織，每月 Config 支出可能達到 5,000 到 20,000 美元。
成本降低模式
- 儘可能將記錄限制在與合規相關的資源類型。
- 在不使用的區域停用 Config。
- 對於大批量檢查，在無需分鐘級偵測的情況下，使用週期性觸發規則代替變更觸發規則。
- 使用 Guard 規則代替 Lambda 規則以消除 Lambda 調用成本。
- 將發現結果彙總到一個 Audit 帳戶；如果 Security Hub 彙整已足夠，不要在每個帳戶都執行一致性套件。
提示：從 Config 委派管理員（通常是 Audit/Security 帳戶）部署組織規則與一致性套件，而不是從管理帳戶。 委派管理員可保持管理帳戶最小化（最佳實務 —— 豁免於 SCP、網路釣魚風險目標）。成員帳戶會自動加入。由 Control Tower 或 Account Factory 建立的新帳戶會自動接收規則。在同一個委派管理員中結合多帳戶多區域彙總器，以便透過 Config 進階查詢 SQL 進行單一視窗查詢。
組態歷程記錄與漂移偵測 — 合規之外
Config 還具備漂移偵測與取證功能。
來自 CloudFormation 堆疊的漂移
CloudFormation 漂移偵測會將堆疊範本與實際資源狀態進行比較並標記差異。Config 記錄器是底層的真理來源。將堆疊漂移偵測與 Config 規則結合，可以同時捕捉「在 CFN 之外建立的資源」以及「CFN 管理的資源在 CFN 之外被修改」。
取證時光旅行
Config 的資源時間軸會顯示資源的每個狀態以及每次關聯性變更。在調查「誰在週二更改了這個安全群組的入站規則？」時，Config + CloudTrail 可以還原完整經過 —— Config 顯示變更了什麼，CloudTrail 顯示是誰改的。
資源關聯性
Config 追蹤關聯性（例如：此 EC2 執行個體使用此安全群組、此 VPC、此 IAM 角色）。這對於影響分析很有用（「如果我刪除此 IAM 角色，哪些 Lambda 函數會壞掉？」）。Config 進階查詢可以遍歷這些關聯性。
AWS Config 規則與一致性套件心智模型。 Config 記錄器捕捉每個資源的組態變更。規則按資源評估合規性。一致性套件將規則捆綁成合規架構 (PCI, HIPAA, NIST)。組織規則與套件自動部署到每個成員帳戶。彙總器將發現結果匯總到一個 Audit 帳戶。SSM 自動化執行手冊修復不合規資源。CloudTrail Lake 回答「誰在什麼時候做了什麼」；Config 回答「現在狀態如何且是否合規」。在 DOP-C02 中，標準的專業答案是：Audit 帳戶作為委派管理員，執行具備自動修復功能的組織一致性套件，彙總器提取所有發現結果，Security Hub 顯示儀表板，CloudTrail Lake 回答取證問題。
常考陷阱 (Common Exam Traps)
DOP-C02 有可預測的 AWS Config 規則與一致性套件陷阱：
- 忘記記錄器必須按區域啟用 —— 在未啟用記錄器的區域，規則根本不會進行評估。上線新區域需要記錄器 + 交付通道 + 規則部署。
- 管理帳戶豁免於組織規則 —— 透過
PutOrganizationConfigRule部署的規則僅套用於成員帳戶。管理帳戶的合規性需要單獨在管理帳戶中部署一條普通規則。 - 將彙總器與規則部署混淆 —— 彙總器僅收集已部署規則的結果；它不負責部署規則。請使用組織規則或 StackSets 進行部署。
- 自動修復破壞生產 —— 對於具破壞性的執行手冊（如終止不合規 EC2）啟用自動修復，會在規則部署時觸發全機群行動。應先試點，必要時透過 EventBridge 控管。
- 在受管規則存在時編寫自訂 Lambda 規則 —— 營運浪費。務必先檢查受管規則清單。
- 需要組態變更偵測時卻使用週期性觸發 —— 週期性規則每 1-24 小時評估一次；新的不合規資源可能存在數小時。對於「每個新資源在建立時必須合規」的要求，請使用變更觸發。
- 一致性套件與 Security Hub 標準重複 —— 為同一個架構同時啟用兩者會部署兩份相同的規則，使 Config 評估成本翻倍。每個架構選擇一條路徑。
- 交付通道 S3 儲存桶缺少 Config 服務主體權限 —— 記錄器無法寫入，歷程記錄會消失。儲存桶政策必須允許
config.amazonaws.com執行 PutObject。 - CI/CD 環境中的 CI 成本爆炸 —— 高變動率的 EC2 機群會不斷產生 CI。應限制記錄的資源類型或使用每日記錄模式。
- 忘記參數化規則中的參數 ——
iam-password-policy會根據預設參數進行評估，除非被覆蓋。一致性套件會根據架構要求提供參數。
DOP-C02 考試優先級 — 合規性中的 AWS Config 規則與一致性套件。 此主題在 DOP-C02 考試中佔有很大權重。掌握每項 AWS 服務所揭露的權衡、決策邊界以及成本/效能觸發因素 —— 考試將測試那些取決於了解哪項服務是錯誤答案的情境，而不僅僅是哪項是正確的。
FAQ
Q1：何時該使用 Config 規則 vs Security Hub 控制項？ 兩者都能產生合規性發現結果。Security Hub 控制項對於熱門架構更容易（一鍵啟用）。Config 規則與一致性套件則允許自訂套件、自訂規則與修復動作。對於 AWS 在兩處都發佈標準的 PCI-DSS / HIPAA / CIS，請擇一使用以避免重複評估成本。對於組織特定的基準，一致性套件是唯一路徑。
Q2：如何將一致性套件部署到我組織中的所有 50 個帳戶？
透過 register-delegated-administrator 指定一個 Config 委派管理員（通常是 Audit 帳戶）。從委派管理員使用套件範本呼叫 PutOrganizationConformancePack。AWS 會部署到每個包含區域中的每個成員帳戶，並自動部署到新帳戶。管理帳戶豁免，若需評估則需單獨部署。
Q3：自訂 Lambda 規則與 Guard 規則有什麼區別？ Lambda 規則在你的 AWS Lambda 函數中執行自訂程式碼 —— 按調用次數付費、維護執行階段、管理 IAM。Guard 規則使用 CloudFormation Guard 政策即程式碼語法編寫 —— 宣告式、無需 Lambda、由 AWS 執行評估。對於宣告式檢查，優先選擇 Guard；對於具狀態邏輯（諮詢外部 API、複雜的多資源關聯），則需要 Lambda。
Q4：如何自動修復不合規的 S3 儲存桶？
將修復組態附加到相關規則（例如 s3-bucket-public-read-prohibited），引用 Systems Manager 自動化執行手冊（例如 AWS-DisableS3BucketPublicReadWrite）。設定自動執行。當規則回報不合規時，Config 會叫用帶有儲存桶參數的執行手冊，執行手冊會移除公開存取。CloudTrail 會記錄此修復動作。
Q5：我可以編寫引用 AWS 之外資料的 Config 規則嗎？ 可以，透過自訂 Lambda 規則實現。Lambda 可以呼叫外部 API（例如 CMDB）來判斷合規性。這在營運上比自足式規則更沉重；常見用法是將資源標籤與外部真相來源進行比較。
Q6：Config 彙總器與 Security Hub 彙總有什麼不同？ Config 彙總器收集 Config 特有的資料（組態項目、規則評估、進階查詢）。Security Hub 則彙整發現結果（Config 發現結果、GuardDuty, Inspector, Macie, Access Analyzer, 第三方）。為了獲得統一的合規狀態，請彙整 Security Hub。為了進行深層組態查詢（跨所有資源的 SQL），請使用 Config 彙總器。大多數組織兩者都會啟用。
Q7：變更觸發規則與週期性規則的成本差異為何？ 兩者每次評估的成本相同。差別在於數量：變更觸發是按每個資源的每個 CI 觸發；週期性是每 N 小時對所有範圍內資源觸發一次。在高變動帳戶中，變更觸發可能更貴；在穩定帳戶中，週期性可能更貴。應根據使用案例而非成本來匹配觸發類型。
Q8：如何從規則中排除特定的資源？
可以設定規則的範疇以包含特定的標籤/資源 ID，或是編寫規則邏輯讓排除的資源返回 NOT_APPLICABLE。對於沒有排除參數的受管規則，自訂 Lambda 是繞過方法。對於一致性套件規則，可以在支援的情況下透過套件參數進行覆蓋。
Q9：Config 可以偵測 CloudFormation 堆疊的漂移嗎？
間接地可以。CloudFormation 有自己的 DetectStackDrift API，底層使用 Config 記錄的狀態。Config 規則 cloudformation-stack-drift-detection-check 會回報處於 DRIFTED 狀態的堆疊。結合 EventBridge 可以在偵測到漂移時發出告警。
Q10：如何在合規規則過於吵雜的沙箱/非生產帳戶中處理 Config？
在純沙箱帳戶中完全跳過 Config（節省成本、安全風險低）。對於應執行規則但需放寬執行的帳戶，部署一個帶有放寬參數（例如更長的密碼輪換、更寬的允許 IP 範圍）的自訂一致性套件，而不是生產套件。為 OU 加上標籤，並在 PutOrganizationConfigRule 上使用 Filter 來限定特定的 OU。
總結 — AWS Config 規則與一致性套件心智模型
AWS Config 規則與一致性套件將合規性從週期性稽核轉變為持續、自動且具備自我修復能力的系統。在 DOP-C02 任務 6.2 和 6.3 中，正確答案總是結合了：在每個帳戶、每個區域啟用組態記錄器；從委派的 Audit 帳戶部署組織一致性套件；針對低風險修正使用 SSM 自動化進行自動修復；針對高影響行動使用手動修復；使用多帳戶彙總器進行統一查詢；以及使用 Security Hub 顯示發現結果級儀表板。每個專業級合規情境都會融合其中三個或更多組件。
成熟的 DOP-C02 答案模式是分層偵測：受管規則涵蓋 80% 的常見檢查，自訂 Guard 或 Lambda 規則涵蓋組織特定政策，一致性套件將它們捆綁為與框架對齊的發佈，組織部署確保全機群覆蓋，彙總器提供單一視窗，而 SSM 自動化則透過自我修復完成閉環。單一規則的答案在專業級中通常是干擾項。