Systems Manager：Automation、Patch Manager 與 Session Manager

AWS Systems Manager 是 SOA-C02 SysAdmin 的瑞士刀——一個統一主控台，取代了 SSH、取代了 cron、取代了臨時補丁腳本、取代了寫死在 EC2 user-data 裡的密鑰，也取代了跳板機。在 SOA-C02 考試中，Systems Manager 貫穿 Domain 3 Task Statement 3.2（「自動化手動或重複性流程」）和 Domain 1 Task Statement 1.2（「根據監控與可用性指標排解問題」），並且是 AWS Config 自動補救的後端、EventBridge 目標選項（Lambda 的替代方案），也是唯一在不開放 port 22 的情況下對整個機隊執行 Run Command 的官方途徑。如果 CloudWatch 是 SOA-C02 的神經系統，Systems Manager 就是 SOA-C02 的雙手。

本指南從 SysOps 角度走過 Systems Manager 全流程：SSM Agent 如何識別一台 instance 以及什麼讓受管 instance 成為「受管」、Run Command 與 State Manager 的差異（單次執行 vs 持續保持期望狀態）、Patch Manager 基線如何定義哪些補丁被核准以及自動核准延遲的運作方式、Maintenance Windows 如何按排程在機隊中協調補丁作業、Automation runbooks 如何透過 assumeRole 與條件分支串接步驟、Session Manager 如何移除 SSH 跳板機與 port 22、Parameter Store SecureString 與 Secrets Manager 的關係（以及差異），以及 Inventory 和 OpsCenter 如何提供合規與事件工作流程。你也會看到反覆出現的 SOA-C02 情境：agent 未受管診斷、「補丁已核准但未安裝」、Maintenance Window 並發調整、Automation runbook IAM AssumeRole，以及私有子網中 Session Manager 的 VPC endpoint 需求。

為什麼 Systems Manager 是 SOA-C02 Domain 3 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 3.2 下列出三項技能：「使用 AWS 服務（例如 Systems Manager、CloudFormation）自動化部署流程」、「實作自動化補丁管理」，以及「使用 AWS 服務（例如 EventBridge、AWS Config）排程自動化任務」。Systems Manager 出現在三項中的兩項，而 Patch Manager 是「實作自動化補丁管理」技能中唯一的 AWS 原生答案——沒有其他在考試範圍內的服務能夠按排程對 EC2 機隊執行 OS 補丁。Domain 3 佔全卷 18%，Task Statement 3.2 產生其中絕大多數的題目。

Domain 1 Task Statement 1.2 則從不同角度再次用到 Systems Manager：「使用 AWS Systems Manager Automation runbooks 根據 AWS Config 規則採取行動」。當 AWS Config 偵測到不合規資源時，aws.config 事件上的 EventBridge 規則路由到執行補救的 SSM Automation document——標記缺少標籤的資源、加密未加密的 EBS 磁碟區、限縮開放的 security group。考試期望你能端對端了解完整的 Config -> EventBridge -> SSM Automation 鏈，包括 SSM 所假設的 IAM 補救角色。

在 SysOps 層級，框架是運維而非架構。SAA-C03 問「你應該使用哪個 AWS 服務來管理機隊的補丁？」SOA-C02 問「夜間補丁週期在 12% 的 instance 上失敗——依序列出診斷步驟」。答案永遠涉及同樣三個基礎：SSM Agent 必須正在執行、IAM instance profile 必須包含 AmazonSSMManagedInstanceCore，以及到 SSM endpoint 的網路路徑必須存在（NAT gateway、internet gateway，或 VPC interface endpoint）。三者缺一，Systems Manager 看起來什麼都沒做——靜默地失敗。這種靜默是 SOA-C02 的經典陷阱。

白話文解釋 Systems Manager Automation、Patch Manager 與 Run Command

Systems Manager 有許多子服務，名稱容易混淆。三個類比能讓架構印象深刻。

類比一：大樓管理處

Systems Manager 是一棟大型辦公大樓（你的 AWS 帳戶）的大樓管理處。每台 EC2 instance 是一間裝了智慧門鎖的辦公室（SSM Agent），而管理處掌握著萬能鑰匙（IAM instance profile AmazonSSMManagedInstanceCore）。沒有安裝門鎖、也沒有萬能鑰匙備案，管理人員就無法進入——那個房間是「未受管的」。Run Command 是管理人員逐間巡視、執行一次性任務（「替所有標記為 Floor=3 的辦公室換燈泡」）。State Manager 是長期重複指令（「每週檢查每間辦公室的煙霧偵測器是否正常，若電池耗盡則更換」）。Patch Manager 是全棟大樓的窗戶更換計畫——有patch baseline（指定哪些型號的窗戶通過規格）、patch groups（北向辦公室和南向辦公室使用不同的玻璃），以及 Maintenance Window（每週日凌晨兩點到五點，每次只替換十間，確保大樓不會全面停業）。Automation runbooks 是管理處的緊急應變手冊，列有編號步驟供管理人員在火災警報響起時依序執行——步驟一疏散、步驟二通報、步驟三隔離、步驟四勘查——每個步驟都有 assumeRole 條款，說明需要哪個部門的鑰匙。Session Manager 是管理人員的萬用感應卡，不需要各辦公室的個別鑰匙（無需 SSH 金鑰）、也不需要側門（無需跳板機）就能進入任何一間——且每次進入都記錄在防竄改的門禁系統中。Parameter Store 是地下室的資料夾總管，存放標準供應品規格（油漆顏色、燈泡瓦數）——SecureString 抽屜用 KMS 金鑰上鎖。

類比二：IT 部門的作業手冊夾

SysAdmin 的實體作業手冊夾有各種索引頁：「建立新 VPN 使用者」、「輪換資料庫密碼」、「修補 RHEL 機隊」、「調查登入失敗警報」。每個索引頁都有編號步驟：步驟一、步驟二、步驟三，並有條件分支（「若步驟二傳回 RC=4，跳至步驟七」）。SSM Automation runbooks 正是那本手冊夾——但可直接執行。Document 將步驟定義為 aws:executeAwsApi（呼叫 AWS API）、aws:executeScript（在執行器上本機執行 Python 或 PowerShell 腳本）、aws:runCommand（在受管 instance 上執行 Command document）、aws:waitForAwsResourceProperty（輪詢直到條件滿足）及 aws:approve（暫停等待人工核准後繼續）。AWS 管理的 runbooks 如 AWS-RestartEC2Instance、AWS-StopEC2Instance、AWS-CreateSnapshot、AWS-PatchInstanceWithRollback 是每個 IT 部門都有的預印頁面；你的自訂 runbooks 是針對你們公司特定流程撰寫的程序。Runbook 作者指定 AssumeRole，讓 runbook 能以人類使用者沒有的較高權限行動——IT 部門的「深夜萬能鑰匙」由 runbook 引擎取出，而不是交給每位初級技術人員。

類比三：連鎖旅館的全國裝修計畫

修補機隊就像翻新一條連鎖旅館。不能一次關閉所有旅館——住客無處可去。Patch Manager + Maintenance Windows 是全國裝修排程：每間標記 Region=APAC 的旅館在週日凌晨兩點到五點進行翻新，MaxConcurrency = 10%（每次最多一成旅館停業施工），MaxErrors = 5%（若超過 5% 的旅館翻新失敗，立即暫停全國推進）。Patch baseline 是裝修規格書——油漆顏色、底漆品牌、光澤度——而自動核准延遲是廠商保固等待期：新油漆配方上市 7 天後才自動核准，讓工廠瑕疵先行浮現。Patch groups 為旅館貼上基線標籤（「豪華連鎖使用規格 A，平價連鎖使用規格 B」）。補丁合規報告是裝修後的驗收報告——每間旅館對應其基線的現況。整條流水線就是 SOA-C02 考試所謂「實作自動化補丁管理」的意涵。

SSM Agent：生命週期、前提條件與疑難排解

SSM Agent 是每項 Systems Manager 能力的基礎。如果 agent 未以受管 instance 形式註冊，該主機上的 Run Command、State Manager、Patch Manager、Session Manager 及 Automation aws:runCommand 步驟全部無效。

Agent 安裝

Agent 自 2017 年起預裝於大多數 AWS 官方 AMI：Amazon Linux 2 / 2023、Ubuntu 16.04+、Windows Server 2008 R2+、RHEL/CentOS 7+、SUSE 12+、macOS，以及用於 EKS 受管節點的 Bottlerocket OS。對於較舊的 AMI、自訂 AMI 或 on-prem 主機，可透過以下方式安裝：

• yum install -y amazon-ssm-agent（RHEL/CentOS/Amazon Linux）或 snap install amazon-ssm-agent --classic（Ubuntu）。
• MSI 安裝程式（Windows Server）。
• Run Command AWS-ConfigureAWSPackage，參數 name=AmazonSSMAgent——僅適用於主機已是受管狀態（先有雞後有蛋：只用於升級）。
• EC2 Image Builder 將最新 agent 版本烘焙進 golden AMI——SOA-C02 首選的機隊一致性做法。

Agent 透過 HTTPS port 443 向外連線至 Systems Manager 的區域端點（ssm.<region>.amazonaws.com、ec2messages.<region>.amazonaws.com 及 ssmmessages.<region>.amazonaws.com）。它從不接受輸入流量——這正是 Session Manager 安全的原因。

成為受管 instance 的三個前提條件

要讓 instance 出現在 Fleet Manager → Managed instances 中，以下三點必須全部成立：

1. SSM Agent 已安裝且正在執行（systemctl status amazon-ssm-agent）。
2. IAM instance profile 附有 AmazonSSMManagedInstanceCore 政策（或等效自訂政策，授予 ssm:UpdateInstanceInformation、ssmmessages:*、ec2messages:*，以及 Inventory/Session Manager 日誌所需的寫入權限）。
3. 到三個 SSM 端點的對外網路路徑——透過 internet gateway（公有子網）、NAT gateway（私有子網），或 com.amazonaws.<region>.ssm、com.amazonaws.<region>.ec2messages 及 com.amazonaws.<region>.ssmmessages 的 VPC interface endpoints（無網際網路輸出的私有子網）。

三者缺任一，instance 將靜默地不進行註冊。Fleet Manager 根本不會列出它。以 instance ID 為目標的 Run Command 會傳回「InvalidInstanceId」——不是權限錯誤，不是網路逾時，就只是「不是有效的 SSM instance」。

On-prem 與混合環境

對於 on-prem 伺服器，透過 Systems Manager hybrid activation 註冊主機：建立一個帶有 IAM 服務角色的 activation（因為沒有 EC2，所以不是 instance profile），取得 activation 代碼和 ID，再於主機上執行 amazon-ssm-agent -register -code <code> -id <id> -region <region>。主機現在會以 mi- 前綴（而非 i-）顯示為受管 instance。SOA-C02 可能會問「在同一排程中補丁混合 EC2 和 on-prem 伺服器」——答案是 hybrid activation + 同時涵蓋兩個集合的 Maintenance Window。

Agent 疑難排解清單

當 Fleet Manager 中找不到某個 instance 時：

1. Agent 是否正在執行？ sudo systemctl status amazon-ssm-agent——若已停止，執行 sudo systemctl restart amazon-ssm-agent 並檢查 journalctl -u amazon-ssm-agent。
2. IAM 角色是否附加且正確？ EC2 主控台 → Instance → Security 索引標籤 → IAM Role。確認角色包含 AmazonSSMManagedInstanceCore。若角色在啟動後才附加，請重啟 agent 讓它重新讀取憑證。
3. Agent 能否到達端點？ 從 instance 執行：curl -v https://ssm.us-east-1.amazonaws.com/——出現 TLS 握手就是好的。若逾時，檢查路由表（是否有 NAT gateway？）、security group 對外規則（443 是否允許？）、NACL 對外與對內規則（是否允許回應的臨時 port？），以及若 VPC 是隔離網路，是否有三個必要的 interface endpoints。
4. Agent 版本不符？ 較舊的 agent 對較新的 SSM 功能有已知 bug。Patch Manager 的 AWS-RunPatchBaseline 在某些 OS 上需要 agent ≥ 3.0。透過 Run Command AWS-UpdateSSMAgent 更新——但 instance 必須已是受管狀態才能接收指令（這就是為什麼將 agent 烘焙進 AMI 是較佳做法）。
5. 資源配額？ 每個區域有受管 instance 的預設配額。對於非常大的機隊，透過 Service Quotas 申請增加。

Run Command：無需 SSH 的臨時機隊執行

Run Command 是 Systems Manager 中最簡單的能力，也是日常 SysOps 使用頻率最高的工具。它對一組目標執行 Command document，收集 stdout/stderr，並回報每台 instance 的成功或失敗狀態。

Run Command 呼叫流程

1. SysOps 工程師選擇一個 Command document——例如 AWS-RunShellScript（Linux）、AWS-RunPowerShellScript（Windows）、AWS-ConfigureAWSPackage（安裝/更新 SSM 分發的套件）、AWS-UpdateSSMAgent、AmazonCloudWatch-ManageAgent，或自訂 document。
2. 定義目標：
   • 依 instance ID——明確列出清單。
   • 依標籤——例如 tag:Environment=prod。機隊規模下最常見的模式。
   • 依 Resource Group——已儲存的查詢，解析為一組 instance。
3. 設定並發控制：
   • MaxConcurrency——同時執行指令的 instance 數（絕對數量或百分比）。
   • MaxErrors——何時停止推進。達到 MaxErrors 次失敗後，不再啟動更多 instance。
4. 選擇性指定 S3 output bucket 和 CloudWatch log group，保留超過主控台 2,500 字元截斷的 stdout 完整輸出。
5. 選擇性整合 CloudWatch alarm——若配置的 alarm 在執行期間觸發，停止指令。

每個目標的 agent 透過 SSM 服務接收工作，在本機執行，然後回報結果。沒有 SSH session、沒有輸入 port、沒有共用憑證。

常用 Command documents

• AWS-RunShellScript / AWS-RunPowerShellScript——執行任意指令。快速但具風險；若有專用 document 請優先使用。
• AWS-ConfigureAWSPackage——從 SSM Distributor 安裝或升級套件（CloudWatch agent、Inspector agent、CrowdStrike 等第三方 agent）。
• AWS-UpdateSSMAgent——升級 agent 本身。
• AmazonCloudWatch-ManageAgent——使用 Parameter Store 中的組態安裝、設定並啟動 CloudWatch agent。
• AWS-RunPatchBaseline——依 Patch baseline 掃描或安裝補丁。Patch Manager 在 Maintenance Window 內就是呼叫這個 document。
• AWS-StartInteractiveCommand / AWS-StartSSHSession——Session Manager 啟動 documents。

Run Command vs State Manager

Run Command 是單次執行：你觸發它，它執行一次，完成。State Manager 是持續保持期望狀態：你建立一個 association，它按排程對目標集重複執行 Command document。兩個 SOA-C02 範例能說清楚差異：

• 「現在立刻將最新的 CloudWatch agent 組態套用到所有 Environment=prod instance」——Run Command。
• 「確保每台新加入的 Environment=prod instance 永遠都安裝並設定好 CloudWatch agent」——State Manager association，每 30 分鐘（預設）或任何 cron 排程執行，自動納入加入標籤的新 instance。

State Manager associations 也是 SOA-C02 對「稽核人員要求每台 instance 持續符合強化 Command document」問題的正確答案——Run Command 是一次性的，無法偵測組態偏移。

Patch Manager：基線、Patch Groups 與掃描 vs 安裝

Patch Manager 是 SOA-C02 自動化 OS 補丁的答案。它依 patch baseline 掃描受管 instance，選擇性安裝已核准的補丁，並回報合規狀況。

Patch baselines

Patch baseline 是一組規則，決定哪些補丁對某個 OS 核准。每個 OS 系列都有 AWS 管理的預設基線：

• AWS-AmazonLinux2DefaultPatchBaseline
• AWS-WindowsPredefinedPatchBaseline-OS
• AWS-UbuntuDefaultPatchBaseline
• AWS-RedHatDefaultPatchBaseline
• AWS-SUSEDefaultPatchBaseline
• AWS-CentOSDefaultPatchBaseline
• AWS-MacOSDefaultPatchBaseline

每個預設基線以 7 天自動核准延遲核准 Critical 和 Important 安全補丁——意即 OS 廠商發布的補丁在發布 7 天後自動核准。延遲的目的是防止社群發現迴歸問題前就推出有問題的補丁。

以下情況需要自訂基線：

• 需要不同的自動核准延遲（緊急零日修補設為 0 天；超保守的生產環境設為 14 或 30 天）。
• 只需核准部分分類（Security 但不含 Bugfix）。
• 需要在自動核准延遲到期前明確核准單一重大 CVE 補丁。
• 需要明確拒絕已知有問題的補丁。
• 需要超出預設值的 OS 層級補丁來源（例如私有套件倉庫）。

自訂基線透過以 Patch Group=<group-name> 標記 instance，與 patch group 建立關聯。一台 instance 只能屬於一個 Patch Group，因此標籤值的選擇至關重要。

掃描 vs 安裝

AWS-RunPatchBaseline document 接受 Operation 參數：

• Scan——依基線評估 instance 並回報合規狀態。不安裝補丁，不重新開機。用於稽核和視窗前的準備度檢查。
• Install——安裝所有缺少的已核准補丁，若有補丁需要則重新開機（可設定：RebootIfNeeded 或 NoReboot）。

常見的運維模式：

1. 透過 State Manager association 每日 Scan——每台 instance 每天回報一次合規狀態。CloudWatch dashboard 顯示全組織的合規百分比。
2. 透過 Maintenance Window 每週 Install——週日凌晨兩點到五點，帶有 Operation=Install 的 Maintenance Window 任務以 MaxConcurrency 和 MaxErrors 控制的批次修補機隊。

將 Scan 與 Install 分開，讓你能在排定的補丁視窗之間觀察偏移情況而不強制重新開機，也能讓合規報告驅動非補丁補救（例如，當某台 instance 重複無法補丁時，aws.ssm 合規事件上的 EventBridge 規則會呼叫值班人員）。

補丁合規回報

Patch Manager 發布每台 instance 的合規狀態，可在以下位置查看：

• Patch Manager 主控台 → Compliance。
• Systems Manager Inventory → Patch compliance。
• EventBridge——aws.ssm 事件的 Configuration Compliance State Change 詳細類型路由至 SNS 或 Lambda。
• AWS Config——ec2-managedinstance-patch-compliance-status-check 受管規則發出 Config 合規結果，可驅動自動補救鏈。

為了稽核目的，合規資料自然地透過 Config 或直接透過 SSM 整合流入 AWS Security Hub。

Maintenance Windows：排程全機隊作業

Maintenance Window 是帶有三個組成部分的週期性或一次性排程：一個排程、一組已註冊目標，以及一組已註冊任務。Maintenance Windows 是 Patch Manager 在機隊規模下運行的方式，對任何不應在上班時間執行的週期性作業也很有用。

排程

排程接受以下其中之一：

• cron 表達式——cron(0 2 ? * SUN *) 表示「每週日 UTC 凌晨兩點」。
• rate 表達式——rate(7 days)。
• 一次性排程，指定特定日期。

選擇性的 ScheduleTimezone 將 cron 置於本地時間（例如 Asia/Taipei），避免 UTC 心算換算。選擇性的 Cutoff 指定在視窗結束前多少小時停止啟動新任務（讓已執行的任務有時間完成）。選擇性的 Duration 是視窗總共開放多長時間。

已註冊目標

目標在任務執行時解析，不在註冊時解析：

• 依 instance ID。
• 依標籤（最常見——tag:Patch Group=prod-rhel9）。
• 依資源群組。

由於目標在執行時解析，符合標籤的新 instance 自動加入下一次視窗的執行。

已註冊任務

任務有四種類型：

• RUN_COMMAND——呼叫 Command document（最常見：AWS-RunPatchBaseline）。
• AUTOMATION——呼叫 Automation runbook。
• LAMBDA——呼叫 Lambda function。
• STEP_FUNCTIONS——啟動狀態機執行。

每個任務帶有：

• MaxConcurrency——同時處理的目標數量。10（絕對數）或 10%（目標總數的百分比）。200 台 instance 的機隊在 MaxConcurrency=10% 下，每次修補 20 台，然後再 20 台，依此類推。
• MaxErrors——停止推進的條件。5（絕對數）或 5%。達到此數量的任務失敗後，不再啟動更多 instance。
• TaskInvocationParameters——document 特定參數（Operation=Install、RebootOption=RebootIfNeeded）。
• ServiceRoleArn——Maintenance Window 執行任務所假設的 IAM 角色（Maintenance Window 服務角色，不是 instance profile——這是兩個不同的 IAM 身分）。
• Priority——當多個任務註冊到同一個視窗時，優先度較低的任務先執行。

情境模式：數百台 EC2 每週日凌晨兩點補丁

SOA-C02 典型設計：

1. 為每台待補丁的 instance 貼標籤 Patch Group=prod-linux（及 Environment=prod）。
2. 為 prod-linux 建立自訂 Patch baseline——Amazon Linux 2、Critical/Important 安全補丁、7 天自動核准延遲，加上所有緊急 CVE 的明確核准清單。
3. 建立 Maintenance Window，使用 cron(0 2 ? * SUN *)、ScheduleTimezone=Asia/Taipei，時長 3 小時，截止 30 分鐘。
4. 已註冊目標：tag:Patch Group=prod-linux。
5. 已註冊任務：AWS-RunPatchBaseline，Operation=Install、RebootOption=RebootIfNeeded、MaxConcurrency=10%、MaxErrors=5%，輸出至 S3 bucket 供稽核。
6. State Manager association 每日以 Operation=Scan 執行 AWS-RunPatchBaseline，讓合規狀態在週中也可見。
7. EventBridge 規則監聽 aws.ssm 合規狀態變更事件，對任何連續兩次未能補丁的 instance 發送 SNS 通知。

這條流水線幾乎是每個「補丁機隊」SOA-C02 情境的答案。

SSM Automation Runbooks：多步驟協調

Run Command 只能針對受管 instance，Automation runbooks 則在單一 document 中協調 AWS API 呼叫、instance 指令和人工核准。Automation runbooks 是將複雜補救和自助運維操作程式化的方式。

Automation document 結構

Automation document 是帶有 parameters、mainSteps 及 assumeRole 的 YAML（或 JSON）。每個步驟有一個來自小型函式庫的 action：

• aws:executeAwsApi——執行任意 AWS API 呼叫（DescribeInstances、StopInstances、RestoreDBClusterFromSnapshot 等）。最強大的 action。
• aws:executeScript——在執行器（Systems Manager 服務，不是你的 instance）上執行 Python 或 PowerShell 腳本。用於轉換和複雜邏輯。
• aws:runCommand——在受管 instance 上執行 Command document。
• aws:waitForAwsResourceProperty——輪詢 API 直到屬性達到目標值。用於等待 instance 進入 running 狀態或 stack 達到 CREATE_COMPLETE。
• aws:assertAwsResourceProperty——若屬性不符則使 runbook 失敗。
• aws:approve——暫停等待一位或多位指定負責人透過主控台核准。用於需要人工判斷的生產影響步驟。
• aws:branch / aws:choice——根據前一步驟的輸出進行條件分支。
• aws:sleep——等待固定時間。

AWS 管理的 runbooks

AWS 發布了大量預建 runbooks。SOA-C02 高頻出現的有：

• AWS-RestartEC2Instance——停止、等待、啟動一台 instance。簡單但在情境中出乎意料地常見。
• AWS-StopEC2Instance / AWS-StartEC2Instance。
• AWS-CreateSnapshot / AWS-DeleteSnapshot。
• AWS-PatchInstanceWithRollback——安裝補丁，若重新開機失敗則回滾。
• AWS-UpdateCloudFormationStack。
• AWS-RunPatchBaseline（也可作為 Run Command 的 Command document）。
• AWSConfigRemediation-*——一系列用於連接 AWS Config 規則的補救 runbooks。

Automation 的 IAM AssumeRole

Runbook 可由使用者、EventBridge、State Manager 或 AWS Config 補救呼叫。Runbook 本身以 document 中指定的 AssumeRole 身分運行——通常是擁有所有步驟所需權限聯集的角色。

角色的信任政策必須信任 ssm.amazonaws.com（Automation 服務主體）。常見錯誤：

