當我們深入使用AWS EventBridge時，常常會發現一個有趣的現象：對于同一個操作（比如啟動一個EC2實例），EventBridge中似乎會出現兩種事件。一種來自CloudTrail，記錄了API調用的行為；另一種則直接來自EC2服務本身，描述了實例狀態的變化。

這引出了一個至關重要的問題：在創建EventBridge規則時，我應該監聽哪一種？它們有什么區別？{"source": [{"prefix": "aws."}]}這樣的泛匹配會不會導致混亂？

別擔心，這篇文章將為大家徹底理清這個概念，讓大家在選擇事件源時，做到胸有成竹，精準無誤。

核心理念：理解“行為事件”與“狀態事件”

要做出正確選擇，首先要理解這兩種事件的根本區別。我們可以把它們比作兩種不同的新聞報道：

1. CloudTrail 事件 (行為事件)：

   • 報道內容：“誰在什么時間、從哪里、做了什么事。”
   • 本質：這是對 API 調用行為 的審計記錄。它關注的是動作本身。
   • 關鍵信息：userIdentity (誰做的), sourceIPAddress (從哪做的), eventName (做了什么API調用), requestParameters (請求參數)。
   • detail-type 典型值：AWS API Call via CloudTrail

2. 服務原生事件 (狀態事件)：

   • 報道內容：“某個資源的狀態發生了什么變化。”
   • 本質：這是資源狀態變更的通知。它關注的是動作的結果。
   • 關鍵信息：資源ID, 新的狀態 (e.g., running, stopped, SUCCEEDED, FAILED) 以及與該狀態相關的上下文。userIdentity通常不存在或不重要。
   • detail-type 典型值：EC2 Instance State-change Notification, S3 Object Created, CodePipeline Stage Execution State Change

一句話總結：CloudTrail告訴我們“有人按了開關”，服務原生事件告訴我們“燈亮了”。

Side-by-Side 對比：一圖勝千言

特性	CloudTrail 事件 (行為事件)	服務原生事件 (狀態事件)
關注點	API調用行為 (The Action)	資源狀態變更 (The Result)
detail-type	AWS API Call via CloudTrail	特定于服務，如 EC2 Instance State-change Notification
關鍵數據	userIdentity, sourceIPAddress, eventName	state, status, 資源具體屬性
延遲	相對較低（分鐘級）	更低，近乎實時
覆蓋范圍	極廣，覆蓋絕大多數可記錄的AWS API調用	有限，僅覆蓋服務主動發布的重要狀態變更
典型用例	安全審計、合規監控、入侵檢測	自動化工作流、資源編排、解耦微服務

決策框架：我該如何選擇？

現在，我們來看幾個實際場景，幫我們建立選擇的直覺。

場景一：安全審計——“誰動了我的S3存儲桶？”

• 目標：當有任何人刪除一個S3存儲桶時，立即向安全團隊發送最高級別告警。
• 分析：這個場景的核心是“誰” (userIdentity) 和“刪除”這個高危動作 (DeleteBucket)。我們需要的是行為的審計記錄，而不是桶消失后的狀態。
• 結論：必須選擇 CloudTrail 事件。
• Event Pattern:

  {"source": ["aws.s3"],"detail-type": ["AWS API Call via CloudTrail"],"detail": {"eventSource": ["s3.amazonaws.com"],"eventName": ["DeleteBucket"]}
  }
  

場景二：自動化工作流——“EC2實例準備就緒后，自動配置它”

• 目標：當一個EC2實例成功啟動并進入running狀態后，觸發一個Lambda函數去安裝應用。
• 分析：我們關心的是實例的最終狀態——它是否已經“準備就緒”。如果我們監聽CloudTrail的RunInstances事件，它觸發時實例尚在pending狀態，Lambda會因無法連接到實例而失敗。
• 結論：必須選擇服務原生事件。
• Event Pattern:

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

場景三：數據處理——“圖片上傳后，自動生成縮略圖”

• 目標：當一個新圖片文件被上傳到S3桶的uploads/目錄下時，觸發Lambda進行處理。
• 分析：我們需要的是文件上傳完成這個結果作為觸發器。服務原生事件（S3 Event Notifications）是為這個場景量身打造的，延遲最低，信息最直接。
• 結論：優先選擇服務原生事件。
• Event Pattern:

  {"source": ["aws.s3"],"detail-type": ["Object Created"],"detail": {"bucket": {"name": ["your-bucket-name"]},"object": {"key": [{"prefix": "uploads/"}]}}
  }
  

如何處理“重復內容”？

大家應該已經意識到了，{"source": [{"prefix": "aws."}]} 會同時捕獲一個動作的“行為事件”和“狀態事件”。例如，我們調用RunInstances API：

1. CloudTrail會記錄RunInstances這個API調用，產生一個行為事件。
2. 稍后，當實例狀態從pending變為running時，EC2服務會產生一個狀態事件。

它們不是嚴格意義的“重復內容”，而是描述同一流程不同階段的兩個獨立事件。

最佳實踐：
在創建生產環境的規則時，永遠不要只用寬泛的source。一定要加上 detail-type 來精確指定我們想監聽的事件類型。

• 想審計？ "detail-type": ["AWS API Call via CloudTrail"]
• 想自動化？ "detail-type": ["EC2 Instance State-change Notification"]

通過明確指定detail-type，我們就能從事件流中精確地“釣”出我們想要的那條魚，徹底避免混淆和規則的意外觸發。

結論

理解CloudTrail事件和原生服務事件的區別，是掌握EventBridge精髓的關鍵一步。記住這個簡單的法則：

• 為了安全和審計（關心“誰做的”） -> 選擇CloudTrail事件。
• 為了自動化和編排（關心“發生了什么”） -> 選擇服務原生事件。

現在，我們不僅知道了如何選擇，更理解了背后的原理。下次再構建EventBridge規則時，我們將能夠更加自信、更加精準地駕馭事件流，構建出穩定而高效的云上系統。