あるEコマース企業が、注文確定時にSQSキューからLambdaを呼び出して在庫を更新するシステムを運用している。ネットワーク障害や外部APIのタイムアウトにより、まれにLambdaが例外をスローして処理が失敗する。失敗した注文メッセージを失わずに後から再処理できるようにしたい。コードの変更を最小限に抑えつつ、処理失敗メッセージを保全する構成として最も適切なものはどれか。

正解: B

SQSトリガーのLambdaでは、処理が失敗してメッセージの削除が行われないとメッセージは可視性タイムアウト後にキューに戻り、再度Lambdaに配信される。これを最大受信数（maxReceiveCount）を超えた回数リトライしても失敗した場合、デッドレターキュー（DLQ）に自動的に移動させることができる。DLQに蓄積されたメッセージは後から調査・再処理が可能であり、コードを変更せずにSQSとLambdaの設定だけで実現できる。選択肢Aのメッセージ保持期間延長は失敗メッセージを「失わない」という目的には部分的に合致するが、正常処理されたメッセージも14日間残り続けるため、キューが肥大化して正常な処理を妨げるリスクがある。選択肢CのタイムアウトはエラーがネットワークやAPIタイムアウトに起因する場合には意味があるが、DLQのような保全メカニズムにはならない。選択肢DはDynamoDBへの手動保存という「コードの変更を最小限に」という要件に反するアプローチである。