前幾天在測試 CodePipeline 時發現當 Source 是 S3 時在 detection source 時多出了 Amazon CloudWatch Events 選項而且還是 recommended，順道了解也記錄一下這兩者的差異是什麼。
找了一下 AWS 文件其實有講到這兩者的差異，一樣把文件先放在前面讓大家可以先閱讀正確的來源「Amazon S3 source actions and CloudWatch Events」為了求知的精神一樣深入探討一下該如何選擇
Detection option：Amazon CloudWatch Events
這是目前 AWS 建議的做法，選擇 Amazon CloudWatch Events 作為 Pipeline 觸發時會依照 S3 Bucket/Object 建立整個 event trigger 的流程
- 上傳 Object 到 S3 Bucket
- PutObject 的 API call 會記錄到 CloudTrail (建立 Codepipeline 時會建立 CloudTrail data event 觸發的 Object pattern)
- CloudWatch events 監看 CloudTrail 是否有符合 pattern rule 的 API call
- CloudWatch Events 觸發 CodePipeline
- CodePipeline 向 S3 拿最新的 Object 版本
流程可以分為以上 5 個步驟，這整個流程在 CodePipeline Console 建立時都會一並建立起來，有興趣可以逐一檢查。
當使用 CloudWatch events 遇到沒有辦法正常觸發 Pipeline 時可以按照這個流程檢查是否哪一個 point 有異常，通常是 S3 Object 可能指定錯誤。
Detection option：AWS CodePipeline
原來預設版本就是 AWS CodePipeline 基本上就是無腦設定，CodePipeline 會在背景輪詢去檢查 S3 的 Object 是否有異動
CodePipeline vs. CloudWatch events
基本上就如文件上提到的，原來 CodePipeline 的觸發方式是背景輪詢 near real-time 的方式所以會比 CloudWatch events 還要慢一些些以外，選擇 CloudWatch events 當出現問題時比較有地方可以 Debug，反之 CodePipeline 比較黑箱讓 AWS 在背景執行。
