事件驅動架構（Event-Driven Architecture，指系統各元件之間透過傳送與接收「事件」來協作，而非直接呼叫彼此）在企業環境落地時，常常遇到一個容易被低估的問題：當事件量與團隊數增加，事件基礎設施本身會開始碎裂。Amazon EventBridge 是 AWS 的託管（managed）事件路由服務，客戶端不必管理底層伺服器，只需定義事件來源、過濾條件與目標。 InfoQ 於 2026 年 10 月 13 日由 Craig Risi 報導，AWS 針對這個問題推出增強版 Custom Event Bus（自訂事件匯流排），目標是讓事件匯流排可以成為跨帳號的組織級事件骨幹，同時補上事件順序、保留與重放、內容去重、訂閱管理與計價方式等長期缺口。
背景：多帳號環境讓事件拓撲失控 企業為了團隊與應用之間的隔離，普遍採用多個 AWS 帳號。隔離帶來安全性與責任邊界的好處，卻也讓 EventBridge 的匯流排被切割在各個帳號裡。跨帳號規則（cross-account rules）與轉發設定（forwarding configuration）於是大量出現：同一個事件必須從來源帳號逐跳轉送到消費端帳號。當消費者數量成長，這個由轉發規則交織成的拓撲會越來越難以理解與治理，平台團隊很難回答「某個事件現在到底會被誰收到」。更實際的成本問題是，同一個事件每經過一層匯流排轉發，都會再產生一次處理與路由費用，成本隨著中繼跳數（hop）累加。
核心變更：單一匯流排跨帳號共用 增強版 Custom Event Bus 的做法是把中央匯流排作為組織級的事件骨幹，透過 AWS Resource Access Manager（RAM，用來跨帳號共用資源的服務）共享給多個帳號。平台團隊建立並管轄中央匯流排，各應用團隊則直接在自己的帳號裡發佈與訂閱。AWS 表示新版匯流排預設可支援最多一萬個訂閱者，數量不足時可另行申請提高配額。
真正的改變不只在技術層面，也在治理模型。過去新增一個消費者，往往需要平台團隊親自配置每條跨帳號連線；現在平台團隊只需界定中央匯流排的邊界與規範，訂閱、過濾條件、目標、重試與失敗目的地（dead-letter destination，指處理失敗的事件最終被送往的位置）由各應用團隊自行管理。平台層級的治理與應用層級的事件消費因此分離，接入新消費者的基礎設施工作量明顯下降。此外，新版匯流排支援同步呼叫（synchronous invocation）目標，例如 AWS Lambda。過去團隊常在 EventBridge 與 Lambda 之間插入 Amazon SQS（一種託管的訊息佇列服務），目的只是為了取得更強的處理確認機制；同步呼叫讓這道中間層在許多情境下變得不再必要，同一個匯流排可以同時服務傳統非同步消費，以及重視順序與處理確認的工作負載。
技術細節：Subscriber 資源、保留重放與內容去重 過去一個 EventBridge 消費者通常由規則（rule）、目標（target）與重試設定組合而成，分散在多處。新版引入 Subscriber 資源，把過濾、目標設定、重試與死信目的地整合成單一的消費者定義，並支援可變的起始時間，方便新消費者從事件歷史的某個點開始接收，或是在故障後重放（replay）既有事件。匯流排本身的耐用性也提升，事件可保留一到 365 天（可配置），消費者可以回溯到較早的事件起點，或在應用故障後自行恢復。
轉換與過濾能力同步強化。新版支援 JSONata（一種用來重塑 JSON 資料的轉換語言），並將 Avro 與 Protocol Buffers（兩種常見的二進位序列化格式，用比 JSON 更省空間的方式編碼資料）反序列化為 JSON，以便進行過濾與路由。另一項是內容去重（content-based deduplication），EventBridge 依據事件內容（payload）辨識重複投遞，AWS 表示在五分鐘視窗內收到的相同事件可被合併，在這個特定去重情境下提供剛好一次（exactly-once）語意。
影響、價格與限制 計價方式也改了。新版採用入口與出口吞吐量（ingress and egress throughput）模型：發佈方依進入匯流排的事件量付費，訂閱方依實際收到的事件量付費。成本不再隨跨帳號與匯流排之間的轉發跳數累加，而是與真正流入、流出中央匯流排的事件資料量對齊，這讓架構上的中繼轉發不再直接等同於帳單成長。
定位上，增強版匯流排確實進入了過去屬於企業事件代理（event broker）與串流平台的領域，以 Apache Kafka 為代表。 Kafka 是分布式事件串流平台，核心是持久化日誌（durable log）、分區（partition）與消費者群組（consumer group），讓工程團隊對高吞吐串流與消費語意有高度控制權。 EventBridge 則維持全託管、無伺服器（serverless）的事件路由服務，底層由 AWS 維運。新版讓 EventBridge 更適合作為企業事件骨幹，但並未讓它在所有串流場景都能直接取代 Kafka。
限制方面需要留意三點。其一，內容去重的剛好一次語意僅限該去重情境，事件重放或跨區域處理時，應用層的冪等性（idempotency，指重複處理同一筆資料也不改變結果）仍然是必要設計。其二，AWS 並未立即取代舊有模型，現存自訂匯流排會以 Custom event bus-classic 名稱持續運作，增強版則作為獨立資源推出，組織可以漸進採用，不必為此重做既有事件驅動應用。其三，增強版目前僅在北美、歐洲與亞太的部分區域可用，可透過 AWS Management Console、CLI 或 EventBridge API 建立，實際導入前仍需確認目標區域支援與配額。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。