• 信任政策缺少 ssm.amazonaws.com——runbook 立即以 AssumeRole 被拒而失敗。
• 角色權限缺少某個 API 呼叫——runbook 在該特定步驟失敗。
• 跨帳號 runbooks——目標帳號需要信任來源帳號的角色，而來源帳號角色需要對目標帳號角色的 sts:AssumeRole 權限。

情境模式：Config 規則 + EventBridge + SSM Automation

Domain 1.2 + Domain 3.2 的典型鏈：

1. AWS Config 規則——例如 s3-bucket-public-read-prohibited。當 bucket 變為公開時，規則移至 NON_COMPLIANT。
2. AWS Config 補救組態——附加到規則，指定 SSM Automation runbook（例如 AWSConfigRemediation-RemoveS3BucketPolicyStatementForS3PublicAccess）和 IAM 補救角色。
3. SSM Automation runbook——對違規的 bucket 執行，移除公開授權聲明，傳回成功。
4. EventBridge 規則（選擇性）——同時將 aws.config 不合規事件路由至 SNS，讓人員了解發生了什麼。

SOA-C02 陷阱：考生直接將 EventBridge 規則連接到 Lambda function，而非使用 Config 原生補救功能。兩者都行得通；當輸入是 Config 規則時，Config 補救是 AWS 原生答案，具備內建重試和日誌記錄。

Session Manager：取代 SSH 與跳板機

Session Manager 提供不需要 SSH 金鑰、不需要跳板機、不需要開放輸入 port 22 或 3389 的瀏覽器或 AWS CLI Shell 存取受管 instance 的方式。它是 SOA-C02 中測試最頻繁的 SSM 能力，因為它解決了每個 SysOps 團隊都面臨的安全問題。

Session 的運作方式

1. 使用者開啟 Systems Manager → Fleet Manager → 選擇 instance → Start session（或從 CLI 執行 aws ssm start-session --target i-0abc123）。
2. Session Manager 服務依 IAM 驗證使用者（使用者需要 ssm:StartSession 權限）。
3. 目標 instance 上的 SSM Agent 透過其現有的對外連線接收請求。
4. Agent 產生一個 shell（預設：ssm-user，帶有 sudo）。stdin 和 stdout 透過 SSM 服務流回使用者的瀏覽器/CLI——不會有輸入流量到 instance。
5. Session 被記錄：每個按鍵和指令輸出可串流至 CloudWatch Logs 和/或 S3，可選擇以 KMS 加密。

Session Manager 在考試中的優勢

與跳板機 SSH 相比，Session Manager：

• 完全移除輸入 port 22——security groups 可拒絕所有輸入流量，大幅縮小攻擊面。
• 移除 SSH 金鑰——IAM 身分驗證 session；無需輪換或分發共用金鑰對。
• 移除跳板機 EC2 成本——不需要永遠開著的跳板機主機。
• 將每個 session 記錄至 S3/CloudWatch——可審計供合規使用。
• 在沒有 NAT/IGW 的私有子網中運作，只要 VPC 有三個 SSM interface endpoints。
• 與 IAM session policies 整合，限制使用者可以執行的指令。

Session 偏好設定

SessionManagerRunShell document 類型儲存帳號層級的偏好設定：

• shellProfile——要啟動哪個 shell（預設 Linux 為 bash，Windows 為 cmd）。
• runAsEnabled——以自訂 OS 使用者而非 ssm-user 啟動 session。
• s3BucketName + cloudWatchLogGroupName——記錄 session 的位置。
• kmsKeyId——用於加密 session 日誌資料的 KMS 金鑰。
• idleSessionTimeout——在 N 分鐘後自動終止閒置 session。
• maxSessionDuration——session 長度的硬性上限。

私有子網的 Session Manager VPC endpoint 需求

對於沒有網際網路輸出的私有子網中的 instance，受管 instance 註冊所需的同三個 SSM VPC interface endpoints 也支援 Session Manager：

• com.amazonaws.<region>.ssm
• com.amazonaws.<region>.ec2messages
• com.amazonaws.<region>.ssmmessages

若你還想讓 session 日誌從 instance 直接傳至 S3（而非透過 SSM 服務），可能還需要一個 S3 gateway endpoint。

Parameter Store：組態與密鑰

Parameter Store 是 Systems Manager 的階層式鍵值儲存。參數名稱是路徑（/myapp/prod/db/host），類型為 String、StringList 或 SecureString，存取透過參數 ARN 上的 IAM 政策控制。

層級

• Standard 層——免費，每個區域每個帳號最多 10,000 個參數，參數值最大 4 KB。不支援參數政策。
• Advanced 層——付費（撰寫時每個參數每月 0.05 USD），最多 100,000 個參數，值最大 8 KB，支援參數政策（到期、到期通知、無變更通知）。

SecureString

SecureString 參數以 KMS 在靜止時加密。參數的加密金鑰可以是：

• AWS 管理的金鑰 alias/aws/ssm（預設）。
• 建立時指定的客戶自管 KMS 金鑰。

讀取 SecureString 需要 ssm:GetParameter(s) 權限以及加密金鑰的 kms:Decrypt 權限。寫入需要 ssm:PutParameter 和 kms:Encrypt。

Parameter Store vs Secrets Manager

這個比較幾乎在每次 SOA-C02 考試中都會出現。

SOA-C02 的判斷線索：「自動輪換」→ Secrets Manager。「應用程式組態值，其中部分敏感」→ Parameter Store SecureString。「EC2 user-data 中有寫死的資料庫密碼，必須移除」→ Secrets Manager（因為從運維角度你也需要輪換，即使題目沒有明確說明）。

Public parameters

AWS 以 public Parameter Store 參數形式發布有用的值，路徑在 /aws/service/ 下：

• /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64——最新的 Amazon Linux 2023 AMI ID。CloudFormation Parameters 可以引用這個，讓 stacks 永遠以最新 AMI 啟動。
• /aws/service/global-infrastructure/regions——所有 region 的清單。
• /aws/service/eks/optimized-ami/...——EKS 最佳化 AMI ID。

Public parameters 是「永遠啟動最新 AMI」而不需將 AMI ID 寫死在範本中的 SOA-C02 正確答案。

