排程任務、Config 自動修復與流程自動化

SOA-C02 Exam Guide 的 Task Statement 3.2 用一句話說完了核心概念：「自動化手動或重複性流程」——而這句話背後藏著三個在 SysOps Administrator 考試中反覆被考的運維領域：按時間表排程任務、偵測資源偏離政策的狀態、以及將 Config rule 串接 EventBridge rule 再到 Systems Manager Automation runbook，形成閉環補救流程。SAA-C03 問「哪個 AWS 服務能偵測不合規的 S3 bucket？」，SOA-C02 問的是「bucket 已不合規——寫出 EventBridge target、掛上 SSM Automation document、設定補救 IAM role，並說明為什麼上週日凌晨 02:00 auto-remediation 靜默失敗」。排程任務與 Config 自動化，是 EventBridge、EventBridge Scheduler、AWS Config、Systems Manager Automation 和 Maintenance Windows 全部交織在一起的主題。

本指南從 SysOps 視角完整走過排程任務與 Config 自動化：什麼情況下 EventBridge Scheduler 才是正確答案而非 EventBridge rule、如何正確讀寫 rate 與 cron 表達式而不掉入 5 欄位對 6 欄位的陷阱、periodic Config rule 與 configuration-change Config rule 在實務中的差異、Config auto-remediation 如何透過 remediation role 掛接 SSM Automation document、以及 Systems Manager Maintenance Windows 如何將修補、快照與任意 runbook 整合到有優先序與並行限制的週期性排程中。你也會看到 SOA-C02 反覆出現的場景：不該用 EC2 cron job 跑的夜間快照、因 trust policy 缺失而補救失敗的 Config rule、因 cron 欄位數錯誤而觸發次數不對的 EventBridge rule，以及透過 EventBridge Scheduler 跨帳號廣播排程的架構。

為什麼排程任務與 Config 自動化是 SOA-C02 Domain 3.2 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 3.2 下列出三項技能：使用 AWS 服務自動化部署流程、實作自動化修補管理，以及「使用 AWS 服務排程自動化任務（例如 EventBridge、AWS Config）」。修補管理在本學習集的另一個主題中獨立討論；部署自動化與 CloudFormation 重疊；本主題負責第三項技能，加上貫穿各服務的膠水層：排程任務與 Config 驅動的自動化。

在 SysOps 層級，問題的框架是運維，而非架構設計。SAA-C03 問「應該用哪個 AWS 服務偵測公開的 S3 bucket？」——答案是 AWS Config 加上受管 rule。SOA-C02 問「public-bucket Config rule 已在觸發，但 auto-remediation 從未執行——為什麼？」——答案通常指向 remediation role 的 trust policy、SSM Automation document 缺少某個 parameter，或是 rule 設在手動而非自動模式。排程任務與 Config 自動化是所有後續 SOA-C02 主題插槽的匯聚點：CloudWatch alarms 餵給 EventBridge、Auto Scaling 對 scheduled action 作出反應、CloudFormation 將排程與 rule 作為 IaC 部署、IAM 政策為整條鏈授權、VPC endpoint 讓私有 instance 能觸達 SSM 與 EventBridge API。

白話文解釋 排程任務、Config Auto-Remediation 與流程自動化

排程任務與 Config 自動化的術語堆疊很快。三個類比能讓這些概念變得具體好記。

類比一：捷運控制中心 + 廣播系統 + 維修班組

把整個 AWS 自動化架構想成一個捷運控制中心的運行排班體系。EventBridge Scheduler 與 EventBridge scheduled rules 是列車時刻表，宣告「現在是凌晨 02:00——啟動夜間快照任務」。AWS Config rules 是車廂感測器，持續監看每節車廂並通報「B3 車廂有一顆未加密的 EBS 磁碟！」EventBridge event-pattern rules 是中央廣播系統，接收所有警報（時刻表鳴笛、感測器告警、閉路攝影機訊號）並決定要派誰去處理。SSM Automation documents 是維修班組的標準作業程序（SOP）——逐步說明要做哪些動作，並以參數指定要修哪個設備。Remediation role 是維修人員的識別證，只開放執行任務所需的門禁，多餘的通道一律鎖死。Maintenance Windows 是計畫性夜間停駛維修班，有自己的班表、人員、優先序——凌晨 02:00 修補韌體、02:30 備份日誌、03:00 複製快照。整個系統的重點在於：凌晨 02:00 不需要任何人手動點擊；一切都因為時刻表、廣播系統和維修班組被明確政策串聯在一起而自動運作。

類比二：餐廳 SOP 作業手冊

現代餐廳廚房靠的是標準作業程序（SOP）。開店前置清單（「10:00 開爐、10:15 檢查冰箱溫度、10:45 完成備料」）是scheduled rule——純粹基於時間觸發。食品安全規則「如果冰箱溫度超過 5°C，隔離食材並通知維修」是Config rule 加 auto-remediation——事件驅動、附帶條件判斷，並掛上對應的 runbook。主廚的擺盤 SOP 是SSM Automation document：步驟一擺主菜、步驟二淋醬汁、步驟三點綴裝飾、步驟四擦拭盤緣。每個步驟都有參數（哪種主菜、哪種醬汁）。新進廚師（新 instance）不會自由發揮；他們照 SOP 執行。當衛生稽查（合規審計）要求「拿出冰箱溫度異常的處理 SOP 給我看」，廚房直接交出作業手冊——這正是 AWS Config 加 SSM Automation 在雲端提供的能力。

類比三：工廠自動化產線與品管閘門

自動化工廠產線按時鐘運行——每 30 秒零件往前推進一站，這個節奏就是EventBridge scheduled rules。每個工作站設有品管閘門——感測器檢查零件是否合規，這就是AWS Config rule 的 configuration-change 觸發。當零件未通過品管閘門，導流臂將它撥離主線，送入返修格執行固定的修正步驟序列，這就是EventBridge → SSM Automation 鏈。返修格的工具之所以能動作，是因為工廠的門禁卡系統授權了它們，這就是remediation role 的 trust policy 與 IAM 權限。每隔一段時間，班長會巡視全線並對照清單審核——這就是每 24 小時執行一次、無論有無事件都全面掃描的periodic Config rule。工廠能穩定出貨，是因為每個步驟都預先定義、參數化、可審計，且能從失敗中恢復。

在 AWS 上排程自動化：EventBridge Scheduler vs EventBridge Rules

AWS 提供兩種排程原語，都掛在 EventBridge 品牌下，但架構上截然不同。選對哪一個是 SOA-C02 反覆出現的題型。

EventBridge scheduled rules（原始原語）

EventBridge scheduled rules 是 CloudWatch Events scheduled rules 的繼承者。它們存在於 default event bus，透過 EventBridge 的「Rules」介面或 PutRule 設定，使用 rate(...) 或 cron(...) 表達式。每條 rule 支援最多五個 target，只在單一 AWS Region 運作，以 rule 名稱識別。定價包含在 EventBridge 中——按觸發次數計費，rule 本身不另外收費。

