DVAAWSのサービスを使用した開発
ある開発者は、Lambda関数を非同期で呼び出すシステムを構築している。Lambda関数の実行が失敗した場合、失敗の詳細（エラーメッセージや入力データなど）を含む情報を自動的に別のLambda関数に渡して後処理させたい。また、成功した場合もその結果を記録したい。最も適切な設定はどれか？
ALambda関数にデッドレターキュー（DLQ）としてSQSキューを設定し、そのキューをトリガーとする別のLambda関数を作成する
DLQは失敗時のみの対応で、入力データのみが渡されるため、成功・失敗両方の実行コンテキスト（出力・エラー情報含む）が必要な要件には情報不足です。
BLambda Destinationsを設定し、成功時と失敗時それぞれに別のLambda関数をデスティネーションとして指定する
✓ 正解
Lambda Destinationsは成功・失敗それぞれに別々のSQS・SNS・EventBridge・Lambdaを設定でき、実行コンテキストが自動的に送信先に渡されます。要件を完全に満たせます。
CCloudWatch Logsのサブスクリプションフィルターを使って失敗ログを検知し、別のLambda関数を起動する
CloudWatch Logsのサブスクリプションフィルターはログをほぼリアルタイムで転送できますが、Lambda実行コンテキスト（入力・出力・エラー情報）を自動取得する機能はなく、構造化ログ設計と追加実装が必要です。
DLambda関数のコード内でtry-catchを使い、失敗時にSNSトピックにエラー情報をパブリッシュする
Lambda関数内でSNS発行するアプローチは、ビジネスロジックとエラーハンドリングが混在し、管理性が低く、関心の分離が実現できません。
解説
Lambda Destinationsは、非同期呼び出しの成功・失敗それぞれに対してSQS、SNS、EventBridge、Lambdaを送信先として設定できる機能です。成功・失敗の両方を処理でき、実行コンテキスト（入力・出力・エラー情報）が自動的にデスティネーションに送信されます。
選択肢ADLQは失敗時のみ対応し入力データしか渡せないためDestinationsより情報量が少ないです。
選択肢CのCloudWatch Logsのサブスクリプションフィルターはログをほぼリアルタイムで転送する仕組みですが、Lambda実行コンテキスト（入力・出力・エラー情報）を自動取得するには構造化ログ設計と追加のLambda実装が必要で管理が複雑です。
選択肢DのLambda関数のコード内でSNSにパブリッシュする方法はアプリケーションコードの変更が必要でビジネスロジックと分離されておらず管理性が低いです。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →