ある企業のイベント駆動型注文処理システムでは、非同期呼び出しのLambda関数が最大リトライ後も失敗するケースがあります。DevOpsチームは以下の要件を満たすエラー処理を実装したいと考えています： ①失敗イベントの完全なペイロードと詳細なエラーコンテキスト（リクエストID・試行回数等）を保持する、 ②スロットリングエラーは再処理キュー（SQS）に送り、ランタイムエラーはアラート通知（SNS）に振り分ける、 ③成功時は後続のLambda関数を起動する、 ④最大試行回数と最大イベント経過時間を設定する。最も適切な実装方法はどれですか？
Lambda Destinationsは非同期関数の成功・失敗それぞれに転送先（Lambda/SNS/SQS/EventBridge）を個別設定でき、失敗時にはエラー情報・元イベントペイロード・試行回数・リクエストIDを含む詳細コンテキストが転送されます。EventBridgeを転送先にするとルールのeventパターンでerrorTypeを参照した動的ルーティングが実現できます。最大試行回数（0〜2回）と最大イベント経過時間（60秒〜21600秒）も非同期呼び出し設定で構成可能です。 選択肢Aの（SQS DLQ）は失敗時のみ対応で成功時の後続処理転送ができず、DestinationsほどのエラーコンテキストがDLQメッセージに含まれません。 選択肢Cの（DynamoDB）ポーリングはリアルタイム性が低いです。 選択肢Dの（AWS Step Functions）は有効ですが既存の非同期呼び出しパターンを変更する必要があり実装コストが高いです。