Chapter 1 Overview of SQS Redrive Allow Policy

Recently, I encountered the aws_sqs_queue_redrive_allow_policy in Terraform and became curious about the benefits it offers compared to merely utilizing an SQS queue along with a Dead Letter Queue (DLQ).

Below is an illustration of this policy as found in Terraform documentation:

resource "aws_sqs_queue" "src" {

name = "srcqueue"

redrive_policy = jsonencode({

deadLetterTargetArn = aws_sqs_queue.example.arn

maxReceiveCount = 4

})

}

resource "aws_sqs_queue" "example" {

name = "examplequeue"

}

resource "aws_sqs_queue_redrive_allow_policy" "example" {

queue_url = aws_sqs_queue.example.id

redrive_allow_policy = jsonencode({

redrivePermission = "byQueue",

sourceQueueArns = [aws_sqs_queue.src.arn]

})

}

So, why not simply implement an SQS queue along with a DLQ, as shown in this example?

resource "aws_sqs_queue" "src" {

name = "srcqueue"

redrive_policy = jsonencode({

deadLetterTargetArn = aws_sqs_queue.example.arn

maxReceiveCount = 4

})

}

resource "aws_sqs_queue" "example" {

name = "examplequeue"

}

After conducting some research, I have identified several reasons for leveraging a redrive policy:

The aws_sqs_queue_redrive_allow_policy serves as an enhancement to the basic SQS redrive policy, granting more precise control over which source queues are permitted to redirect messages to a specific DLQ.

In default settings, when a redrive policy is configured on a source queue to transfer failed messages to a DLQ, that action is automatically permitted. However, the aws_sqs_queue_redrive_allow_policy introduces an extra layer of permission validation to ensure that only designated source queues can send messages to that DLQ.

Here are some compelling reasons to consider using the aws_sqs_queue_redrive_allow_policy:

1. Security & Permission Control: In a scenario with multiple teams managing their own applications and SQS queues, a central DLQ may be overseen by a dedicated team. Without the aws_sqs_queue_redrive_allow_policy, any team could potentially direct their queue's redrive policy to this central DLQ. By implementing the redrive allow policy, the central team can explicitly define which queues are authorized to redirect messages to the central DLQ.
2. Avoiding Unintentional Redrives: In extensive systems with numerous SQS queues, there's a risk of someone inadvertently directing their redrive policy to the incorrect DLQ. The aws_sqs_queue_redrive_allow_policy acts as a protective measure against such errors.
3. Auditing & Compliance: Organizations requiring strict data flow control for auditing and compliance purposes can benefit from having a clearly defined list of queues permitted to redrive to a DLQ. This ensures that only validated and authorized queues can send messages to the DLQ.
4. Complex Architectures: In more intricate scenarios, you might encounter DLQs that process messages differently depending on their source. By utilizing the aws_sqs_queue_redrive_allow_policy, you can dictate which source queues are allowed to redirect messages to a specific DLQ designed for those messages.

Chapter 2 Summary of Benefits

While simpler applications can function adequately with just a redrive policy set on the source queue, the aws_sqs_queue_redrive_allow_policy provides an added layer of control and security. This is particularly advantageous in larger, more complex, or regulated environments.