Inventory：軟體與組態目錄

Systems Manager Inventory 按排程收集受管 instance 的中繼資料：

• 已安裝應用程式（含版本）。
• 已安裝的 AWS 元件。
• 網路組態（介面、路由）。
• 已安裝的 Windows 更新。
• 指定路徑的檔案。
• 登錄機碼（Windows）。
• 操作員定義的自訂 Inventory 類型。

Inventory 底層是一個 State Manager association——它按排程（預設每 30 分鐘）執行 AWS-GatherSoftwareInventory document。收集的資料可在 SSM 主控台和 Inventory API 中查詢，也可透過 Resource Data Sync 同步至中央 S3 bucket，供跨帳號、跨 region 以 Athena 或 QuickSight 查詢。

SOA-C02 常見使用情境：

• 「找出所有執行 Apache 版本 < 2.4.55 的 instance」——Inventory 查詢已安裝應用程式。
• 「稽核組織內所有 Windows hotfix 安裝情況」——Resource Data Sync 至 S3 + Athena。
• 「識別具有特定組態檔案的 instance」——自訂 Inventory 類型。

OpsCenter：運維事項聚合

OpsCenter 是 Systems Manager 管理運維問題（稱為 OpsItems）的工作流程工具。OpsItem 是一個受追蹤的運維問題——它有狀態（Open、In Progress、Resolved）、受指派人員、相關資源和類別。

OpsItems 從以下來源自動建立：

• CloudWatch alarm 狀態變更（設定後）。
• AWS Config 不合規事件。
• AWS Health 事件。
• GuardDuty 發現。
• SysOps 工程師手動建立。

OpsCenter 是 SOA-C02「將多個 AWS 服務的運維警報整合到單一分流視圖」的答案。對於完整的事件回應，OpsCenter 與 Incident Manager（獨立子功能）整合，後者增加了 runbooks、值班輪換和聊天頻道整合。

常見陷阱：隔離 VPC 中的 SSM Endpoints

SOA-C02 的典型陷阱：完全私有子網中的 instance（無 NAT、無 IGW、無 Direct Connect、無公有 IP）即使 agent 正在執行且 IAM 角色正確，也無法以受管 instance 形式註冊。Agent 靜默地重試對 ssm.<region>.amazonaws.com 的 DNS 解析和 TLS 握手並逾時。修復方式是三個 SSM VPC interface endpoints（ssm、ec2messages、ssmmessages）。遺漏其中任何一個會產生部分功能問題：

• 缺少 ssm endpoint——instance 永遠無法註冊。
• 缺少 ec2messages endpoint——Run Command 和 Patch Manager 失敗。
• 缺少 ssmmessages endpoint——特別是 Session Manager 失敗（session 建立使用此 endpoint），但 Run Command 可能仍然運作。

考試直接測試三個 endpoint 的需求——只配置 ssm endpoint 並假設其他也能用的考生答錯了。

常見陷阱：Patch Manager 在上班時間重啟生產環境

如果你在 Maintenance Window 之外執行 AWS-RunPatchBaseline 並設定 Operation=Install 和 RebootOption=RebootIfNeeded——例如作為臨時的 Run Command——目標 instance 會在補丁需要時立即重新開機，不管你是在午餐時間還是正在處理 SEV1 事件。Maintenance Window 才是強制排程和並發的機制。SOA-C02 的教訓：Run Command 用於緊急情況或僅掃描；生產補丁應放在帶有 MaxConcurrency 和 MaxErrors 控制的 Maintenance Window 中。

常見陷阱：Hybrid Activation 代碼重複使用

Hybrid activation 代碼是短期的（預設 24 小時，最長 30 天），且受限於 instance 數量上限。操作員有時嘗試對數百台 on-prem 主機重複使用同一個 activation 代碼，發現超過上限後註冊失敗。正確的模式是在佈建時透過基礎設施即程式碼（CloudFormation、Terraform 透過 Systems Manager API）為每批次鑄造帶有適當 instance 數量上限的 activation 代碼，並定期輪換代碼。

常見陷阱：Run Command 沒有輸出

如果你在 Run Command 呼叫中沒有設定 S3 output bucket 或 CloudWatch Log Group，指令的 stdout 在 Run Command 主控台中截斷為前 2,500 個字元。對於任何產生有意義輸出的指令（多行腳本、組態轉儲、合規報告），請務必在呼叫時指定 S3 輸出位置——這是 SOA-C02 常見干擾項，考生以為 Run Command 壞了，但實際上只是輸出被截斷了。

SOA-C02 vs SAA-C03：運維視角

SAA 考生選擇服務；SOA 考生正確設定它、在不註冊時進行疑難排解，並在事件中操作補丁週期、自動化流水線和 session 日誌稽核。

考試信號：如何辨識 Domain 3.2 題目

• 「補丁未安裝」——診斷 agent + IAM + 網路，然後檢查基線自動核准延遲，再檢查 Maintenance Window MaxErrors 停止。
• 「無法 SSH 進入私有子網 instance」——Session Manager + SSM VPC endpoints。永遠不是跳板機 + SSH 金鑰。
• 「寫死的憑證必須移除」——Secrets Manager（帶輪換）或 Parameter Store SecureString（不需輪換）。
• 「Config 規則必須自動補救」——Config 補救組態 → SSM Automation runbook，帶有正確的 AssumeRole 和對 ssm.amazonaws.com 的信任。
• 「持續合規，而非單次」——State Manager association，不是 Run Command。
• 「按排程補丁」——帶有 cron 的 Maintenance Window、已註冊標籤、AWS-RunPatchBaseline 任務、MaxConcurrency 和 MaxErrors。
• 「永遠啟動最新 AMI」——/aws/service/ 下的 Public Parameter Store 參數。
• 「來自多個來源的運維警報需要分流」——OpsCenter OpsItems。
• 「稽核每個管理員 session」——Session Manager + S3/CloudWatch Logs + KMS 加密。
• 「在同一排程中補丁 on-prem 主機和 EC2」——SSM hybrid activation + 同時涵蓋兩者的 Maintenance Window。

決策矩陣——每個 SysOps 目標對應的 Systems Manager 能力

考試時使用此查詢表。

常見陷阱總整理——Systems Manager Automation、Patch Manager 與 Run Command

