EventBridge 自動修復與 SSM Automation Runbooks

使用 SSM 自動化執行手冊 (SSM Automation Runbooks) 進行 EventBridge 自動修復，是 DOP-C02 期望您用來閉合偵測與修復循環的核心機制。當一個事件抵達 —— 例如 Config 規則標記了非合規資源、CloudWatch 警示觸發、AWS Health 發布了服務降級通知、GuardDuty 發現威脅或 EC2 狀態檢查失敗。EventBridge 會將該事件路由到一個 SSM 自動化文件，該文件執行一組等冪 (Idempotent) 的步驟來恢復至所需狀態。除非明確要求，否則無需人為參與。在領域 5 中，任何包含「自動地」、「無需手動介入」、「自我修復」或「修復」字眼的題目，都在要求您設計或選擇這個連鎖機制。如果文件類型選錯、IAM 角色選錯、等冪性出錯，或未能設定無效信件佇列 (DLQ)，這個連鎖機制就會成為下一個故障點，而不是預防故障。

本指南假設您已瞭解基本的 EventBridge 規則和 SSM 自動化。我們將重點放在 DOP-C02 的實作深度：自動化文件的 schema 版本 0.3、AWS 擁有的執行手冊目錄（超過 300 個預建文件，如 AWS-StopEC2Instance、AWS-RestartRDSInstance、AWS-DisableS3BucketPublicReadWrite）、編寫具有 aws:executeAwsApi、aws:executeScript、aws:branch、aws:approve、aws:waitForResource 步驟的自定義 YAML/JSON 文件、執行手冊的輸入與輸出、Assume Role 語義、Config 觸發的修復（手動與自動、重試行為）、EventBridge → Lambda 與 EventBridge → SSM 自動化的權衡、需要長時間運行工作流時選擇 Step Functions、安全重試的等冪性模式、透過變更管理員 (Change Manager) 和 aws:approve 進行的核准、修復本身失敗時的回退 (Rollback) 模式，以及針對無法啟動目標的事件所設的無效信件佇列。DOP-C02 考試指南的領域 5.1 和 5.2 涵蓋了這些內容。

為什麼 EventBridge 自動修復在 DOP-C02 中很重要

領域 5（事件和事件回應）是 DOP-C02 中全新的內容 —— DOP-C01 中沒有對應的部分。多個社群考試回報將其列為最困難的領域之一，因為第三方學習資料較少。考試測試的不是服務的存在，而是串接方式：哪個事件來源連接到哪個路由器，後者又連接到哪個執行器，最終影響哪個目標。漏掉一個環節或選錯環節都會失分。

此處的考試風格是架構模式識別。典型的題目如下：「當 Amazon EC2 執行個體報告 StatusCheckFailed_System 時，團隊希望如果是 EBS 根磁碟則自動恢復執行個體，如果是執行個體存儲則指示 Auto Scaling 群組終止並替換。針對標記為 production 的執行個體，修復路徑必須包含人工核准。哪種架構符合要求？」錯誤的答案會提供由 Lambda 執行所有邏輯的方案。正確答案是 警示狀態變更事件上的 EventBridge 規則 → 具備 aws:branch (EBS vs 執行個體存儲) 的 SSM 自動化文件 → 針對生產標籤，透過 SNS 路由至值班工程師的 aws:approve 步驟 → 條件式調用 RebootInstances 或 TerminateInstances API。考試測試您是否知道 aws:approve 和 aws:branch 的存在，以及瞭解將所有這些放入原始 Lambda 在營運上是不利的，因為執行手冊是可見的、具備版本的，且可以集中管理。

白話文解釋 EventBridge 自動修復執行手冊

自動修復循環概念上簡單，但機制上很複雜。三個類比可以澄清這些組成部分。

類比 1：智慧家庭警報系統

想像一個到處都是感應器的智慧家庭 —— 煙霧、漏水、運動、門、窗。當條件滿足時，每個感應器（CloudWatch 警示、Config 規則、GuardDuty 發現）都會向中央控制中心 (EventBridge) 報告。中心有一本規則手冊 (EventBridge 規則與模式)，上面寫著：「如果煙霧且非烹飪時段，執行煙霧應對程序；如果地下室漏水，執行切斷水源程序；如果門在凌晨 3 點打開且警報已啟動，執行通知警察程序」。每個程序都是預定義步驟的序列 —— 關閉瓦斯閥、解鎖前門、發送通知、記錄事件。那個序列就是 SSM 自動化文件。有些程序在執行真正具有破壞性的動作（如切斷電源）之前，會有一個「等待屋主核准」的步驟 (aws:approve)。屋主透過簡訊連結核准。如果屋主在 10 分鐘內未核准，程序就會逾時並退回到更安全的預設行為（例如僅通知而不斷電）。這正是 DOP-C02 測試的 EventBridge → 自動化文件 → 條件式核准模式。

類比 2：醫院「藍色代碼 (Code Blue)」應對

當病人的心率低於閾值時，心電圖監控器 (CloudWatch 警示) 會發出藍色代碼 (EventBridge 事件)。醫院廣播系統 (EventBridge 規則) 會將其廣播到特定頻道：值班心臟科醫師、快速反應護士、中央護理站。每位回應者口袋裡都有一本執行手冊 (SSM 自動化文件)：「步驟 1：確認脈搏。步驟 2：開始 CPR。步驟 3：呼叫急救車。步驟 4：給予藥物 X。步驟 5：記錄在病歷中。」執行手冊是等冪的 —— 即使兩名護士趕到並同時開始步驟 1，也不會造成傷害，因為確認脈搏重複做是安全的。Step Functions 相當於更長、跨越多天的照護計劃 —— 轉入 ICU、多天給藥排程、出院計劃、後續追蹤。藍色代碼短暫，由自動化處理；ICU 長期，由 Step Functions 處理。鏈接以 OpsItem（醫院個案管理系統中的事件圖表）結束，早班團隊可以透過它查看通宵發生的情況。

類比 3：工廠生產線自我修復

一家汽車零件工廠有數百個機器手臂。當感應器報告異常 —— 冷卻液不足、振動過高、馬達過熱 —— 工廠事件匯流排會分派正確的維修程序。常見程序是預先準備好的 (AWS 擁有的執行手冊目錄)：「冷卻液低 → 加滿至基準水平」。自定義的工廠特定程序則由維修團隊編寫（自定義 YAML 文件）。對於會改變生產排程的程序（例如停線一小時），程序中會有一個透過無線電 (SNS) 路由給班組主管的核准步驟。主管在定義的逾時內核准或拒絕。如果核准，生產線停機，且變更管理員會記錄正式變更以供稽核。如果程序本身失敗（例如加水閥門卡住），它會發出更高優先級的事件，呈報給人工技術員。這就是回退與呈報模式：修復執行手冊本身應該發出失敗事件，以觸發退回執行手冊或人工呼叫。

SSM 自動化文件解剖

一個文件具備頂層鍵值：

schemaVersion: '0.3'
description: 具備健康檢查的重啟 EC2 執行個體
parameters:
  InstanceId:
    type: String
    description: 目標 EC2 執行個體 ID
assumeRole: '{{ AutomationAssumeRole }}'
mainSteps:
  - name: stopInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: StopInstances
      InstanceIds:
        - '{{ InstanceId }}'
  - name: waitStopped
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds:
        - '{{ InstanceId }}'
      PropertySelector: $.Reservations[0].Instances[0].State.Name
      DesiredValues:
        - stopped
  - name: startInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: StartInstances
      InstanceIds:
        - '{{ InstanceId }}'

文件將整個程序捕捉為具備版本、可審查的程式碼，可從 EventBridge、主控台、CLI 或透過 Config 修復執行。

常見步驟類型

• aws:executeAwsApi：任何 AWS SDK 調用；最核心的步驟。
• aws:executeScript：內嵌任意 Python 或 Node.js；用於 SDK 無法直接處理的邏輯。
• aws:branch：根據輸入或前一步驟輸出的條件式下一步。
• aws:approve：暫停並等待透過帶有核准/拒絕連結的 SNS 通知進行的人工核准。
• aws:waitForAwsResourceProperty：輪詢直到資源屬性達到所需值。
• aws:assertAwsResourceProperty：如果屬性不符合預期，則使文件執行失敗的斷言。
• aws:runCommand：在 EC2 執行個體上調用 SSM Run Command 文件。
• aws:invokeLambdaFunction：調用 Lambda 以執行複雜的自定義邏輯。
• aws:createStack：部署 CloudFormation 堆疊作為修復的一部分。
• aws:changeInstanceState：停止/啟動/終止/重啟的簡寫。

IAM 與 Assume Role

文件宣告一個 assumeRole 佔位符。執行時，您傳遞角色 ARN。該角色必須具備文件執行的每個 API 調用的權限。一個常見模式是：EventBridge 規則的目標角色假設一個獨立的自動化執行角色，該角色僅限於特定文件和資源集。

EventBridge → SSM 自動化模式

典型的串接流程：

1. 事件來源發布到 EventBridge（CloudWatch 警示狀態變更、Config 合規性變更、AWS Health、GuardDuty 發現、自定義應用程式事件）。
2. EventBridge 規則透過模式匹配事件，例如 {"source": ["aws.config"], "detail-type": ["Config Rules Compliance Change"], "detail": {"newEvaluationResult": {"complianceType": ["NON_COMPLIANT"]}}}。
3. 目標：SSM 自動化執行。配置文件名稱、文件版本和一個輸入轉換器 (Input Transformer)，將事件欄位映射到文件參數（如從 $.detail.resourceId 獲取 InstanceId）。
4. DLQ（無效信件佇列）設在規則目標上，捕捉交付失敗以供事後分析。
5. 目標上的重試策略設定最大存留時間和最大嘗試次數。

規則目標上的 IAM 角色需要對文件 ARN 的 ssm:StartAutomationExecution 權限。SSM 自動化文件的角色需要其步驟所需的所有 AWS API 權限。

Config 規則自動修復

Config 的整合比通用的 EventBridge → SSM 模式更緊密。您可以針對每個規則配置修復動作：

• 文件：SSM 自動化文件名稱。
• 參數：將非合規資源屬性映射到文件輸入。特殊參數 RESOURCE_ID 會被自動填充。
• 模式：Automatic（非合規後立即執行）或 Manual（需要操作員點擊）。
• 重試：最大嘗試次數和嘗試間隔秒數。
• 並行性：最大平行執行次數。

當修復可能影響生產穩定性且您希望具備人工票據和審核步驟時，手動模式是正確選擇。自動模式適用於低風險、經過充分測試的修復，如「移除公開 S3 ACL」或「在新磁碟卷上啟用 EBS 加密」。

用於長時間運行工作流的 Step Functions

SSM 自動化文件每次執行有 12 小時的最大執行時間。對於運行時間更長的工作流 —— 多天帳戶配置、週級階段性遷移、複雜的 Saga 模式 —— 請使用 AWS Step Functions。Step Functions：

• 標準工作流：長達 1 年，精確一次執行，具備完整稽核歷史。
• 高速工作流 (Express workflows)：高吞吐量，至少一次執行，最長 5 分鐘。

Step Functions 可以調用 SSM 自動化作為服務整合 (aws-sdk:ssm:startAutomationExecution)，因此模式可以組合：EventBridge → Step Functions → 多個 SSM 文件 → 通知。

等冪性模式

每個修復文件都必須是等冪的 (Idempotent) —— 執行兩次應產生相同的最終狀態且不報錯。常見模式：

• 先檢查後執行：使用 aws:assertAwsResourceProperty 步驟驗證目前狀態；如果已處於所需狀態，則跳過動作。
• 使用等冪的 API：PutBucketEncryption 是等冪的；CreateBucket 不是（對現有儲存貯體會報錯）。
• 等冪性權仗 (Idempotency Tokens)：接受 ClientRequestToken 參數的 AWS API（CloudFormation、SQS 等）可以實現安全重試。
• 基於標籤的防衛：在第一次修復時標記資源；後續執行檢查標籤，如果已修復則跳過。

若無等冪性，重試會放大故障：如果在 10 個步驟中的第 5 步發生暫時性 API 錯誤，重試會再次執行步驟 1-4，可能會建立重複資源。

核准 —— aws:approve 與變更管理員

人工介入的兩種模式：

aws:approve 步驟

在文件本身，aws:approve 步驟會暫停執行並發送帶有核准/拒絕連結的 SNS 訊息。最多支持 10 位核准者；可配置所需的最少核准人數。逾時時間（預設 7 天）過後，核准預設為拒絕。

變更管理員 (Change Manager)

變更管理員將整個文件執行包裝在一個變更請求中，具備模板、核准工作流和稽核歷史。當您需要符合正式的變更管理合規性（如 SOC 2、ISO 27001、醫療保健法規）時，請使用變更管理員。變更管理員模板定義：

• 每個變更類型的必要核准者。
• 允許的變更窗口（例如「生產變更僅限週日 02:00-04:00」）。
• 必要的模板欄位和理由說明。

DOP-C02 考試測試您是否知道 aws:approve 是一種較輕量的模式（僅在一個執行手冊內的核准門檻），而變更管理員是較沉重的正式治理模式（變更請求、模板、行事曆強制執行）。

OpsCenter 整合

當自動修復無法完全解決問題時，執行手冊應在 OpsCenter 中建立一個 OpsItem 以供人工審查。OpsItem 包含：

• 來源資源 ARN。
• 嚴重性。
• 相關警示、X-Ray 追蹤、CloudWatch 儀表板。
• 來自執行手冊執行的筆記。
• 建議的後續執行手冊。

OpsCenter 成為「需要人工處理的問題」的中央佇列 —— 當自動化鏈條部分成功或需要人工判斷時，這就是正確的目的地。

高頻考試陷阱

陷阱 1：Lambda vs SSM 自動化

當動作是以固定序列執行一系列 AWS API 調用時，優先選擇 SSM 自動化。Lambda 適用於任意程式碼、自定義邏輯或非 AWS API 調用。對於簡單的多步驟 API 序列，考試會提供 Lambda 作為干擾項；請選擇執行手冊。

陷阱 2：12 小時自動化限制

如果工作流運行時間超過 12 小時，您需要 Step Functions。SSM 自動化將會逾時。

陷阱 3：aws:approve 預設逾時

7 天。如果題目要求「在 1 小時內核准」，請明確設定 Timeout。

陷阱 4：Config 自動修復並行性

預設並行性為 1。對於跨許多資源的大規模修復，請增加並行限制，或直接透過 EventBridge → SSM 進行修復以繞過限制。

陷阱 5：EventBridge 重試 vs Lambda 非同步重試

EventBridge 在規則目標上有自己的重試與 DLQ。Lambda 非同步調用也有自己的重試與 DLQ。它們是分層的 —— 兩者都要配置。

陷阱 6：文件架構版本不匹配

自動化需要 schemaVersion: '0.3'（或舊版的 0.2）。Run Command 需要 2.2。狀態管理員關聯使用 2.0。架構版本不匹配會在執行時失敗。

陷阱 7：跨帳戶修復需要信任

要從中央稽核帳戶修復成員帳戶中的資源，稽核帳戶的自動化角色需假設每個成員帳戶中的一個角色。成員帳戶必須具備信任策略。CloudFormation StackSets 或 Control Tower 可以統一部署這些信任角色。

DOP-C02 考試模式與實戰情境

情境 1：禁用整個組織中的公開 S3 儲存貯體

題目：「一個組織需要所有變為公開讀取的 S3 儲存貯體在 5 分鐘內得到修復。」正確做法：透過合規套件 (Conformance Pack) 向每個帳戶部署 Config 規則 s3-bucket-public-read-prohibited；使用 AWS-DisableS3BucketPublicReadWrite 進行自動修復。錯誤做法：每 5 分鐘輪詢所有儲存貯體的 Lambda。

情境 2：隔離 GuardDuty 高嚴重性發現

題目：「當 GuardDuty 發現受損的 EC2 執行個體時，立即將其移至隔離安全性群組並建立調查票據。」正確做法：針對嚴重性 ≥ 7 的 GuardDuty 發現設定 EventBridge 規則；目標為執行以下操作的 SSM 自動化文件：(1) 修改安全性群組，(2) 使用發現詳情建立 OpsItem，(3) 對執行個體進行快照以供取證。AWS 擁有的 AWS-DisableGuardDutyFinding-Compromised-EC2 提供了一個起始模板。

情境 3：具備核准機制的 RDS 故障自動重啟

