DOPインシデントとイベントへの対応
あるフィンテック企業では、決済処理の失敗イベントが Amazon SQS 標準キューに送信される。DevOpsチームは、特定の失敗パターン（エラーコードで判別）に該当するイベントだけを抽出し、外部の不正検知APIの結果でイベントを付加情報付き（エンリッチ）にしたうえで、AWS Step Functions のインシデント対応ワークフローを起動したい。現在は Lambda が SQS をポーリングしてフィルタリングし、別の Lambda を呼び出してエンリッチしてから Step Functions を起動しており、カスタムコードの保守負荷が高い。カスタムコードを最小化しつつ、この一連の処理を実現する方法はどれか。
AAmazon EventBridge ルールで SQS キューをイベントソースに指定し、入力トランスフォーマーでイベントを加工したうえで、ターゲットとして Step Functions ステートマシンを直接起動する構成にする
EventBridge ルールのイベントソースは AWS サービスのイベントやカスタムイベントであり、SQS キューを送信元として直接ポーリングする機能はない。そのため SQS 起点のこのシナリオでは構成自体が成立しない。
BAmazon EventBridge Pipes を作成し、送信元に SQS キュー、フィルターで対象の失敗パターンを絞り込み、エンリッチメントに Lambda 関数、ターゲットに Step Functions ステートマシンを設定する
✓ 正解
EventBridge Pipes は送信元・フィルター・エンリッチメント・ターゲットを単一のマネージドパイプで連結でき、SQS 送信元、Lambda によるエンリッチ、Step Functions ターゲットを設定するだけで、ポーリングやディスパッチのコードを排除できる。
CAmazon SNS トピックへ SQS からメッセージを転送し、サブスクリプションフィルターポリシーで対象イベントを絞り込んだうえで、Lambda 関数を経由して Step Functions を起動する構成にする
SNS はパブリッシュ/サブスクライブのファンアウト向けで、SQS からの転送やイベントのエンリッチメントには別途 Lambda 実装が必要となり、カスタムコードの最小化という要件を満たせない。
DAmazon Kinesis Data Streams へ SQS の内容を送信し、拡張ファンアウトのコンシューマー Lambda でフィルタリングとエンリッチメントの両方を行ってから Step Functions を起動する構成にする
Kinesis Data Streams はストリーム処理向けで、フィルタリングとエンリッチメントをコンシューマー Lambda に自前実装する必要があり、現状と同様にカスタムコードの保守負荷が残るため要件に合わない。
解説
EventBridge Pipes は「送信元→フィルター→エンリッチメント→ターゲット」を一つのマネージド構成で実現するポイントツーポイント統合であり、SQS を送信元、Lambda をエンリッチメント、Step Functions をターゲットに指定できる。ポーリングやディスパッチのカスタムコードが不要になり、保守負荷を最小化できる。
選択肢0の EventBridge ルールは、SQS キューをイベントソース（送信元）として直接指定できないため、この構成は成立しない。
選択肢2の SNS は、SQS からの転送やエンリッチメント処理に別途 Lambda を要し、カスタムコードを削減できない。
選択肢3の Kinesis Data Streams は、フィルタ・エンリッチ・起動をすべてコンシューマー Lambda に実装する必要があり、保守負荷は下がらない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →