1. この記事の内容
S3へのファイルのアップロードをトリガーにLambdaを呼び出す仕組みを構築する際には以下の2つの構成パターンが選択肢になる。
今回「1のS3イベント通知によるLambda呼び出し」と「2のEventBridgeによるLambda呼び出し」のどちらのパターンで実装するかを検討した際に、当初はEventBridgeを挟まないパターン1の構成がシンプルでよいと考えていた。
しかし、具体的な要件に照らして比較してみると案外使い勝手の違いがあり、最終的にパターン2を採用することになった。
さらにパターンで設計・実装を進めた際に とある制約 に引っかかり構成を変更することになった。
この記事では今回の経験を踏まえて以下の内容を紹介する。
- 今回分かったパターン1とパターン2の機能の違い
- パターン2を利用する際に引っかかった制約
2. S3イベント通知とS3イベント通知のEventBridge統合の機能の違い
2.1. それぞれの機能の特徴
今回比較した2つの機能については以下のAWS News Blogに特徴が紹介されている。
AWS News Blog：New – Use Amazon S3 Event Notifications with Amazon EventBridge
この記事で紹介されているそれぞれの機能の概要は以下の通り。
- パターン1で利用する「S3イベント通知」
- 2014年 にリリースされた機能
- イベントの配信先は Lambda関数以外にSNSトピックとSQSキューを選択することができ合計 3個のAWSサービス を配信先として設定できる
- パターン2で利用する「S3イベント通知のEventBridge統合」
- 2021年 のこのブログで新機能として紹介された機能
- 従来のS3イベント通知では、複数チームが同じバケットのイベントを共有する エンタープライズ規模での利用に課題 があったためリリースされた
- S3イベント通知と比べたメリットは以下の通り
- イベントフィルタリングの柔軟性：S3のファイルサイズやキー名のような S3の追加のメタデータを利用 して、配信先を呼び出す条件をより柔軟に設定できる
- 配信先の選択肢の多様性：Step Functions, Kinesis Firehose, Kinesis Data Streamsを含む 18のAWSサービス やHTTPターゲットを配信先として設定できる
- 信頼性の高い呼び出し：S3は 少なくとも1回EventBridgeにイベントを配信 する仕様になっており信頼性が高い *1
あとからリリースされた 「S3イベント通知のEventBridge統合」 は S3イベント通知の課題を解消するもので、より 利便性が高い 印象。
なお、*1 の 「少なくとも1回イベントを配信」する仕様 は、少なくとも2026年現在は S3イベント通知にも適用 されていて、 S3イベント通知のEventBridge統合ならではのメリットではなくなっている。
同じイベントが複数回配信される場合の順番制御や重複排除のやり方については AWS Storage Blog：Manage event ordering and duplicate events with Amazon S3 Event Notifications で紹介されている。
2.2. 今回の検討時に分かったEventBridgeのメリット
今回「1のS3イベント通知によるLambda呼び出し」と「2のEventBridgeによるLambda呼び出し」のどちらを採用するか考える中で、上記のAWS News Blogだけでは分からなかったパターン2のメリットを3点見つけたので紹介する。
メリット1点目：Lambdaの呼び出し停止・再開が簡単
パターン2は EventBridgeの無効化機能 を利用すればS3へのファイルアップロードが発生したとしてもLambdaを呼び出さないよう簡単に対応できるのに対し、パターン1ではS3イベント通知に無効化機能に相当するものが存在しないため複雑でリスクの高い対応が必要になる。
今回Lambdaの呼び出し停止・再開を念頭に置いたのは、この仕組みをリリースした後に Lambdaのアプリケーションコードの改修やランタイムのアップグレード が必要になるためである。
Lambdaのメンテナンス中にはLambdaの呼び出しを一時的に停止して、メンテナンス完了後に再開するという運用が必要になるので、呼び出し停止・再開が簡単であることがEventBridge採用の理由の1つになった。
なお、LambdaのアプリケーションロジックによってLambdaの呼び出し停止・再開を制御するやり方も考えられるが、今回はあくまでLambdaのアプリケーションロジックを使わない方法を優先的に検討した。
その場合はLambdaの環境変数で有効フラグを持たせ、フラグをオフにしたメンテナンス作業中はLambda関数が呼び出されたとしてもロジックを実行せず空振りさせるような設計とするイメージだった。
メリット2点目：単一のEventBridgeルールで複雑なLambdaの呼び出し条件設定が可能
今回構築しようとしている仕組みでは以下のように複数のバケットの複数のフォルダいずれかへのファイルアップロードをトリガーに単一のLambdaを呼び出す要件があった。
このような仕組みを構築する場合、 EventBridgeは1つのルールで条件設定が可能 なのに対し、S3イベント通知の場合はS3パスごとにリソースを作成する必要がありこの例だと7つ作成することになる。
S3イベント通知はアカウントごとに作成可能なのは最大100個までなので、今回に近い要件がある場合は上限に気をつける必要がある。
参考：Amazon Simple Storage Service endpoints and quotas
今回はS3イベント通知を採用したとしても上限100個には到達しない見通しだったが、メリットの1点目にも書いた Lambdaの呼び出し停止・再開の運用 を念頭に置くと、リソース数を集約できるEventBridgeを利用する方式に優位性があると判断した。
メリット3点目：複数のLambdaを呼び出すことが可能
S3イベント通知では同じフォルダへのファイルアップロードをトリガーに複数のLambdaを呼び出すことができない が、EventBridgeでは可能となっている。
今回構築しようとしている仕組みでは同一フォルダへのファイルアップロードをトリガーに複数のLambdaを呼び出す構成はとらなかった。
しかし、検討段階で案の1つとして出てきており、もし採用した場合にはEventBridgeを利用する方式一択になっていた。
参考：【AWS】S3の同一オブジェクトをトリガーに複数のLambdaを動かしたい！
3. S3イベント通知のEventBridge統合の利用時に引っかかった制約
以下の要件通りにEventBridgeでLambda呼び出しの条件を設定する場合、
イベントパターンという設定で以下のようなJSONを指定することになる。
{
"source": ["aws.s3"],
"detail-type": ["Object Created"],
"detail": {
"bucket": {
"name": ["bucket1"]
},
"object": {
"key": {
"prefix": ["folderA/", "folderB/", "folderC/","folderD/"]
}
}
},
"detail": {
"bucket": {
"name": ["bucket2"]
},
"object": {
"key": {
"prefix": ["folderX/","folderY/","folderZ/"]
}
}
}
}
このJSONの文字数には2048という上限があり、今回引っかかってしまった。
参考：Amazon EventBridge quotas
上限は緩和可能だが、将来的にさらに文字数が増える可能性が見込まれるため、今回はファイルアップロード先のバケット単位でEventBridgeのルールを分ける設計に切り替えて対応した。
4. まとめ
「S3イベント通知によるLambda呼び出し」と「EventBridgeによるLambda呼び出し」でできることはほぼ同じだと思っていたが、今回の経験でかなり違いがあることが分かった。
EventBridgeを利用した方が総じて利便性が高い ので、この記事の内容を参考に意識して使い分けしてほしい。
ただし、EventBridgeルールにも イベントパターンの文字数に上限 がある。
複数のバケットの複数のフォルダへのファイルアップロードをトリガーにLambdaを呼び出す場合には上限に到達しやすいので、適宜ルールを分割する設計に切り替えるなどの対応を検討することになる。