題目：「當 RDS 報告故障轉移失敗狀態時，重啟它；如果是生產執行個體，則先要求核准。」正確做法：在 Production 標籤上具備 aws:branch 的 SSM 文件；生產分支具有路由到值班 SNS 主題的 aws:approve 步驟；非生產分支直接進入 RebootDBInstance。

情境 4：長時間運行的多帳戶配置

題目：「配置新帳戶需要 3 天時間：SCP 附加、CloudFormation StackSet 部署、IAM Identity Center 配置、Config 彙總器納入。」正確做法：使用 Step Functions 標準工作流編排多天鏈條；SSM 自動化處理單個短任務。

情境 5：EBS 磁碟卷加密漂移

題目：「偵測任何未加密的 EBS 磁碟卷，並進行快照-加密-恢復，或者如果無法安全地就地重新加密則發出警示。」正確做法：Config 規則 encrypted-volumes → 自動修復 AWSConfigRemediation-EncryptUnencryptedVolume（執行快照、加密、交換）。

常見問題

Q1：我應該使用 SSM 自動化、Lambda 還是 Step Functions 進行修復？

對於可能存在 AWS 擁有的執行手冊的短時間 (≤12 小時) AWS API 驅動工作流，請使用 SSM 自動化。對於任意程式碼或非 AWS API 調用，請使用 Lambda。對於長時間運行 (>12 小時) 或複雜分支的工作流，請使用 Step Functions。Step Functions 也可以編排多個 SSM 文件。

Q2：如何使修復執行手冊具備等冪性？

三種模式：(1) 使用 aws:assertAwsResourceProperty 進行先檢查後執行以驗證目前狀態。(2) 使用等冪的 API (PutBucketEncryption, PutBucketPolicy)。(3) 基於標籤的防衛 —— 第一次運行標記資源，後續運行如果標籤存在則跳過。

Q3：Config 自動修復何時重試？

Config 修復會根據規則的 RetryAttemptSeconds 和 MaximumAutomaticAttempts 配置進行重試。用盡嘗試次數後，規則仍保持為 NON_COMPLIANT，且 Config 會向 EventBridge 發出修復失敗事件以供進一步呈報。

Q4：如何在修復前要求核准？

兩個選項：(1) 在 SSM 文件中設定行內 aws:approve 步驟（較輕量）。(2) 將文件執行包裝在變更管理員中，使用需要核准者簽署的模板（正式變更管理）。當稽核/合規部門關心變更請求的書面記錄時，請使用變更管理員。

Q5：如何從中央帳戶修復成員帳戶中的資源？

在每個成員帳戶中部署一個信任角色（透過 CloudFormation StackSets 或 Control Tower），允許中央帳戶的自動化角色假設它。SSM 文件在每個步驟前使用 assumeRole 假設進入成員帳戶。

Q6：如果我的修復執行手冊本身失敗了怎麼辦？

SSM 自動化執行會向 EventBridge 發出失敗事件。使用後續規則捕捉這些事件，建立 OpsItem 並呼叫值班工程師。建立具有顯式失敗處理的修復鏈，而不是盲目重試。

Q7：如何偵錯失敗的修復？

檢查 SSM 自動化執行歷史紀錄，查看失敗的步驟及其錯誤訊息。查看 EventBridge 規則的 DLQ 以尋找甚至從未啟動的事件。查看 CloudTrail 中的 StartAutomationExecution API 調用以查看是誰調用的。查看 CloudWatch Logs 以獲取任何 aws:executeScript 步驟的輸出。

交叉引用

• CloudWatch 警示與 EventBridge 是這些修復鏈的觸發層；請參閱 cloudwatch-alarms-eventbridge-integration。
• CloudTrail 與 Config 儀表板提供了觸發修復的偵測訊號；請參閱 cloudtrail-config-audit-dashboards。
• 事件管理員 (Incident Manager) 與 AWS Health 處理超出自動修復範圍的高嚴重性呈報；請參閱 systems-manager-incident-manager-health。
• 部署失敗故障診斷使用相同的 EventBridge → SSM 模式進行回滾自動化；請參閱 deployment-failure-troubleshooting。
• CloudWatch 指標與日誌洞察 (Logs Insights) 提供了對修復執行情況的可觀測性；請參閱 cloudwatch-metrics-logs-insights。