陷阱一：補丁「已核准」但未安裝

補丁可以被基線核准，但仍未安裝——因為 instance 不在任何帶有 Operation=Install 的 Maintenance Window 任務範圍內，或因為 Maintenance Window 因 MaxErrors 停止，或因為 instance 在與預期不同的 Patch Group 中。檢查 Maintenance Window 歷程記錄和每台 instance 的合規狀態。

陷阱二：預設 7 天自動核准延遲拖慢緊急補丁

以明確核准清單或 auto-approval delay = 0 的自訂基線覆蓋。不要等 7 天。

陷阱三：SSM Agent 在缺少 IAM 或網路時靜默失敗

AmazonSSMManagedInstanceCore 加上到三個 SSM 端點的連線能力。缺少任一都是靜默失敗——Fleet Manager 根本不會列出該 instance。

陷阱四：Session Manager 日誌未加密

預設 session 日誌未加密。對於合規環境，在 session 偏好設定中使用客戶自管 KMS 金鑰設定 kmsKeyId。

陷阱五：Automation runbook 的 AssumeRole 為空

沒有 AssumeRole，runbook 嘗試使用呼叫者的身分。有線配置的 Config 補救無法提供這個——runbook 必須指定 AssumeRole，且角色的信任政策必須包含 ssm.amazonaws.com。

陷阱六：Run Command 輸出截斷為 2,500 字元

對任何非簡單的指令輸出，在呼叫時務必指定 S3 output bucket 和/或 CloudWatch Log Group。

陷阱七：Parameter Store SecureString 缺少 kms:Decrypt

讀取 SecureString 需要 ssm:GetParameter 以及加密金鑰的 kms:Decrypt。缺少後者會在解密時產生 AccessDeniedException，考生常誤診為參數存取問題。

陷阱八：Maintenance Window 任務應使用 Maintenance Window 服務角色而非 instance profile

Maintenance Window 本身以服務角色（AWS-SystemsManager-MaintenanceWindowRole 或類似）執行，與目標 instance 的 instance profile 不同。協調 Run Command 的權限來自服務角色；document 在主機上執行的動作的權限來自 instance profile。混淆兩者會導致難以追蹤的權限錯誤。

陷阱九：Patch Group 標籤鍵有空格

字面標籤鍵是 Patch Group（含空格）——不是 PatchGroup（駝峰式）也不是 patch_group。拼錯鍵名會讓 instance 靜默地退回預設基線。

陷阱十：一台 instance，一個 Patch Group

一台 instance 每次只能屬於一個 Patch Group。以 Patch Group=foo 和 Patch Group=bar 同時標記一台 instance（第二個標籤覆蓋第一個）不會讓它進入兩個基線——它只採用最後套用的標籤值。

FAQ — Systems Manager Automation、Patch Manager 與 Run Command

Q1：為什麼 Run Command 沒有列出我的 EC2 instance？

三個前提條件必須全部滿足：(a) SSM Agent 正在 instance 上執行——檢查 systemctl status amazon-ssm-agent；(b) IAM instance profile 附有 AmazonSSMManagedInstanceCore（或等效政策）；以及 (c) instance 透過 HTTPS port 443 有到 ssm.<region>.amazonaws.com、ec2messages.<region>.amazonaws.com 和 ssmmessages.<region>.amazonaws.com 的對外網路連線——透過 internet gateway、NAT gateway 或 VPC interface endpoints。如果 instance 在完全私有的子網中，你必須建立全部三個 VPC interface endpoints。SOA-C02 考試的診斷順序確實是：先 agent、再 IAM、再網路。

Q2：Run Command 和 State Manager 有什麼差異？

Run Command 是單次執行：你觸發它，它執行一次，完成。State Manager 是持續保持期望狀態：一個 State Manager association 按排程對目標集重複執行 Command document，自動納入符合目標標籤的新 instance。兩者底層使用相同的 Command documents。SOA-C02 的判斷線索是動詞：「現在執行」或「套用一次」→ Run Command；「確保」、「維持」或「持續強制執行」→ State Manager。State Manager 也為每個 association 記錄每台 instance 的合規狀態，而 Run Command 不會。

Q3：當預設基線有 7 天自動核准延遲時，如何在 24 小時內推出緊急安全補丁？

三個選項。(a) 以 KB 編號或 CVE 將特定補丁加入基線的明確核准清單——這僅對該補丁覆蓋自動核准延遲。(b) 為緊急情況建立 auto-approval delay = 0 的新 Patch baseline，關聯到受影響的 Patch Group，之後再還原。(c) 使用 Run Command 搭配 AWS-RunPatchBaseline 和指向一次性緊急基線的 BaselineOverride 參數。預設 7 天延遲不是硬性限制——它是保護免受問題補丁影響的預設值，當已知重大漏洞的風險超過迴歸風險時可以覆蓋。

Q4：什麼時候應選擇 Parameter Store SecureString vs Secrets Manager？

在以下情況使用 Secrets Manager：(a) 密鑰需要自動輪換——Secrets Manager 對 RDS、Redshift、DocumentDB 憑證有內建 Lambda 輪換，對其他密鑰有自訂輪換；(b) 密鑰值較大（Secrets Manager 允許 64 KB，而 SecureString 的 Advanced 層為 8 KB，Standard 層為 4 KB）；或 (c) 你需要透過資源政策進行細粒度的跨帳號共享。在以下情況使用 Parameter Store SecureString：(a) 值是組態資料，可能敏感，但不需要輪換；(b) 大量使用時成本較重要——Parameter Store Standard 免費；(c) 你想要階層組織（/myapp/prod/db/host）。對於 SOA-C02 考試，「輪換」或「RDS 憑證」→ Secrets Manager；「應用程式組態值，部分敏感」→ Parameter Store SecureString。

Q5：為什麼我的 SSM Automation runbook 因「AssumeRole 被拒」而失敗？