適合使用 scheduled rules 的情境：

• 每個 Region 排程數量少（幾十到幾百個）。
• 排程天然與你已在使用的 event bus 綁定。
• 希望在同一個 rule 列表中統一管理 event-pattern rule 和 scheduled rule。
• 從 CloudWatch Events 遷移——相同的 cron(...) 語法仍完全相容。

促使團隊轉向 EventBridge Scheduler 的限制：

• 每條 rule 最多五個 target；50 個 target 就需要 10 條 rule。
• 沒有原生一次性排程（at(...) 表達式）。
• 沒有原生時區支援——cron 一律以 UTC 評估。
• 沒有 flexible time window 可加入 jitter——當 10,000 個排程同時在同一秒觸發，下游 API 會被打垮。
• 每個 Region 的 rule 數量有配額上限。
• 2020 年前沒有原生的每條 rule DLQ。

EventBridge Scheduler（新一代專用服務）

EventBridge Scheduler 於 2022 年 11 月以獨立服務推出，專為大規模排程呼叫設計。它支援 一次性排程（at(...)）、週期性排程（rate(...) 或 cron(...)）、時區感知的 cron 評估、flexible time windows 加入 jitter、dead-letter queues、指數退避重試政策，以及用於組織排程與套用標籤的 schedule groups。它支援超過 270 種 AWS 服務 API 作為 target（相較之下 EventBridge rule 的內建 target 清單較小），並為常見 target（Lambda、SQS、SNS、ECS、Step Functions、SSM Automation）提供範本化設定，以及可呼叫任意 AWS API 的通用 target。

適合使用 EventBridge Scheduler 的情境：

• 每個帳號有數百、數千甚至數百萬個排程。
• SaaS 應用的每租戶排程——每個租戶各有獨立排程。
• 時區感知 cron——「每個工作日東京時間早上 9 點」需要 cron(0 9 ? * MON-FRI *) 加上 TimeZone: Asia/Tokyo 設定。
• 一次性排程——「在 2026-05-15T09:00:00 UTC 只發送一次這個提醒」。
• Flexible time windows——「在以 02:00 UTC 為中心的 15 分鐘視窗內任意時點觸發」以分散流量。

決策摘要

EventBridge Rate 與 Cron 表達式：語法與考試陷阱

幾乎每位 SOA-C02 考生都會碰到至少一道需要讀懂或寫出 rate 或 cron 表達式的題目。欄位看似簡單，但陷阱都是真實存在的。

Rate expressions

Rate expression 的格式為 rate(value unit)，其中：

• value 是正整數。
• unit 為 minute(s)、hour(s) 或 day(s)。1 用單數，其餘用複數。

有效範例：rate(5 minutes)、rate(1 hour)、rate(2 hours)、rate(7 days)。

無效範例：rate(30 seconds)（不支援秒級粒度）、rate(0 minutes)（必須為正整數）、rate(1 minutes)（應為 1 minute）、rate(1 month)（沒有 month 單位——改用 rate(30 days) 或 cron）。

Rate expression 從 rule 建立的時間點開始計算。一條在 09:13:42 建立、設定 rate(1 hour) 的 rule，下次觸發是 10:13:42，再下次是 11:13:42，依此類推。若要將觸發時間對齊整點（如精確的 09:00、10:00、11:00），就需要改用 cron expression。

EventBridge cron expressions — 六個欄位

EventBridge cron 有 六個欄位，依序為：

cron(minutes hours day-of-month month day-of-week year)

考試關鍵規則：

• 不能在同一個表達式中同時對 day-of-month 和 day-of-week 使用 *。其中一個必須設為 ?（「無特定值」萬用字元）。標準 Unix cron 沒有 ? 萬用字元；EventBridge 強制要求。
• Day-of-week 的數值為 1=SUN、2=MON、……、7=SAT（與某些 cron 方言不同）。
• Year 欄位是必填的——EventBridge 不接受 5 欄位 cron。
• 對 EventBridge scheduled rules，cron 一律以 UTC 評估。EventBridge Scheduler 可設定 TimeZone。

常見 cron 範例

常見排程自動化 Target：Lambda、SSM Automation、Step Functions 等

排程觸發之後，實際呼叫什麼？Target 的選擇決定了你的自動化運作方式。

Lambda — 適合輕量、單步驟任務

Lambda function 是正確的 target，當：

• 工作時間短（低於 15 分鐘——Lambda 的逾時上限）。
• 是單步驟 API 呼叫或計算——呼叫 EC2 API、寫入 S3、推送到 webhook。
• 你想用 Python 或 Node.js 解析事件 payload 並轉發。
• 目標服務不被 EventBridge 或 Scheduler 原生支援。

範例：夜間掃描過期憑證、每小時健康探測、每週費用報告 email。

Systems Manager Automation document — 適合多步驟運維序列

SSM Automation document 是正確的 target，當：

• 工作有多個步驟，含分支、重試或等待資源狀態的語意。
• 你需要 IAM 有界執行（assume 特定 role，使用 AssumeRole action）。
• 你需要一份人工也能手動執行相同任務的文件化 runbook。
• 你需要參數化——同一份 document，不同輸入（instance ID、tag 值）。

範例：依 tag 在 18:00 停止 instance、09:00 啟動（AWS-StopEC2Instance、AWS-StartEC2Instance）；為標記的磁碟建立 EBS 快照（AWS-CreateSnapshot）；修補整批機器（AWS-RunPatchBaseline）；按排程更新 security group rule（自訂 document）。

Step Functions — 適合長時間執行、複雜編排

Step Functions 是正確的 target，當：

• 工作橫跨多個服務且有複雜的錯誤處理邏輯。
• 執行時間可能超過 15 分鐘——Standard Workflows 可跑長達一年。
• 你需要明確的狀態機視覺化以供審計。
• 你需要帶 map state 語意的並行分支——以每個項目的重試策略並行處理 N 個項目。

範例：夜間 ETL 管線、多 Region 容錯移轉編排、複雜的災難復原演練。

其他常見 target

• SQS / SNS — 廣播給多個訂閱者而不直接呼叫運算資源。
• ECS RunTask — 按排程啟動容器化批次任務。
• CodePipeline — 按排程觸發 pipeline 執行。
• EC2 / Auto Scaling action — 透過 Auto Scaling scheduled action（Auto Scaling 原生的原語，與 EventBridge 排程模式有所重疊）調整容量。
• Generic AWS API target（僅限 Scheduler） — 不寫 Lambda 就能直接呼叫任意 AWS API。

AWS Config Rule 觸發類型：Periodic vs Configuration Change

AWS Config 以兩種觸發模式對照 rule 評估資源，選擇哪種模式在運維上有重大影響。

Configuration-change rules

Configuration-change rule 在 Config 記錄到指定資源類型的變更時立即觸發。Config 以近即時（通常在幾分鐘內）記錄所有受支援資源的變更。rule 觸發時，只評估發生變更的那個資源——而非整個資源群。

適合使用 configuration-change rule 的情境：

