1. はじめに
Amazon S3（S3）のイベントを基にAWS Lambda（Lambda）を起動したい場面はよくあります。
S3にはイベント通知機能があり、S3にデータがアップロードや削除されるなどのイベントをトリガーとして、LambdaやAmazon SQS（SQS）、Amazon SNS（SNS）に連携できます。
しかしながら、本記事執筆時点では、S3の同一オブジェクト（フォルダ）をトリガーとして複数のイベント通知を設定することはできません。
例えば、該当のオブジェクトをトリガーとして既にLambdaが設定されている場合や
データの後続処理が複数あり、並列して処理したい場合などがあります。
本記事では、以下について記載しております。
- S3から直接Lambdaを起動するパターン
- S3の同一オブジェクトをトリガーとして、複数のLambdaを起動させたい場合のパターン
- 各パターンのメリット・デメリット、およびユースケース
S3からLambdaを直接起動するパターン
S3のイベント通知の設定で、直接Lambdaを連携させるパターンです。
メリット
- S3のイベント通知設定のみで、完了するため、構築が容易
デメリット
- 同一オブジェクトをトリガーとする場合、複数のLambdaを起動することができません
ユースケース
- 特定のオブジェクトから1つのLambdaを起動させる場合
2. S3の同一オブジェクトを起点として複数のLambdaを起動するパターン
S3のイベント通知単体では、1つのLambdaしか起動できませんでしたが、以下のようなパターンでは、同一イベントから複数のLambdaを起動することが可能です
S3のイベント通知を利用し、同一オブジェクトに基づいて複数のLambdaを起動する方法には、主に以下の3つのパターンがあります。
個人的には「SQS + EventBridge Pipes」がおすすめです。
- パターン1：SNS
- パターン2：EventBridge
- パターン3：SQS + EventBridge Pipes
各パターンは、大きく以下のようなユースケースで分けることができます。
| パターンNo | 利用サービス | ユースケース |
|---|---|---|
| パターン1 | SNS | Lambdaに渡す引数を変換しなくてよい場合 |
| パターン2 | EventBridge | Lambdaに渡す引数を変換したい場合 |
| パターン3 | SQS + EventBridge Pipes | エラーハンドリングもしたい・引数の変換もしたい |
3. パターン1: SNSの利用
3.1 SNS単独利用
アーキテクチャ
S3のイベント通知をSNSに送信し、SNSから複数のLambdaを直接トリガーするパターンです。
メリット
- SNSとイベント通知の設定のみで簡単に試すことができます
デメリット
- SNSは数回の再試行は実施してくれますが、メッセージのバッファリング（長期間保持）ができないため、数回の再試行でLambdaが起動しない場合は、そのメッセージが削除されます
- SNSのサブスクリプション設定でSQSを作成すればデットレターキューとして設定することは可能です
Lambdaのトリガーとして設定できるのはSNSのスタンダードタイプのみです
- SNSのFIFOタイプはアーカイブ機能ががありますが、Lambdaのトリガーとして利用できません
- Lambdaに渡す引数を変換することができません
ユースケース
- 簡易的なテストとして、素早くLambdaの動作確認をしたい場合
- 小規模な処理で、エラーハンドリングの要件が低い場合
3.2 SNS + SQSの利用
アーキテクチャ
SNSとSQSを組み合わせることで、SNSのメッセージをSQSにキューイングし、SQSからLambdaをトリガーする形にします。
メリット
- SQSはSNSと異なり、バッファリング（長期保存）が可能です（60秒から14日間まで設定可能）
- デッドレターキュー（DLQ）を活用し、メッセージの処理失敗時に再試行可能です
デメリット
- SNS単体同様、SQS内でLambdaに渡す引数を変換することができません
ユースケース
-
S3イベントが大量に発生する場合
- 例：基幹システムからS3へ1秒間に数百ファイルがアップロードされる場合
-
エラーハンドリングが重要な場合（リトライやDLQ管理）
補足
- 1つのデータ量が重い場合は、Lambdaのメモリや実行時間の延長などが必要です
4. パターン2: EventBridgeの利用
4.1 EventBridge単独利用
アーキテクチャ
S3のイベント通知をEventBridgeに送信し、EventBridgeルールを使用して複数のLambdaを起動させます
メリット
- 引数変換が可能です
EventBridgeのルール機能を使用して、Lambdaに渡す引数を柔軟に変換することができます。
デメリット
-
エラーハンドリングをLambda側で実装する必要があります
-
複雑な処理フロー（ワークフロー制御）は困難です
複雑な処理を実装する場合は、Step Functionsを利用しましょう。
- SNS同様バッファリングがありません。ただし、リトライ回数を指定することが可能です
- EventBridgeからSQSを介してLambdaを実装することも可能ですが、補足に記載しているパターンの方がおすすめです
ユースケース
-
Lambdaが単純な並列処理の場合
例えば、Lambda（A）とLambda（B）が独立した処理を行っている場合です -
Lambdaの処理順序や条件分岐を制御しなくていい場合
- 以下の場合はStep Functionsを利用しましょう
- Lambda（A）のあとにLambda（B）を実行するなど順番を制御する場合
- 変数AがtrueであればLambda（A）を動かす、falseであればLambda（B）を実行
4.2 EventBridge + Step Functionsの利用
アーキテクチャ
EventBridgeをトリガーにして、Step Functionsを利用して実行順序や条件分岐を制御しながら、Lambdaを起動させることが可能です。
メリット
- 複雑なワークフロー管理が可能
- エラーハンドリングやリトライ管理が容易
- 可視化がしやすく、監視が容易
デメリット
- Step Functionsの利用に応じた追加コストがかかる
ユースケース
- Lambdaの実行順序を制御したい場合
- 複雑なワークフローを実装したい場合
5. パターン3: SQS + EventBridge Pipes
アーキテクチャ
SQSのバッファリング機能に加えて、Lambdaに渡す引数をEventBridge Pipesで変換することが可能です。
メリット
- SQSのバッファリング機能を活用可能
- EventBridge Pipesで引数変換が可能
- エラーハンドリングが容易
デメリット
- 構成がやや複雑になる
ユースケース
- 引数変換が必要で、エラーハンドリングも重要な場合
- 大量のイベント処理が必要な場合
- 例えば、基幹システムからS3へ1秒間に数百ファイルが出力される場合
6. まとめ
個人的には、SQSからEventBridge Pipesを介してLambdaを呼ぶパターンが、さまざまな運用面を考慮するとよいのではないかと考えています。
以下に機能面と条件・要件面での各パターンのまとめを記載します。
コメントにみなさまの意見を記載してもらえると大変参考になります。
条件・要件面
| 条件 | パターン |
|---|---|
| Lambdaに渡す引数を変換したい場合 | EventBridge |
| 複雑なワークフローを管理したい場合 | EventBridge + Step Functions |
| Lambdaに渡す引数を変換しない場合かつ、お試しでLambdaを実行したい場合 | SNS |
| 引数を変換しないかつ、エラーハンドリングが重要な場合 | SNS + SQS（DLQ活用） |
| Lambdaに渡す引数を変換したいかつ、エラーハンドリングが重要な場合 | SQS + EventBridge Pipes |
機能面
| 機能軸 | SNS | SNS + SQS | EventBridge | EventBridge + Step Functions | SQS + EventBridge Pipes |
|---|---|---|---|---|---|
| 到達性 | At least once | At least once | At least once | At least once | At least once |
| 配信の信頼性 | At least once | At least once | At least once | At least once | At least once |
| リトライ可否 | 可能（設定簡単） | 可能（DLQ活用） | 可能（設定簡単） | 可能（Step Functionsで制御） | 可能（DLQ活用） |
| バッファリング | なし | 最大14日間 | なし | なし | 最大14日間 |
| スケーラビリティ | 高い | 高い | 高い | 高い | 高い |
| メッセージの変換 | なし | なし | 可能（ルール設定） | 可能（Step Functionsで制御） | 可能（Pipesで変換） |
| エラーハンドリング | DLQ設定可能 | DLQ設定可能 | DLQ設定可能 | DLQ設定可能もしくはStep Functionsで制御可能 | DLQ設定可能 |
| 監視と可視化 | CloudWatch対応 | CloudWatch対応 | CloudWatch対応 | CloudWatch + Step Functions可視化 | CloudWatch対応 |
7. 注意点
- S3のイベント通知やEventBridgeはFIFO（順序保証）をサポートしておりません
- S3のイベント通知やEventBridgeは「少なくとも1回実行」のため、同一イベントが複数回実行される場合があります。そのため、処理によってはLambda側で冪等性を考慮する必要があります。