Runbook 的 assumeRole 參數指向一個 IAM 角色，該角色的信任政策必須包含 ssm.amazonaws.com 作為受信任主體。沒有它，Systems Manager Automation 服務就無法假設該角色，需要該角色權限的每個步驟都會失敗。此外，角色必須擁有任何步驟所執行的每個 API 呼叫的權限——aws:executeAwsApi 呼叫需要被呼叫 API 的明確 IAM 權限。常見模式：呼叫 s3:PutBucketPolicy 的補救 runbook 若角色不包含該權限，即使 AssumeRole 本身成功，也會在該步驟失敗。排解 Automation runbook 失敗時，務必同時檢查信任政策和權限。

Q6：如何在同一個排程中補丁 on-prem 伺服器和 EC2 instance？

透過 SSM Hybrid Activation 註冊 on-prem 伺服器：在 Systems Manager 主控台中，建立帶有 IAM 服務角色的 activation，取得 activation 代碼和 ID，並在每台 on-prem 主機上以 amazon-ssm-agent -register -code <code> -id <id> -region <region> 執行 agent。主機現在會以 mi- 前綴（相對於 EC2 的 i-）顯示為受管 instance。以和你的 EC2 機隊相同的 Patch Group 標籤標記 on-prem instance。設定帶有匹配標籤的目標集的 Maintenance Window，同樣的 AWS-RunPatchBaseline 任務會在同一個視窗中補丁 EC2 和 on-prem instance。這是 SOA-C02 跨雲和 on-prem 統一補丁的典範答案。

Q7：Maintenance Window 中的 MaxConcurrency 和 MaxErrors 有什麼差異？

MaxConcurrency 控制並行度——同時執行任務的目標 instance 數量。10 表示同時 10 台；10% 表示目標集的 10%。第一批完成後，下一批開始。MaxErrors 控制失敗容忍度——整個推進停止前的任務失敗數量。5 表示 5 次失敗後停止；5% 表示目標集的 5% 失敗後停止。兩者配合使用：在 200 台 instance 的機隊上，MaxConcurrency=10% 和 MaxErrors=5% 意味著視窗以 20 台一批進行，若 200 台中有 10 台失敗則永久停止。生產補丁通常使用較小的並發（5–20%）和較小的錯誤容忍（1–5%），避免有問題的補丁導致整個機隊下線。

Q8：能否從另一個帳號執行 SSM Automation runbook？

可以，透過 Automation 跨帳號、跨 region 執行。Runbook 在來源帳號中呼叫，但透過假設的角色在目標帳號中執行 API 呼叫。設定方式：(a) 在每個目標帳號中，建立由來源帳號信任且帶有 runbook 所需權限的 IAM 角色；(b) 在來源帳號中，建立能對目標帳號角色執行 sts:AssumeRole 的 AWS-SystemsManager-AutomationExecutionRole；(c) 以列出目標帳號和 region 的 TargetLocations 參數呼叫 runbook。Runbook 引擎為每個位置假設目標帳號角色並在該處執行。SOA-C02 可能問「從中央安全帳號補丁多帳號機隊」——Automation 跨帳號執行 + Systems Manager StackSets 式扇出是答案。

Q9：Session Manager session 日誌如何運作，日誌存放在哪裡？

Session 可記錄至 CloudWatch Logs、S3 或兩者，在 session 偏好設定（SessionManagerRunShell SSM document）中設定。每個按鍵和指令輸出都串流至配置的目的地。KMS 加密透過偏好設定中的 kmsKeyId 選擇性啟用。啟動 session 的 IAM 主體需要配置目的地的 s3:PutObject 和 logs:CreateLogStream / logs:PutLogEvents（SSM 服務代表使用者身分串流資料）。Session 日誌是 SSH 替代使用情境的主要稽核軌跡，SOA-C02 預期你在合規情境中以 KMS 加密啟用它們。不設定 session 偏好設定，sessions 完全不會記錄——只有中繼資料（誰、何時、哪個 instance）會出現在 CloudTrail 中。

Q10：Maintenance Window 任務在視窗時長結束時仍在執行會怎樣？

Maintenance Windows 有一個 Cutoff 值（以小時計），指定在視窗結束前多少時間停止啟動新任務。已執行的任務在視窗結束後若主機在合理時間內完成則繼續進行，但截止後不再納入新 instance。例如，Duration=4 小時、Cutoff=1 小時，視窗從凌晨兩點開始，五點停止啟動新任務，六點結束。這保護了在最後時刻啟動的任務不會在維護時間內無法完成。SOA-C02 考試可能問「補丁只部分套用到機隊，超過某個時間點後新 instance 未被納入」——答案是 Cutoff，不是失敗。調整 Cutoff 至少等於最長預期的每台 instance 任務時長，確保推進在視窗內乾淨完成。

延伸閱讀與相關運維模式

• What is AWS Systems Manager
• Working with SSM Agent
• Troubleshooting SSM Agent
• AWS Systems Manager Run Command
• AWS Systems Manager State Manager
• AWS Systems Manager Patch Manager
• About Patch Baselines
• About Patch Groups
• AWS Systems Manager Maintenance Windows
• AWS Systems Manager Automation
• Automation Runbook Reference
• AWS Systems Manager Session Manager
• Setting Up Session Manager
• AWS Systems Manager Parameter Store
• AWS Systems Manager Inventory
• AWS Systems Manager OpsCenter
• Create an IAM Instance Profile for Systems Manager
• Create VPC Endpoints for Systems Manager
• Systems Manager Compliance
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Systems Manager 就位後，接下來的運維層包括：CloudFormation Stacks 和 StackSets，用於部署 SSM 資源本身的基礎設施即程式碼佈建，為可重複環境補充 Systems Manager；排程任務與 Config 自動補救，用於驅動 Systems Manager Automation 的 EventBridge cron 規則和 Config 補救設定；EventBridge 規則和 SNS 通知，用於將 alarms 和 Health 事件路由進同一條 SSM Automation 流水線；以及 IAM 政策、MFA、SCPs 和存取疑難排解，用於每項 Systems Manager 能力所依賴的 IAM 身分（instance profiles、automation 角色、Maintenance Window 服務角色）。

• CloudFormation Stacks、StackSets 與疑難排解 — SOA-C02 學習筆記
• 排程任務、Config 自動補救與流程自動化 — SOA-C02 學習筆記
• EventBridge 規則、SNS 與自動補救 — SOA-C02 學習筆記
• IAM 政策、MFA、SCPs 與存取疑難排解 — SOA-C02 學習筆記