• 你希望在資源被錯誤建立或錯誤修改時立即收到回饋。
• 檢查成本低且以資源為範圍（例如「這個 EBS 磁碟必須加密」）。
• 你想在問題資源上立即驅動 auto-remediation。

範例：s3-bucket-public-read-prohibited、encrypted-volumes、restricted-ssh、iam-user-mfa-enabled。

Periodic rules

Periodic rule 按排程觸發——每 1、3、6、12 或 24 小時。觸發時，它評估所有在範圍內的資源，而非只評估有變更的那些。

適合使用 periodic rule 的情境：

• 檢查需要跨多個資源進行聚合，或依賴外部狀態（例如「此帳號至少啟用一條 CloudTrail trail」）。
• 你希望捕捉不會產生 configuration-change 事件的緩慢漂移（例如附加在多個 role 上的受管政策）。
• 檢查成本較高，你希望限制其執行頻率。

範例：cloudtrail-enabled、securityhub-enabled、multi-region-cloudtrail-enabled、required-tags（常設為 periodic 以避免在每次 tag 變更時評估）。

混合評估

許多 AWS 受管 rule 同時支援兩種觸發類型——在建立 rule 時選擇。常見的運維模式是：configuration-change 提供快速回饋，再加上每日 periodic 重新評估作為安全網。

AWS Config Auto-Remediation：完整鏈條

AWS Config auto-remediation 是 SOA-C02 Domain 3.2 的頭號閉環補救模式。完整的鏈條是：Config rule 偵測到不合規 → 補救動作執行 SSM Automation document → document 修復資源 → 選擇性地重新評估確認已合規。

補救設定的解剖

補救設定附加在 Config rule 上，並指定以下內容：

1. Target：一份 SSM Automation document——可以是 AWS 受管 document（例如 AWS-EnableS3BucketEncryption、AWS-DisablePublicAccessBlockS3、AWS-ConfigureS3BucketLogging）或自訂 document。
2. Parameters：document 的輸入值。特殊參數 ResourceId（或 ResourceValue）由 Config 自動填入不合規資源的 ID。
3. Resource ID resolver：Config 記錄的哪個資源對應到 document 的哪個參數。對 S3 rule 而言，bucket name 透過此映射綁定到 document 的 BucketName 參數。
4. Automatic vs manual：automatic 模式下，Config 一偵測到 NON_COMPLIANT 就立即呼叫 document。manual 模式下，需由人工在 Config 主控台點擊「Remediate」。
5. Maximum automatic attempts：重試次數 1–25 次，間隔 60–2700 秒。
6. Execution role：SSM assume 來執行 document 的 IAM role。這是最容易出錯的設定項。

Remediation IAM role

Remediation role 必須：

• 擁有允許 ssm.amazonaws.com assume 它的 trust policy（principal block 中必須有 Service: ssm.amazonaws.com）。
• 擁有足夠寬的權限以執行 SSM Automation document 的各步驟——s3:PutBucketEncryption、ec2:CreateTags 等。
• 若 document 呼叫需要傳遞 role 的其他服務，還需要對自身具有 iam:PassRole 權限。

常見失敗模式：補救執行到「InProgress」後再也無法進入「Success」，原因是 assumed role 在多步驟 document 深處缺少某個特定 API 權限。診斷方式：在主控台開啟 SSM Automation 執行記錄，鑽入失敗的步驟，閱讀 AccessDenied 錯誤，然後將缺少的權限加入 role 政策。

範例：端到端 auto-remediation——未加密的 EBS 磁碟

1. Config rule：encrypted-volumes（受管，configuration-change 觸發）。
2. Remediation document：AWS-EnableEbsVolumeEncryption——實際上並不存在這個就地加密的受管 document。實際可行的補救方式是 AWS-CreateEncryptedVolumeFromSnapshot，或自訂 document：快照 → 加密複製快照 → 建立新磁碟 → 卸載舊磁碟 → 掛載新磁碟 → 標記資源。
3. Parameters：VolumeId 從 Config 資源 ID 映射；KmsKeyId 設為加密用的 KMS key。
4. Mode：manual（因為這個工作流程具破壞性——卸載磁碟需要停機，需由人工審核）。
5. Role：SSM remediation role，具備 EC2 快照、複製、建立磁碟、掛載、卸載與標記的權限。

範例：端到端 auto-remediation——不合規的 tag

1. Config rule：required-tags（受管，configuration-change 觸發），參數設為 tag1Key=Owner、tag1Value=*。
2. Remediation document：AWS-SetRequiredTags（自訂或社群版）。對資源 ID 呼叫 ec2:CreateTags（或其他可標記服務的 API）。
3. Parameters：ResourceId 來自 Config；tag key/value 來自 rule 參數。
4. Mode：automatic，重試 3 次，間隔 300 秒。
5. Role：Remediation role 具備 ec2:CreateTags、s3:PutBucketTagging 等，適用於範圍內的資源類型。

Conformance packs — 打包好的 rule 與補救

Conformance pack 是一個 YAML 範本，將多條 Config rule 和補救動作打包成單一可部署的單元。AWS 發布了對齊 CIS、NIST 800-53、PCI-DSS、HIPAA 以及 AWS 運維最佳實踐集的範例 pack。Conformance pack 可在帳號層級部署，或透過 Organizations 整合跨整個組織部署。實務使用案例：「我們需要在每個帳號強制執行 CIS 控制」——在 org 層級部署 CIS conformance pack 一次，透過 aggregator dashboard 監控合規狀態，並依 region 自訂參數。

Systems Manager Maintenance Windows：有 Target、Task 與優先序的週期排程

Maintenance Window 是 Systems Manager 中的週期性時間槽，在其中執行一組定義好的排程任務，作用於指定的 target。Maintenance Windows 是 SOA-C02 答覆「每週定時對同一批機器執行例行運維工作」的標準答案。

四大構成要素

1. Schedule：cron(...) 或 rate(...) 表達式，加上持續時間與截止時間。持續時間是視窗開放的時長（例如 4 小時）；截止時間是在視窗結束前多少分鐘停止啟動新任務（例如 1 小時）。每個視窗可獨立設定時區。
2. Targets：視窗的已登記資源集合。目標定位模式包括 instance ID、tag-based（tag:Environment=Production）或 resource group ARN。Target 只需登記一次，所有 task 都可重複使用。
3. Tasks：實際要執行的工作。Task 類型包括：
   • RUN_COMMAND — 執行 SSM Run Command document（例如 AWS-RunPatchBaseline）。
   • AUTOMATION — 執行 SSM Automation document。
   • LAMBDA — 呼叫 Lambda function。
   • STEP_FUNCTIONS — 啟動 Step Functions 狀態機。
4. Priority 與 concurrency：每個 task 有數字優先序（數字越小優先級越高；相同優先序的 task 並行執行）。你還需設定最大並行數（一次最多對多少 target 動作——10 個 instance 或機器群的 25%）以及最大錯誤數（多少失敗後停止——2 個 instance 或 10%）。

運維使用案例

