Amazon EventBridge 的核心能力是依內容路由：各個 AWS 服務內部發生狀態變化時，會自動把相關資訊送進 EventBridge，使用者寫規則比對送進來的內容，決定分流到哪個目的地，不用自己寫輪詢程式去偵測變化，也不用手動把服務一個一個串接起來。來源不限於 AWS 服務本身，自訂應用程式與第三方 SaaS 的通知也能一併送進來，統一交由同一套規則分流。

🚌 Event Bus、Rule、Target

EventBridge 由三個元件組成，事件依序經過它們：

事件本身是一個 JSON 物件，基本結構如下：

{
  "source": "aws.ec2",
  "detail-type": "EC2 Instance State-change Notification",
  "detail": { "instance-id": "i-0123abcd", "state": "stopped" }
}

Event pattern 也是 JSON，只列出需要比對的欄位，沒列到的欄位不影響結果。下面這條 pattern 會比對所有被停止或終止的 EC2：

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

每個欄位的值寫成陣列，符合其中任一個就算符合。除了完全相等，event pattern 也支援前綴、後綴、數值範圍等比對方式，例如「key 以 .pdf 結尾，而且大小超過 10 MB」。

🆚 EventBridge 與 SNS

SNS（Day 16）同樣能把一則訊息送到多個目的地，也支援依內容篩選（filter policy 比對訊息屬性或本文）。兩者的差別在訊息來源與附加功能：

選擇依據：要回應 AWS 服務的狀態變化、接 SaaS 事件、需要排程或重播時，用 EventBridge；應用程式自己發出、要推送給大量訂閱者或直接發簡訊和 email 時，用 SNS。

🔗 常見組合：AWS 服務的事件觸發自動處理

EventBridge 在架構裡最常見的用法，是讓 AWS 服務的事件直接觸發後續動作，中間不需要任何查詢程式：

多帳號的環境也是同樣的做法：每個帳號的 default bus 只收到自己帳號的事件，所以在中央帳號建立一個 custom bus，用 resource-based policy 允許其他帳號寫入，各帳號再用一條 rule 把事件轉送過去，就能集中處理所有帳號的事件。

考題描述「某件事發生時，自動執行某個動作」，而那件事是 AWS 服務本身的狀態變化或 API 呼叫時，答案通常就是 EventBridge。

🪣 S3 的事件：event notification 與 EventBridge

S3 自己也有通知功能，稱為 S3 event notification。同樣是「檔案上傳後觸發處理」，有兩種做法：

只需要「上傳 .jpg 就觸發一個 Lambda」時，S3 event notification 最簡單。需要依物件大小等條件分流，或同一個事件要送到多個目的地時，改用 EventBridge。

⏰ 排程

EventBridge 的 rule 除了比對事件，也可以依時間表觸發，不需要任何事件來源：

Cron expression 和 Linux 的 cron 有兩個差別：欄位有 6 個（分、時、日、月、星期、年），比 Linux 多了「年」；「日」和「星期」兩個欄位必須有一個填 ?，代表不指定。時間一律以 UTC 計算。

固定時間要執行的工作，以前需要一台全年開機的機器跑 cron；改用排程 rule 觸發 Lambda 之後，只在執行時計費，也不用維護作業系統。

AWS 後來另外推出 EventBridge Scheduler，專門處理排程：支援一次性排程（例如「明天早上 9 點執行一次」）、指定時區，並能管理大量排程。新的排程需求，AWS 建議使用 Scheduler。

📌 補充

✅ 小結

摘要：EventBridge 接收 AWS 服務、自己的應用程式和 SaaS 產生的事件，再用 rule 比對事件內容，送到對應的 target。它讓「某件事發生時自動執行某個動作」不需要寫查詢程式，也取代了需要專門機器的 cron 排程。

下一天進 Lambda：Serverless 執行模型與限制。

🧠 AI 出題

問題 1

某公司以 AWS Organizations 管理 40 個帳號，每個帳號都已啟用 CloudTrail。資安團隊要求：任何成員帳號只要有人修改 Security Group 的輸入規則，相關事件都必須在幾秒內送到資安帳號，由那裡的 Lambda 統一分析，而且之後新加入組織的帳號也要一併涵蓋。公司希望以維運負擔最低（LEAST operational overhead）的方式完成。

解決方案架構師應該怎麼做？

