Introduction
Hi, I'm miruky.
An Amazon SQS dead-letter queue is most useful when you can inspect a failed message and return it to normal processing after fixing the cause. This hands-on exercise builds that lifecycle in the AWS Console: create a queue pair, force one message into the DLQ, redrive it, and verify that it returns to the source queue.
The procedure uses Standard queues in us-east-1, the N. Virginia Region. It uses a maximum receive count of 1 only to make the failure reproducible; AWS recommends a higher value in real workloads so that transient receive failures still have room for retries.
Amazon SQS charges by request with no minimum fee, and the current Free Tier includes one million requests per month. Check the pricing page before running the exercise if your account already has SQS traffic or if you use services that add separate charges.
1. Open Amazon SQS in the target Region
Open the Amazon SQS console and make sure that you are working in the N. Virginia Region before creating either queue.
The page shows Queues (0) and No queues, so this walkthrough begins without an existing queue in the list. The Region selector shows United States (N. Virginia), which is the Console wording captured for the N. Virginia Region in this session.
2. Create the dead-letter queue
Start a queue-creation form for the DLQ. Use the generated name shown below so that you can distinguish the two temporary queues while following the screenshots.
The selected type is Standard, and the queue name is miruky-phaiishofnwqyzbc. Message retention period is set to 14 Days, giving failed messages the longest SQS retention window while they await diagnosis.
Submit the configured queue and wait for AWS to finish creation.
The green banner states Queue miruky-phaiishofnwqyzbc created successfully. The Start DLQ redrive control is disabled because the queue does not contain a failed message yet.
3. Create the source queue and attach the DLQ
Create another Standard queue. A short visibility timeout keeps this demonstration moving, but production values should reflect the longest time a consumer needs to process and delete a message.
The source queue is named miruky-kuxxycndnscnavou. Its Visibility timeout is 10 Seconds, while Message retention period remains 4 Days.
Continue to the optional dead-letter queue settings in the same form.
Dead-letter queue is Enabled, the selected destination ends with miruky-phaiishofnwqyzbc, and Maximum receives is 1. The account portion of the queue ARN is intentionally redacted; it is not needed to reproduce the configuration.
Submit the source-queue form and wait for its details page.
The banner states Queue miruky-kuxxycndnscnavou created successfully. The page also exposes Send and receive messages, which is the path used to create and consume the test message.
4. Force one message into the DLQ
Open the send-and-receive page for the source queue. Enter this JSON as the message body and submit it:
{"event":"delivery-check","attempt":1}
The notification reads Your message has been sent and is ready to be received. The successful send state is visible before any consumer polls the queue. The details dialog contains a generated Message ID, which confirms the individual message accepted by SQS without exposing account data.
Close the details dialog and poll the source queue once. Do not delete the returned message.
The polling panel reports Success, and Messages (1) contains a row whose Receive count is 1. Leaving the message undeleted allows its visibility timeout of 10 seconds to expire, which makes it eligible for another receive attempt.
Wait at least 10 seconds, poll again, then return to the queue list and refresh it.
The source queue now shows 0 under Messages available, while the DLQ shows 1. That split is the visible failure state: the message left the source queue after exceeding the configured receive limit and is available for inspection in the DLQ.
Open the DLQ, poll for messages, select the remaining row, and view its body.
The Body tab displays {"event":"delivery-check","attempt":1}, matching the payload sent earlier. A DLQ preserves the failed message for diagnosis; receiving it in this view does not delete it.
5. Redrive the message to its source queue
Return to the DLQ, then continue into redrive configuration.
Keep Redrive to source queue(s) selected as the message destination and keep System optimized selected for velocity control. SQS uses the recorded source as the destination and controls the movement rate.
Submit the redrive operation and wait for the task status to finish.
Percent processed is 100%, Status is Successfully completed, and Redrive destination is Source queue(s). AWS documents that a redriven message is treated as a new message with a new message ID and enqueue time, so consumers should identify work from message content or application attributes rather than the earlier SQS message ID.
Return to the queue list and refresh it one final time.
The source queue now shows 1 under Messages available, and the DLQ shows 0. This is the final verification: the failed payload has left the DLQ and is available to the source queue's consumers again.
Wrap-up
The Console run demonstrated the complete DLQ recovery path with retained evidence: a message reached the source queue, exceeded the receive limit, appeared in the DLQ, completed a redrive task, and returned to the source queue. For a production queue, raise the receive limit, monitor DLQ depth and message age, and address the consumer failure before redriving a backlog.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
Top comments (0)