Systems Manager (SSM) 是 DOP-C02 中機群配置管理的主力。如果說 CloudFormation 負責基礎設施的佈署，那麼 State Manager 則確保運行中的執行個體保持在所需的軟體狀態，而 Patch Manager 則根據合規排程交付並報告作業系統與應用程式的修補程式。結合 Run Command、自動化 (Automation)、維護時段 (Maintenance Windows)、庫存 (Inventory) 和 Distributor，它們構成了網域 2.3（「針對複雜任務的自動化解決方案」）和網域 5.2（「針對事件的配置變更」）所測試的營運層。
本指南假設你已經知道什麼是 SSM Agent，以及 EC2 執行個體需要具備 AmazonSSMManagedInstanceCore 政策的執行個體描述檔才能註冊。DOP-C02 的重點在於：State Manager 關聯 (associations) vs Run Command vs 自動化、修補基準規則與核准延遲、透過標籤建立的修補群組、維護時段與註冊的目標/任務、合規報告、內部部署伺服器的混合啟動，以及關於修補頻率、僅掃描 (scan-only) vs 掃描並安裝 (scan-and-install) 以及覆蓋清單之間的微妙區別。
為什麼 SSM State Manager 與 Patch Manager 對 DOP-C02 很重要
DOP-C02 明確將「自動化系統庫存、配置和修補管理（例如 Systems Manager、AWS Config）」列為網域 2.3 的一項技能。根據考後報告，SSM 情境是最容易混淆的主題群之一：考生知道單個 SSM 組件，但會糾結該選哪一個。「團隊需要確保每台帶有特定標籤的 EC2 執行個體都安裝並運行了 CloudWatch Agent，如果有人將其移除，則重新安裝」 —— 這是 State Manager（聲明式、持續性），而非 Run Command（命令式、單次性）。「團隊需要在三個時區的各自夜間時段為 5,000 台執行個體進行修補」 —— 這是「維護時段 + Patch Manager + 修補群組」，而非按計劃觸發的 Lambda。
考試還會區分 State Manager 與具備補救功能的 AWS Config 規則：兩者都能讓資源保持在所需狀態，但它們針對的層級不同。Config 監控 AWS 資源配置；State Manager 監控執行個體作業系統內部。了解題目針對哪一層是排除錯誤選項的第一步。
- SSM Agent：安裝在 EC2/內部部署主機上的守護程序，負責輪詢 SSM 以獲取指令、關聯和庫存。
- 受管執行個體 (Managed instance)：任何在 SSM 註冊並在 Fleet Manager 中可見的主機（EC2 或內部部署）。
- State Manager 關聯 (association)：目標（執行個體 ID、標籤、資源群組）與 SSM 文件之間的綁定；State Manager 讓目標在定義的排程上保持與文件的一致性。
- SSM 文件 (SSM Doc)：JSON/YAML 腳本：
Command(Run Command)、Automation(工作流)、Session(Session Manager)、Package(Distributor)、ApplicationConfiguration(AppConfig) 等。 - Run Command：命令式、針對目標單次執行 Command 文件。
- 自動化 (Automation)：編排的多步驟工作流（通常是 AWS 提供的執行手冊，如
AWS-RestartEC2Instance）。 - 修補基準 (Patch baseline)：一組規則（嚴重性、分類、核准延遲），決定哪些修補程式會被自動核准。
- 修補群組 (Patch group)：將執行個體映射到特定修補基準的標籤值（
Patch Group=production）。 - 維護時段 (Maintenance window)：具有註冊目標和任務（Run Command、自動化、Lambda、Step Functions）的週期性時間窗口；支援下班後的修補。
- SSM 庫存 (Inventory)：收集安裝的應用程式、檔案、網路配置、服務和每個執行個體的自定義庫存的中繼資料收集器。
- 混合啟動 (Hybrid activation)：讓內部部署伺服器使用 IAM 服務角色在 SSM 註冊為受管執行個體的權杖與 ID 對。
- 參考資料：https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html
白話文解釋 SSM 狀態與修補管理
這些服務可以清晰地對應到非軟體領域的營運模式。三個維度涵蓋了聲明式與命令式的區別、修補生命週期以及維護時段的機制。
類比 1：辦公大樓的清潔服務
想像一棟 50 層的辦公大樓。Run Command 是一次性的清潔請求 —— 「派清潔工去 14 樓清理打翻的東西，然後離開」。一次往返，一份工作，沒有後續。State Manager 是常駐清潔合約 —— 「每個樓層必須在每個工作日晚上吸塵，每個洗手間每天補充物資；如果你發現肥皂盒空了，自動補滿」。持續、聲明式、自我修復。自動化 (Automation) 是多步驟的搬出工作流 —— 「清洗地毯、刷牆、更換天花板磁磚、歸還鑰匙」 —— 作為單個協調程序運行。
Patch Manager 是 空調 (HVAC) 維護排程：規則規定「每月維修所有 5 年以上的熱泵，所有較新的熱泵每季維修一次」，大樓管理員（修補基準）在延遲 7 天后自動核准哪些單元需要維修（以便在部署前審查緊急修補程式）。修補群組是大樓區域 —— 有些樓層標記為 Production（任務關鍵，需要完整驗證的謹慎修補），有些標記為 Lab（激進修補，壞了也沒關係）。
維護時段是下班後的服務時間：沒人想在辦公時間停空調，因此所有重型維護都安排在晚上 11 點到凌晨 5 點。在窗口內，註冊的任務以並行限制受控執行。
類比 2：汽車經銷商服務部門
經銷商每週為數百輛車提供服務。State Manager 是常駐服務計劃 —— 「由客戶 X 擁有的每輛車，其油壓感測器韌體必須符合製造商的最新發布；如果感測器被更換且運行舊韌體，則自動重新刷新」。Run Command 是一次性召回通知 —— 「這批 200 個車身號碼 (VIN) 的安全氣囊韌體需要更新一次」。自動化 (Automation) 是多步驟的交車前檢查 —— 「運行診斷、更換座艙空氣濾網、加滿冷卻液、清洗外觀」。
具備修補基準的 Patch Manager 是製造商的服務活動規則 —— 「任何分類為『嚴重』或『高』的缺陷在公告 3 天后自動套用；『中』每週審查；『低』推遲到下次排定服務」。修補群組是車隊客戶層級 —— 政府客戶 (Patch Group=critical-fleet) 獲得具有 0 天核准延遲的最嚴格基準；實驗用車 (Patch Group=test-fleet) 則立即獲得最新修補程式進行驗證。
維護時段是維修車位時間：每個客戶獲得一個週期性的時段（「週一早上 6 點到 10 點」），車位技師（Run Command 目標）在並行限制下執行一組註冊的任務（機油、輪胎、韌體）（一次維修不超過 5 輛車）。
類比 3：醫院藥物核對工作流
醫院每天為每位患者核對藥物。State Manager 是常駐核對規則 —— 「每位入院患者的藥物清單必須與醫生的當前醫囑相符；如果藥房存放了錯誤劑量，則自動標記並更換」。Run Command 是一次性緊急醫囑 —— 「給 412 房患者服用 5 毫克藥物 X」。自動化 (Automation) 是出院工作流 —— 「驗證最終處方、生成帶回家的文件、更新電子健康紀錄 (EHR)、安排隨訪」。
Patch Manager 基準對應於醫院處方集委員會規則：嚴重的藥物召回會立即自動撤回庫存；化妝品包裝變更則每季審查。修補群組是病房分類 —— 加護病房 (ICU) 患者獲得最嚴格的藥物管理；門診病人則遵循標準規則。
維護時段是護士執行藥物任務的排定巡房時間 —— 任務在並行上限下運行（一名護士每小時只能看 N 名患者），如果失敗任務過多則中止（失敗容忍度），以維護患者安全。
對於 State Manager vs Run Command vs 自動化的區別，汽車經銷商最清晰。對於修補基準核准延遲的推理，醫院處方集很直觀。對於維護時段的並行和失敗容忍度，辦公大樓清潔排程最接近。參考資料：https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html
State Manager：持續配置
State Manager 按照排程將 SSM 文件綁定到目標，並在發生偏差時重新套用文件。
關聯分析 (Association Anatomy)
一個關聯包含：
- 目標 (Target)：執行個體 ID、基於標籤、資源群組或帳戶區域中的所有執行個體。
- 文件 (Document)：通常是 Command 文件（例如，用於安裝/更新軟體的
AWS-ConfigureAWSPackage）或自定義 YAML 文件。 - 參數 (Parameters)：傳遞給文件的值。
- 排程表達式 (Schedule expression)：cron 或 rate（例如，
cron(0 2 ? * SUN *)表示每週日凌晨 2 點）。 - 合規嚴重性：如何報告不合規情況。
- 輸出位置：用於執行日誌的 S3 儲存桶。
State Manager 在排程上運行關聯，並且在執行個體啟動並註冊時運行（因此新執行個體能立即合規）。啟動時運行對自動調整規模群組 (ASG) 至關重要。
State Manager 並非持續監視執行個體並對偏差做出反應。它按照配置的排程運行關聯。如果你將排程設置為每週一次，而有人在週二卸載了代理程序，則執行個體在週日之前都會保持不合規狀態。對於由偏差觸發的補救，請結合使用 State Manager 與 Config 規則 + EventBridge + Lambda。參考資料：https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-state-about.html
State Manager vs Run Command
考試非常喜歡考這個區別：
| 維度 | Run Command | State Manager |
|---|---|---|
| 頻率 | 一次性 | 週期性排程 |
| 偏差處理 | 無（單次執行） | 按排程重新套用 |
| 新執行個體 | 不會自動執行 | 註冊時自動套用 |
| 使用場景 | 即時作業 | 持續合規 |
如果情境說「確保 X 始終已安裝」 —— 選擇 State Manager。如果說「現在立即在特定清單上安裝 X」 —— 選擇 Run Command。
Patch Manager：基準、群組、時段
Patch Manager 有三個主要元件，它們組合成機群修補策略。
修補基準 (Patch Baselines)
修補基準是一組決定哪些修補程式會被自動核准安裝的規則。AWS 為每個作業系統提供預設基準（Amazon Linux 的 AWS-DefaultPatchBaseline、Windows 的 AWS-WindowsPredefinedPatchBaseline-OS 等），你也可以創建自定義基準。
自定義基準包含：
- 核准規則：按分類（安全、錯誤修復、嚴重、重要）、嚴重性、作業系統產品進行篩選，並帶有自動核准延遲（修補程式發布後多少天變為「已核准」）。
- 已核准的修補程式：明確的清單，不論規則如何。
- 已拒絕的修補程式：明確的拒絕清單，不論規則如何。
- 合規報告：分配給不合規執行個體的嚴重性。
- 來源：替代存儲庫（例如，用於 RHEL 自定義衛星伺服器）。
自動核准延遲是關鍵的安全旋鈕：7 天的延遲意味著新發布的修補程式在一週內不會安裝，這讓 AWS 或供應商有時間撤回錯誤的修補程式。
修補群組 (Patch Groups)
你透過標籤鍵 Patch Group（區分大小寫，帶空格）將執行個體分配到修補群組。每個基準可以與一個或多個修補群組關聯。不屬於任何群組的執行個體會回退到其作業系統的預設基準。
修補群組用於隔離環境：Patch Group=production 映射到具備嚴格 14 天延遲的基準，Patch Group=staging 映射到優先獲取修補程式的 0 天延遲基準。
一個常見情境：考生使用 PatchGroup（無空格）或 patch-group（不同大小寫），執行個體會默默回退到預設基準。標籤鍵是 Patch Group —— 大寫 P，大寫 G，一個空格。SSM 在使用錯誤標籤時不會發出警告。參考資料：https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-patchgroups.html
維護時段 (Maintenance Windows)
維護時段包含：
- 排程：週期性時段開始的 cron/rate 表達式。
- 持續時間：時段保持開啟的時間。
- 截止時間：時段結束前多少分鐘停止啟動新任務。
- 註冊的目標：執行個體 ID 或標籤篩選器。
- 註冊的任務：Run Command、自動化、Lambda 調用或 Step Functions 執行。
- 任務並行性：最大並行執行數。
- 任務錯誤率：如果錯誤率超過此值，則停止啟動新任務。
對於修補，標準模式是：
- cron 為
cron(0 2 ? * SUN *)的維護時段。 - 註冊目標：標籤
Patch Group=production。 - 註冊任務：Run Command 文件
AWS-RunPatchBaseline，參數為Operation=Install。 - 並行度 10%，錯誤率 5%。
這會在每週日凌晨 2 點同時為最多 10% 的生產執行個體進行修補，如果失敗超過 5% 則中止。
僅掃描 (Scan-Only) vs 掃描並安裝 (Scan-and-Install)
AWS-RunPatchBaseline 接受一個 Operation 參數：
Scan：報告合規性但不安裝。Install：套用缺失的已核准修補程式。
常見的 DevOps 模式是每日 Scan（低成本，向儀表板報告合規性）+ 每週 Install（在維護時段內）。這將可見性頻率與變更頻率分開。
預設的 AWS-RunPatchBaseline 修補由作業系統管理的套件 (yum, apt, Windows Update)。在作業系統套件管理員之外安裝的第三方應用程式（自定義 .tar.gz、在 Patch Manager 之外構建的容器映像）不會被修補。請結合使用 SSM Distributor 與 State Manager 來保持自定義套件的更新。參考資料：https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-baselines.html
合規報告
State Manager 和 Patch Manager 都會將合規資料寫入 SSM 合規 (SSM Compliance)：每個執行個體的狀態（合規、不合規、無定論）以及嚴重性標記。你可以：
- 透過 Fleet Manager 和合規儀表板查看彙整的合規情況。
- 在
Compliance State Change時將事件推送到 EventBridge 並觸發 Lambda 補救。 - 透過將資源資料同步 (Resource Data Sync) 到 S3 + Athena/QuickSight 來彙整全組織範圍的合規情況。
- 結合使用 AWS Config 規則
ec2-managedinstance-applications-required、ec2-managedinstance-association-compliance-status-check、ec2-managedinstance-patch-compliance-status-check。
混合啟動與內部部署
對於內部部署伺服器，你需要創建一個混合啟動 (hybrid activation)：
aws ssm create-activation返回ActivationId和ActivationCode。- 在內部部署伺服器上安裝 SSM Agent。
- 運行
amazon-ssm-agent -register -code <code> -id <id> -region <region>。 - 伺服器會以 ID 前綴
mi-出現（EC2 為i-）。
混合啟動需要啟動所參照的 IAM 服務角色（AmazonSSMRoleForInstancesQuickSetup 或自定義）；內部部署伺服器使用 SSM 簽發的執行個體中繼資料樣式憑證。
註冊後，混合執行個體參與 State Manager、Patch Manager、Run Command、自動化、庫存和 Session Manager 的方式與 EC2 完全相同。
SSM Distributor
Distributor 封裝軟體（.zip 或 .tar.gz），帶有安裝/卸載/更新腳本和版本追蹤。你發布一個 Distributor 套件，然後透過以下方式部署：
- 一次性 Run Command (
AWS-ConfigureAWSPackage)。 - State Manager 關聯（持續性 —— 保持安裝此版本）。
- 維護時段任務。
在 DOP-C02 中，當題目要求「在機群中一致地部署第三方代理程序（Datadog、Splunk、自定義二進位檔），具備版本控制和持續合規性」時，Distributor 就是答案。
CloudWatch Agent 與 SSM
CloudWatch Agent 安裝是一個頻繁出現的整合場景。考試中的正確模式：
- 將代理程序配置存儲在 SSM Parameter Store 中，名稱為
AmazonCloudWatch-<名稱>（前綴對於amazon-cloudwatch-agent-ctl的識別很重要）。 - 使用具有
AmazonCloudWatch-ManageAgent文件的 State Manager 關聯。 - 每日排程。
- 在文件參數中傳遞參數名稱。
這為你提供了監控儀表化的持續合規性 —— 如果有人停止了代理程序，下一次關聯運行會重新啟動它；如果你更新了參數，所有執行個體都會按排程獲取更新。
常見陷阱 (Common Pitfalls)
- 在需要持續合規時選擇 Run Command：Run Command 是一次性的；重新套用需要 State Manager。
- 修補群組標籤鍵錯誤：必須是帶空格的
Patch Group。其他變體會默默回退到預設基準。 - 忘記自動核准延遲：0 天延遲意味著在 AWS/供應商發布修補程式的那一刻就進行部署 —— 如果發布了損壞的修補程式，這很危險。
- 混淆掃描與安裝：掃描只報告而不變更；安裝會執行變更。兩者都是
AWS-RunPatchBaseline的有效操作模式。 - 假設 Patch Manager 處理第三方應用程式：預設僅處理作業系統管理的套件；自定義應用程式需要 Distributor。
- 遺漏執行個體描述檔：沒有
AmazonSSMManagedInstanceCore（或同等權限）的執行個體永遠不會顯示為受管執行個體；State Manager 和 Patch Manager 會直接默默跳過它們。 - 將維護時段視為硬性保證：超過時段截止時間的任務不會啟動；時段的持續時間加上截止時間定義了實際的執行包絡。
DOP-C02 考試優先順序 — Systems Manager State Manager 與 Patch Manager。 此主題在 DOP-C02 考試中佔有份量。掌握權衡取捨、決策邊界以及每項 AWS 服務暴露的成本/效能觸發因素 —— 考試將測試那些取決於了解哪項服務是錯誤答案的情境，而不僅僅是哪項是正確的。
常見問題 (FAQ)
Q1：我應該何時使用 State Manager 或具備補救功能的 AWS Config？
State Manager 在執行個體作業系統內部運作 —— 它在主機上運行腳本。Config 則針對 AWS 資源配置運作 —— 它監控 IAM 政策、安全群組、S3 儲存桶設置。對於「安全群組是否對 0.0.0.0/0 開放」使用 Config；對於「SSM Agent 是否在主機上運行」使用 State Manager。兩者都可以進行補救 —— 選擇取決於所在的層級。
Q2：Patch Manager 可以修補容器映像嗎？
Patch Manager 修補運行中的 EC2 主機。對於容器，答案是 EC2 Image Builder 用於 AMI 修補，或透過 CodeBuild + ECR + 部署管道進行容器映像掃描和重新構建。修補運行中的容器通常是一種反模式；應重新構建映像並重新部署。
Q3：我如何修補大部分時間處於停止狀態的執行個體？
維護時段在排定時間針對運行中的執行個體執行；停止的執行個體會被跳過。模式：(1) 在時段前 30 分鐘啟動執行個體，修補，結束後停止；(2) 依賴 State Manager，它會在下一次執行個體啟動時運行；(3) 對於 ASG 管理的機群，透過 Image Builder 將修補程式構建到 AMI 中。
Q4：SSM 自動化 (Automation) 與 Step Functions 有什麼區別？
自動化是專為 SSM 操作構建的（切換角色、在 EC2 機群運行、整合核准程序、AWS API）。Step Functions 是通用編排（Lambda、ECS、SNS）。對於以 SSM 為中心的工作流，自動化更簡單；對於跨服務編排，Step Functions 更靈活。自動化還具備內建的核准步驟，可暫停等待受 IAM 驗證的核准人員。
Q5：我如何將跨帳戶的修補合規情況報告給單個儀表板？
資源資料同步 (Resource Data Sync) 將每個帳戶的庫存和合規資料寫入中央 S3 儲存桶。使用 Athena 彙整資料並在 QuickSight 中視覺化，或透過 Lambda 推送到 OpenSearch 以實現即時儀表板。Config 彙整器 (aggregator) 也可以跨帳戶收集合規狀態，但不包含作業系統內部的資料。
Q6：為什麼我的 Patch Manager 掃描在 RHEL 上報告為「無定論」(Inconclusive)？
RHEL 上的「無定論」通常意味著缺失 subscription-manager 註冊，或者執行個體無法從其子網訪問 Red Hat Update Infrastructure (RHUI) 端點。驗證連通性，檢查 /var/log/amazon/ssm/amazon-ssm-agent.log 中的代理程序日誌，並確認 subscription-manager 狀態。
Q7：State Manager 可以針對動態變化的標籤嗎？
可以。基於標籤的目標在每次關聯運行時都會重新評估；獲得標籤的執行個體會自動包含在內，失去標籤的則被排除。帶著正確標籤啟動到 ASG 中的新執行個體也會在註冊時被納入。
總結
State Manager 透過聲明式的 SSM 文件讓 EC2 和內部部署執行個體保持持續合規。Patch Manager 透過基準、群組和具備自動核准延遲安全機制的維護時段處理作業系統修補。Run Command 執行單次作業。自動化編排多步驟工作流。DOP-C02 的答案模式：聲明式持續 = State Manager，命令式單次 = Run Command，多步驟 = 自動化，作業系統修補 = Patch Manager + 維護時段。精確記憶 Patch Group 標籤鍵、掃描與安裝操作模式、混合啟動流程以及用於第三方套件的 Distributor，SSM 場景就會變成一種識別練習，而非服務名稱的猜測。