• A. 在資安帳號的 default event bus 建立一條 rule，event pattern 比對所有成員帳號的 Security Group 變更事件
• B. 在每個成員帳號建立 SNS topic，由各帳號的 Lambda 發布變更通知，資安帳號的 Lambda 跨帳號訂閱這些 topic
• C. 在資安帳號建立 custom bus，以 resource-based policy 允許整個組織寫入，各成員帳號用 rule 把事件轉送到這個 bus
• D. 讓每個成員帳號把 CloudTrail 日誌寫進資安帳號的 S3 bucket，再由 Lambda 每 5 分鐘掃描新檔案找出變更事件

問題 2

某公司有一台全年開機的 t3.small EC2，唯一的用途是用 cron 每 15 分鐘執行一次腳本，呼叫外部 API 同步匯率並寫進 DynamoDB，每次執行約 20 秒。維運團隊還得定期幫這台機器更新作業系統。公司希望以最符合成本效益（MOST cost-effective）的方式處理。

哪一個方案能以最低的成本取代這台機器？

• A. 把腳本改寫成 Lambda 函式，由 rate(15 minutes) 的 EventBridge 排程規則觸發
• B. 保留這台 EC2 並購買 3 年期 Compute Savings Plans，以承諾用量換取較低的每小時費率
• C. 把這台機器改成 Spot Instance 繼續執行 cron，並設定中斷後由 Auto Scaling group 自動補回一台
• D. 把腳本打包成容器，由 EventBridge 排程每 15 分鐘啟動一次 ECS on Fargate task，跑完即結束

問題 3

某電商把訂單事件送進 EventBridge 的 custom bus，由 rule 觸發 Lambda 寫入會計系統。上個月 Lambda 的一次錯誤部署讓處理失敗了 6 小時，EventBridge 重試用完後把事件丟棄，會計資料因此出現缺口。公司要求：之後 target 失敗時，送不出去的事件不能遺失、要能讓工程師檢查；程式修正後，也要能把出錯期間的事件重新送一次。

解決方案架構師應該採取哪兩項做法？（選擇兩項）

• A. 把 Lambda 函式的 timeout 從 30 秒調高到 15 分鐘，讓每次處理有更充裕的時間完成
• B. 為 target 設定一個 SQS dead-letter queue，接住重試用完後仍然送不出去的事件
• C. 在同一條 rule 再加一個 CloudWatch Logs log group 作為 target，完整保存送進來的每一筆事件
• D. 在這個 custom bus 上建立 archive 保存事件，程式修正後以 replay 重送指定時段的事件
• E. 在 bus 與 Lambda 之間加入 SNS topic，由 SNS 推送事件並使用 SNS 的重試機制傳送

問題 4

某設計公司的使用者會把檔案上傳到同一個 S3 bucket。副檔名為 .jpg 的檔案要交給 Lambda 產生縮圖；副檔名為 .pdf 且大於 10 MB 的檔案要啟動 Step Functions 工作流程做分頁處理；其他檔案不處理。公司希望盡量不寫額外的分流程式碼，並以維運負擔最低的方式完成。

哪一個方案能以最少的維運工作滿足需求？

• A. 設定 S3 event notification 以 .jpg 與 .pdf 後綴觸發同一個 Lambda，由它判斷大小再啟動 Step Functions
• B. 設定 S3 event notification 把所有上傳事件送進 SQS，由 EC2 上的 worker 讀取後依副檔名與大小分派
• C. 啟用 CloudTrail 的 S3 data events，再由 Lambda 定期查詢 CloudTrail 日誌，找出新上傳的檔案後分派
• D. 啟用 bucket 的 EventBridge 通知，建立兩條 rule，以 key 後綴與物件大小的 event pattern 分送各自的 target

問題 5

某品牌在 SaaS 電商平台 Shopify 上開設網路商店。營運團隊要求：只要有訂單被取消，就要在一分鐘內自動於 AWS 上觸發 Lambda，建立內部事件並通知客服主管追蹤原因。開發團隊人力有限，公司希望盡量不撰寫、也不維護整合用的程式碼。

解決方案架構師應該怎麼做？

• A. 撰寫 Lambda 每分鐘呼叫 Shopify API 查詢訂單狀態，由 EventBridge 排程觸發，篩出被取消的訂單後處理
• B. 在 EventBridge 接上 Shopify 的 partner event source，用 partner bus 的 rule 篩出取消訂單的事件
• C. 用 API Gateway 與 Lambda 建立 webhook 端點給 Shopify 呼叫，由這個 Lambda 解析內容並篩出被取消的訂單
• D. 在帳號的 default bus 建立 rule，比對 source 為 Shopify 的事件，篩出取消訂單的事件後觸發 Lambda 處理