• 修補：每週日 02:00 以 10% concurrency、max errors 5% 對 tag-based target 執行 AWS-RunPatchBaseline Run Command。
• 快照：每週對所有生產 EBS 磁碟執行 AWS-CreateSnapshot Automation。
• 日誌輪替 / 清理：自訂 Run Command，在視窗期間輪替每個 instance 上的舊日誌。
• 設定漂移檢查：Lambda task 輪詢 Config rule 的合規狀態並產生報告。

Maintenance Windows vs EventBridge scheduled rules

兩者都可以用 cron 表達式觸發。那什麼情況選哪個？

SSM Automation Document 解剖：Parameters、Steps 與 Outputs

只要答案涉及執行多步驟自動化，實際執行的就是 SSM Automation document。了解其結構，讓你能推斷 runbook 為何停頓或失敗。

Document 結構（YAML）

schemaVersion: "0.3"
description: "Stop EC2 instances by tag."
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  InstanceIds:
    type: StringList
    description: List of instance IDs.
  AutomationAssumeRole:
    type: String
    default: ""
mainSteps:
  - name: stopInstances
    action: aws:changeInstanceState
    inputs:
      InstanceIds: "{{ InstanceIds }}"
      DesiredState: stopped
  - name: waitForStopped
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds: "{{ InstanceIds }}"
      PropertySelector: "Reservations[0].Instances[0].State.Name"
      DesiredValues:
        - stopped
outputs:
  - stopInstances.StoppedInstances

關鍵欄位：

• schemaVersion：0.3 是現代 Automation schema；1.2 是較舊的 Run Command。
• assumeRole：document 所 assume 的 IAM role。在 Config auto-remediation 中，這就是 remediation role。
• parameters：類型化輸入（String、StringList、Integer、Boolean、MapList）——在執行時傳入。
• mainSteps：有序的 action 列表。每個步驟有 action（action plugin）、inputs、選用的 onFailure、onCancel、nextStep 與 outputs。
• outputs：document 的頂層輸出，參照各步驟的輸出。

常見 Automation actions

• aws:executeAwsApi — 直接呼叫任意 AWS API。
• aws:runCommand — 在 EC2 或地端機器上執行 SSM Run Command document。
• aws:executeScript — 內嵌執行 Python 或 PowerShell 腳本。
• aws:waitForAwsResourceProperty — 暫停等待資源屬性達到期望值（instance 運行中、快照完成）。
• aws:assertAwsResourceProperty — 若屬性不符則讓 document 失敗（前提條件檢查）。
• aws:branch — 依前一步驟的輸出進行條件分支。
• aws:approve — 暫停等待透過 SNS 通知進行的人工審核。
• aws:changeInstanceState — 啟動、停止、終止、重新開機。

從 Config 傳遞參數

當 Config 呼叫 document 進行補救時，它會從 rule 上下文自動填入參數。預設映射使用 ResourceId、ResourceValue、BucketName 等參數名稱（依資源類型而異）。你在補救設定中配置映射關係：「document 的 BucketName 參數應綁定到 Config 偵測到的 S3 bucket 不合規 ResourceValue」。

結合 Config + EventBridge + SSM：持續合規管線

Config 直接呼叫 SSM 補救只能處理簡單的情況。對於複雜的合規管線，通常需要在中間插入 EventBridge，以實現額外的路由、轉換與廣播。

經典三階段管線

1. 偵測：AWS Config 評估 rule，並向 EventBridge 發出 Config Rules Compliance Change 事件，其中 complianceType: NON_COMPLIANT。
2. 路由：EventBridge rule 比對事件 pattern（例如特定 rule 名稱、帳號、region、嚴重性），並路由到一個或多個 target：
   • SNS topic 用於通知人員。
   • Lambda function 用於過濾或豐富事件。
   • SSM Automation 執行用於修復資源。
   • Step Functions 狀態機用於多步驟編排。
3. 補救：SSM Automation document 執行修復，並將完成事件回送到 EventBridge 供審計使用。

這比 Config 內建補救更靈活，因為 EventBridge rule 可以讓你：

• 根據 rule 名稱或資源類型路由到不同 target（例如低嚴重性 rule 送到 Slack 頻道；高嚴重性 rule 觸發自動 SSM 補救）。
• 套用輸入轉換，將 Config 事件映射到 SSM document 的參數格式。
• 同時廣播到資安工單系統以及補救管線。
• 結合跨帳號 event bus，將合規處理集中到資安帳號。

CloudTrail 在管線中的角色

CloudTrail 不直接觸發補救——Config 才是。但 CloudTrail 提供了誰改了資源以及何時改的審計軌跡，這正是補救執行後待命工程師需要查閱的資訊。一個完整的管線通常會搭配 Config（持續記錄設定）加 CloudTrail（API 審計），使「bucket 被設為公開、被補救修正，而 CloudTrail 日誌顯示使用者 dev-jane 在 14:32 執行了該變更」成為一條可查詢的時間軸。

範例：多帳號 org 的持續合規架構

針對管理整個 AWS Organization 的資安團隊的架構：

1. Config aggregator 在資安帳號中，收集每個成員帳號的合規狀態。
2. Conformance pack 透過 Organizations 部署，對所有帳號套用相同的 25 條 rule。
3. 每個成員帳號中的 EventBridge rule 監聽 Config Rules Compliance Change → 跨帳號傳送到資安帳號的中央 event bus。
4. 資安帳號的 EventBridge rule 依嚴重性路由：
   • 高嚴重性（公開 S3、缺少加密）→ SSM Automation 跨帳號補救 document，assume 進入來源帳號的 role。
   • 中嚴重性（缺少 tag）→ Slack 頻道（透過 SNS to webhook Lambda）。
   • 低嚴重性（資訊性）→ CloudWatch Logs 存檔。
5. 審計 dashboard 建立在 Config aggregator + CloudWatch metric streams + 對 CloudTrail 的 Athena 查詢上。

自動化 EBS 快照：DLM vs EventBridge → Lambda vs 舊版 CloudWatch Events

EBS 快照排程是這個主題的熱門場景，因為有幾種有效的模式，而考試會測試你對運維取捨的判斷。

Amazon Data Lifecycle Manager（DLM）— SOA 首選答案

DLM 是專為排程 EBS 快照和 AMI 建立而設計的服務。你定義一個policy（依 tag 定位、排程、保留規則、跨 region 複製、fast snapshot restore），DLM 處理其餘的事。不需要 Lambda 程式碼、不需要複雜的 IAM 設定（只需 DLM service role）、也不會因為 cron-on-EC2 的主機被替換而漏跑。

適合使用 DLM 的情境：

• 工作就是「按排程對已標記的磁碟建立快照並保留」。
• 保留策略以數量或時效計算（保留最新的 7 份日快照、4 份週快照、12 份月快照）。
• 你需要跨 region 或跨帳號複製快照。
• 你需要按 AZ 啟用 fast snapshot restore。

EventBridge scheduled rule → SSM Automation AWS-CreateSnapshot

當快照需要作為更大編排 runbook 的一部分時使用這個模式——例如「停止應用程式 → 快照 EBS → 執行資料庫備份 → 重啟應用程式」。Automation document 串聯各步驟；EventBridge rule 觸發整條鏈。

EventBridge scheduled rule → Lambda → EC2 snapshot API

當 DLM 無法滿足需求（自訂保留邏輯、複雜的 tag 驅動命名、與 CMDB 整合），且 SSM Automation document 對所需邏輯來說太過僵化時，使用此模式。

為什麼不要用 cron-on-EC2

EC2 instance 裡的 cron job 在該 instance 被修補、終止、被 Auto Scaling 替換或跨 AZ 搬移的那一刻就會失效。還有沒有審計軌跡、沒有 IAM 有界執行、沒有重試、沒有機群層級的可見性等問題。SOA-C02 在每一個排程任務場景中都拒絕 cron-on-EC2。

跨帳號排程：EventBridge Scheduler 與跨帳號 Event Buses

生產 AWS 環境幾乎都橫跨多個帳號。排程與補救必須能跨越帳號邊界運作。

EventBridge Scheduler 的跨帳號 target

EventBridge Scheduler 可以透過 assume 跨帳號 role 來呼叫不同帳號的 AWS API。來源帳號的排程執行 role 被授予對目標帳號 role 的 sts:AssumeRole；目標帳號 role 授予實際的 API 權限，並信任來源帳號 role。Scheduler 以 assumed role 的身份呼叫目標 API。

這個模式適用於集中式排程帳號，向多個成員帳號發起快照、審計或清理任務。

跨帳號 EventBridge event buses

自訂 event bus 可以被授予 resource policy，允許其他帳號呼叫 PutEvents。常見架構：每個成員帳號的本地 Config 發出合規變更事件到本地 default bus；default bus 上的 EventBridge rule 將事件轉發到資安帳號的中央 event bus；中央 bus 上的 rule 路由到補救與通知 target。

Maintenance Window 跨帳號

Maintenance Windows 本身是每帳號獨立的，但視窗內的 task 可以 assume role 來呼叫跨帳號 API。對跨帳號的機群修補，運維模式是透過 CloudFormation StackSets 在每個帳號部署一個 Maintenance Window，並設定一致的排程與目標 tag。

運維 Runbook：將手動流程轉換為 SSM Automation Documents

SysOps 團隊的 wiki 手動 runbook（「當訂單處理佇列積壓時如何恢復」）是遷移到 SSM Automation document 的自然輸入。轉換過程大部分是機械式的。

逐步轉換

1. 識別步驟，找出手動 runbook 中的步驟並排序。每個步驟成為 Automation 的一個 mainSteps 項目。
2. 識別 parameters——任何操作者需要手動輸入的內容（instance ID、佇列名稱、閾值）。這些成為 document 的 parameters。
3. 識別檢查點——操作者在繼續前驗證狀態的地方。這些成為 aws:assertAwsResourceProperty 或 aws:waitForAwsResourceProperty action。
4. 識別審核點——操作者等待人工簽核的地方。這些成為 aws:approve action。
5. 識別錯誤路徑——runbook 在步驟失敗時應採取的動作。這些成為 onFailure 子句（Abort、Continue、step:<name>）。
6. 識別 outputs——runbook 最後回報的結果（快照 ID、工單編號）。這些成為 document 的 outputs。
7. 在非生產環境測試，使用較小的參數集，確認後再上到生產。

為什麼要轉換

• 審計：每次執行都記錄在 CloudTrail 和 SSM Automation 歷史記錄中。手動執行 runbook 只留下 Slack 頻道的證據。
• 可重複性：document 每次以完全相同的方式執行；人在壓力下會跳過步驟。
• IAM 有界：assumed role 強制執行最小權限；手動操作者可能有更寬的憑證。
• 可排程：document 可以被 EventBridge、Maintenance Windows 或 Config 補救呼叫。
• 可組合：document 可以呼叫其他 document，形成一套「積木式」runbook 函式庫。

場景模式：偵測到 S3 Bucket 公開存取——自動封鎖管線

一個結合 Config、EventBridge 與 SSM 的典型 SOA-C02 場景。完整流程：

1. 偵測層：在帳號中啟用 AWS Config；開啟受管 rule s3-bucket-public-read-prohibited（configuration-change 觸發）。同時開啟 s3-bucket-public-write-prohibited 以涵蓋寫入側。
2. 路由層：選擇 (a) Config 內建補救直接呼叫 SSM，或 (b) EventBridge rule 監聽 Config Rules Compliance Change 事件。當你同時需要透過 SNS 通知資安團隊、並行透過 Lambda 建立 Jira 工單時，選 (b)。
3. 補救層：SSM Automation document——本案例使用自訂 document 或 AWS-DisablePublicAccessBlockS3（取決於你要翻轉 bucket 層級的 public access block 或移除公開 ACL / bucket policy 條目）。Parameters：BucketName 來自 Config 資源 ID；若加固加密也是同步驟的一部分，則加入 KmsKeyId。
4. IAM 層：Remediation role 信任 ssm.amazonaws.com，具備 s3:PutBucketPublicAccessBlock、s3:GetBucketPublicAccessBlock、s3:PutBucketPolicy，以及 document 的 aws:executeScript 步驟用於記錄變更內容的審計日誌權限。
5. 審計層：CloudTrail 記錄原始 API 呼叫（含 IAM 身份，顯示誰將 bucket 設為公開）以及補救 API 呼叫（含 SSM remediation role 的身份）。EventBridge rule 監聽 RemediationExecution 事件，並將記錄寫入用於 SOX/PCI 合規佐證的資安 S3 bucket。
6. 重新評估：補救完成後，Config 重新評估 rule。若轉回 COMPLIANT，管線記錄成功。若仍是 NON_COMPLIANT（例如 policy 被外部工具重新加入），重試機制啟動或升級呼叫值班人員。

整條管線是宣告式的，存在於 CloudFormation 範本中，並透過 StackSets 部署到每個帳號。

場景模式：超過 30 天的 EBS 快照——每週日 02:00 清理

另一個典型的 SOA-C02 場景，這次是純排程任務。完整流程：

1. Schedule：EventBridge scheduled rule，cron(0 2 ? * SUN *)——每週日 UTC 02:00。
2. Target：SSM Automation document，自訂——MyOrg-DeleteOldSnapshots。Parameters：MaxAgeDays=30、TagFilter=Environment=Production、DryRun=false。
3. Document 邏輯：aws:executeScript Python 步驟，呼叫 ec2:DescribeSnapshots 加 tag filter，從 StartTime 計算年齡，對超過 MaxAgeDays 的每個快照呼叫 ec2:DeleteSnapshot，並將 ID 記錄到 S3 審計日誌。
4. Role：Automation assume role，具備 ec2:DescribeSnapshots、ec2:DeleteSnapshot、審計 bucket 的 s3:PutObject，以及若適用則有 kms:Decrypt 用於 tag 加密元資料。
5. Notification：document 最後一個步驟向 SNS topic 發布摘要——「已刪除 47 個快照，總大小 1.2 TB，完整清單在 s3://audit-bucket/2026/04/26/snapshots.json」。
6. Maintenance Window 替代方案：若此任務是更廣泛的週日夜間批次作業的一部分，可改用 Maintenance Window 包覆；否則 EventBridge scheduled rule + Automation 更為簡潔。

此模式明確排除：在「公用 EC2 instance」上的 cron job（脆弱）、不帶審計軌跡重新實作快照年齡計算的 Lambda（可追溯性低），以及每季手動清理（緩慢且容易出錯）。

常見陷阱：Config Auto-Remediation 靜默失敗模式

Config auto-remediation 有幾種靜默失敗模式，這些都在 SOA-C02 中出現。診斷清單：

1. 模式是 manual 而非 automatic — rule 觸發、補救出現在主控台，但在人工點擊「Remediate」之前什麼都不會發生。修正：將補救設定的模式切換為 automatic。
2. Remediation role trust policy 缺少 ssm.amazonaws.com — SSM 無法 assume 該 role。修正：在 trust policy 的 principal block 中加入 Service: ssm.amazonaws.com。
3. Remediation role 缺少 API 權限 — role assume 成功但 document 在特定步驟失敗。修正：讀取 SSM Automation 執行的失敗原因並加入缺少的權限。
4. Document parameter 映射錯誤 — Config 傳入 ResourceId 但 document 預期 BucketName。修正：在補救設定中調整參數映射。
5. 重試耗盡 — document 失敗 N 次後 Config 放棄。修正：調查失敗原因，調整重試設定（最多 25 次，間隔 60–2700 秒），或修復根本問題。
6. 資源類型不被 document 支援 — document 只處理 Config rule 評估資源的子集。修正：拆分成多條 rule 或撰寫能處理所有類型的自訂 document。
7. Region 不符 — Config rule 在 us-east-1，但 document 在 us-west-2 註冊。Document 是 regional 的。修正：在與 rule 相同的 region 中註冊 document。

常見陷阱：EventBridge Cron 欄位數與 Day-of-Week / Day-of-Month 萬用字元

EventBridge cron 語法至少會讓每位考生踩到一次：

• 6 個欄位，不是 5 個：cron(0 2 * * SUN) 無效；cron(0 2 ? * SUN *) 才正確。
• ? 是必填的：day-of-month 或 day-of-week 至少一個必須是 ?。兩個都是 * 是語法錯誤。
• 一律 UTC：cron(0 9 ? * MON-FRI *) 在 UTC 09:00 觸發，不是台北時間 09:00。如需時區，使用 EventBridge Scheduler 搭配 TimeZone: Asia/Taipei。
• Day-of-week 編號：1=SUN 到 7=SAT。部分 Unix 方言用 0=SUN；不要假設。
• 名稱必須大寫：MON，不是 Mon 或 mon。

常見陷阱：Auto Scaling Scheduled Actions vs EventBridge Scheduled Rules

Auto Scaling 有自己的原生 scheduled action API——aws autoscaling put-scheduled-update-group-action——與 EventBridge 排程分開。Scheduled actions 由 Auto Scaling 服務本身評估，可以在指定時間調整 min、max 和 desired 容量。

選用哪個：

• Auto Scaling scheduled action — 純粹按排程調整容量（每個工作日 08:00 擴展到 50 個 instance，每個工作日 20:00 縮回 10 個）。原生、不依賴 EventBridge、更簡單。
• EventBridge scheduled rule — 任何非容量調整的情境，或是排程需要同時觸發多個動作（調整容量加上通知加上儀表板刷新）。

兩者都接受 cron 表達式。SOA-C02 有時問「按排程擴展 Auto Scaling group 以因應流量高峰」——當目標純粹是容量時，AWS 推薦的答案是原生的 Auto Scaling scheduled action。

常見陷阱：Periodic Rule 頻率 vs 即時合規預期

一個團隊設定了 24 小時頻率的 periodic Config rule，並假設「合規每天檢查一次，這樣就夠了」。當開發者在 09:00 建立不合規資源時，rule 不會標記它，直到下一次 periodic 執行——可能是 23 小時後。修正方式是切換為 configuration-change 觸發（若 rule 類型支援），或同時加設一條 configuration-change rule 用於快速偵測，再保留 periodic 進行定期重新驗證。

SOA-C02 vs SAA-C03：接線 vs 選服務

SAA-C03 和 SOA-C02 都提到 Config、EventBridge 和 SSM，但視角不同。

SAA 考生選服務；SOA 考生寫 cron 表達式、設定 trust policy，並診斷為什麼鏈條在凌晨 02:00 停住了。

考試訊號：如何辨識 Domain 3.2 排程任務或 Config 自動化題型

SOA-C02 的 Domain 3.2 題目遵循可預測的模式。認出它們，你在每道題上的作答時間就會大幅縮短。

• 「轉換這個 cron 表達式」 — 答案幾乎一定涉及 6 欄位的 EventBridge 語法加上 ? 萬用字元。留意 5 欄位干擾項。
• 「在未來排程一次性任務」 — 答案是 EventBridge Scheduler 搭配 at(...)。EventBridge scheduled rules 不支援乾淨的一次性未來呼叫。
• 「需要時區感知排程」 — 答案是 EventBridge Scheduler 搭配 TimeZone 設定。
• 「排程數百萬個每租戶任務」 — 答案是 EventBridge Scheduler 搭配 schedule groups。
• 「Auto-remediation 沒有執行」 — 答案幾乎一定涉及 remediation IAM role 的 trust policy（ssm.amazonaws.com）或補救模式（manual vs automatic）。
• 「立即偵測不合規」 — 答案是 configuration-change Config rule，不是 periodic。
• 「每天審計所有範圍內的資源」 — 答案是 periodic Config rule 搭配 24 小時頻率。
• 「每週日 02:00 以受控方式修補生產機群」 — 答案是 Maintenance Window 搭配 AWS-RunPatchBaseline、concurrency 和 max errors。
• 「每週對已標記的 EBS 磁碟快照並保留」 — 答案是 DLM，不是自訂 Lambda。
• 「跨組織集中管理合規」 — 答案是透過 Organizations 部署的 conformance pack 加上中央 Config aggregator。
• 「將手動 runbook 轉換為自動化」 — 答案是 SSM Automation document，含 parameters、有序步驟和 assumed role。
• 「在下班後對機群執行指令」 — 答案是 Maintenance Window 搭配 Run Command task，不是 cron-on-EC2。

決策矩陣 — 選擇正確的自動化構件

考試時用這張表快速查找。

常見陷阱總整理 — 排程任務、Config Auto-Remediation 與流程自動化

每次 SOA-C02 考試都會遇到其中的兩到三個干擾項。

陷阱 1：在 EventBridge 中使用 5 欄位 Unix cron

EventBridge cron 有 6 個欄位。cron(0 2 * * SUN) 無效；cron(0 2 ? * SUN *) 才正確。

陷阱 2：day-of-month 和 day-of-week 都設為 *

必須有一個是 ?。EventBridge 在驗證時強制執行此規則。

陷阱 3：Cron 以本地時間評估

EventBridge scheduled rules 一律以 UTC 評估 cron。若需其他時區，使用 EventBridge Scheduler 搭配 TimeZone。

陷阱 4：EventBridge Scheduler 一個排程多個 target

Scheduler 是每個排程一個 target。在同一個 group 裡建立更多排程以對應多個 target。

陷阱 5：Config 補救設在 manual 模式，卻預期自動執行

Rule 觸發、補救佇列填滿，但在人工點擊之前什麼都不會發生。切換到 automatic 模式。

陷阱 6：Remediation role trust policy 缺少 ssm.amazonaws.com

Role 存在、權限正確，但 SSM 無法 assume 它。修正 trust policy。

陷阱 7：使用 Periodic Config rule 進行快速偵測

Periodic rules 每 1、3、6、12 或 24 小時才執行一次。需要即時偵測請使用 configuration-change 觸發。

陷阱 8：用 cron-on-EC2 執行排程工作

脆弱、不透明，考試也不會選它。改用 EventBridge schedule + SSM/Lambda/Step Functions。

陷阱 9：忽略 DLM 改用自訂 Lambda 處理快照

DLM 是 EBS 和 AMI 快照搭配 tag-based 定位和保留的 SOA 首選答案。

陷阱 10：Auto Scaling scheduled action vs EventBridge schedule

純容量調整時，原生的 Auto Scaling scheduled action 比 EventBridge 更簡單。

陷阱 11：Maintenance Window task 未設定 max-errors

對 1,000 個 instance 執行修補 task 而沒有 max-errors 限制，一個有問題的修補包就能毀掉整個機群。設定 max errors = 5% 或類似值。

陷阱 12：Periodic rule 的頻率設定錯誤

頻率選項只有 1、3、6、12 或 24 小時。沒有「每 30 分鐘」的 periodic 選項——若需要此頻率，使用 configuration-change 觸發或另設一個排程 Lambda。

FAQ — 排程任務、Config Auto-Remediation 與流程自動化

Q1：什麼時候選 EventBridge Scheduler，而不是 EventBridge scheduled rule？

選 EventBridge Scheduler 的條件：(a) 需要 at(...) 的一次性未來呼叫、(b) 需要時區感知、(c) 有數十萬或數百萬個排程（SaaS 每租戶）、(d) 需要 flexible time windows 加入 jitter、(e) 想用 270+ 種 AWS API target 而不寫 Lambda。選 EventBridge scheduled rules 的條件：排程數量不到幾百個、需要每條 rule 多個 target（最多 5 個）、已在自訂 event bus 上組織 rule，或從 CloudWatch Events 遷移並使用相同語法。簡單判斷規則：Scheduler 是新專案的現代預設；scheduled rules 是已在 EventBridge bus 上的小型環境的舊版相容選擇。

Q2：EventBridge cron 表達式與 Unix cron 有何不同？

三個結構性差異。第一，EventBridge cron 有六個欄位——minutes、hours、day-of-month、month、day-of-week、year。Unix cron 只有五個，沒有 year 欄位。第二，EventBridge 要求在 day-of-month 或 day-of-week 之一使用 ? 萬用字元（不能兩個都是 *）；標準 Unix cron 沒有 ?。第三，EventBridge cron 對 scheduled rules 一律以 UTC 評估（Scheduler 支援 TimeZone）；Unix cron 使用主機的本地時間。Day-of-week 編號也不同（EventBridge：1=SUN 到 7=SAT）。最常見的轉換錯誤是直接貼上 Linux cron——務必改寫為帶有 ? 且明確以 UTC 推算的 6 欄位格式。

Q3：為什麼我的 Config auto-remediation 沒有執行？如何診斷？

診斷路徑是循序的。步驟 1：確認 rule 有在觸發——查看 Config rules dashboard，尋找 NON_COMPLIANT 資源。步驟 2：確認補救設定是automatic 模式，不是 manual。步驟 3：檢查 remediation IAM role 的 trust policy——必須允許 ssm.amazonaws.com assume 它。步驟 4：開啟 SSM Automation 執行歷史記錄，找到失敗的執行，鑽入失敗的步驟，閱讀 AccessDenied 或 parameter 不符的原因。步驟 5：確認補救設定中的 parameter 映射——Config 偵測到的 ResourceId 是否映射到 document 預期的參數名稱？步驟 6：確認 document 在與 Config rule 相同的 region 中註冊。約 80% 的實際失敗在步驟 3（trust policy）或步驟 4（document 深處缺少 API 權限）時診斷出來。

Q4：如何選擇 configuration-change Config rule 和 periodic Config rule？

使用 configuration-change 的條件：(a) rule 評估的資源屬性在變更時可見（加密旗標、公開 ACL、tag 存在），且 (b) 你希望立即偵測（幾分鐘內）。使用 periodic 的條件：(a) rule 需要跨多個資源聚合或檢查全局狀態（例如「此帳號至少啟用一條 CloudTrail trail」），(b) 檢查成本較高且你希望限制執行頻率，或 (c) 你想捕捉不會產生 configuration-change 事件的緩慢漂移。許多 AWS 受管 rule 同時支援兩種觸發——依使用案例選對的，或兩者並用以實現快速偵測加每日完整性驗證。

Q5：Maintenance Window 的 priority 和 concurrency 如何運作？

Maintenance Window 有一份已登記的 task 列表，每個 task 都有 priority（數字越小優先級越高）以及 max concurrency 和 max errors 設定。視窗開啟時，task 依 priority 分組——相同 priority 的 task 並行執行，priority 數字較小的 task 先於較大的執行。在單一 task 內，max concurrency 限制同時處理多少 target（10 個 instance 或機群的 25%）。Max errors 是失敗閾值——超過此限制的 target 數量失敗後，task 停止。範例：priority 1 task 以 10% concurrency、max errors 5% 修補 500 個 instance；priority 2 task 建立快照；priority 3 task 輪替日誌。視窗在 02:00 開啟，運行 4 小時，截止時間為 1 小時（最後 1 小時不啟動新 task）；priority 1 在 03:00 前完成，然後 priority 2 和 3 並行執行。

Q6：EventBridge Scheduler 如何超越 EventBridge scheduled rules 進行擴展？

EventBridge scheduled rules 在每個 Region 有 rule 數量配額，且不是為每租戶 SaaS 模式設計的。EventBridge Scheduler 是專門為擴展到每帳號數百萬個排程而設計的，使用 schedule groups（組織容器，預設每帳號 500 個，可提高）。每個排程有自己的 rate 或 cron、時區、target 和重試設定。可透過 CreateSchedule 和 DeleteSchedule API 以高頻率程式化建立和刪除排程，不用擔心限流。對於 SOA-C02 題目「我們 SaaS 的每個客戶在他們的本地 09:00 收到各自的日報」，答案是 EventBridge Scheduler，在 customer-reports schedule group 中為每個客戶建一個排程，各自設定客戶所在時區的 TimeZone。

