S3 をソースとする CodePipeline のトリガーにちょっとハマった話

こんにちは！AWS事業本部コンサルティング部のたかくに（@takakuni_）です。

今回は S3 をソースとする CodePipeline がトリガーしなかった時に見るポイントをご紹介できればと思います。

おさらい

まずはじめに S3 をソースとしたパイプラインのスタート方法は、「ポーリング型」と「イベント型」の2種類があります。

2023年2月現在ではイベント型が推奨されており、具体的に以下のメリットがあります。

• イベントは、平均して大幅に高速化されます。定期的なチェックが必要なポーリングとは異なり、イベントでは、発生直後にパイプラインを開始します。
• 制限の引き上げ。変更をポーリングするパイプラインに比べて CodePipeline は、より多くのイベントベースのパイプラインをサポートできます。
• 多数のパイプラインでのエクスペリエンスの向上。お客様によっては、多数のパイプラインでのコードの変更を調べるためにリポジトリを継続的にポーリングすることで、スロットリングまたはコストの増加が発生する場合があります。これらの問題はイベントを使用することで回避できます。

プッシュイベントを使用するようにパイプラインを編集する

そのため、本エントリは「イベント型」にフォーカスして、書いていこうと思います。

イベント型は、 Amazon EventBridge を使用した方式です。

EventBridge ルールでは、 AWS CloudTrail で検出された PutObject, CompleteMultipartUpload, CopyObject アクションでイベントをトリガーします。¹

イベントがトリガーされると EventBridge に設定された IAM ロールを通じて対象のパイプラインに対してStartPipelineExecutionアクションを実行します。図にすると、次のイメージです。

EventBridge のルール忘れ

マネジメントコンソールから CodePipeline を作ると、 EventBridge に付与される IAM ロールや EventBrige のルールが自動的に作成されます。

自動で作成されている分、普段見えないため IaC で定義し忘れやすいリソースだと思います。

EventBridge ルール、 IAM ロールが正しく設定されていることを確認してみてください。

CloudFormation で作成する場合は、以下を参考に作成してみてください。²

CloudTrail を確認する

本エントリはここが本題です。

「EventBridge問題ないな...アカウント変えたら動かなくなったぞ...」

そんな方は、今すぐ CloudTrail の設定を確認してみましょう。

「CloudTrailで S3 データイベントを取得していますか？」

はい、そうです。 S3 がソースの場合は CloudTrail のデータイベントがイベントのトリガーに使われます。

CodeCommit や ECR を普段トリガーにしている場合は、 CloudTrail の管理イベントのみで問題ないのですが、 S3 がソースの場合はこの事象が起こります。

CloudTrail のデータイベントはデフォルトでは取得されないため、アカウントによって設定がさまざまです。

デフォルトでは、証跡はデータイベントを記録しません。追加の変更がイベントデータに適用されます。詳細については、「AWS CloudTrail 料金」を参照してください。

証跡のデータイベントの記録

また、別途料金がかかる機能のため、課金を最小限に抑えたい方は、「ソースバケットの対象オブジェクトのみ証跡を取る」ような詳細な設定も可能なためご検討ください。

（ちなみに、マネジメントコンソールで作成した場合、ソースバケット,オブジェクトに対してのデータイベントのみを取得する証跡が自動的に作成されていました。）

まとめ

以上、「S3 をソースとする CodePipeline のトリガーにちょっとハマった話」 でした。

EventBridge, IAM Role (EventBridge), CloudTrail (データイベント)の順にトラブルシューティングがおすすめです。

しっかりハマったため、ブログにしてみました。この記事がどなたかの参考になれば幸いです。

AWS事業本部コンサルティング部のたかくに（@takakuni_）でした！