💡 解答

1. C

EventBridge 可以跨帳號傳送事件：在資安帳號建立 custom bus，resource-based policy 以 aws:PrincipalOrgID 條件允許整個組織寫入；各成員帳號的 default bus 會收到自己帳號的 Security Group 變更事件（透過 CloudTrail 產生的 API 事件），再用一條 rule 把它轉送到資安帳號的 bus。事件幾秒內就能送達。成員帳號的 rule 可以用 CloudFormation StackSets 自動部署到新帳號，不用另外寫程式。

A 是誤解：每個帳號的 default bus 只會收到自己帳號產生的事件，資安帳號的 bus 看不到其他帳號的變更。B 要在每個帳號各寫一個發布通知的 Lambda，等於自己重做 EventBridge 原生就有的事件來源，維運負擔最高。D 能收集到事件，但 CloudTrail 日誌是批次寫進 S3 的，再加上每 5 分鐘掃描一次，做不到「幾秒內」送達。

2. A

EventBridge 的排程規則直接取代 cron，Lambda 只在每 15 分鐘被叫醒的那 20 秒計費，沒呼叫時完全不用付錢，也不用再維護作業系統。一天 96 次、每次 20 秒的工作量，Lambda 的費用遠低於一台全年開機的 EC2。

B 能降低 EC2 的費率，但這台機器 99% 的時間都在閒置，打折之後依然是在為閒置付費，也沒有解決更新作業系統的負擔。C 更便宜一些，但一樣是全天候跑一台機器，還多了中斷後重建的複雜度。D 是最有誘惑力的干擾項：Fargate task 跑完就結束，同樣不用維護作業系統；但 Fargate 以秒計費、每次最少收 1 分鐘，20 秒的工作要付 1 分鐘的錢，每次啟動還要拉取容器映像檔，另外得維護映像檔和 task definition，成本和工作量都輸給 Lambda。

3. B、D

target 的 DLQ 會接住重試用完之後仍然送不出去的事件，事件不會被丟棄，工程師可以直接到 SQS 裡檢查。archive 則會保存送進這個 bus 的事件，程式修正後，可以用 replay 把指定時段的事件重新送一次，補回出錯期間的資料。兩項各自滿足一個要求。

A 在調整 Lambda 的資源，但這次失敗是錯誤部署造成的，不是時間不夠。C 確實能把每一筆事件存下來，但那只是日誌：要重新送一次，得自己寫程式把事件從日誌讀出來再逐筆送回 bus；而且兩個 target 是分開送的，哪些事件在 Lambda 那邊失敗，日誌裡也看不出來。E 只是多一個負責推送的服務，SNS 同樣不會保存歷史事件，沒辦法事後重送，反而多了一層要維護。

4. D

S3 可以把 bucket 的事件送進 EventBridge，而 EventBridge 的 event pattern 可以同時比對事件內容裡的 key 後綴（suffix matching）和物件大小（numeric matching）。兩條 rule 各自把 .jpg 送到 Lambda、把大於 10 MB 的 .pdf 送到 Step Functions，分流完全靠設定，不用寫程式碼。

A 是最常見的做法，也是最有誘惑力的干擾項：S3 event notification 支援依前綴、後綴篩選，但不支援依物件大小篩選，只能再寫一個 Lambda 判斷大小，違反「盡量不寫額外的分流程式碼」。B 要自己維護 EC2 上的 worker 和分派邏輯，維運負擔最高。C 用 CloudTrail 加輪詢，延遲高又要寫查詢程式，是繞遠路的做法。

5. B

EventBridge 有現成的 SaaS partner 整合，Shopify 就是其中之一。在 Shopify 設定 EventBridge 作為 webhook 的傳送目的地後，訂單事件會直接送進帳號裡的 partner bus，只要寫一條 event pattern 篩出「訂單取消」的事件並觸發 Lambda，整合的部分完全不用寫程式，而且是事件驅動、即時送達。

A 能做到，但要自己寫、自己維護呼叫 Shopify API 的輪詢程式，還要處理認證、分頁和重複資料。C 也能做到，但 webhook 端點、驗證與解析邏輯都要自己寫和維護，跟「盡量不寫整合程式碼」相反。D 是誤解：SaaS 夥伴的事件不會進到 default bus，一定要透過 partner event source 送進專屬的 partner bus，rule 也要建在那個 bus 上。