EventBridge Rules、SNS 與自動化補救

Amazon EventBridge 與 Amazon Simple Notification Service（SNS）是 AWS 上將被動觀察轉化為主動運維的兩大核心服務。SOA-C02 Task Statement 1.2——「根據監控與可用性 metrics 執行補救行動」——幾乎完全圍繞著一條鏈路：從 CloudWatch alarm 或 AWS Config rule 出發，經過 EventBridge rules 與 SNS topics，進入 Systems Manager Automation runbooks、Lambda functions 或 SQS queues 執行矯正動作。SAA-C03 考的是「如何設計一個事件驅動架構」，SOA-C02 考的則是「如何正確接線、在事件未能送達 target 時如何排查，以及如何調整 retry、dead-letter 與 filtering 行為，讓值班人員收到訊號卻不被噪音淹沒」。

本指南從運維 SysOps 的角度帶你走過 EventBridge 與 SNS 的全貌：event buses 如何路由 AWS 服務事件、event patterns 與 JSON path 比對的差異、為何 scheduled rules 正逐漸被 EventBridge Scheduler 取代、四種完全繞過 SNS 的 CloudWatch alarm actions、SNS fan-out 模式與 message filtering policies、HTTP/S 與 AWS 原生傳遞之間不同的 retry 語意，以及 SOA-C02 Domain 1 每四題就會考一次的標準三服務補救鏈——Config rule、EventBridge rule、SSM Automation document。你也會看到反覆出現的場景：跨 region 與跨帳號的事件轉發、SNS message filter policies 針對 MessageAttributes 與 message body 的差異、EventBridge rule dead-letter queues，以及在需要 retry 與解耦時 EventBridge 與 alarm 直接觸發 Lambda 的運維取捨。

為什麼 EventBridge 與 SNS 是 SOA-C02 補救行動的骨幹

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 1.2 下列出三項技能：根據通知和 alarms 排查或採取矯正行動、設定 Amazon EventBridge rules 以觸發動作，以及使用 AWS Systems Manager Automation runbooks 根據 AWS Config rules 採取行動。EventBridge 與 SNS 貫穿每一項技能。Topic 1 的 CloudWatch alarm 觸發後，其 action 指向一個 SNS topic 或 EventBridge rule；CloudTrail 與 Config topic 中的 Config rule 偵測到不合規，不合規事件會落在預設的 EventBridge bus 上；Domain 3 的 Systems Manager Automation document 執行矯正步驟，而它是由 EventBridge rule 觸發，而非由 alarm 直接觸發。

在 SysOps 層級，問題的框架是運維，而非架構設計。SAA-C03 問：「設計一個訂單處理 pipeline 的事件驅動架構。」SOA-C02 問：「EventBridge rule 已設定，但 SSM Automation runbook 從未執行——缺了什麼？」答案集很小也很可預測：rule 的 IAM role 缺少呼叫 target 的權限、event pattern 因一個引號錯字而無法比對、target 在另一個 region 或帳號但缺少跨 region/跨帳號的配置、rule input transformer 格式錯誤，或 rule 掛在 default bus 而來源事件卻落在 custom bus 上。EventBridge 與 SNS 是所有監控與補救流程的插槽：CloudWatch alarms 透過它路由（Domain 1）、Auto Scaling lifecycle hooks 向它發布事件（Domain 2）、CloudFormation stack 事件在此浮現（Domain 3）、GuardDuty findings 落在這裡（Domain 4）、Health Dashboard 事件流經它（Domain 1），而 Config 驅動的自動補救也依賴它（Domain 3）。

白話文解釋 EventBridge and SNS

EventBridge 與 SNS 的術語交疊在三個層次——事件、路由、傳遞。三個類比有助於理解。

類比一：捷運站的智慧分流系統

EventBridge 是你 AWS 帳號的捷運路網調度中心。每項 AWS 服務都把乘客（事件）送上default event bus，也就是所在 region 的主要大站。Event patterns 是調度員套用的班車比對規則：「如果這班車標示 EC2 且狀態是 stopped，導向運維月台。」Custom event buses 是專用月台——你的訂單系統有自己的月台，不與 AWS 服務事件的班車混流。Partner buses 是外部鐵路接駁站，Auth0、Datadog 等 SaaS 夥伴的班車停靠在這裡，與系統內部路線分開管理。

SNS 是終點站出口的廣播員。調度中心把一則訊息交給 SNS，SNS 為訂閱名單上的每個人複製一份——五封 email、兩個呼叫器、一個 Slack webhook 和一個 Lambda function。Message filter policies 是每位訂閱者自訂的偏好設定：「我只接收自己管轄路段的通知，不要全線通知。」Dead-letter queues 是無法送達的掛號信箱——當某個 SNS HTTP 訂閱者長時間離線，訊息就放進一個獨立的 SQS queue，讓站務長（SysOps 工程師）事後調查。

對 SOA-C02 考生而言，重點是：EventBridge 把一個事件路由到少數幾個明確指定的 targets；SNS 把一則訊息 fan-out 給一份訂閱者清單，每位訂閱者有自己的過濾條件與傳遞管道。兩者組合使用：EventBridge rule 的 target 通常是一個 SNS topic，這樣同一個事件就能同時 fan-out 給人工訂閱者和 Lambda。

類比二：消防感應器接線到多種響應

CloudWatch alarm 是大樓裡的火警感應器。觸發後，它有四種動作接線到控制面板：一個 SNS topic 鳴響樓層警報讓所有人聽到、一個 EC2 action 自動關閉防火閘（reboot、stop、terminate、recover）、一個 Auto Scaling action 調度更多消防員（scale-out），以及一個 Systems Manager OpsCenter action 開立維修工單。SNS 是警報聲和人工通知管道；EC2 與 Auto Scaling actions 是直接接線在面板上的機械響應，完全繞過 SNS。EventBridge 是大樓的中央警報盤，能把感應器接上更豐富的響應——呼叫消防局（SSM Automation runbook）、排定後續複查（Step Functions），或關閉某些設備（Lambda）。

對 SOA-C02 而言，運維問題是選哪條路。CloudWatch alarm 直接 action 快速但耦合緊、功能有限。CloudWatch alarm → SNS → email 是最簡單的人工通知。CloudWatch alarm → EventBridge rule → SSM Automation 是有 retry、解耦、轉換與跨帳號 fan-out 的生產級路徑。

類比三：夜市點餐叫號系統

