SQSキューを使用したメッセージ処理システムで、Lambda関数がメッセージ処理中に失敗した場合、同じメッセージを何度も再処理してLambdaが無限ループするという問題（ポイズンピルメッセージ）が発生している。ダウンタイムなしでこの問題を解決し、失敗したメッセージを後で調査できるようにするベストプラクティスはどれですか？
SQS DLQはポイズンピルメッセージの標準的な解決策です。maxReceiveCountを3〜5程度に設定することで、指定回数失敗したメッセージは自動的にDLQに隔離されます。DLQのメッセージは後から調査・再処理が可能なため、ダウンタイムなしで問題を解決できます。なお、Lambda Destinations（OnFailure）はSNS・S3・EventBridgeなど非同期呼び出しに適用される機能であり、SQSイベントソースマッピングには適用されません。 選択肢AのSQSメッセージ保持期間の短縮は失敗メッセージを調査できなくなるため、後から調査できるようにする要件に反します。 選択肢CのLambda関数のタイムアウト短縮は処理時間を制限しますが、ポイズンピル問題の根本的な解決にはなりません。 選択肢DのSQS FIFOキューはメッセージ順序を保証しますが、ポイズンピル問題の解決策にはならず、切り替えコストも高くなります。