Amazon EventBridge 是 DVA-C02 考試中應用程式整合的主角。在 V2.1 考綱中，AWS 將 EventBridge 從配角晉升為「路由事件、解耦生產者與消費者、扇出至多個目標並支援過濾、事故後重播、或排程週期性任務」的預設解答。若你能深入理解 Amazon EventBridge — 事件匯流排、規則、Schema Registry、封存與重播、EventBridge Scheduler、EventBridge Pipes — 就已掌握 Domain 2 應用程式整合分數的最大塊。圍繞 Amazon EventBridge 的還有三個考試仍會測驗的服務：Amazon SNS 負責純粹的 pub/sub 扇出，Amazon SQS 負責耐久的訊息佇列，AWS Step Functions 負責含重試機制的多步驟協調。本筆記頁涵蓋開發者需要的每一項 Amazon EventBridge 功能，逐一將 Amazon EventBridge 與 Amazon SNS、Amazon SQS、AWS Step Functions 比較，並提供一棵決策樹，讓你在考試當天選出正確服務。
Amazon EventBridge 在 DVA-C02 中至關重要，因為考試已不再問「這是 SNS 還是 SQS？」，而是改問「哪個 Amazon EventBridge 功能能解決這個問題？」Amazon EventBridge 規則取代了輪詢。Amazon EventBridge Scheduler 取代了 cron。Amazon EventBridge Pipes 取代了膠水 Lambda。Amazon EventBridge 封存與重播取代了「設一個 DLQ 然後祈禱」。Amazon EventBridge Schema Registry 取代了手工維護的 JSON 合約。現代 AWS 開發者應優先考慮 Amazon EventBridge，只有在特定限制迫使你時，才退而求其次使用 Amazon SNS、Amazon SQS 或 AWS Step Functions。
Amazon EventBridge 是什麼？
Amazon EventBridge 是一個無伺服器事件匯流排，它從 AWS 服務、SaaS 合作夥伴以及你自己的應用程式擷取事件，再根據規則（rules）將事件路由至一個或多個目標（targets）；規則的依據是事件模式（event pattern）。Amazon EventBridge 的事件是一份具有已知信封格式的 JSON 文件，包含：source、detail-type、detail、time、region、account。規則是儲存在匯流排上的過濾器，定義「當此匯流排上的事件符合此模式時，將其傳遞至這些目標」。目標是 Amazon EventBridge 可直接呼叫的 30 多種 AWS 服務之一 — Lambda、Step Functions、SQS、SNS、Kinesis Data Streams、Firehose、ECS tasks、API Gateway、API destinations 等等。
Amazon EventBridge 有三種匯流排類型，知道應使用哪種匯流排是 DVA-C02 的常見考點：
- 預設匯流排（Default bus） — 每個 AWS 帳號在每個 Region 有一條預設 Amazon EventBridge 匯流排，大多數 AWS 服務（EC2 狀態變更、啟用後的 S3 物件事件、CodePipeline 轉換、Health 事件等）會自動發送事件至此。預設匯流排無法重新命名或刪除。
- 自訂匯流排（Custom bus） — 你可以為自己的應用程式事件建立自訂 Amazon EventBridge 匯流排。將
OrderPlaced、UserSignedUp、InvoicePaid等業務事件放在自訂匯流排，避免與預設匯流排上的 AWS 服務事件混雜。大多數真實應用程式都向自訂 Amazon EventBridge 匯流排發布事件。 - 合作夥伴匯流排（Partner bus） — SaaS 合作夥伴（Zendesk、PagerDuty、Datadog、Shopify、Auth0、MongoDB Atlas、透過合作夥伴整合的 Stripe 等）將事件傳送至你帳號中的專屬合作夥伴 Amazon EventBridge 匯流排。你可在合作夥伴匯流排上建立規則，將符合條件的事件轉發至你的 Amazon EventBridge 目標或進一步處理。
Amazon EventBridge 依照每百萬筆發布至自訂或合作夥伴匯流排的事件收費；AWS 服務發送至預設匯流排的事件則免費。這個定價細節在設計具成本意識的扇出架構時很重要，考試也可能考到。
白話文解釋 Amazon EventBridge
以下四個生活化比喻說明 Amazon EventBridge 為何在 DVA-C02 中佔有舉足輕重的地位。
比喻一：Amazon EventBridge 如同捷運控制中心
想像台北捷運的控制中心。每分鐘都有數百件事情發生 — 列車進站、月台門開啟、票務異常、緊急廣播觸發、清潔人員簽到。Amazon EventBridge 就是那個控制中心。每件值得關注的事情都以事件的形式上報（source: gate-system, detail-type: door-opened），控制中心有一本規則手冊：「如果 source 是 safety 且 detail-type 是 fire-alarm，立即通知所有站務人員並啟動廣播；如果 source 是 ticketing 且 detail-type 是 abnormal-transaction，只通知稽查人員。」控制中心本身不處理各站的實際工作，它只根據規則手冊路由事件。Amazon EventBridge 的規則與目標運作方式完全相同 — 規則比對事件模式，每個符合的事件最多傳遞至五個 Amazon EventBridge 目標。
比喻二：Amazon EventBridge Schema Registry 如同圖書館的圖書目錄
想像一間公共圖書館。每本新書到館時都會被編目 — 書名、作者、ISBN、類別、年份 — 記錄在主目錄（Schema Registry）中。新讀者（開發者）想找某主題的書，不必逐本翻閱內文，直接查目錄條目即可。Amazon EventBridge Schema Registry 就是事件的這本目錄。開啟自動探索功能後，Amazon EventBridge 監看流經匯流排的事件約五分鐘，推斷每個不同 source + detail-type 組合的 JSON 結構，並將 schema 寫入 discovered-schemas registry。開發者下載程式碼繫結（code bindings） — Java、Python、TypeScript — 直接匯入 IDE，event.detail.orderId 可自動補全，編譯器也會在建置時拒絕拼錯的欄位名稱。再也不用透過通訊軟體追問 JSON 欄位的格式。
比喻三：Amazon EventBridge 封存與重播如同 DVR 加上時光機按鈕
想像電視上的 DVR。它錄下某個頻道播出的所有節目，你可以在幾週後倒帶、暫停或重播。Amazon EventBridge 封存（archive）就是 Amazon EventBridge 匯流排的 DVR。啟用後設定保留期限（1 天到無限期），Amazon EventBridge 就會靜靜地擷取所有符合可選過濾條件的事件。如果你的消費者 Lambda 有 bug，錯誤處理了三天的 OrderPlaced 事件，你部署修復後，執行一次 Amazon EventBridge 重播（replay），將那三天的封存事件重新傳回匯流排 — Amazon EventBridge 目標收到這些事件，就像是即時發生的一樣。這是事件驅動架構的時光機除錯工具，Amazon SNS 和 Amazon SQS 都不具備這項功能。
比喻四：Amazon EventBridge Pipes 如同已組裝好的廚房家電
在 Amazon EventBridge Pipes 出現之前，要將 SQS 訊息佇列接到 Step Functions 工作流程，必須撰寫一個中間的 Lambda — 輪詢訊息佇列、解析訊息、啟動執行、處理錯誤。你等於是用零散的馬達零件自組一台食物調理機。Amazon EventBridge Pipes 是已組裝好的家電：一端是來源（SQS、Kinesis、DynamoDB Streams、MSK、MQ、自管 Kafka），中間可選過濾、可選豐富化（Lambda、Step Functions、API destination、API Gateway），另一端是目標（任何 Amazon EventBridge 目標）。零膠水程式碼。插上電，按下按鈕，食物就出來了。這就是 Amazon EventBridge Pipes。
Amazon EventBridge 事件匯流排深度解析
Amazon EventBridge 匯流排是事件存在的地方。一個 Region 擁有一條預設 Amazon EventBridge 匯流排、零條或多條自訂 Amazon EventBridge 匯流排，以及每個已啟用 SaaS 合作夥伴整合對應一條合作夥伴匯流排。每個 Amazon EventBridge 事件在同一時間只屬於一條匯流排，但跨帳號與跨 Region 的轉發可以在匯流排之間移動事件。
預設匯流排
大多數 AWS 服務會自動將事件發送至各 Region 的預設 Amazon EventBridge 匯流排。如果你想對 EC2 執行個體狀態變更、S3 物件建立（在 bucket 上啟用後）、CodeBuild 建置階段變更、CodePipeline 階段轉換、Health 事件或 AWS Config 規則評估作出反應，你只需在預設 Amazon EventBridge 匯流排上撰寫一條模式如 {"source": ["aws.s3"], "detail-type": ["Object Created"]} 的規則。AWS 服務發送至預設匯流排的事件不計費，這是大多數「對 AWS 服務反應」情境的入口。
自訂匯流排
當你的應用程式需要發布自己的業務事件時，你可以建立一條自訂 Amazon EventBridge 匯流排，例如命名為 orders-prod。你的結帳服務呼叫 PutEvents，帶入 source: com.example.orders、detail-type: OrderPlaced，以及包含訂單 ID、客戶 ID 和總金額的 detail 酬載。在 orders-prod 上的消費者撰寫 Amazon EventBridge 規則，依據 source 和 detail-type 過濾，只接收自己關心的事件。自訂 Amazon EventBridge 匯流排讓你的領域事件與 AWS 服務的事件隔離，並可套用自己的資源政策，讓 IAM 權限更清晰。
合作夥伴匯流排
合作夥伴匯流排接收來自已與 Amazon EventBridge 整合的外部 SaaS 應用程式的事件。建立合作夥伴事件來源訂閱後（每個合作夥伴、每個帳號、每個 Region 做一次），Amazon EventBridge 會為你建立一條合作夥伴匯流排，例如 aws.partner/zendesk.com/account/ticket-events。你可在該合作夥伴匯流排上撰寫 Amazon EventBridge 規則，對 Zendesk 票券、PagerDuty 事件、Datadog 警報、Shopify 訂單等作出反應。對於 SaaS 密集型工作負載，合作夥伴匯流排正是 Amazon EventBridge 勝過 Amazon SNS 的關鍵原因。
跨帳號與跨 Region 路由
一條 Amazon EventBridge 匯流排可以作為另一條 Amazon EventBridge 匯流排的目標 — 無論是同帳號（自訂匯流排 → 自訂匯流排）、不同帳號（透過資源政策），或不同 Region（透過跨 Region 目標）。常見模式：每個 AWS 帳號將本地事件發布至自己的自訂匯流排，再由一條規則將特定事件轉發至安全帳號中的集中稽核匯流排。跨帳號 Amazon EventBridge 路由是取代自訂 SNS 跨帳號主題的現代方案，在 DVA-C02 的多帳號架構題型中反覆出現。
Amazon EventBridge 規則與事件模式
一條 Amazon EventBridge 規則有三個部分：它所在的匯流排、一個事件模式（或排程，但現代排程應交給 EventBridge Scheduler — 詳見後文），以及最多五個目標。當事件抵達 Amazon EventBridge 匯流排時，服務會平行對所有已啟用規則的模式進行測試；每條符合的規則都會觸發，該規則上的每個目標都會收到一份事件副本。
事件模式語法
Amazon EventBridge 事件模式是一份 JSON 文件，其結構映射事件的形狀。要符合比對，模式中的每個頂層欄位都必須與事件中對應的欄位相符。值以陣列表示 — 只要事件的值存在於陣列中，規則即符合。一個最簡單的模式：
{
"source": ["com.example.orders"],
"detail-type": ["OrderPlaced"]
}
Amazon EventBridge 支援內容過濾器（content filters）以實現更豐富的比對：
- 前綴比對（Prefix matching） —
"region": [{"prefix": "us-"}] - 後綴比對（Suffix matching） —
"detail-type": [{"suffix": "Created"}] - 排除比對（Anything-but） —
"source": [{"anything-but": ["aws.autoscaling"]}] - 數值比對（Numeric matching） —
"detail": {"amount": [{"numeric": [">", 1000]}]} - 存在性比對（Exists） —
"detail": {"customerId": [{"exists": true}]} - IP 位址比對（IP address） —
"detail": {"ip": [{"cidr": "10.0.0.0/8"}]} - 忽略大小寫相等（Equals-ignore-case） —
"detail": {"status": [{"equals-ignore-case": "failed"}]} - 萬用字元（Wildcard） —
"detail": {"path": [{"wildcard": "/orders/*/refund"}]}
這些 Amazon EventBridge 內容過濾器遠比 Amazon SNS 訊息過濾政策（message filter policies）更具表達力；SNS 只支援字串與數值的相等／範圍比對，加上 exists 和 anything-but。
Amazon EventBridge 目標 — 30 多種目的地
Amazon EventBridge 可直接呼叫超過三十種目標類型，無需膠水 Lambda。DVA-C02 最重要的幾個：
- AWS Lambda function — 以事件作為酬載呼叫。最常見的目標。
- Amazon SQS queue（標準與 FIFO）— 耐久地將工作交給工作節點群。
- Amazon SNS topic — 在 Amazon EventBridge 路由後進行廣播。
- AWS Step Functions state machine — 啟動一個工作流程執行。
- Amazon ECS task — 執行容器化的工作。
- Amazon Kinesis Data Streams / Firehose — 串流至分析系統。
- 另一個帳號或 Region 的 Amazon EventBridge bus — 跨邊界轉發。
- API destination — 具備 OAuth／API key 連線與內建重試及速率限制的 HTTPS 端點。
- Amazon SageMaker pipeline、AWS Batch job、CodeBuild project、CodePipeline execution、Systems Manager Run Command 和 Automation、Redshift cluster data API、EC2 instance CreateSnapshot 等等。
每個 Amazon EventBridge 目標都可以有自己的輸入轉換器（input transformer），將事件重塑為目標所需的確切 JSON 格式，以及自己的 DLQ（一個 SQS 訊息佇列），用來捕捉 Amazon EventBridge 重試後仍無法傳遞的事件。
規則評估限制
Amazon EventBridge 以平行方式將事件與匯流排上的所有規則比對，因此增加更多規則不會減慢事件傳遞速度 — 這是與基於輪詢的 Amazon SQS 架構的一個關鍵操作差異。單一 Amazon EventBridge 規則最多可有 5 個目標。帳號層級的預設配額為每條匯流排 300 條規則，但這是軟性配額，可向 AWS 申請提高。
Amazon EventBridge Schema Registry 與自動探索
Amazon EventBridge Schema Registry 是最能將 Amazon EventBridge 與 Amazon SNS 區分開來的功能。它是一個帶有程式碼繫結產生功能的事件 schema 版本化目錄，在 DVA-C02 中，它是所有「確保跨團隊發布事件時的型別安全」問題的答案。
Amazon EventBridge Schema Registry 的運作方式
Amazon EventBridge 中的 schema 是一份 OpenAPI 3 或 JSONSchema 描述，說明事件類型中有哪些欄位、其型別，以及是否為必填。Amazon EventBridge 將 schema 組織成registries。AWS 維護一個內建的 registry aws.events，包含所有 AWS 服務事件的 schema。你也可以為自己的事件類型建立自訂 registry。
自動探索（Auto-Discovery）
在 Amazon EventBridge 匯流排上開啟 schema discovery，Amazon EventBridge 就會監看事件約五分鐘，推斷每個不同 source + detail-type 組合的 JSON 結構，並將 schema 寫入 discovered-schemas registry。當新欄位出現或現有欄位的型別改變時，Amazon EventBridge 會自動建立新的 schema 版本。你再也不需要手動維護事件 wiki。
程式碼繫結（Code Bindings）
從任何 schema，Amazon EventBridge 都能為 Java、Python、TypeScript、Go、C#/.NET 產生可下載的程式碼繫結。開發者執行 aws schemas get-code-binding-source 即可取得該事件類型的即用類別。IntelliSense 現在可以自動補全 event.detail.orderId，編譯器也會在建置時拒絕 event.detail.orderld（小寫 L 與小寫 I 的拼字錯誤）。AWS Toolkit for IntelliJ、PyCharm、VS Code 和 Visual Studio 可直接從 IDE 下載 Amazon EventBridge 程式碼繫結。
對 DVA-C02 的重要性
任何考試情境提及「多個團隊發布和消費共享事件需要一份合約」、「下游服務在生產者新增欄位後不斷崩潰」，或「在 IDE 中產生強型別事件類別」，都指向 Amazon EventBridge Schema Registry。Amazon SNS 和 Amazon SQS 沒有類似的功能 — 它們將酬載視為不透明的字串。
Amazon EventBridge 封存與重播
Amazon EventBridge 封存與重播是 Amazon SNS 和 Amazon SQS 根本不具備的第二項功能。這就是 DVR 加時光機比喻的實現。
建立 Amazon EventBridge 封存
你可以在特定的 Amazon EventBridge 匯流排上建立封存。封存設定包含：
- 保留期限 — 1 天到無限期。
- 可選的事件模式 — 只有符合此模式的事件才會被封存，讓你只封存
OrderPlaced事件，跳過大量的心跳事件。 - KMS 加密（預設 AWS 管理金鑰或客戶管理的 CMK）。
啟用後，Amazon EventBridge 封存會靜靜地擷取所有符合條件的事件。封存依照儲存的 GB 數計費。
重播封存事件
**重播（replay）**在選定的時間窗口內，將封存的事件重新傳送回 Amazon EventBridge 匯流排。你選擇一個封存、一個開始和結束時間，以及可選的要重新觸發的規則子集（你可以只重播至一條規則，讓其他規則不受影響）。Amazon EventBridge 的重播速率最高可達封存時的擷取速率。
重播是以下考試情境的正確答案：
- 「下游 Lambda 有一個 bug，持續 48 小時；你要如何重新處理它錯誤處理的事件？」— Amazon EventBridge 重播。
- 「你需要用 30 天的歷史事件為新的分析管道播種。」— Amazon EventBridge 重播。
- 「稽核要求：重現導致這次停機的確切事件序列。」— Amazon EventBridge 重播。
重播的事件帶有一個標記（事件元資料中的 replay-name），讓目標程式碼在需要時可以對重播事件有不同的行為（例如，在重播時跳過發送客戶電子郵件）。
Amazon EventBridge Scheduler — Cron 的替代品
歷史上，Amazon EventBridge 允許你使用 cron 或 rate 表達式建立排程規則，定時向目標觸發事件。該功能仍為了向後相容而存在，但 AWS 在 2022 年底將排程功能抽出為一個獨立服務，稱為 Amazon EventBridge Scheduler，DVA-C02 期望你了解它。
EventBridge Scheduler 存在的原因
Amazon EventBridge 上的排程規則有實際限制：每個帳號最多 300 個排程（受匯流排規則配額限制）、無法一次性排程、目標類型有限，也沒有內建的重試政策調整。Amazon EventBridge Scheduler 移除了所有這些限制：
- 每個帳號可建立數百萬個排程（相較於規則的數百個）。
- 使用
at(2026-12-25T09:00:00)表達式的一次性排程 — 不再需要「建立規則、觸發一次、刪除規則」的繁瑣流程。 - **彈性時間窗口（Flexible time windows）**讓 Amazon EventBridge Scheduler 在窗口內任選一分鐘觸發，以分散負載。
- 支援日光節約時間的時區 —
cron(0 9 * * ? *)在America/New_York時區實際上在紐約時間上午 9 點執行。 - 每個排程的重試政策和 DLQ。
- 透過 AWS SDK 通用目標機制支援超過 270 種目標類型。
排程類型
Amazon EventBridge Scheduler 支援三種表達式類型：
- Rate —
rate(5 minutes)、rate(1 hour)、rate(7 days)。 - Cron — 標準的六欄位 cron，加上時區。
- 一次性（One-time） —
at(yyyy-mm-ddThh:mm:ss)，用於一次性觸發排程。
目標與輸入
每個 Amazon EventBridge Scheduler 排程指向一個目標，並可傳入固定的 JSON 輸入。Lambda、SQS、SNS、Step Functions、ECS RunTask、EventBridge PutEvents 以及任何 AWS SDK 呼叫都是有效的目標。
值得記住的考試情境
- 「每週日紐約時間凌晨 3 點執行清理 Lambda」→ Amazon EventBridge Scheduler cron 加時區。
- 「在使用者操作後整整一小時排程一封提醒郵件」→ Amazon EventBridge Scheduler 一次性排程。
- 「每天為各客戶觸發 50,000 個排程」→ Amazon EventBridge Scheduler（而非排程規則）。
- 「在 30 分鐘窗口內分散發票處理以避免驚群效應」→ Amazon EventBridge Scheduler 彈性時間窗口。
Amazon EventBridge Pipes — 生產者到目標，無需膠水程式碼
Amazon EventBridge Pipes 是 V2.1 考綱提升地位的第四項 Amazon EventBridge 功能。一個 Pipe 是點對點整合：一個來源（source） → 可選過濾（filter） → 可選豐富化（enrichment） → 一個目標（target）。
Pipes 來源
Amazon EventBridge Pipes 的來源是輪詢型來源，之前需要 Lambda 事件來源映射或自訂消費者：
- Amazon SQS 訊息佇列。
- Amazon Kinesis Data Streams。
- Amazon DynamoDB Streams。
- Amazon MSK（Managed Streaming for Kafka）和自管 Apache Kafka。
- Amazon MQ brokers（ActiveMQ 和 RabbitMQ）。
Pipes 過濾
過濾使用與 Amazon EventBridge 規則相同的模式語法，只有符合條件的訊息才會繼續流經管道。過濾發生在管道向你計算豐富化或目標呼叫費用之前 — 設計上就具有成本效益。
Pipes 豐富化
可選的豐富化步驟會呼叫一個豐富化目標，在訊息到達最終目標之前對其進行轉換或擴充：
- AWS Lambda — 任意程式碼。
- AWS Step Functions（僅 Express 工作流程）— 短暫的協調流程。
- Amazon API Gateway — 呼叫你自己的 HTTP 端點。
- Amazon EventBridge API destinations — 使用身份驗證呼叫第三方 HTTPS 端點。
Pipes 目標
Pipes 目標與 Amazon EventBridge 規則目標相同 — Lambda、Step Functions、SQS、SNS、Kinesis、Firehose、ECS、EventBridge bus、API destination 等等。
何時使用 Amazon EventBridge Pipes
DVA-C02 中最清楚的 Amazon EventBridge Pipes 情境：「你有一個 SQS 訊息佇列，接著一個 Lambda 負責過濾訊息、呼叫內部 API 豐富化訊息，然後啟動一個 Step Functions 工作流程。」沒有 Amazon EventBridge Pipes 的話，那是一個身兼三職的 Lambda 和一堆警報。有了 Amazon EventBridge Pipes，就是一個具備過濾 + 豐富化 + 目標的受管 Pipe — 無需維護任何 Lambda 程式碼。
Amazon SNS — 大規模的簡單 Pub/Sub
Amazon SNS 仍然在 DVA-C02 考試範圍內 — 但它的角色已縮小為「在不需要 Amazon EventBridge 功能的前提下，以極高吞吐量進行簡單扇出」。將 Amazon SNS 理解為 Amazon EventBridge 的對比，是回答「SNS 還是 EventBridge？」問題的最快方法。
Amazon SNS 主題（Topics）
Amazon SNS 主題是一個 pub/sub 通道。發布者呼叫 Publish，帶入訊息和可選屬性。訂閱者可以是 SQS 訊息佇列、Lambda 函式、HTTPS 端點、電子郵件地址、SMS 號碼、行動推播端點（APNs、FCM）、Kinesis Data Firehose 串流，或另一個 AWS 帳號的資源。發布至 Amazon SNS 主題的一則訊息會平行扇出至每個訂閱者 — 這就是扇出的定義。
Amazon SNS 支援兩種主題類型：
- 標準主題（Standard topics） — 至少一次傳遞、盡力排序、幾乎無限的吞吐量，支援所有訂閱者類型。
- FIFO 主題（FIFO topics） — 精確一次傳遞、每個訊息群組嚴格排序，每秒最多 300 次發布（或 3,000 次帶批次），訂閱者限制為 SQS FIFO 訊息佇列。
Amazon SNS 訊息過濾
Amazon SNS 訂閱過濾政策（subscription filter policies）讓每個訂閱者根據訊息屬性（或使用基於酬載的過濾時，根據 JSON 本文）只接收主題訊息的子集。運算子包括字串相等、前綴、anything-but、數值範圍、exists 和 CIDR。重要：Amazon SNS 過濾政策比 Amazon EventBridge 事件模式更簡單 — 沒有後綴、沒有萬用字元、沒有 equals-ignore-case。如果情境需要其中任何一種，就是 Amazon EventBridge 的情境。
Amazon SNS 扇出至 Amazon SQS
經典模式：發布者 → Amazon SNS 主題 → 多個 Amazon SQS 訊息佇列，每個下游微服務一個。每個微服務以自己的步調輪詢自己的訊息佇列，並有自己的 DLQ 和可見性逾時。這種模式解耦了生產者與消費者，當情境強調耐久性、獨立的消費者步調，以及「每個消費者都能收到每則訊息」時，在 DVA-C02 上仍是正確答案。若情境強調基於內容的路由、schema 或重播，則切換至 Amazon EventBridge。
Amazon SNS 仍勝過 Amazon EventBridge 的情況
- 行動推播、SMS、電子郵件 — Amazon EventBridge 無法傳遞至這些通道。Amazon SNS 是唯一選項。
- 最高原始吞吐量且成本最低 — Amazon SNS 標準主題每百萬次發布收費 0.50 美元；Amazon EventBridge 自訂匯流排每百萬筆收費 1.00 美元。在每月數十億事件的規模下，差額相當可觀。
- 超簡單扇出 — 每個訂閱者都收到每則訊息，無需過濾，無需 Schema Registry。Amazon SNS 更簡單。
Amazon SQS — 耐久的訊息佇列
Amazon SQS 是 AWS 最古老的整合服務，仍然是耐久解耦訊息佇列的正確答案。在 DVA-C02 上，考試特別測驗四個 Amazon SQS 機制：可見性逾時（visibility timeout）、無效信件佇列（dead-letter queues）、長輪詢（long polling），以及標準佇列與 FIFO 佇列的選擇。
Amazon SQS 標準佇列與 FIFO 佇列
- 標準佇列（Standard queues） — 至少一次傳遞、盡力排序、無限吞吐量。重複和亂序傳遞是可能的，你的消費者必須具備冪等性。
- FIFO 佇列（FIFO queues） — 精確一次處理（5 分鐘去重視窗）、每個訊息群組嚴格 FIFO 排序，帶批次每秒最多 3,000 則訊息（不帶批次則為 300 則）。當順序至關重要或重複訊息是災難性問題時使用。
Amazon SQS 可見性逾時（Visibility Timeout）
當消費者呼叫 ReceiveMessage 時，Amazon SQS 會在可見性逾時期間（預設 30 秒，最長 12 小時）對其他消費者隱藏該訊息。消費者必須在逾時過期前呼叫 DeleteMessage；否則訊息將再次變為可見，另一個消費者可能會取走它 — 此時第一個消費者也可能完成處理，導致同一則訊息被處理兩次。將可見性逾時調整為「比最壞情況處理時間略長一點」是開發者的責任。對於耗時較長的工作，可呼叫 ChangeMessageVisibility 延長鎖定時間。
Amazon SQS 無效信件佇列（DLQ）
DLQ 是一個獨立的 Amazon SQS 訊息佇列，接收來源佇列在超過 maxReceiveCount 次嘗試後仍無法處理的訊息。DLQ 讓你在不遺失訊息的情況下檢查有問題的訊息，並防止單一壞訊息永遠阻塞訊息佇列。在生產 Amazon SQS 訊息佇列上務必設定 DLQ — 這是每個考試週期都會出現的 DVA-C02 最佳實踐題。DLQ 的類型必須與來源訊息佇列相符（FIFO 來源 → FIFO DLQ）。
Amazon SQS 長輪詢（Long Polling）
Amazon SQS 支援短輪詢（預設 — ReceiveMessage 立即返回，可能沒有任何訊息）和長輪詢（WaitTimeSeconds 1–20；呼叫最多等待指定秒數直到訊息到達）。長輪詢減少了空回應，降低了 API 成本，並減少了消費者 CPU 浪費。在訊息佇列層級（ReceiveMessageWaitTimeSeconds）或每次請求設定長輪詢。考試規則：「降低輪詢成本」→ 長輪詢。
Amazon SQS 與 Amazon EventBridge 的整合
Amazon SQS 是 Amazon EventBridge 最常見的目標之一。模式：Amazon EventBridge 規則比對事件，將其路由至 SQS 訊息佇列，下游消費者（Lambda、ECS）從訊息佇列處理，並有自己的可見性逾時和 DLQ。Amazon SQS 也作為 Amazon EventBridge 的目標 DLQ 出現 — 當 Amazon EventBridge 在重試後仍無法將事件傳遞至目標時，它會將該事件丟入設定好的 Amazon SQS DLQ。
AWS Step Functions — 含重試的流程協調
AWS Step Functions 是 DVA-C02 情境描述「多步驟工作流程」、「失敗時重試」、「等待人工審核」、「平行分支」或「長時間執行的流程」時的正確答案。Amazon EventBridge 路由事件；AWS Step Functions 協調流程。
標準工作流程與 Express 工作流程
- 標準工作流程（Standard workflows） — 最長 1 年、精確一次執行、完整執行歷史記錄於 CloudWatch Logs，每秒最多啟動 2,000 次執行。最適合業務流程、訂單履行、人工審核。
- Express 工作流程（Express workflows） — 最長 5 分鐘、至少一次執行、極高吞吐量（每秒 100,000 次執行），除非明確記錄否則歷史記錄極少。最適合高量事件處理、IoT 管道、串流轉換。
Amazon States Language（ASL）
工作流程以 ASL 定義，這是一種基於 JSON 的 DSL。核心狀態類型：
- Task — 執行工作（呼叫 Lambda、執行 ECS task、呼叫 AWS SDK、呼叫 API destination）。
- Choice — 根據輸入欄位分支。
- Parallel — 同時執行多個分支，等待全部完成。
- Map — 對陣列進行迭代，可選擇平行執行（Distributed Map 模式支援最多 10,000 個同時執行，可處理 S3 中多達 1 億個項目）。
- Wait — 暫停一段時間或直到某個時間戳記。
- Pass — 空操作（用於測試、資料重塑）。
- Succeed / Fail — 終止狀態。
錯誤處理 — Retry 與 Catch
每個 Task 和 Parallel 狀態都可以宣告：
- Retry — 錯誤匹配器清單，每個匹配器帶有退避策略、最大嘗試次數和抖動。例如：對
States.Timeout最多重試 3 次，初始間隔 2 秒，退避係數 2.0。 - Catch — 錯誤匹配器清單，在失敗時將執行路由至備用狀態。例如：捕捉
CustomError.InsufficientFunds並轉換至SendApologyEmail狀態。
這個內建的 retry/catch 正是 Step Functions 勝過「用 SQS 串連 Lambda」的原因。你無需撰寫重試迴圈就能獲得宣告式的錯誤處理，且每次重試都清晰可見於執行歷史中。
服務整合與 .sync / .waitForTaskToken
Step Functions 透過優化整合（optimized integrations，例如 arn:aws:states:::lambda:invoke 的捷徑 ARN）與 200 多個 AWS 服務原生整合。DVA-C02 重要的兩種特殊呼叫模式：
- .sync — Step Functions 呼叫服務並等待其完成。例如：
arn:aws:states:::ecs:runTask.sync執行一個 ECS task 並在任務結束後才進行下一個狀態。 - .waitForTaskToken — Step Functions 暫停執行並發出一個task token；下游程式碼（人工審核 UI、外部系統、另一個 Lambda）呼叫
SendTaskSuccess或SendTaskFailure並帶上該 token 以恢復工作流程。這是人工審核和回呼式整合的經典模式。
Step Functions 作為 Amazon EventBridge 目標
Amazon EventBridge 規則可以直接將 Step Functions 狀態機作為目標啟動。事件成為工作流程的輸入。這是 DVA-C02 的乾淨模式：Amazon EventBridge 處理路由，Step Functions 處理多步驟邏輯。中間不需要 Lambda。
Amazon EventBridge vs SNS vs SQS vs Step Functions — 決策樹
以下是 DVA-C02 期望你在每道應用程式整合題上套用的決策樹。
步驟一 — 是事件還是訊息？
- 事件（某件事發生了；接收者自行決定要做什麼）→ Amazon EventBridge 或 Amazon SNS。
- 訊息（有工作要做；接收者是特定的）→ Amazon SQS。
- 多步驟流程（有狀態的一系列動作）→ AWS Step Functions。
步驟二 — 事件路徑：你需要過濾、Schema、重播或 SaaS 來源嗎？
- 需要其中任何一項 → Amazon EventBridge。
- 不需要，只要以高吞吐量扇出至多個訂閱者 → Amazon SNS。
- 需要行動推播 / SMS / 電子郵件傳遞 → Amazon SNS（Amazon EventBridge 無法做到）。
步驟三 — 訊息路徑：順序和重複訊息是否至關重要？
- 是，嚴格順序且不允許重複 → Amazon SQS FIFO。
- 否，吞吐量更重要 → Amazon SQS 標準。
- 不撰寫 Lambda 膠水程式碼就將 SQS 連接至目標 → Amazon EventBridge Pipes。
步驟四 — 工作流程路徑：需要多長時間、多快的速度？
- 最長 1 年、精確一次、符合稽核要求 → Step Functions 標準。
- 5 分鐘內、極高吞吐量 → Step Functions Express。
- 需要人工審核步驟 → Step Functions .waitForTaskToken。
步驟五 — 排程
- Cron 風格或一次性排程 → Amazon EventBridge Scheduler。
- 「每 5 分鐘」的輪詢式排程規則 → 仍然可行，但新建設應優先使用 Amazon EventBridge Scheduler。
跨帳號 Amazon EventBridge 路由深度解析
多帳號架構在 DVA-C02 中很常見。Amazon EventBridge 支援兩種跨帳號路由方式：授予另一個帳號權限以將事件發送至你的匯流排，或從你的匯流排中的規則以另一個帳號的匯流排作為目標。
模式 A — 遠端帳號將事件發送至你的匯流排
在你的 Amazon EventBridge 自訂匯流排上附加一個資源政策，授予遠端帳號的主體 events:PutEvents 權限。遠端帳號呼叫 PutEvents，並將 EventBusName 設為你的匯流排 ARN。你的規則接著正常處理這些事件。
模式 B — 你的規則以另一個帳號的匯流排為目標
帳號 A 中的規則將帳號 B 中的 Amazon EventBridge 匯流排列為其目標。帳號 B 的匯流排必須有允許帳號 A 的規則角色呼叫 events:PutEvents 的資源政策。帳號 A 的規則需要一個 IAM 角色，讓 Amazon EventBridge 可以假設該角色跨帳號呼叫 PutEvents。
典型使用案例：每個工作負載帳號將本地事件發布至自己的自訂匯流排；在一個專用帳號中的集中安全/稽核匯流排透過跨帳號規則接收轉發副本，以供合規性和可觀測性使用。
整合模式與範例
三個 DVA-C02 經典整合模式將所有內容整合在一起。
模式一 — 訂單成立透過 Amazon EventBridge 扇出
結帳服務在自訂匯流排 orders-prod 上呼叫 PutEvents，帶入 source: com.example.orders、detail-type: OrderPlaced。該匯流排上的規則：
- 規則「notify-customer」— 目標 Lambda 發送確認電子郵件。
- 規則「charge-payment」— 目標 Step Functions 標準工作流程，呼叫付款供應商並帶重試/捕捉。
- 規則「analytics」— 目標 Kinesis Data Firehose，傳送至 S3。
- 規則「audit」— 目標安全帳號中的 Amazon EventBridge 匯流排。
Amazon EventBridge Schema Registry 自動探索 OrderPlaced schema，並將程式碼繫結提供給每個團隊。封存功能將 OrderPlaced 事件保留 90 天，讓工程師在下游服務發生 bug 時可以重播。
模式二 — SQS 透過 Amazon EventBridge Pipes 接至 Step Functions
入站 Webhook 處理程式將工作項目寫入 Amazon SQS 訊息佇列。一個 Pipe 以訊息佇列為來源，用事件模式過濾掉心跳訊息，透過 API destination 呼叫內部定價 API 豐富化每個工作項目，然後以 Step Functions Express 工作流程執行實際工作作為目標。零膠水 Lambda，過濾 + 豐富化 + 目標全部宣告式設定。
模式三 — 使用 Amazon EventBridge Scheduler 的排程清理
排程 cron(0 3 ? * SUN *) 在時區 America/Los_Angeles 設定為每週日太平洋時間凌晨 3 點觸發，目標是一個 Step Functions 標準工作流程，該工作流程在 12 個微服務資料庫中平行刪除過期 Session，並帶有每分支的錯誤處理。排程有自己的重試政策和 SQS DLQ 以應對失敗。
DVA-C02 常見陷阱
陷阱一 — 假設 Amazon SNS 等同於 Amazon EventBridge
Amazon SNS 提供 pub/sub；Amazon EventBridge 提供 pub/sub 加上 Schema、封存/重播、SaaS 合作夥伴事件擷取、帶萬用字元的內容過濾器、API destinations 和 Scheduler。任何提及 Schema、重播、SaaS 來源或 API destination 的情境都是 Amazon EventBridge，而非 Amazon SNS。
陷阱二 — 忘記 Amazon SQS 長輪詢
「降低輪詢成本」永遠是長輪詢。短輪詢消耗金錢和 CPU。除非有特殊理由，否則在生產 Amazon SQS 消費者上將 ReceiveMessageWaitTimeSeconds 設為 20。
陷阱三 — 用 Lambda 鏈取代 Step Functions
如果情境描述三個 Lambda 相互呼叫並帶有錯誤處理，正確答案是 AWS Step Functions，而非「在每個 Lambda 之間放 SQS」。Step Functions 提供宣告式重試/捕捉、完整執行歷史和視覺化除錯。
陷阱四 — 混淆 Amazon EventBridge 規則與 Amazon EventBridge Pipes
規則是推送型的，存在於匯流排上；Pipes 是輪詢型的，將單一來源（SQS、Kinesis、DynamoDB Streams、MSK、MQ）連接至單一目標。
陷阱五 — 使用排程規則而非 Amazon EventBridge Scheduler
排程規則仍然有效，但 Amazon EventBridge Scheduler 支援數百萬個排程、一次性排程、彈性時間窗口、時區和 270 多種目標。新建設應使用 Amazon EventBridge Scheduler。
陷阱六 — 忘記設定 DLQ
每個 Amazon EventBridge 目標、每個 Amazon SQS 訊息佇列，以及每個 EventBridge Pipes 目標在生產環境中都應設定 DLQ。DVA-C02 很愛考「為什麼這些事件遺失了？」的情境，正確答案是「設定 DLQ」。
陷阱七 — 混淆可見性逾時與訊息保留期限
可見性逾時是訊息在 ReceiveMessage 後被隱藏的時間（最長 12 小時）。訊息保留期限是未處理的訊息在訊息佇列中停留的時間（1 分鐘到 14 天）。兩者是無關的數字。
必記數字與限制
- Amazon EventBridge PutEvents 每筆事件最大尺寸：256 KB。
- Amazon EventBridge 每條規則最多目標數：5 個。
- Amazon EventBridge 預設配額：每條匯流排 300 條規則（軟性限制）。
- Amazon EventBridge Scheduler：每個帳號數百萬個排程。
- Amazon EventBridge 封存保留期限：1 天到無限期。
- Amazon SQS 訊息大小：256 KB（使用 Extended Client Library 搭配 S3 最高可達 2 GB）。
- Amazon SQS 保留期限：1 分鐘到 14 天（預設 4 天）。
- Amazon SQS 可見性逾時：0 秒到 12 小時（預設 30 秒）。
- Amazon SQS 長輪詢最大等待時間：20 秒。
- Amazon SQS FIFO 吞吐量：不帶批次 300 msg/s，帶批次 3,000 msg/s。
- Amazon SNS 標準發布速率：實際上無限制；FIFO：300/s（帶批次 3,000/s）。
- Step Functions 標準工作流程最長時間：最長 1 年；Express：最長 5 分鐘。
- Step Functions Distributed Map：最多 10,000 個同時子執行，最多 1 億個 S3 項目。
成本模型快速參考
- Amazon EventBridge 自訂/合作夥伴匯流排：每百萬筆事件發布 $1.00。
- Amazon EventBridge 預設匯流排：AWS 服務事件免費；跨 Region 和 API destination 呼叫仍需收費。
- Amazon EventBridge Scheduler：每百萬次排程呼叫 $1.00。
- Amazon EventBridge Pipes：每百萬則訊息處理 $0.40。
- Amazon SNS 標準：每百萬次發布 $0.50。
- Amazon SQS 標準：每百萬次請求 $0.40。
- AWS Step Functions 標準：每 1,000 次狀態轉換 $0.025。
- AWS Step Functions Express：依執行次數計費，費用依持續時間和記憶體計算。
確切數字會變動 — 理解規律更重要：Amazon EventBridge 每筆事件的成本高於 Amazon SNS，但 Amazon EventBridge 取代了你原本需要付費的 Lambda 膠水程式碼，因此總體持有成本往往對 Amazon EventBridge 有利。
常見問題
Q1：我應該在什麼情況下選擇 Amazon EventBridge 而非 Amazon SNS？
當情境需要基於事件屬性的內容路由、透過 Amazon EventBridge Schema Registry 進行 schema 驗證、事件封存與重播、SaaS 合作夥伴事件來源（Zendesk、Datadog、PagerDuty、Shopify），或用於對外 HTTPS 呼叫的 API destinations 時，請選擇 Amazon EventBridge。當訂閱者包含行動推播、SMS 或電子郵件，或情境強調以最高吞吐量進行簡單扇出時，請選擇 Amazon SNS — Amazon EventBridge 無法直接傳遞至那些通道。在 DVA-C02 上，現代預設答案是 Amazon EventBridge，除非情境明確指名 Amazon SNS 專屬通道，或強調在數兆事件規模下的原始成本/吞吐量。
Q2：Amazon EventBridge Pipes 與 Amazon EventBridge 規則有何不同？
Amazon EventBridge 規則是推送型的，存在於 Amazon EventBridge 匯流排上 — 生產者呼叫 PutEvents，規則對已發布的事件評估事件模式，並將符合者傳送至最多五個目標。Amazon EventBridge Pipes 是輪詢型的 — Pipe 持續輪詢單一來源（Amazon SQS、Kinesis Data Streams、DynamoDB Streams、Amazon MSK、自管 Kafka 或 Amazon MQ），可選過濾和豐富化訊息，然後將每則訊息傳送至單一目標。規則用於事件匯流排架構；Pipes 用於在不撰寫 Lambda 膠水程式碼的情況下，將串流和訊息佇列來源連接至目標。
Q3：Amazon EventBridge Scheduler 與排程規則有何差異？
兩者都能以 cron 或 rate 表達式觸發目標。Amazon EventBridge Scheduler 是較新的專用服務，具有顯著優勢：每個帳號可建立數百萬個排程（規則受每條匯流排數百個的上限限制）、使用 at(...) 表達式的一次性排程、可在時間窗口內分散負載的彈性時間窗口、具備日光節約時間處理的時區感知 cron、每個排程的重試和 DLQ 政策，以及透過通用目標機制支援 270 多種目標類型。新建設應使用 Amazon EventBridge Scheduler；排程規則為了向後相容而保留。在 DVA-C02 上，強調「數百萬個排程」、「一次性提醒」、「時區」或「彈性窗口」的情境始終指向 Amazon EventBridge Scheduler。
Q4：Amazon EventBridge 封存與重播如何運作，它們不具備什麼能力？
Amazon EventBridge 封存在設定的保留期限內（1 天到無限期）捕捉特定匯流排上符合可選模式的事件，並使用 KMS 加密。重播在選定的時間窗口內，將封存的事件重新傳送至匯流排上選定的一條或多條規則。重播用於在 bug 修復後重新處理事件、為新消費者播種歷史資料，或重現事故。重播不是目標狀態的備份，不是在傳輸中修改事件的方式，也不適用於 Amazon SNS 或 Amazon SQS。重播的事件帶有 replay-name 標記，讓目標程式碼能偵測到它們。
Q5：我應該在什麼情況下使用 AWS Step Functions 而非 Amazon EventBridge？
Amazon EventBridge 根據規則將事件路由至目標 — 它是無狀態路由。AWS Step Functions 執行一個有狀態的多步驟工作流程，包含分支、平行區段、重試、捕捉和可選的人工審核（透過 task token）。如果情境是「事件發生，呼叫一個或幾個目標」，請使用 Amazon EventBridge。如果情境是「協調 5 個 Lambda、等待人工審核、重試付款步驟 3 次，且最長執行一週」，請使用 AWS Step Functions。實際上你會組合使用兩者：Amazon EventBridge 路由事件，其中一個目標是執行實際工作流程的 Step Functions 狀態機。
Q6：如何在 Amazon EventBridge 中處理失敗？
Amazon EventBridge 預設以指數退避方式重試目標呼叫最長 24 小時。如果所有重試均失敗，Amazon EventBridge 會丟棄該事件，除非你在目標上設定了無效信件佇列（一個 Amazon SQS 訊息佇列）。務必在生產 Amazon EventBridge 目標上設定 DLQ。對於 Amazon EventBridge Pipes，來源輪詢和目標呼叫都支援重試政策和 DLQ。對於排程規則和 Amazon EventBridge Scheduler，需設定每個排程的重試和 DLQ。結合 AWS Step Functions 在每個 task 狀態上的重試/捕捉，可在整個整合流程中實現端對端的失敗處理。
Q7：Amazon EventBridge 能完全取代 Amazon SQS 和 Amazon SNS 嗎？
不行，而且 DVA-C02 考試會測驗這一點。Amazon EventBridge 是一個路由器，而不是耐久的訊息佇列。如果消費者離線數小時且不能遺失工作項目，你仍然需要 Amazon SQS — 訊息會在訊息佇列中等待，直到消費者恢復。Amazon EventBridge 可以以 Amazon SQS 訊息佇列為目標（這是常見的模式），但 Amazon EventBridge 本身在自己的重試窗口之外，並不為速度較慢的消費者儲存事件。同樣地，Amazon SNS 仍然是包含行動推播、SMS 或電子郵件的扇出的正確答案 — Amazon EventBridge 不支援這些作為目標的通道。現代架構三者並用：Amazon EventBridge 負責路由，Amazon SQS 負責耐久緩衝，Amazon SNS 負責簡單地扇出至通知通道。
Q8：DVA-C02 中 Amazon EventBridge 的跨帳號情境是什麼？
Amazon EventBridge 支援兩種跨帳號模式。第一種：如果你的匯流排的資源政策授予了該主體，另一個帳號可以直接 PutEvents 至你的自訂匯流排。第二種：你的規則可以以另一個帳號中的 Amazon EventBridge 匯流排為目標 — 你的規則角色需要對目標 ARN 有 events:PutEvents 權限，且目標匯流排的資源政策必須信任你的角色。常見的 DVA-C02 情境：每個工作負載帳號發布至自己的自訂匯流排，而集中安全帳號的稽核匯流排透過跨帳號規則接收轉發的副本，以進行集中合規管理。
摘要 — DVA-C02 必記重點
Amazon EventBridge 是 DVA-C02 應用程式整合的主角。掌握其核心詞彙 — 事件、規則、目標、匯流排 — 然後疊加 Schema Registry、封存與重播、Amazon EventBridge Scheduler、Amazon EventBridge Pipes 以及跨帳號路由。圍繞 Amazon EventBridge，牢記三個配角：Amazon SNS 負責簡單的高吞吐量 pub/sub 及行動/SMS/電子郵件傳遞，Amazon SQS 負責帶可見性逾時和 DLQ 的耐久訊息佇列，AWS Step Functions 負責帶重試和人工審核的有狀態多步驟工作流程。在每道考試題目上套用決策樹：事件、訊息還是工作流程，再依過濾/schema/重播需求、排序要求或工作流程持續時間進行篩選。記住關鍵數字 — 256 KB 事件大小、每條匯流排 300 條規則、Amazon SQS 最長 14 天保留、最長 20 秒長輪詢、標準工作流程最長 1 年、Express 工作流程最長 5 分鐘。到處都要設定 DLQ。當對現代答案有疑問時，選 Amazon EventBridge。