EventBridge 是夜市攤位的叫號系統。每張顧客點單（事件）列印出票號沿軌道滑動。Rules 是各攤的廚師——烤肉攤只接「烤肉類」票號，涼麵攤只接「涼麵類」票號。如果一道餐點需要兩個攤位合作，兩位廚師都能取同一張票（一個事件、多個 targets）。Scheduled rule 是固定備料時程——不管有沒有客人點單，傍晚五點都要從冰箱取出備料。Event bus 是票號系統本身；貴賓包廂有專屬叫號機，不與外場混用。

SNS 是出餐口的取餐廣播員，當一道菜準備好時，廣播通知各組送餐員——第一組送到五號桌、第二組把備份送給主廚平板確認、第三組把時間記錄到 POS 系統。Filter policy 是每位送餐員說「我只送甜點。」Dead-letter queue 是遺失票號的暫放格，放超時沒人領的訂單。Fanout pattern——SNS 到多個 SQS queues——就是同一張票同時出現在備餐站、庫存系統和顧客回饋問卷。

EventBridge Event Buses：Default、Custom 與 Partner

Event bus 是事件的路由通道。每個 AWS 帳號的每個 region 都有剛好一個 default bus，加上你自行建立的 custom bus 與 partner bus。

Default event bus

每項發出事件的 AWS 服務都發布到事件發生帳號與 region 的 default event bus——EC2 instance 狀態變更、S3 物件事件（若在 bucket 上啟用 EventBridge）、CodeBuild 建置狀態、CodePipeline 階段轉換、GuardDuty findings、Health Dashboard 事件、AWS Config 合規變更、CloudWatch alarm 狀態變更、Systems Manager parameter 變更、Auto Scaling lifecycle hooks、ECS task 狀態變更等。SOA-C02 要求你知道：default bus 是 AWS 服務事件的落地點、它是 regional 的，且你無法刪除它。

Custom event buses

Custom event bus 是你明確建立的 bus。你的程式碼透過 PutEvents API 發布的應用程式事件會落在你指定的 custom bus 上，與 default bus 上的 AWS 服務流量隔離。Custom buses 也能實現跨帳號事件傳遞：你透過 resource-based policy 授予另一個帳號發布到你 bus 的權限。SOA-C02 中 custom bus 的場景包括「將 50 個成員帳號的事件匯聚到單一安全事件 bus」以及「建立自訂應用程式事件分類法而不污染 default bus」。

Partner event buses

Partner event bus 接收來自 SaaS 夥伴的事件——Auth0、Datadog、MongoDB Atlas、Zendesk、PagerDuty 等。夥伴從其平台產生事件，你建立一個設定了其 event source ARN 的 partner bus。夥伴事件直接送達此 bus，從不觸碰 default bus。考試對 partner bus 著墨較少，但要認識這個術語。

Archives 與 replay

EventBridge 支援可選擇保留期限的 event archives，用來儲存 bus 上的事件。Replay 讓你把封存的事件重新發送回 bus 用於除錯或復原——例如，將過去一小時的事件重放給一個修正過的 Lambda。SOA-C02 偶爾會考「團隊需要用上週的事件測試一條新 EventBridge rule」——答案是 archive + replay，而非自訂的 log 爬取。

EventBridge Rules：Event Pattern 比對 vs Scheduled Rules

Rule 是一個 EventBridge 資源，監看單一 bus 並將符合條件的事件路由到一個或多個 targets。一條 rule 只有一種觸發來源：event pattern（比對 bus 上的即時事件）或 schedule expression（按固定頻率觸發）。一條 rule 不能同時擁有兩者。

Event pattern 比對

Event pattern 是一份 JSON 文件，表示「比對長得像這樣的事件」。Pattern 逐欄位與事件 payload 比對，支援多種比對運算子：

• 精確值："source": ["aws.ec2"] 在 source 恰好是 aws.ec2 時比對。
• Prefix："region": [{"prefix": "us-"}] 比對 us-east-1、us-west-2 等。
• Suffix：[{"suffix": ".example.com"}] 比對以 .example.com 結尾的 FQDN。
• Anything-but：[{"anything-but": "ap-southeast-1"}] 比對除了該 region 以外的所有 region。
• Numeric：[{"numeric": [">=", 500]}] 比對符合比較條件的數值。
• Exists：[{"exists": true}] 在欄位存在時比對。
• Equals-ignore-case：[{"equals-ignore-case": "WARNING"}] 用於不區分大小寫的比對。
• IP address range：[{"cidr": "10.0.0.0/8"}] 用於來源 IP 過濾。

比對 EC2 instance 狀態變更的典型 pattern 如下：

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped", "terminated"]
  }
}

Pattern 是階層式的，各欄位之間是 AND 關係；同一欄位內的陣列值是 OR 關係。頂層欄位之間不存在巢狀 OR——這是「rule 不觸發」排查問題的常見原因。

Scheduled rules

Scheduled rule 使用 schedule expression 取代 event pattern。有兩種語法：

• rate(value unit) — rate(5 minutes)、rate(1 hour)、rate(7 days)。簡單的週期性間隔。
• cron(minutes hours day-of-month month day-of-week year) — 六個欄位，day-of-month 或 day-of-week 其中之一允許填 ?，但不能兩者都填。

SOA-C02 的經典 cron 表達式是 cron(0 18 ? * MON-FRI *) — 每個工作日 UTC 18:00，day-of-month 填 ? 因為已指定 day-of-week。考生常因寫成 cron(0 18 * * MON-FRI *) （五欄位 POSIX cron）而被 EventBridge 拒絕而失分。

SOA-C02 因 cron 語法而失分的情況出人意料地多。EventBridge cron 有六個欄位（minutes hours day-of-month month day-of-week year），而非 POSIX 的五個。day-of-month 和 day-of-week 中恰好一個必須是 ?；兩個都填 * 會被拒絕。Scheduled rules 也只以 UTC 評估——不支援時區設定。若場景需要在 Asia/Taipei 時間早上九點觸發任務，你必須自行計算 UTC 偏移（並在非亞洲 region 的 DST 變更時記得更新），或改用 EventBridge Scheduler，它有原生時區支援。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html ::

EventBridge Scheduler vs scheduled rules

Amazon EventBridge Scheduler 是 2022 年推出的獨立新排程服務。它取代了新工作負載的 scheduled rules，並提供：

• 更高配額 — 每帳號數百萬個 schedules，遠超 per-bus 的 rule 上限。
• 單次排程 — 在指定時間戳只觸發一次。
• 時區支援 — cron(0 9 * * ? *) 以 Asia/Taipei 而非 UTC 評估。
• 彈性時間視窗 — 在 15 分鐘視窗內的任意時間觸發，用於負載平滑。
• 內建 retry、DLQ 與 target 加密。

