What is the RedriveAllowPolicy attribute on an Amazon SQS queue, and what does its redrivePermission setting control?

## The asymmetry it fixes The dead-letter relationship in SQS is declared in one place only: the source queue's `RedrivePolicy`, naming a `deadLetterTargetArn`. The target queue is not consulted and its own attributes carry no trace of who points at it. In a single-team account that is harmless. In a shared account it is a real problem — any queue owner in the same account and Region can name your queue as their dead-letter queue, and the first you learn of it is unfamiliar messages appearing in a queue you thought you understood. `RedriveAllowPolicy` closes that gap. It is a queue attribute set on the *target*, and it is a small JSON document: ```json { "redrivePermission": "byQueue", "sourceQueueArns": [ "arn:aws:sqs:us-east-1:111122223333:orders", "arn:aws:sqs:us-east-1:111122223333:orders-priority" ] } ``` ## The three permission modes **`allowAll`** is the default, and it is what every queue has unless you say otherwise. Any queue in the same account and Region may set this queue as its dead-letter target. Convenient, and fine for a queue whose only job is to be a DLQ for one service. **`denyAll`** forbids all of it. This is the right setting on ordinary work queues that should never accidentally become somebody's DLQ, and on a queue you are decommissioning as a DLQ once you have drained it — it stops new sources attaching while you finish the migration. **`byQueue`** is the explicit allow-list. It requires a `sourceQueueArns` array naming the exact queues permitted, and it is the mode to use for a shared DLQ that legitimately serves several sources within one service. The list is bounded, so `byQueue` is not a scaling mechanism for dozens of sources; if you find yourself pressing against the limit, that is a signal the DLQ is serving too many owners and should be split. Attempting to set a `RedrivePolicy` that the target's `RedriveAllowPolicy` forbids fails, so enforcement happens at configuration time rather than silently at runtime. ## Where it fits operationally The reason to care is not primarily security — an SQS queue policy already governs who can call the SQS APIs, and this attribute is not an IAM policy. It is about **operational ownership**. A dead-letter queue is only useful if the presence of a message in it means one specific, well-understood thing: "a message from *my* pipeline failed repeatedly". As soon as a second, unrelated source is dumping into the same queue, your "any message is an incident" alarm starts paging you for someone else's failures, and a replay task risks moving their messages into your source queue. `byQueue` keeps that invariant enforced by the platform rather than by convention. ```bash aws sqs set-queue-attributes \ --queue-url https://sqs.us-east-1.amazonaws.com/111122223333/orders-dlq \ --attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"arn:aws:sqs:us-east-1:111122223333:orders\"]}"}' ``` As with `RedrivePolicy`, the value is passed as a JSON string, which is a frequent source of confusion when writing it by hand. ## The name trap The word "redrive" appears in three distinct SQS concepts and candidates conflate them constantly: - `RedrivePolicy` — on the source queue: where failures go, and after how many deliveries. - `RedriveAllowPolicy` — on the target queue: who is allowed to send failures here. - The message move task (`StartMessageMoveTask`) — the operation that replays messages *out of* a DLQ. Only the third one moves any message. The first two are configuration, and `RedriveAllowPolicy` in particular does not grant, restrict, or otherwise touch permission to run a replay — that is governed by ordinary IAM permissions on the SQS API. Getting these three straight in one sentence is a cheap way to sound like you have operated this rather than read about it.