あるEC企業が、EventBridgeルールを使ってS3バケットへのオブジェクトアップロードイベントを検知し、画像リサイズLambdaを起動している。しかし一部のイベントでLambdaが起動されないことがある。原因を調査したところ、イベントパターンのフィルタリング設定に問題があることがわかった。EventBridgeでイベントが確実にLambdaに配信されるよう監視する最も適切な方法はどれか。
- A. S3イベント通知を直接Lambda関数に設定し、EventBridgeをバイパスする
- B. EventBridgeのデッドレターキュー（DLQ）をルールのターゲット設定に追加し、配信失敗したイベントをSQSでキャプチャする。CloudWatch MetricsのFailedInvocationsをアラーム監視する
- C. EventBridgeルールを削除して、S3バケット通知でSNSトピックを経由してLambdaを起動する
- D. EventBridgeルールのターゲットにSQSキューとLambdaを両方設定し、SQSをバックアップとして使う
解答と解説を見る
正解: B
EventBridgeルールのターゲットへの配信失敗（Lambdaのスロットリング、タイムアウト等）に対してDLQ（SQSキュー）を設定することで、失敗イベントを失わずに後で再処理できる。さらにCloudWatch MetricsのFailedInvocationsメトリクスをアラームで監視することで配信失敗を検知できる。これがEventBridgeの公式推奨の信頼性パターンである。DのSQSとLambdaの並列設定では、SQSへのイベント配信とLambdaへの配信は独立して行われ、Lambdaの配信失敗をSQSが補完する設計にはならない。AのS3直接通知はEventBridgeのルールベースフィルタリング機能（detail-typeや属性フィルタ）が使えず、複雑なフィルタ要件がある場合に不適切。CのSNS経由は追加コンポーネントを増やすだけでEventBridgeの問題（パターン設定の改善）を解決しない。
📚 関連サービスの解説: Amazon EventBridge ・ Amazon SQS