SOA-C02 兩者都會考。Default bus 上的 scheduled rule 是較舊、較簡單的選項，適合 AWS 服務事件式的排程。EventBridge Scheduler 是「數千個每位顧客的排程」、「單次延遲動作」或任何時區敏感 cron 的答案。

Rule input transformers

Rule 可以在將事件送到 target 之前進行轉換。Input transformer 使用 input paths 從事件中萃取欄位，以及一個 template 將其插值成新的 payload。當 SSM Automation document 期望一個與 EC2 狀態變更事件格式不符的特定參數結構時，這個功能就很關鍵。

常見 EventBridge Targets

一條 rule 最多可有 5 個 targets。SOA-C02 範疇內最常見的 targets：

• AWS Lambda function — 同步調用；事件作為 function 的輸入傳入。Lambda 錯誤的 retry 由 rule 管理，而非由 Lambda 管理。
• Amazon SNS topic — fan-out 給多個訂閱者（人工、Lambda、SQS）。
• Amazon SQS queue — 為下游消費者提供持久緩衝；standard 或 FIFO。
• AWS Systems Manager Automation document（runbook） — 多步驟補救；rule 需要一個具有 ssm:StartAutomationExecution 權限的 IAM role。
• AWS Step Functions state machine — 編排長時間執行的多步驟工作流程。
• Amazon ECS task — 按需啟動一次性任務。
• EC2 actions — RebootInstances、StopInstances、TerminateInstances。注意這些是 EventBridge 的內建 actions，不同於 CloudWatch alarm 的 EC2 actions。
• Amazon Kinesis Data Stream / Firehose — 串流 pipeline 的資料攝入。
• API destination — 使用已儲存驗證資訊向第三方 API 發出 HTTPS 呼叫。
• 跨帳號/跨 region event bus — 將事件轉發到另一個帳號或 region 的 bus。

IAM permissions

EventBridge 需要權限才能調用每個 target。對於同帳號的 Lambda、SNS 和 SQS targets，EventBridge 使用 resource-based policies — 將 rule 的 ARN 加為 target 上的授權 principal。對於 SSM Automation、Step Functions、ECS 及大多數其他 targets，rule 有一個明確的 execution IAM role 授予必要的 action。忘記在 SSM Automation target 上設定 IAM role，是 rule「觸發但什麼都沒做」最常見的單一原因。

Rule dead-letter queues

Target 可能失敗——Lambda 被 throttle、SNS topic 被刪除、SSM Automation 參數無效。預設情況下 EventBridge 以指數退避重試 24 小時。耗盡 retry 後，事件會被丟棄，除非你在 rule 上設定了 dead-letter queue（SQS）。SOA-C02 直接考這一點：「事件偶爾無法送達 target 但沒有人知道」——答案是在 rule 上設定 DLQ，加上針對 DLQ 的 ApproximateNumberOfMessagesVisible 設定 CloudWatch alarm。

CloudWatch Alarm Actions：SNS、EC2、Auto Scaling 與 Systems Manager

CloudWatch alarms 有四種內建 action 類別，在狀態轉換（OK、ALARM、INSUFFICIENT_DATA）時觸發。每種各自獨立。

SNS notification action

最常見的 alarm action 是 SNS topic ARN。Alarm 發布一則描述狀態變更的 JSON 訊息到 topic，再由 topic fan-out 給訂閱者。典型模式：

• Critical alarm SNS topic — 訂閱者包括 PagerDuty HTTPS endpoint 和值班 email。
• Warning alarm SNS topic — 訂閱者包括 Slack 頻道 webhook 和團隊 email。
• Info SNS topic — 只有一個用於保留日誌的稽核 Lambda 訂閱。

Alarm action 與 SNS topic 必須在同一個 region（alarms 不能直接發布到跨 region 的 topic）。若需要跨 region 通知，可讓 region A 的 SNS topic 訂閱一個 Lambda 再重新發布到 region B，或將 alarm action 設為 EventBridge rule，再轉發到跨 region 的 bus。

EC2 actions

CloudWatch alarms 可以直接觸發四種 EC2 instance actions，而不需要經過 SNS 或 EventBridge：

• Recover — 用於受損 instance（因 AWS 端硬體問題導致的 status check 失敗）。Instance 保留其 instance ID、私有 IP、Elastic IP 和 metadata。只在特定 instance 類型和純 EBS instance 上可用。
• Stop — 用於帳單 alarm 觸發時停止失控的 dev 或 test instance。
• Terminate — 搭配 autoscaling 用於終止健康檢查失敗的縮放 instance。
• Reboot — 快速補救軟性卡頓。

這四種 actions 作為 alarm actions 存在，是因為它們是常見且對延遲敏感的補救手段，經由 EventBridge → Lambda → EC2 API 會增加不必要的間接層。SOA-C02 考「在 system status check 失敗時自動復原 EC2 instance」——答案是 CloudWatch alarm 的 recover action，而非 EventBridge。

Auto Scaling actions

CloudWatch alarm 可以直接調用 Auto Scaling 的 scaling policy ARN 作為其 action。Target tracking 與 step scaling policies 在內部使用這個機制。大多數正式環境讓 target tracking 自動管理 alarms，而非手動建立。

Systems Manager OpsCenter / Incident Manager actions

較新的 alarm action 類別包括在 Systems Manager OpsCenter 建立 OpsItem，或觸發 Incident Manager 的響應計劃。這些是運維事件管理功能，在部分 SOA-C02 題目中出現。

為何補救行動要用 EventBridge 而非直接 alarm actions

直接 alarm actions（SNS、EC2、Auto Scaling）簡單快速但耦合緊密。對於複雜的補救——多步驟 SSM Automation、條件分支、retry、DLQ、跨帳號 fan-out——SOA-C02 的最佳實踐是同時把 alarm 送到 SNS topic 和 EventBridge rule。SNS topic 通知人工；針對 aws.cloudwatch source 比對 CloudWatch Alarm State Change 的 EventBridge rule 調用 SSM Automation runbook，具備 retry、DLQ 與解耦。

SNS Topic 設定：Subscriptions、Filtering 與 Fan-Out

Amazon SNS 是一個全受管的 pub/sub 服務，用於 fan-out 傳遞。Topic 是發布端點；subscriptions 是傳遞 targets。

Subscription 類型

單一 SNS topic 可以有多種混合類型的訂閱：

