After deploying a fix, how do you replay the messages sitting in an Amazon SQS dead-letter queue back to the queue they came from, and what should you verify before you start?

## The operation SQS gives you Before 2023 the standard answer to "how do you replay a DLQ" was "write a Lambda that receives from the DLQ and sends to the source queue, and be careful with idempotency". SQS now ships the operation natively as a **message move task**, exposed through three APIs: - `StartMessageMoveTask` — begins moving messages off a dead-letter queue. - `ListMessageMoveTasks` — reports status and progress for a source queue's tasks. - `CancelMessageMoveTask` — stops one in flight. The parameters that matter: ```bash aws sqs start-message-move-task \ --source-arn arn:aws:sqs:us-east-1:111122223333:orders-dlq \ --max-number-of-messages-per-second 10 ``` `SourceArn` is required and must be a dead-letter queue — specifically a DLQ whose sources are other SQS queues. A queue that only collects failures from other services is not a valid source for the task. `DestinationArn` is optional. Omit it and messages return to the queue or queues they originally came from, which is the common case. Supply it to divert the replay somewhere else — a quarantine queue, or a separate queue consumed by a repair worker — when you want the messages inspected or transformed rather than reprocessed as-is. `MaxNumberOfMessagesPerSecond` is optional and is the parameter experienced operators reach for. Without it the task moves as fast as it can, and if the DLQ holds a large backlog you have just converted a quiet incident into a thundering herd against whatever downstream was already struggling. Throttling to a rate your consumers and downstream dependencies can absorb turns the replay into a controlled drain. One task may be active per source queue at a time, so replay is a serialised operation you can reason about, not something a script can accidentally start five copies of. ## The move is destructive to the DLQ Messages are moved, not copied. As each one is sent to the destination it is removed from the dead-letter queue. If the replay fails downstream, your safety net is now the source queue's own redrive policy sending them back — which works, but each round trip consumes retention budget measured from the original enqueue time. This is why the pre-flight is the substance of the answer. ## The pre-flight **Is the fix actually live?** Not merged, not built — deployed, serving, and receiving traffic. Replaying into the old code produces exactly the same failures plus a second pass through `maxReceiveCount`. **Was the failure transient or structural?** Retry-safe causes — a downstream outage, a throttled dependency, a bad deploy since rolled back — replay cleanly. Malformed payloads, references to entities that no longer exist, or messages a schema change made unparseable will fail again no matter how healthy the consumer is. Receiving a handful with `ReceiveMessage` and reading them is a two-minute check that saves an hour. **Are the consumers healthy and scaled?** A replay lands as a burst. If the consumer fleet is sized for steady state, throttle the task or scale out first. **Is reprocessing safe?** Some of these messages may have been partially processed before failing — a row written, an email sent, a charge attempted. Whether replay is safe depends on the handler's idempotency, and if it is not idempotent, the honest options are to make it so, to route the replay to a repair consumer via `DestinationArn`, or to triage by hand. **Is the message still meaningful?** A message that has been sitting for a week may reference a state that no longer exists, or represent a decision that has since been superseded. Replaying stale work can be worse than dropping it. ## Watching it and stopping it ```bash aws sqs list-message-move-tasks \ --source-arn arn:aws:sqs:us-east-1:111122223333:orders-dlq ``` The result reports the task's status along with how many messages have moved and how many failed. Watch the source queue's own error rate and the DLQ depth at the same time: if messages start arriving back in the DLQ while the task runs, the fix did not work, and `CancelMessageMoveTask` stops the bleeding immediately. ## The framing that reads as senior The API is the easy half. What distinguishes a strong answer is treating replay as a change to production: verify the fix, choose a rate, watch a signal that tells you it is working, and know the abort command before you start. Candidates who answer only "there's a redrive button in the console" have described the mechanism and skipped the operation.