Q7：Config 內建補救與 EventBridge → SSM 管線有何差別？

Config 內建補救將 SSM Automation document 直接綁定到 Config rule。當 rule 觸發 NON_COMPLIANT 時，Config 自動呼叫 document（或排入手動審核佇列）。較簡單、靈活性較低——一條 rule、一份 document、一個 parameter 映射。EventBridge → SSM 管線將 Config Rules Compliance Change 事件透過 EventBridge rule 路由，然後可以廣播到多個 target（SNS 通知、Lambda 豐富事件、SSM 補救、Step Functions 多步驟編排）。更靈活、更多活動元件。「rule 觸發 → 修復它」的簡單情況用內建補救；需要平行通知加補救、依嚴重性路由或跨帳號補救時用 EventBridge → SSM。

Q8：如何跨多個 AWS 帳號排程任務？

三個模式。模式 A — EventBridge Scheduler 搭配跨帳號 role：中央排程帳號建立排程，其執行 role assume 目標帳號中擁有實際 API 權限的 role。集中化，但每個目標帳號必須信任排程帳號。模式 B — StackSets 部署的排程：透過 CloudFormation StackSets 將相同的 EventBridge scheduled rule（或 Scheduler 排程）部署到每個帳號。分散執行但集中管理設定。模式 C — 跨帳號 EventBridge event bus：將排程事件發送到中央 bus，路由到正確帳號的 bus，在本地執行。模式 A 最適合臨時跨帳號任務；模式 B 是每個帳號應擁有自己執行審計軌跡時的正確答案；模式 C 是排程只是更大事件驅動架構的一部分時的正確答案。

Q9：何時選 DLM，何時選 EventBridge → Lambda 進行 EBS 快照？

只要符合以下模型，使用 DLM：tag-based 定位、時間排程、數量或時效保留、選用跨 region 複製、選用 fast snapshot restore。DLM 是 SOA 首選答案，因為不需要自訂程式碼、有專用的 service role、支援跨帳號複製，且可在 DLM 主控台審計。當快照邏輯不符合 DLM 時，使用 EventBridge → Lambda——例如「只有當自訂 tag 值符合 CMDB 查詢時才快照該磁碟」、「以應用程式版本的雜湊值命名快照」或「當 Maintenance Window 啟動時跳過快照」。當快照是更大編排 runbook 中的一個步驟時，使用 EventBridge → SSM Automation（停止應用程式 → 快照 → 執行資料庫匯出 → 重啟應用程式）。永遠不要在 EC2 instance 裡寫 cron job 取快照——那個 instance 一被替換就完了。

Q10：什麼是 conformance pack？它與個別 Config rule 有何不同？

Conformance pack 是一個 YAML 或 JSON 範本，將多條 Config rule 和補救動作打包成單一可部署的單元。AWS 發布了對齊合規框架（CIS、NIST 800-53、PCI-DSS、HIPAA、AWS 運維最佳實踐集）的範例 pack。Conformance pack 以原子方式部署——要麼所有 rule 全部部署成功，要麼部署失敗——並支援可依環境自訂的參數。透過 AWS Organizations 整合，一個 conformance pack 可以一次操作部署到所有成員帳號。運維差異：個別部署 25 條 Config rule 需要 25 次 PutConfigRule API 呼叫、各別的 IaC 項目和每條 rule 的生命週期管理；conformance pack 將這 25 條視為一個邏輯單元，擁有單一的生命週期。SOA-C02 每當題目說「跨多帳號一致性合規」或「對整個 org 套用 CIS benchmark」時，都偏好 conformance pack。

Q11：為什麼我的 EventBridge rule 沒有比對到 Config 事件？

診斷清單。第一，確認 rule 在 default event bus 上——Config 事件傳到那裡，而不是自訂 bus（除非你明確轉發）。第二，檢查 event pattern JSON——source 必須是 aws.config，detail-type 必須是 Config Rules Compliance Change，以及任何額外的 filter（detail.configRuleName、detail.newEvaluationResult.complianceType）必須與實際事件格式完全一致。第三，確認 rule 是啟用狀態——停用的 rule 不會比對。第四，在 CloudWatch 中查看 rule 的 invocations metric（AWS/Events、Invocations 和 FailedInvocations）——零次觸發表示沒有比對到；非零失敗觸發表示 target 在拒絕。第五，使用主控台中的 EventBridge sandbox 貼入範例事件並測試 pattern。最常見的原因是 detail-type 中的錯別字（例如 Config Rule Compliance Change 而不是 Config Rules Compliance Change）。

Q12：SSM Automation document 如何處理審核步驟？

aws:approve action 暫停 document 並向設定的 SNS topic 發送通知。審核者收到通知後，使用 aws ssm send-automation-signal --signal-type Approve --automation-execution-id <id>（或主控台的「Approve」按鈕）繼續 document 執行。此 action 的參數包含 SNS topic ARN、審核者 IAM principal 清單（只有這些身份可以審核）、所需的最低審核數（預設 1），以及選用的訊息。對於具破壞性的補救動作——卸載 EBS 磁碟、終止 instance、刪除快照——請使用審核步驟，因為自動執行帶來的風險無法接受。審核步驟也是一個有用的審計檢查點，因為每次審核決定都會在 CloudTrail 中記錄審核者的身份。

進一步閱讀與相關運維模式

• What is Amazon EventBridge — User Guide
• Creating an EventBridge Rule that Runs on a Schedule
• What is EventBridge Scheduler
• EventBridge Scheduler Schedule Types
• EventBridge Rate Expressions
• EventBridge Cron Expressions
• EventBridge Targets Reference
• What is AWS Config
• Evaluating Resources with AWS Config Rules
• Remediating Noncompliant Resources
• AWS Config Conformance Packs
• List of AWS Config Managed Rules
• Systems Manager Maintenance Windows
• Assigning Tasks to a Maintenance Window
• Systems Manager Automation
• Systems Manager Automation Documents
• AWS SOA-C02 Exam Guide v2.3 (PDF)

排程與 Config 自動化就緒後，接下來的運維層次是：Systems Manager Automation and Patch Manager——提供每個補救步驟背後的 runbook 深度；EventBridge Rules、SNS 與自動補救——處理同一自動化架構的 alarm 驅動面；CloudFormation Stacks and StackSets——將排程、Config rule、conformance pack 和 Maintenance Window 以 IaC 方式跨帳號部署；CloudTrail and AWS Config for Audit and Compliance——提供驗證每次自動化變更的審計訊號。

• Systems Manager：Automation、Patch Manager 與 Session Manager — SOA-C02 學習筆記
• EventBridge Rules、SNS 與自動補救 — SOA-C02 學習筆記
• CloudFormation Stacks、StackSets 與疑難排解 — SOA-C02 學習筆記
• CloudTrail 與 AWS Config 的審計與合規 — SOA-C02 學習筆記