• Email — RFC 標準 email；訂閱者必須透過點擊確認連結才能收到訊息。
• Email-JSON — 相同，但包含完整 JSON payload。
• SMS — 簡訊；有速率限制且受 region 限制（某些 region 如 ap-east-1 不支援 SMS）。
• HTTP/S — POST 到 webhook URL；適用於 Slack、PagerDuty、Datadog、ServiceNow。
• AWS Lambda — 以訊息作為輸入調用 function。
• Amazon SQS — 為下游消費者提供持久緩衝；標準 fan-out 模式的典型選擇。
• Application（行動推播） — Apple Push、Firebase Cloud Messaging、Amazon Device Messaging。
• Amazon Data Firehose — 將訊息串流到 S3、OpenSearch、Redshift、Splunk。
• AWS Event Fork Pipelines — 預建的 fan-out，分流到封存（S3 via Firehose）、分析、replay 和 DLQ pipelines。

Standard vs FIFO topics

• Standard topics — 盡力保序、至少一次傳遞、無限吞吐量。幾乎所有 SOA-C02 通知與補救模式的正確預設選擇。
• FIFO topics — 依 message group ID 嚴格排序、恰好一次傳遞，每秒最多 300 個發布請求（批次模式可到 3,000）。FIFO topics 只支援 SQS FIFO 訂閱者——不支援 Lambda、email、HTTP 或 SMS。

考試偏好 standard topics。只有當場景明確提到有序處理或重複訊息去重時才選 FIFO。

Message filter policies

Subscription filter policy 是一份 JSON 文件，限制哪些訊息能送達訂閱者。預設針對訊息的 message attributes（與 body 一起發送的 key-value metadata）評估。可選擇使用 FilterPolicyScope: MessageBody 啟用對 message body 本身的過濾。

典型的 filter policy：

{
  "severity": ["critical", "high"],
  "region": ["us-east-1", "us-west-2"]
}

此訂閱者只接收 severity attribute 為 critical 或 high，且 region attribute 在列舉值內的訊息。Filter policies 支援與 EventBridge patterns 相同的運算子（prefix、anything-but、numeric、exists）。Publisher 在呼叫 Publish 時設定 attributes。

Fan-out pattern

SOA-C02 的標準 fan-out 模式是 一個 SNS topic → 多個 SQS queues，每個 queue 有自己的 filter policy，由不同的微服務或補救 Lambda 消費。這將 publisher 與 N 個消費者解耦，為每個消費者提供持久緩衝，並讓每個消費者套用自己的過濾與處理速率而不影響其他人。

跨帳號 topics

SNS topic policy 可以授予另一個帳號的 principal 發布權限。另一個帳號的訂閱者需要自己的訂閱權限。SOA-C02 考「稽核帳號中的中央安全 topic，由 50 個應用程式帳號的 SQS queues 訂閱」——答案是跨帳號 topic policy 加上每帳號的 subscription filter policies。

SNS Delivery Retries、DLQ 與 HTTP Semantics

SNS 的傳遞語意因訂閱者類型而異，差異會在考試中被測試。

Retry policies

• AWS 原生訂閱者（Lambda、SQS、Firehose） — SNS 在 AWS 端 throttling 和瞬間錯誤時使用指數退避重試，通常在數小時內重試數十次。若已設定 topic 層級或 subscription 層級的 DLQ，失敗的傳遞會落在 DLQ。
• HTTP/S 訂閱者 — SNS 使用三個 retry 階段的明確 retry policy：即時重試（數秒內少量嘗試）、pre-backoff（線性退避）和 post-backoff（指數退避）。預設約在一小時內重試，policy 可透過 delivery policy JSON 按 subscription 設定。
• Email 與 SMS — SNS 在內部重試；失敗（bounced email、blocked SMS）不會傳遞到 DLQ。

Subscription DLQs

每個訂閱可以有一個 SQS DLQ。當 SNS 耗盡 retry 後，訊息連同失敗 metadata 一起落在 DLQ。DLQ 是每個訂閱各自設定，而非每個 topic——一個有五個訂閱者的 topic，若每個訂閱都需要失敗可視性，就需要五個 DLQ 設定。

訊息大小與結構

SNS 訊息限制 256 KB（與 EventBridge 相同）。對於較大的 payload，使用 SNS Extended Client，它將 payload 儲存在 S3，只發送 S3 參考。或者，發送通知訊息，由訂閱者從 S3 取回完整資料。

使用 Systems Manager Automation 進行自動化補救

SOA-C02 的標準補救鏈有三個環節：AWS Config rule 偵測不合規、EventBridge rule 比對 Config 合規變更事件、Systems Manager Automation runbook 執行矯正步驟。

三服務鏈的詳細說明

1. Config rule 根據規則邏輯評估資源（受管規則如 s3-bucket-public-read-prohibited 或自訂 Lambda-backed rules）。不合規時，Config 將 Config Rules Compliance Change 事件發布到 default EventBridge bus。
2. EventBridge rule 有一個 event pattern，比對 aws.config source、Config Rules Compliance Change detail-type，以及特定 rule 名稱和 NON_COMPLIANT 狀態。Target 是一個 SSM Automation document。
3. SSM Automation runbook 執行矯正動作——以 S3 bucket 為例，可能是 AWSConfigRemediation-RemoveS3BucketPublicReadAccess，它呼叫 s3:PutBucketAcl 將 ACL 設為 private，並呼叫 s3:PutBucketPolicy 移除公開存取聲明。

EventBridge rule 上的 IAM role 需要 ssm:StartAutomationExecution，Automation document 上的 role 需要來自 EventBridge role 的 iam:PassRole 以及實際的補救權限（s3:PutBucketAcl 等）。忘記任一層都是 SOA-C02 常見的錯誤答案陷阱。

Config managed remediation

Config 也支援不需要明確 EventBridge rule 的 direct managed remediation — 你在 Config rule 的「Remediation actions」分頁直接附加 SSM Automation document，並選擇 Automatic 或 Manual 模式。Automatic remediation 在不合規時立即執行；Manual 需要人工在 Config console 點擊「Remediate」。

當 SOA-C02 問「自動補救不合規資源的最簡設定」，答案是 Config managed remediation 的 Automatic 模式 — 不需要 EventBridge rule。當場景需要條件邏輯、fan-out、retry 或跨帳號補救時，答案是明確的 Config → EventBridge → SSM Automation 鏈。

常見 AWS 受管補救 documents

• AWSConfigRemediation-RemoveS3BucketPublicReadAccess
• AWSConfigRemediation-RemoveS3BucketPublicWriteAccess
• AWS-EnableEbsEncryptionByDefault
• AWS-DisablePublicAccessForSecurityGroup
• AWSConfigRemediation-EnableCloudTrailLogFileValidation
• AWS-RestartEC2Instance
• AWS-StopEC2Instance
• AWSConfigRemediation-EnableEbsEncryptionByDefault

