CloudWatch 警示 (Alarms) 與 EventBridge 的整合是 AWS 上每個 DevOps 自動化鏈的觸發層 (trigger layer)。警示觸發；EventBridge 規則接聽；目標 (SNS、Lambda、Step Functions、SSM Automation、ECS 任務、API 目標) 作出反應。DOP-C02 期望你能在現實限制下正確建立這些自動化鏈 —— 包括多帳戶、多區域、限制爆炸半徑 (blast radius)、冪等 (idempotent) 重試以及重複資料刪除，這樣你就不會因為一次故障而傳呼值班人員十次。考試測試的是微小但嚴苛的細節：複合警示 (composite alarms) vs 指標運算 (metric math) vs 異常偵測 (anomaly detection)、n 個資料點中的 m 個 評估期、遺失資料處理、EventBridge 模式匹配語法 (這不是 JSON)、預設事件匯流排與自訂匯流排的區別、用於事件還原的封存與重播 (archive-and-replay)、新的 EventBridge Scheduler 與排程規則 (scheduled rules) 的對比，以及具備正確資源政策的跨帳戶事件匯流排。
本指南假設你已了解基礎的 CloudWatch 警示（指標超過閾值）和 EventBridge 概念（事件源、規則、目標）。它專注於 DOP-C02 的實作深度：複合警示布林邏輯、警示定義中的指標運算運算式、異常偵測頻帶、包括 EC2 修復和 Auto Scaling 在內的警示動作、具備內容過濾和前綴匹配的 EventBridge 事件模式語法、EventBridge Scheduler 的單次和遞迴排程、用於事後分析的封存與重播、針對失敗目標的寄丟郵件佇列 (dead-letter queues, DLQ)、將事件重塑為目標友好負載的輸入轉換器 (input transformers)、用於類型化事件處理的結構描述註冊表 (schema registry) 以及跨帳戶事件交付。網域 4.3 (自動化監控與事件管理) 和網域 5.1 (管理事件源以進行處理、通知和採取行動) 是此內容的核心。
為什麼 CloudWatch 警示與 EventBridge 在 DOP-C02 中很重要
DOP-C02 考試在結構上偏向事件驅動的自動化。網域 5 (事件與事故回應，佔 14%) 的引入是 C01 到 C02 最大的擴展，而每個網域 5 的情境都以 EventBridge 作為事件匯流排。CloudWatch 警示是合成事件源，將指標閾值轉化為事件；EventBridge 規則是路由架構，將這些事件發散到修復、通知和工單系統。它們共同回答了常見的考試問題：「當某事發生時，系統如何自動回應而無需在凌晨 3 點傳呼人工？」
警示與 EventBridge 也是 DOP-C02 測試相鄰服務區分能力的地方。警示 vs 指標運算 vs 異常偵測有微妙的區別。EventBridge 規則 vs EventBridge Scheduler vs CloudWatch Events (舊稱) 需要你了解目前的趨勢。複合警示 vs SNS 主題組合在微妙之處有所不同。考試不測試這些功能的存在 —— 它測試的是在指定限制 (成本、延遲、多帳戶邊界、重複刪除需求) 下選擇正確的功能。
- 指標警示 (Metric alarm)：監控單一指標 (或指標運算運算式) 並在 OK、ALARM 和 INSUFFICIENT_DATA 狀態之間切換的規則。
- 複合警示 (Composite alarm)：一種元警示 (meta-alarm)，使用布林運算子 (AND, OR, NOT) 監控其他警示的狀態 —— 用於抑制噪音和實作多訊號邏輯。
- 異常偵測警示 (Anomaly detection alarm)：具有 ML 衍生預期頻帶的指標警示；當指標離開頻帶時 (高於、低於或兩個方向) 發出警示。
- 指標運算 (Metric math)：一種運算式語法 (
m1+m2,RATE(m1),IF(m1>5, 1, 0))，可將多個指標組合成一個可警示的序列。 - 警示動作 (Alarm action)：狀態變更時叫用的目標 —— SNS 主題、Auto Scaling 動作、EC2 停止/終止/重新開機/修復、Systems Manager OpsItem/事故、Lambda (透過 SNS)。
- EventBridge 預設事件匯流排 (Default event bus)：每個帳戶中自動接收 AWS 服務事件的匯流排。
- 自訂事件匯流排 (Custom event bus)：用於應用程式或夥伴事件的獨立具名匯流排；跨帳戶交付和 SaaS 夥伴整合所需。
- 事件模式 (Event pattern)：一種類似 JSON 的規則，使用欄位、前綴、後綴、anything-but、數值和 exists 匹配器對傳入事件進行匹配。
- 輸入轉換器 (Input transformer)：每個目標的模板，使用 JSONPath 參考將原始事件重塑為自訂負載。
- EventBridge Scheduler：專用的排程服務 (2022 年推出)，用於單次和遞迴排程；在規模上取代了排程規則。
- 封存與重播 (Archive and replay)：捕捉匯流排上的事件、將其儲存一段保留期，並在以後重新發出以進行事故重現或回補的功能。
- 參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
白話文解釋 CloudWatch 警示與 EventBridge
警示與匯流排模式比較抽象，而布林組合規則經常讓那些認為警示是獨立觸發器的工程師感到困惑。以下三個不同的類比會有幫助。
類比 1：煙霧偵測器與大樓火災面板
大樓中的每個煙霧偵測器都是一個 CloudWatch 指標警示：它監控單一訊號 (煙霧密度)，並在超過閾值時觸發。偵測器本身不知道該做什麼 —— 它只是輸出狀態變更。一個側翼的所有偵測器都連接到大樓火災面板，這就是複合警示：它應用布林邏輯 (「如果走廊 AND 樓梯間同時報警，這是真的火災；如果只有廚房報警，可能只是吐司烤焦」)。火災面板不直接傳呼消防隊 —— 它向大樓事件匯流排 (EventBridge 預設匯流排) 傳送訊號，多個訂閱者在此接聽。消防隊訂閱了 (一個透過 Lambda 目標發送簡訊的 EventBridge 規則)，電梯系統訂閱了 (一個將電梯返回地面的規則)，空調系統訂閱了 (一個關閉排風機以減緩煙霧的規則)，大樓日誌也訂閱了 (一個寫入 S3 用於事後分析的規則)。一個事件，發散到多個目標，每個目標都有自己的重試和寄丟郵件佇列。EventBridge 輸入轉換器是火災面板將「偵測器 Z14，煙霧水平 380 ppm」轉換為消防隊期望負載格式 (「地址：忠孝東路 123 號；區域：西翼；嚴重性：3」) 的方式。重播則是錄製的大樓過去事件迴圈，你可以在下次演習中播放，以測試新的調度軟體。
類比 2：工業 SCADA 系統
在電廠中，每個感測器 (渦輪轉速、冷卻劑溫度、電壓) 都輸入到 PID 控制器 —— 這就是你的 具備指標運算的 CloudWatch 指標警示。控制器計算衍生訊號 (coolant_temp - ambient_temp) 並在超過容許值時跳脫。多個控制器級聯成一個安全連鎖矩陣 (safety interlock matrix) —— 這就是你的具備 AND/OR/NOT 邏輯的複合警示，可防止單一錯誤讀取觸發停機。當真正的連鎖跳脫時，它會在電廠的程序匯流排 (process bus) (EventBridge 自訂事件匯流排，與企業 IT 匯流排隔離) 上引發事件。訂閱者包括自動化動作 (關閉閥門 V12、啟動備用泵、傳呼輪班主管) 和較慢的程序 (安排維護工單、通知法規監控)。EventBridge Scheduler 是電廠的預防性維護行事曆 —— 每個週二 02:00，在 A 泵上執行潤滑執行手冊；每季執行完整的振動測試。封存與重播是電廠的黑盒子記錄器，捕捉 90 天內的所有程序事件，以便調查人員在事故後重現序列。
類比 3：新聞通訊社 (Newsroom Wire Service)
通訊社 (如路透社、美聯社) 本身就是 EventBridge。世界各地的記者 (AWS 服務、自訂應用程式、SaaS 夥伴) 將故事 (事件) 推送到通訊線路 (匯流排)。每間新聞編輯室 (訂閱者 Lambda、Step Function、ECS 任務、第三方 API) 都註冊了描述其關注內容的規則：「任何標記為 politics 且來自 台北 的內容」，「任何嚴重性為 critical 的內容」。通訊社獨立地將每個匹配的故事交付給每個訂閱者 —— 即發散 (fan-out)，每個訂閱者按自己的節度進行處理。輸入轉換器是通訊社的分發層，將同一個故事重新包裝成每間新聞編輯室喜歡的格式 (報紙想要短段落，深度報導網站想要長篇)。跨帳戶事件匯流排是國際分發頻道 —— 路透社透過契約許可交付給路透社東京分社。封存與重播是通訊社的過往檔案庫 —— 所有過去故事的可搜尋存檔，如果下游新聞編輯室錯過了幾個小時，你可以重播。
對於專注於「警示組合與噪音抑制」的題目，請參考大樓火災面板類比。對於專注於「工業自動化與排程執行手冊」的題目，請參考SCADA 電廠類比。對於專注於「發散、多帳戶事件分發與重播」的題目，請參考新聞通訊社類比。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
CloudWatch 指標警示組成解析
指標警示具有以下必要參數：指標 (或指標運算運算式)、比較運算子 (例如 GreaterThanOrEqualToThreshold)、閾值、評估期 (必須違規的連續期間數)、警示所需資料點計數 (n 個資料點中的 m 個) 以及遺失資料處理。這些組合比看起來更微妙。
n 個資料點中的 m 個 (m-out-of-n) 評估
預設：n 個連續期間全部違規。m-out-of-n 模式讓你設定「如果過去 5 個期間中有 3 個違規就發出警示」 —— 這在短暫尖峰正常但持續違規才重要的情況下很有用。情境：追蹤 CPUUtilization 70% 的 Auto Scaling 目標應該忽略一分鐘的尖峰；請使用 5 個中的 3 個 而非 1 個中的 1 個。
遺失資料處理 (Missing data treatment)
四個選項：notBreaching (將遺失視為健康)、breaching (將遺失視為警示)、ignore (不更改狀態)、missing (切換到 INSUFFICIENT_DATA)。預設為 missing。對於部署安全警示 (例如，「如果未收到成功請求則部署失敗」)，你需要 breaching。對於週期性批次作業，你需要 notBreaching 以避免狀態頻繁切換。
警示動作 (Alarm actions)
動作在狀態變更轉換時觸發 (OK→ALARM, ALARM→OK, ALARM→INSUFFICIENT_DATA 等)。內建動作類型：
- SNS 主題通知 —— 最常見；發散到電子郵件、簡訊、Lambda、SQS。
- EC2 動作 ——
stop,terminate,reboot,recover。recover(修復) 僅適用於使用 EBS 支援之根磁碟區的執行個體；它會在不同的底層硬體上啟動該執行個體。 - Auto Scaling 動作 —— 觸發步進或簡單擴展政策。
- Systems Manager OpsItem —— 在 OpsCenter 中建立類似工單的成品，供人工審查。
- Systems Manager Incident —— 升級到事故管理員 (Incident Manager) 回應計畫。
DOP-C02 的一個常見陷阱：考生選擇「警示直接調用 Lambda」作為答案。CloudWatch 警示無法直接以 Lambda 為目標。路徑是 警示 → SNS 主題 → Lambda 訂閱，或 警示 → EventBridge 規則 (透過警示狀態變更事件) → Lambda 目標。後者是現代推薦的模式，因為 EventBridge 支援重試、寄丟郵件佇列和輸入轉換。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
複合警示 — 用於噪音抑制的布林邏輯
複合警示監控多個指標警示，僅在布林運算式評估為 true 時才觸發。語法範例：ALARM("WebTier-5xx") AND ALARM("WebTier-Latency-High") AND NOT ALARM("Maintenance-Window")。使用案例：
- 抑制維護噪音：在排程部署期間觸發抑制警示 (inhibitor alarm)；複合警示使用
NOT ALARM("Maintenance-Window")來靜音下游傳呼。 - 多訊號關聯：僅當錯誤率 AND 延遲同時惡化時才傳呼 —— 單一訊號可能是噪音。
- 階層化警示樹：頂層的「應用程式健康度」複合警示彙整了數十個分葉警示。
複合警示本身可以作為其他複合警示的輸入 (深度可達 10 層)。它們有自己的動作列表，與分葉警示分開 —— 分葉警示通常不設動作；僅由複合警示觸發傳呼。這是對應「防止值班人員因一次事件被傳呼 30 次」的正確答案。
異常偵測警示 (Anomaly Detection Alarms)
異常偵測圍繞指標封裝了 CloudWatch 內建的 ML 模型，以計算預期頻帶。當指標離開頻帶 (高於、低於或兩者皆是) 時發出警示。組態：
- 方向：
GreaterThanUpperThreshold(高於上限)、LessThanLowerThreshold(低於下限) 或LessThanLowerOrGreaterThanUpperThreshold(超出頻帶)。 - 標準差：頻帶的寬度。預設為 2；較高意味著較少的誤判。
- 訓練期：ML 使用 14 天的歷史資料。
對於具有季節性模式且固定閾值無法捕捉正常情況的指標 (例如每日流量形狀、週末下降)，請使用異常偵測。不要對具有硬性 SLO 的指標 (例如延遲 P99 < 500 ms) 使用異常偵測；在這種情況下應使用靜態閾值，因為業務合約關心的是絕對值，而不是統計上的正常度。
警示中的指標運算 (Metric Math)
指標運算定義了一個用於警示的衍生序列。語法範例：
(errors / requests) * 100—— 錯誤率。RATE(m1)—— 計數器的每秒速率。FILL(m1, REPEAT)—— 用最後一個值填充遺失資料 (慎用)。IF(m1 > 5, 1, 0)—— 條件旗標。ANOMALY_DETECTION_BAND(m1, 2)—— 在運算式內建異常頻帶。
指標運算警示按底層指標擷取率計費。它們不能在單一運算式中包含跨區域或跨帳戶指標 —— 為此，請使用跨帳戶可觀察性並在儀表板層級進行彙總。
EventBridge 事件模式 — 真實語法
事件模式看起來像 JSON，但它們不是任意的 JSON 匹配器。它們遵循特定語法：
- 精確匹配：
{ "source": ["aws.ec2"] }—— 陣列意味著 "OR"。 - 前綴匹配：
{ "detail": { "instance-id": [{ "prefix": "i-abc" }] }}—— 僅限字串欄位。 - 後綴匹配：
{ "detail": { "filename": [{ "suffix": ".gz" }] }}。 - Anything-but (非)：
{ "source": [{ "anything-but": ["aws.health"] }] }。 - 數值 (Numeric)：
{ "detail": { "cpu": [{ "numeric": [">", 80] }] }}。 - Exists (存在)：
{ "detail": { "status": [{ "exists": true }] }}。 - 萬用字元 (Wildcard, 2024 年推出)：有限的前綴/後綴；原始語法不支援完整的萬用字元 (glob)。
常見的 DOP-C02 陷阱：考生寫成 {"source": "aws.ec2"} (字串而非陣列)。語法要求使用陣列。另一個陷阱：他們期望直接使用 == 或 > 運算子；語法要求使用 numeric 匹配器物件。
背熟匹配器集合：prefix, suffix, anything-but, numeric, exists, cidr (用於 IP), equals-ignore-case 以及 wildcard (較新)。每個值都封裝在陣列中 —— 即使是單個值。模式透過精確路徑與事件 JSON 樹進行匹配。跨模式邏輯在欄位內使用陣列 OR；欄位間的 AND 是隱含的。模式不支援通用的正則運算式 (regex)。對於複雜的匹配，請透過 Lambda 進行轉換與路由。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html
EventBridge Scheduler vs 排程規則
執行排程任務的舊方法是使用具有 cron 或 rate 運算式的 EventBridge 規則，目標為 Lambda 或 SSM。2022 年 11 月，AWS 推出了 EventBridge Scheduler 作為專用服務。在 DOP-C02 中，兩者的區別很重要：
| 功能 | 排程規則 (舊版) | EventBridge Scheduler |
|---|---|---|
| 每個帳戶排程限制 | 300 | 100 萬以上 |
| 時區支援 | 僅限 UTC | 任何 IANA 時區 |
| 單次排程 | 否 | 是 |
| 彈性時間視窗 | 否 | 是 (抖動/jitter) |
| 目標 | EventBridge 目標清單 | 模板化目標，透過 SDK 支援 270 多個服務 |
| 計費 | 免費 | 按叫用次數付費 |
對於新工作，務必選擇 EventBridge Scheduler。考試會提供「排程規則」作為干擾項；當提到規模或單次排程時，請選擇 Scheduler。
自訂事件匯流排與跨帳戶交付
預設事件匯流排僅接收你帳戶中的 AWS 服務事件。要接收來自應用程式、夥伴 SaaS 或其他帳戶的自訂事件，你需要建立一個自訂事件匯流排。跨帳戶交付需要：
- 接收端的自訂匯流排具有基於資源的政策，允許來源帳戶進行
events:PutEvents。 - 來源帳戶在其匯流排上建立一條以目標匯流排 ARN 為目標的規則，並具備 EventBridge 用於交付的 IAM 角色。
- 目標匯流排在接收帳戶中擁有具有目標的規則。
此模式廣泛用於集中式安全和營運匯流排。考試測試點：
- 預設匯流排不能接收來自另一個帳戶的事件 (必須使用自訂匯流排)。
- 跨帳戶
PutEvents每個事件有 256 KB 的硬性限制。 - 交付是盡力而為的；請在規則目標上為失敗配置寄丟郵件佇列 (DLQ)。
封存與重播 (Archive and Replay)
「封存」捕捉到達匯流排的所有事件，並在 EventBridge 中儲存一段保留期 (1 天到無限期)，可選用基於模式的過濾。「重播」在選擇的時間視窗內將封存的事件重新發送到同一個匯流排。使用案例：
- 在部署新規則之前，針對過去流量進行測試。
- 重現事故以偵錯下游處理。
- 在目標故障後回補 Lambda。
重播不包含原始交付 —— 目標會像事件實時到達一樣被重新叫用。請及早建立封存，因為你無法追溯捕捉已經通過匯流排的事件。
輸入轉換器 — 交付前重塑
輸入轉換器使用 JSONPath 參考將匹配的事件重塑為目標特定的負載。包含兩部分：
- 輸入路徑 (Input paths)：變數名稱到 JSONPath 運算式的映射 (
{ "instance": "$.detail.instance-id", "state": "$.detail.state" })。 - 輸入模板 (Input template)：使用變數的字串模板 (
"執行個體 <instance> 變更為 <state>")。
使用案例：透過 API 目標將 AWS 服務事件轉換為 Slack 友好的文本，或將事件塑造成 SSM Automation 執行手冊期望的結構。
寄丟郵件佇列 (DLQ) 與重試
每個 EventBridge 目標都支援選用的寄丟郵件佇列 (一個 SQS 佇列) 和重試政策 (事件最大壽命、最大重試次數)。預設重試政策為 24 小時和 185 次重試。請為任何生產環境目標配置 DLQ，以便捕捉失敗的交付進行事後分析，而不是默默丟棄。
一個高頻率的 DOP-C02 陷阱：Lambda 目標在部署期間拋出異常，EventBridge 規則在 24 小時內重試 185 次，然後丟棄該事件。團隊根本不知道事件遺失，直到客戶回報漏掉通知。務必在每個生產目標上配置 SQS DLQ，並對 ApproximateNumberOfMessagesVisible 設定警示，以便丟棄的事件觸發調查。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-dlq.html
結構描述註冊表 (Schema Registry)
結構描述註冊表儲存事件的 JSON Schema 或 OpenAPI 定義。EventBridge 會自動從匯流排上的傳入事件探索結構描述 (Schema Discovery)，並讓你為下游消費者產生強類型程式碼繫結 (Java, Python, TypeScript, Go)。當你擁有許多自訂應用程式事件並希望強制執行生產者-消費者契約時，請使用此功能。
高頻考試陷阱
陷阱 1：Lambda 不能是直接的警示動作
請使用 SNS → Lambda 或警示狀態變更 EventBridge 規則 → Lambda。直接 Lambda 不是警示動作。
陷阱 2：EC2 修復 (Recover) 需要 EBS 支援的根磁碟區
修復動作不適用於執行個體儲存 (instance-store) 支援的執行個體。干擾項：「在具有 NVMe 執行個體儲存的 i3.xlarge 上使用修復動作」 —— 錯誤。
陷阱 3：複合警示不能擁有自己的指標
複合警示僅引用其他警示。規則運算式中不能包含原始指標。
陷阱 4：預設事件匯流排不能接收跨帳戶事件
必須使用具有資源政策的自訂匯流排。預設匯流排僅接收 AWS 服務事件。
陷阱 5：EventBridge 模式不是 JSON 匹配
{"source": "aws.ec2"} (字串) 不匹配。必須是 {"source": ["aws.ec2"]} (陣列)。
陷阱 6：排程規則 vs 大規模 Scheduler
每個帳戶 300 個排程規則的限制會影響多租戶 SaaS 設計。對於大約 100 個以上的任何規模排程，請使用 EventBridge Scheduler。
陷阱 7：異常偵測頻帶需要 14 天的歷史資料
新指標在累積 14 天的訓練資料之前無法使用異常偵測。干擾項：「立即在全新的自訂指標上建立異常偵測警示」 —— 在訓練完成前會失敗。
複合警示使用帶有 ALARM("name"), OK("name"), INSUFFICIENT_DATA("name") 函數以及 AND, OR, NOT 布林運算子的規則字串。EventBridge 使用 JSON 模式。它們是無關的語法。考試會在干擾項中混用它們 —— 請選擇與題目背景服務相匹配的語法。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm_How_To.html
DOP-C02 考試模式與案例解析
情境 1：在部署期間抑制報警
題目： 「由於執行個體循環退出，每次部署期間值班工程師都會收到 50 次傳呼。」正確答案：使用具備 NOT ALARM("Maintenance-Window") 抑制器的複合警示。維護視窗警示在部署前後手動或透過部署管線設定。
情境 2：每天自動停止閒置的 EC2 執行個體
題目：「在使用者本地時間每天 19:00 停止開發用的 EC2 執行個體。」正確答案：使用 EventBridge Scheduler 搭配使用者的 IANA 時區，以 aws-sdk:ec2:stopInstances 作為目標。錯誤答案：排程規則 (僅限 UTC)。
情境 3：多區域彙總警示
題目：「當 us-east-1 和 eu-west-1 的總錯誤率超過 5% 時發出警示。」正確答案：跨帳戶可觀察性監控帳戶託管到中央帳戶的指標串流；警示在監控帳戶中執行，使用彙總串流資料的指標運算運算式。指標運算本身不能在單一運算式中跨區域。
情境 4：重播過去事件以測試新邏輯
題目：「團隊希望針對過去 7 天的訂單事件測試新的詐欺偵測 Lambda，而不重新執行訂單。」正確答案：在訂單匯流排上建立 EventBridge 封存，然後重播到新 Lambda 訂閱的測試匯流排。
情境 5：關鍵執行個體的 EC2 修復警示
題目：「某個 EC2 執行個體託管了一個無法忍受底層硬體故障的具狀態資料庫。」正確答案：對 StatusCheckFailed_System (系統狀態檢查，AWS 基礎設施端) 設定警示並採取 recover (修復) 動作；這會在不同的硬體上重建執行個體，同時保留執行個體 ID、IP 和 EBS 磁碟區。錯誤答案：對 StatusCheckFailed_Instance 設定警示 (這是執行個體作業系統端，修復動作無效)。
FAQ
Q1：我何時該使用複合警示、指標運算或異常偵測？
當你需要具有固定閾值的衍生數值序列時，請使用指標運算 (錯誤率 = 錯誤/請求)。當你需要跨已定義警示狀態的布林邏輯時，請使用複合警示 (抑制噪音、關聯訊號)。當指標具有季節性模式且沒有固定閾值時 (每日流量形狀)，請使用異常偵測。
Q2：我應該使用排程規則還是 EventBridge Scheduler？
對於任何新工作，請使用 EventBridge Scheduler。它支援時區、單次排程、彈性時間視窗，以及每個帳戶 100 萬個以上的排程。排程規則僅保留用於向後相容性，且每個帳戶限制為 300 個。
Q3：如何透過 CloudWatch 警示以具備重試和 DLQ 的 Lambda 為目標？
兩種模式：(1) 警示 → SNS → Lambda (在 Lambda 函數本身設定 DLQ，透過 SNS 訂閱的重新驅動政策重試)。(2) 警示狀態變更事件流向預設 EventBridge 匯流排；建立一條匹配 aws.cloudwatch 來源和 CloudWatch Alarm State Change 詳細類型的規則，目標為具備規則級 DLQ 和重試配置的 Lambda。模式 2 在重試控制方面更佳。
Q4：EventBridge 事件可以跨區域交付嗎？
可以 —— 規則目標可以是另一個區域中的事件匯流排 ARN。適用與跨帳戶相同的資源政策和 IAM 角色模式，此外跨區域交付是盡力而為的，會有額外的延遲。對於高流量的跨區域路由，建議優先使用 SQS 或 Kinesis。
Q5：為什麼我新的指標異常偵測警示一直處於 INSUFFICIENT_DATA 狀態？
異常偵測在計算頻帶之前需要 14 天的訓練資料。新指標需要擷取歷史記錄後警示才會啟動。在前兩週請使用靜態閾值，然後切換到異常偵測。
Q6：預設匯流排上的 EventBridge 規則與自訂匯流排上的規則有什麼區別？
預設匯流排會自動接收 AWS 服務事件。自訂匯流排僅接收你向其 PutEvents 的內容。請將自訂匯流排用於應用程式事件、夥伴 SaaS 和跨帳戶交付。規則可以附加到其中任何一個。
Q7：我可以使用 EventBridge 進行即時串流處理嗎？
EventBridge 是事件路由，而非串流處理。對於具有狀態的高吞吐量單事件處理，請使用 Kinesis Data Streams 或 Kinesis Data Firehose。對於每條規則每秒 0-50 個事件且需發散到多個目標的情況，EventBridge 非常出色。
交叉參考
- CloudWatch 指標與 Logs Insights 是此處所述警示的資料層；請參閱
cloudwatch-metrics-logs-insights。 - EventBridge 自動修復執行手冊解釋了警示與事件鏈如何以 SSM Automation 結束；請參閱
eventbridge-auto-remediation-runbooks。 - Systems Manager Incident Manager 解釋了警示如何升級到值班回應計畫；請參閱
systems-manager-incident-manager-health。 - CloudTrail 與 Config 儀表板解釋了共享相同 EventBridge 架構的稽核與合規事件源；請參閱
cloudtrail-config-audit-dashboards。 - 部署失敗故障排除使用相同的警示動作鏈來使部署失敗並回滾；請參閱
deployment-failure-troubleshooting。