AWSは最近、AWS SDKまたはコマンドラインインターフェイスを使用したSQSのデッドレターキューのリドライブのサポートを発表した。この新しい機能により、開発者は既存のデッドレターキューから処理されていないメッセージを元のキューに戻すことができる。
エラーが発生すると、SQSは消費されなかったメッセージをデッドレターキュー（Dead-Letter Queue:DLQ）に移動し、開発者は正常に処理されなかったメッセージを確認してアプリケーションの障害に対応できる。AWSのプリンシパル・デベロッパー・アドボケイトであるSébastien Stormacq氏は次のように説明する。
コンシューマー・アプリケーションがメッセージを処理するたびに、メッセージ受信カウントは 1 ずつインクリメントされる。メッセージ受信カウントが最大受信数を越えると（ReceiveCount＞maxReceiveCount）、Amazon SQSは人による分析とデバッグを行うためにメッセージを指定したDLQに移動します。そのためDLQにアラームを関連付け、このようなイベントが発生したときに通知を送信させるのが一般的です。
失敗したメッセージがデバッグされるか、コンシューマー・アプリケーションがそれを消費できるようになると、新しいリドライブ機能はメッセージをソース・キューに戻すので、分散システムの拡張時に処理されなかったメッセージのライフサイクルをプログラムで管理できる。
以前は、コンソールでメッセージを手動で処理できなかった。AmptのCEOで創設者のJeremy Daly氏は当時、こう書いている。
これは機能でもAPIでもなく、AWS Consoleでのみ利用可能な "人が関わる体験"です。欲しいですか？はい！AWS Consoleにログインして使いたいですか？そんなことはありません。
DLQ メッセージの再処理に開発者は以下のタスクを使用できる。 StartMessageMoveTaskデッドレターキューから新しいメッセージ移動タスクを開始する。 CancelMessageMoveTaskメッセージ移動タスクをキャンセルする。ListMessageMoveTasks 指定されたソース・キューの最新のメッセージ移動タスク（最大 10 個）を取得する。
この機能はコミュニティから好評を得ており、MUSIC Tribeのクラウド＆プラットフォーム責任者であるTiago Barbosa氏は次のようにコメントしている。
これはいい改善です。私がDLQを使うのが好きでなかった理由のひとつは、そこで終わったアイテムを再処理するメカニズムを構築する必要があることです。
Curantis SolutionsのCTOであるBenjamen Pyle氏が、GolangとStep Functionsを使ってメッセージをリドライブする方法について記事を書いた。
DLQの設定では、メッセージを送信元のキューに送り返すか、別のキューに送り返すかを、カスタム宛先オプションのARNを使って指定できる。PostNLのリードエンジニアでAWS Serverless HeroのLuc van Donkersgoed氏は次のようにツイートしている。
元のキューにリドライブすればいいだけだ。これは、任意の宛先キューを指定することができるので、非常に素晴らしい。これはLambda関数のクラス全体だ…パッと消えた。
ドキュメントを読むと、いくつかの制限事項があることがわかる。 SQSはデッドレターキューのリドライブを標準的なキューに対してのみサポートしており、再処理中のメッセージのフィルタリングや変更はサポートしていない。さらに、DLQのリドライブ・タスクは最大36時間まで実行可能で、1アカウントにつき最大100個のリドライブ・タスクをアクティブにできる。開発者の中には、Step機能でサポートがないことに疑問を持つ人もいる。
SQSは自動的にDLQを作成しないため、未消費メッセージを受信する前にキューを作成し、設定する必要がある。