這些涵蓋約 80% 的合規自動補救場景。自訂 Automation documents 以 YAML 或 JSON 撰寫，步驟包含 aws:executeAwsApi、aws:executeScript、aws:waitForAwsResourceProperty、aws:assertAwsResourceProperty 等。

矯正行動流程：CloudWatch Alarm → SNS → Lambda → API 呼叫

第二條標準補救鏈從 CloudWatch alarm 而非 Config rule 出發。

簡易形式

1. CloudWatch alarm 偵測到 metric 超閾值（例如 RDS FreeableMemory 低於閾值）。
2. SNS topic 接收 alarm action 訊息。
3. 訂閱 SNS topic 的 Lambda function 解析訊息並呼叫 AWS APIs 進行補救（例如將 RDS 擴展到更大的 instance class，或透過 SSM Run Command 重啟程序）。

健全形式（SOA-C02 偏好）

1. CloudWatch alarm 發布狀態變更。
2. EventBridge rule 針對 aws.cloudwatch source 比對特定 alarm 名稱與 state.value: "ALARM" 的 CloudWatch Alarm State Change。
3. EventBridge target 直接指向 SSM Automation runbook（AWS 受管補救不需要 Lambda）。
4. Rule 設有 DLQ 以捕捉失敗的調用。
5. Automation document 的 role 具備矯正動作所需的最小權限。
6. 同一條 rule 的另一個 target（或針對同一 alarm 事件的另一條 rule）發送到 SNS topic 供人工通知。

健全形式更受偏好，因為 EventBridge 處理 retry、DLQ 和 rule input transformation，而 SNS topic 專門用於人工通知，而非觸發補救。將補救邏輯混入 SNS topic 的 Lambda 訂閱者中，會把通知與行動混為一談。

何時可以用 alarm 直接觸發 Lambda

• 單帳號、單 region、簡單補救邏輯。
• 嚴格的延遲需求（sub-second 調用；SNS 會增加數十毫秒）。
• 無需長期維護的臨時運維腳本。

考試通常傾向 EventBridge-based 的答案，但要知道 alarm 直接觸發 Lambda 並非錯誤——只是健全性較低。

EventBridge Scheduled Events：取代 EC2 Cron Jobs

常見的 SysOps 反模式是在個別 EC2 instance 上跑 cron jobs 執行定期任務——每晚備份、每週報告、每小時資料匯出。每個 instance 都成為單點故障和設定孤島。SOA-C02 認可的替代方案是 EventBridge scheduled rules（或 EventBridge Scheduler）調用 Lambda function 或 SSM Automation document。

遷移模式

1. 稽核整個 fleet 上的現有 EC2 cron jobs。
2. 對每個 job 識別工作內容——是呼叫 AWS APIs 的 shell 腳本（改寫為 Lambda）、多步驟程序（改寫為 SSM Automation document）、還是長時間執行的批次作業（改寫為 ECS scheduled task 或 AWS Batch）？
3. 以等效的 UTC cron 表達式建立 EventBridge scheduled rule（或 Scheduler）。
4. 將 target 設定為新的運算資源。
5. 在 rule 上設定 DLQ。
6. 在 staging 測試，然後停用 EC2 cron，再刪除 EC2 cron 項目。

AWS 上常見的排程模式

• 每晚 EBS 快照 — cron(0 3 * * ? *) 調用 SSM Automation AWS-CreateSnapshot（或直接使用 Amazon Data Lifecycle Manager）。
• 每週合規報告 — cron(0 9 ? * MON *) 調用 Lambda，查詢 Config 與 Trusted Advisor，產生 S3 報告。
• 每小時清理 — rate(1 hour) 調用 Lambda，掃描孤立快照、未標記 EC2、過期 Elastic IPs。
• 上班時間擴展 — 兩條 scheduled rules，一條在 UTC 工作日早上八點 scale up，另一條在晚上八點 scale down。

跨帳號與跨 Region 事件轉發

許多 SOA-C02 場景涉及將來自多個帳號或 regions 的事件匯聚到中央位置進行監控或補救。

跨帳號事件傳遞

將事件從帳號 A 發送到帳號 B：

1. 在帳號 B（接收方），編輯目標 event bus（default 或 custom）的 resource-based policy，允許帳號 A 的 principal 執行 events:PutEvents。
2. 在帳號 A（發送方），建立一條 rule，其 target 為 arn:aws:events:region:accountB:event-bus/default（或 custom bus 名稱）。
3. 帳號 A 的 rule 需要一個 IAM role，授予對目標 bus ARN 執行 events:PutEvents 的權限。

考試測試兩個方向——許多考生記得目標端的 resource-based policy，卻忘了來源端 rule 上的 IAM role。

跨 region 事件傳遞

相同模式：target ARN 指向另一個 region 的 bus，來源端 rule 的 IAM role 授予跨 region 對目標 bus 執行 events:PutEvents 的權限。EventBridge 不會自動跨 region 轉發事件；你必須明確設定。

集中式 event bus 模式

對於擁有 50 個帳號的公司，SOA-C02 正確架構是：

• 在專用稽核帳號的主要 region 建立一個中央安全 event bus。
• 每個成員帳號在其 default bus 上建立 rules，將安全相關事件（GuardDuty findings、Config 合規變更、CloudTrail 的 root 帳號活動）轉發到中央 bus。
• 中央 bus 上的 rules fan-out 到 SNS（安全團隊）、Lambda（工單建立）和 S3（透過 Firehose 的稽核日誌封存）。

場景模式：EC2 Instance 反覆 Status Check 失敗

常見的 SOA-C02 排查場景。處理流程：

1. CloudWatch alarm 監控 StatusCheckFailed_System（系統狀態檢查，表示 AWS 端硬體損壞）。
2. Alarm 直接接線了 EC2 recover action — 當 alarm 觸發時，EC2 嘗試在不同的底層硬體上復原 instance。
3. 若復原成功，instance 保留其私有 IP、Elastic IP、instance ID 和 EBS 掛載。系統狀態檢查恢復通過。
4. 若復原失敗（例如 instance 類型不支援 recovery，或 alarm 是針對 StatusCheckFailed_Instance 這個 OS 端問題），一條針對 EC2 Instance State-change Notification 比對 state: stopped 的 EventBridge rule 會調用 SSM Automation runbook，執行深度診斷、為鑑識目的快照磁碟，並為值班人員建立 OpsItem。
5. SNS notification fan-out 到值班頻道，並在 IT 服務管理系統中建立工單。

