什麼是 EventBridge？

簡單來說，EventBridge 就是 AWS 的神經中樞，專門幫你把各種「系統的神經訊號」收一收、分一分，然後送去對的地方。你不用再自己瞎搞一堆 queue + polling 的黑魔法了，EventBridge 幫你把這些工作做掉。當然，前提是你得先搞懂它，不然就是「事件有發生，Lambda 沒反應，老闆卻很有反應」。

想像一下，你的系統是一個人。

• S3 上傳檔案 → 就像手指被火燙到。
• DynamoDB 資料更新 → 就像肚子餓了咕嚕叫。
• EC2 crash → 就像腦袋當機需要重開機（工程師日常啦）。

這些狀況發生的瞬間，訊號會丟到 EventBridge（神經中樞），然後它會依規則把訊號傳到對應的「器官」。
舉例：檔案上傳事件觸發 Lambda 幫你做 ETL → 系統的「反射動作」就完成了。
換句話說，它就是 AWS 世界裡的「你打我左臉，我右手就自己揮出去」自動反應系統。

EventBridge 的主要功能

AWS 官網文件的說法可能太制式化了，我們把官網的制式說法翻成工程師聽得懂的版本：

• 支援跨服務事件整合：AWS 生態系事件大集合，統一入口。就像 Slack 各種頻道的通知都跑進同一個視窗，你再用 filter 決定要不要假裝沒看到。
• 建立自訂規則：你可以設定 event pattern，類似「正則表達式」般的規則。問題是，這東西設錯了，事件可能直接被吞掉。到時候老闆問：「為什麼 Lambda 沒跑？」你只能說：「在我的環境裡是正常的啊。」
• 無伺服器、高擴展性：不用管底下有幾台 server。AWS 幫你顧好，就算雙十一被流量屠殺，事件還是穩穩送到。 （當然你的信用卡帳單也會穩穩送到你信箱。）
• 輕鬆自動化流程：排程？跨服務觸發？全部交給 EventBridge。你可以假裝自己很 DevOps，其實只是多點了幾個選單而已。

基本架構與運作方式

EventBridge 的架構圖大概如以下的 AWS 官方圖示：

用比較寫實的例子來做說明：

1. 事件發生（例：S3 上傳一張圖，老闆的貓自拍），Event Source 就是S3，上傳一張圖,這個動作會產生一個事件 Event 。
2. 事件進 Event Bus（匯流排）。
3. 你的規則（Rule）判斷，看是要觸發哪一個目標 。
4. 自動觸發 Target（目標），例如丟 Lambda 處理縮圖。
5. Lambda 處理完後將執行結果以 JSON 格式輸出。

基本元素就四個：

• Event Bus
• Event
• Rule
• Target
  只要搞清楚這幾個 AWS EventBridge 也就差不多了 。

聽起來很簡單吧？但等你真的 deploy，才會發現「為什麼 Lambda 沒被觸發？」。你會發現要抓特定 Event 的 Event Filter 真的是很難寫得正確，因為服務和動作太多啦！！！

優點與缺點

EventBridge 的優勢

• 簡化事件驅動架構：不用自己搞 queue、polling。設定規則就像寫 LINE bot 一樣：「有關鍵字就回應」。
• 高擴展性：再多人點擊、再多流量爆炸，AWS 幫你穩住。
• 生態系整合：S3、DynamoDB、CloudWatch、ECS 全都能當 EventBridge 的好朋友。

缺點

• 學習曲線：規則 filter 就像在玩解謎遊戲。你設錯就 GG。結果不是 Lambda 沒跑，就是老闆在你背後問：「為什麼不會動？」
• 成本：雖然便宜，但事件量大起來還是會爆。帳單寄來的時候，你會開始懷疑是不是多開了一個區域的 EventBridge 在幫你刷流量。畢竟流量變大也不是你能控制的，可以的話,還是設定一下帳單限額通知吧！

整體來說用好 EventBridge，你可以讓系統反應更靈敏，維運更輕鬆。
用不好，它就會變成一個吞事件的黑洞，然後老闆又會來問：「為什麼結果還是怪怪的 ？」

所以，下一次有人問你：「EventBridge 到底幹嘛用的？」
你就可以用一句最簡單的話來做總結：
「簡單說，它就是 AWS 的神經中樞，讓你的系統自己長反射動作，Deploy 到 production 沒壞就是成功。」