A dead-letter queue collects messages a consumer could not process, which means it often holds the strangest and sometimes most sensitive payloads you have. Treat it like a production data store: control which queues can feed it, match its encryption to the source, set retention on purpose, and alarm when anything arrives.
What a DLQ is
The AWS documentation describes DLQs as targets for messages that are not processed successfully, useful for debugging because you can isolate and inspect them. The dead-letter queue must be in the same account and Region as the source queue.
A redrive policy sets maxReceiveCount, the number of times a consumer can receive a message before it moves to the DLQ. Set it too low and one transient failure sends a good message away. Set it high enough for sensible retries.
Who may use the DLQ
The redrive allow policy states which source queues can use the dead-letter queue. The documentation says the default allows all source queues. You can instead allow specific queues by ARN, up to 10, or choose denyAll so the queue cannot be a DLQ.
Why it matters: a DLQ shared by many source queues mixes data from different trust levels, and anyone who can read it sees all of it. Prefer one DLQ per source queue or per team, and restrict the allow policy.
Retention is a data lifetime decision
For standard queues, expiry is based on the original enqueue timestamp, and that timestamp does not change when the message moves to the DLQ. The documentation's example: a message spends one day in the source queue, the DLQ retention is four days, so it is deleted after three more days. The stated best practice is to set the DLQ retention longer than the source queue retention.
For FIFO queues the enqueue timestamp resets on the move. The same documentation also warns against using a DLQ with a FIFO queue when you must not break exact message order.
From a privacy view, retention is also how long personal data lingers. Pick a number you can defend.
Encryption must match
Per the SQS encryption documentation, moving a message does not change its encryption state. An unencrypted source feeding an encrypted DLQ leaves messages unencrypted. Enable the same protection on both. See SQS encryption choices.
Operate it
- Alarm on any message arriving in the DLQ. The documentation points to CloudWatch alarms for this.
- Limit read access to the people who debug that service.
- Treat redrive as a deliberate action, since replaying failed messages can repeat their side effects.
- Do not replay blindly. A message that failed may be malformed on purpose.
Poison messages and attackers
A DLQ also contains the output of anyone who sent your consumer something it choked on. Review it as evidence. Repeated failures from one producer identity are worth a look.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can a DLQ live in another region?
No. The documentation requires the same account and Region as the source queue.
Should retention be shorter or longer than the source queue?
The documentation advises longer for the DLQ, because the original enqueue time keeps counting for standard queues.
Sources
Last reviewed: 19 October 2026.