EventBridge rule 以 runbook 作為 target，runbook 有一個具備 ec2:DescribeInstances、ec2:CreateSnapshot、ssm:CreateOpsItem 的 execution role，rule 設有 DLQ。通知流程與補救流程解耦，因此 Slack 中斷不會阻止快照的建立。

場景模式：Config 標記不合規的 S3 Bucket

這是標準的 Config + EventBridge + SSM Automation 場景。

1. AWS Config rule s3-bucket-public-read-prohibited 持續評估帳號中的每個 S3 bucket。
2. 開發人員意外建立了一個有公開讀取 ACL 的 bucket。
3. Config 在幾分鐘內偵測到不合規，並將 Config Rules Compliance Change 事件發布到 default EventBridge bus。
4. EventBridge rule 的 event pattern 比對 source: ["aws.config"]、detail-type: ["Config Rules Compliance Change"]、detail.configRuleName: ["s3-bucket-public-read-prohibited"]、detail.newEvaluationResult.complianceType: ["NON_COMPLIANT"] 並觸發。
5. Rule 的 target 是 SSM Automation document AWSConfigRemediation-RemoveS3BucketPublicReadAccess，透過 input transformer 從事件映射輸入參數（具體是從 $.detail.resourceId 取得 bucket 名稱）。
6. Automation document 的 role 具有對 arn:aws:s3:::* 的 s3:PutBucketAcl 和 s3:PutBucketPolicy 權限。
7. Runbook 呼叫 s3:PutBucketAcl 將 ACL 設為 private。幾秒內 bucket 不再公開。
8. 同一條 rule 的第二個 target 發送到 SNS topic，通知安全團隊用於稽核。

對於更簡單的情況，使用 Config managed remediation 的 Automatic 模式 可達到相同結果——不需要 EventBridge rule；Config rule 直接調用 SSM Automation document。根據場景是強調簡單性（managed remediation）還是可擴展性/多 target fan-out（明確的 EventBridge rule）來選擇答案。

常見陷阱：SNS HTTP Retry Semantics vs Lambda Subscriber

考生常假設 SNS retry 在所有訂閱者類型上是一致的。事實並非如此。

• HTTP/S 訂閱者 使用可設定的 delivery policy，有三個 retry 階段（immediate、pre-backoff、post-backoff）。預設總持續時間約一小時。
• Lambda 訂閱者 使用 SNS-Lambda 整合；retry 行為由 Lambda 的非同步調用 retry 規則管理（兩次 retry 加指數退避，之後若 Lambda function 或 SNS subscription 上設有 DLQ 則送往 DLQ）。
• SQS 訂閱者 在 SQS 於該 region 健康的情況下幾乎從不失敗；罕見的失敗會送往 DLQ。
• Email 與 SMS 內部重試；失敗（bounce、blocked）對 publisher 不可見。

混淆這些 retry 模型會導致「設定 SNS retry policy 以修正 Lambda 執行失敗」這樣的錯誤答案——SNS HTTP delivery policy 不適用於 Lambda 訂閱者。

常見陷阱：EventBridge 跨帳號 Bus

SOA-C02 常見的跨帳號 EventBridge 錯誤答案是：「在來源帳號建立 SNS topic，發布到目標帳號的 Lambda，Lambda 重新發布事件」。這能運作，但不是 AWS 推薦的模式。正確模式是透過目標 bus 的 resource policy 加上來源 rule 的 IAM role 直接進行跨帳號事件傳遞。Lambda 重新發布模式多增加一個跳轉和一個移動部件卻沒有任何好處；SOA-C02 期望的是原生跨帳號流程。

第二個跨帳號陷阱：忘記來源 rule 的 IAM role 需要對目標 bus ARN 的 events:PutEvents 權限。許多考生只設定了目標 bus 的 resource policy，卻不明白為何 rule 觸發了（Invocations metric 遞增）但事件沒有到達目標（目標 bus 上的 MatchedEvents metric 為零）。

常見陷阱：SNS Message Attributes vs Body 的過濾

預設情況下，SNS subscription filter policies 針對 message attributes 評估，而非 message body。若你的 producer 把 severity 放在 JSON body 而非 attribute 中，filter policy 永遠不會比對，導致所有訊息都不送達或全部送達（取決於 filter 是正向還是負向 pattern）。

解法之一是：

• 在發布時設定 message attributes，讓 filter policies 能使用（推薦——attributes 就是為過濾而設計的）。
• 啟用 body filtering，在 subscription 上設定 FilterPolicyScope: MessageBody。這樣 policy 就會針對 JSON body 中的欄位評估。注意 body filtering 是 2021 年後的功能，需要 JSON body 而非任意文字。

SOA-C02 干擾選項包含「filter policy 語法有誤」，而實際問題是 FilterPolicyScope 未設定。閱讀場景時注意「producer 發布 JSON」與「producer 設定 attributes」來選擇正確答案。

常見陷阱：EventBridge Rules 是 Regional 的

EventBridge rules 與 event buses 是 regional 的。us-east-1 的 EC2 狀態變更落在 us-east-1 的 default bus 上，us-west-2 的 rule 若沒有明確的跨 region 轉發就無法比對到它。這與 CloudWatch alarms（regional）和大多數其他 AWS 服務的模型相同。

當 SOA-C02 問「將 12 個 regions 的事件匯聚到單一 dashboard」時，答案涉及跨 region 事件轉發 rules（每個來源 region 各一條），路由到中央 region 的 bus，加上中央 rule fan-out 到 SNS 或 Lambda。EventBridge 沒有「全球」bus。

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

SAA 考生選服務；SOA 考生正確設定它、在事件丟失時排查，並在事故期間運維事件驅動管道。

考試訊號：如何辨認 Domain 1.2 的題目

SOA-C02 的 Domain 1.2 題目遵循可預測的形式。

• 「Rule 觸發了但 target 從未執行」 — Rule 上缺少 IAM role，或 input transformer 格式錯誤，或 target 在另一個 region/帳號但缺少跨 region/跨帳號配置。
• 「自動補救不合規資源」 — Config rule 搭配 Automatic remediation，或明確的 Config → EventBridge → SSM Automation 鏈。閱讀場景判斷是簡單性還是可擴展性。
• 「值班人員錯過一個事件」 — 未設定 DLQ、filter policy 過於嚴格，或 message attribute 未設定。
• 「排程一個定期任務」 — 簡單情況用 EventBridge scheduled rule、時區或單次情況用 EventBridge Scheduler、快照用 DLM、修補用 SSM Maintenance Window。
• 「將 EC2 cron jobs 轉移到 AWS」 — EventBridge → Lambda 或 SSM Automation，加上 DLQ。
• 「HTTP webhook 有時會離線」 — SNS HTTP delivery policy 搭配延長的 retry，加上 subscription DLQ。
• 「從多個帳號匯聚事件」 — 跨帳號 event bus，搭配 resource policy 和來源 rules 上的 IAM role。
• 「自動復原 EC2 instance」 — CloudWatch alarm 對 StatusCheckFailed_System 的 recover action，而非 EventBridge。
• 「Alarm 觸發時通知並補救」 — Alarm action 到 SNS 通知人工，EventBridge rule 監控 alarm 狀態變更並觸發 SSM Automation 執行補救。

決策矩陣 — 針對每個 SysOps 目標選用 EventBridge 或 SNS

常見陷阱整理 — EventBridge 與 SNS

陷阱一：EventBridge rule 觸發但 target 從未執行

Rule 上缺少 IAM role（最常見）、input transformer 格式錯誤、target 在另一個 region/帳號但缺少配置，或 Lambda permission policy 缺少 EventBridge service principal。

陷阱二：Filter policy 預設針對 attributes 而非 body

預設 scope 是 MessageAttributes。若 producer 將判別欄位放在 JSON body 而非 attributes 中，需設定 FilterPolicyScope: MessageBody。

陷阱三：HTTP retry semantics 套用到 Lambda

SNS HTTP delivery policy 不適用於 Lambda 訂閱者。Lambda 非同步調用的 retry 是獨立的。

陷阱四：跨帳號需同時設定 resource policy 和 IAM role

目標 bus 的 resource policy 是必要條件但不充分。來源 rule 的 IAM role 必須授予對目標 bus ARN 的 events:PutEvents 權限。

陷阱五：五個欄位的 Cron 表達式

EventBridge cron 有六個欄位：cron(minutes hours day-of-month month day-of-week year)。五個欄位的 POSIX cron 會被拒絕。day-of-month 或 day-of-week 其中之一必須填 ?。

陷阱六：正式環境 EventBridge rules 未設定 DLQ

EventBridge 在 retry 耗盡後靜默丟棄事件。務必設定 DLQ，加上針對其訊息數量的 CloudWatch alarm。

陷阱七：CloudWatch alarm 直接 EC2 actions 與 EventBridge EC2 actions 混淆

CloudWatch alarm 的內建 EC2 actions（recover、stop、terminate、reboot）完全繞過 SNS 和 EventBridge。它們綁定到 alarm 的 InstanceId dimension。EventBridge EC2 actions 接受任意 instance ID 清單。

陷阱八：SSM Automation execution role 權限

EventBridge rule 需要 ssm:StartAutomationExecution。Automation document 需要自己的 execution role，包含來自 EventBridge role 的 iam:PassRole 以及實際的補救權限。兩者缺一不可。

陷阱九：FIFO topic 搭配非 SQS FIFO 訂閱者

FIFO SNS topics 只能傳遞到 SQS FIFO queues。Email、SMS、HTTP 和 Lambda 訂閱者無法訂閱 FIFO topic。

陷阱十：Scheduled rules vs DLM 用於 EBS 快照

針對 EBS 快照生命週期，Amazon Data Lifecycle Manager 是 AWS 原生答案。EventBridge scheduled rules 調用 AWS-CreateSnapshot 可以運作，但缺少 DLM 的保留規則、快速快照還原管理和跨 region 複製功能。

FAQ — EventBridge 與 SNS Notifications

Q1：EventBridge 與 SNS 的差異是什麼，各自在什麼時候使用？

EventBridge 是事件路由器。它接收來自 AWS 服務和應用程式的事件，套用 pattern-matching rules，並將符合的事件路由到最多 5 個 targets。它有 buses、rules、archives、replay 和豐富的 event pattern 語法。SNS 是 fan-out pub/sub。它接收一則發布的訊息，並複製給多個訂閱者（email、SMS、HTTP、Lambda、SQS、行動推播），每位訂閱者可有自己的 filter policy。兩者可組合：EventBridge rule 的 target 通常是 SNS topic，這樣同一個事件能同時 fan-out 給人工（email、SMS、Slack）和其他 AWS 服務（Lambda、SQS）。路由與補救選 EventBridge；有多種傳遞管道的 fan-out 通知選 SNS。

Q2：為什麼我的 EventBridge rule 觸發了但 target 從未執行？

五個常見原因，按頻率排序：(a) rule 的 IAM role 缺失或沒有調用 target 的權限——檢查 role 和 target 的 resource policy；(b) input transformer 產生的 payload 被 target 以 validation 錯誤拒絕——查看 target 的 CloudWatch Logs；(c) target 被 throttle（Lambda 並發、SQS 吞吐量），retry 在傳遞前耗盡——在 rule 上加 DLQ；(d) target 被刪除或移動，ARN 已過期；(e) rule 在錯誤的 bus 上（default vs custom）。CloudWatch metric Invocations 在 rule 觸發時遞增，FailedInvocations 表示 target 傳遞失敗——檢查差值來定位問題。

Q3：如何自動補救 Config rule 違規？

兩種模式。簡單：在 Config rule 上設定 Config managed remediation，模式為 Automatic，附加 SSM Automation document（通常是 AWS 受管的 AWSConfigRemediation-... document），並提供 document 的參數。Config 在不合規時直接調用 document。可擴展：建立明確的鏈——Config rule 發出 Config Rules Compliance Change 事件，一條 EventBridge rule 比對 rule 名稱和 NON_COMPLIANT 調用 SSM Automation document，第二個 target 發送到 SNS 供稽核通知。場景強調最小設定時選簡單；需要 fan-out、條件邏輯或跨帳號補救時選可擴展。

Q4：如何根據訊息的屬性通知訂閱者？

使用 SNS subscription filter policies。預設情況下，filter policies 針對訊息的 MessageAttributes（與 body 一起發送的 key-value metadata）評估。在發布時設定 attributes：Publish(TopicArn, Message, MessageAttributes={severity: {DataType: String, StringValue: "critical"}})。訂閱者的 filter policy {"severity": ["critical", "high"]} 就只傳遞 severity attribute 符合的訊息。若判別欄位在 JSON body 而非 attributes 中，在 subscription 上設定 FilterPolicyScope: MessageBody，policy 就會針對 body 評估。Filter policies 支援精確比對、prefix、anything-but、numeric、exists——與 EventBridge event patterns 相同的運算子家族。

Q5：從成員帳號將 EventBridge 事件轉發到中央稽核帳號的正確方法是什麼？

設定直接的跨帳號事件傳遞。(1) 在稽核帳號，建立 custom event bus（或使用 default），編輯其 resource-based policy 授予 events:PutEvents 給成員帳號的 principal ARNs。(2) 在每個成員帳號，在 default bus 上建立一條 rule，event pattern 比對你要轉發的事件（GuardDuty findings、Config 合規變更、CloudTrail 的 root 帳號事件等）。(3) Rule 的 target 是稽核帳號的 bus ARN。(4) Rule 有一個 IAM role 授予對目標 bus ARN 執行 events:PutEvents 的權限。(5) 在稽核帳號，在中央 bus 上建立 rules，fan-out 到 SNS（安全團隊）、Lambda（工單建立）和 S3 archive via Firehose。兩個方向——目標 resource policy 和來源 IAM role——都是必要的。

Q6：EventBridge 對失敗的 target 調用重試多久？

預設情況下，EventBridge 以指數退避重試 24 小時。24 小時失敗重試後，事件會被丟棄，除非你在 rule 上設定了 dead-letter queue（SQS）。正式環境 rules 應始終設有 DLQ，加上針對 DLQ 的 ApproximateNumberOfMessagesVisible 的 CloudWatch alarm，讓值班人員了解傳遞失敗。Retry 持續時間可透過 rule 的 RetryPolicy 設定（MaximumEventAge，以秒為單位）按 rule 設定，最短 60 秒，最長 86,400 秒（24 小時）。

Q7：什麼時候使用 EventBridge Scheduler 而非 scheduled EventBridge rule？

EventBridge Scheduler（2022 年推出）是更新的排程服務，取代新工作負載的 scheduled rules。以下情況使用 Scheduler：(a) 每帳號需要數百萬個 schedules（rules 受 per-bus 限制）；(b) 需要在特定時間戳的單次排程；(c) 需要時區感知的 cron 表達式，如在 Asia/Taipei 評估的 cron(0 9 * * ? *)；(d) 需要彈性時間視窗用於負載平滑（在 15 分鐘視窗內的任意時間觸發）；(e) 想要每個排程各自設定的內建 retry、DLQ 與 target 加密。以下情況使用 scheduled rule：(f) 只有少量簡單的 cron 排程；(g) 排程自然是 default bus 上事件驅動流程的一部分；(h) 工作負載是遺留系統且 rules 已就位。SOA-C02 兩者都會考；Scheduler 是規模與時區場景的現代優選答案。

Q8：為什麼我的 SNS HTTPS 傳遞失敗且訊息消失了？

兩個可能原因：(a) HTTP endpoint 離線時間超過 SNS retry policy 的涵蓋範圍——預設 policy 重試約一小時。設定包含延長 retry 的自訂 delivery policy（numRetries、numMaxDelayRetries、minDelayTarget、maxDelayTarget、backoffFunction）。在 retry 耗盡後，設定 subscription DLQ 讓失敗訊息落在 SQS queue 而非消失。(b) Endpoint 回傳 SNS 視為終態的 non-2xx 回應碼（預設情況下 4xx 除了 408/429）。查看 endpoint 的日誌確認實際回應。SOA-C02 的陷阱是假設 Lambda 訂閱者的 retry 規則適用於 HTTP——它們不適用；HTTP 與 Lambda 使用完全不同的 retry 模型。

Q9：如何從 CloudWatch alarm 觸發 SSM Automation runbook？

兩條路徑。直接：設定 EventBridge rule，針對 aws.cloudwatch source 比對特定 alarm 名稱且 state.value: ["ALARM"] 的 CloudWatch Alarm State Change。Rule 的 target 是 SSM Automation document。Rule 有一個帶 ssm:StartAutomationExecution 的 IAM role。Automation document 有自己的 execution role 具備實際補救權限。Rule 設有 DLQ。透過 SNS 間接：alarm action 發布到 SNS topic；訂閱 topic 的 Lambda 解析訊息並呼叫 ssm:StartAutomationExecution。直接 EventBridge 路徑更受偏好——移動部件更少、原生 retry、無需維護 Lambda 程式碼。SOA-C02 對任何「自動化補救」場景偏好直接 EventBridge 答案。

Q10：我可以用同一個 SNS topic 同時用於人工通知和自動化補救嗎？

可以，但這不是 SOA-C02 最佳實踐。乾淨的分離是：SNS topic 用於人工（email、SMS、Slack、PagerDuty 訂閱者），EventBridge rule 用於自動化（SSM Automation、Lambda、Step Functions targets）。兩者從相同的來源事件觸發（CloudWatch alarm 狀態變更、Config 合規變更）。分離的理由：(a) 人工通知與自動化有不同的 retry、filter 和 DLQ 需求；(b) Slack 中斷不應阻止補救；(c) Automation document 失敗不應讓值班人員靜音；(d) 對 SNS filtering 有用的 message attributes 可能與 EventBridge pattern 欄位不同。例外是小型、簡單的環境，在 SNS topic 上用一個同時負責補救和人工訂閱的 Lambda 訂閱者是可以接受的。

延伸閱讀與相關運維模式

• What Is Amazon EventBridge — User Guide
• EventBridge Event Buses
• EventBridge Rules
• EventBridge Event Patterns
• Creating an EventBridge Rule on a Schedule
• EventBridge Targets
• Sending and Receiving EventBridge Events Across Accounts
• EventBridge Rule Dead-Letter Queues
• Amazon EventBridge Scheduler
• What Is Amazon SNS
• Creating an Amazon SNS Topic
• Amazon SNS Message Filtering
• Amazon SNS Message Delivery Retries
• Amazon SNS Dead-Letter Queues
• Amazon SNS FIFO Topics
• CloudWatch Alarm Actions Reference
• AWS Systems Manager Automation
• AWS Config Remediation
• AWS SOA-C02 Exam Guide v2.3 (PDF)

事件驅動補救到位後，下一層運維是：CloudWatch Metrics、Alarms 與 Dashboards——為 EventBridge 與 SNS 提供上游訊號；Systems Manager Automation 與 Patch Manager——EventBridge 所調用的 runbook 層；排程任務與 Config 自動補救——以 EventBridge 為骨幹的定期與持續合規流程；以及 CloudWatch Logs 與 Insights——通常產生驅動 alarms 的 metric filters 的應用程式與系統日誌遙測。

• CloudWatch Metrics、Alarms 與 Dashboards — SOA-C02 學習筆記
• Systems Manager：Automation、Patch Manager 與 Session Manager — SOA-C02 學習筆記
• 排程任務、Config 自動補救與流程自動化 — SOA-C02 學習筆記
• CloudWatch Logs、Log Groups 與 Logs Insights — SOA-C02 學習筆記