Skip to main content

Use Case for AWS SQS Queues should have a redrive queue configured

  1. Configure AWS SQS Queues should have a redrive queue configured
  2. Use Case for AWS SQS Queues should have a redrive queue configured
  3. Triage Guides by Violation Type
    1. Triage AWS SQS Queues should have a redrive queue configured NO_REDRIVE_POLICY_CONFIGURED

Should I configure a DLQ / redrive policy for my AWS SQS Queue?​

Pros​

  1. Dead-letter queues (DLQs) assist in debugging by isolating unconsumed messages for examination (Amazon SQS dead-letter queues).
  2. DLQs are instrumental for monitoring and alerting on message failures, enhancing the system's reliability and transparency.
  3. DLQs can decrease overall message volume and mitigate the risk of disruptive "poison pill", or unprocessable messages. Without a DLQ, you're unable to set the maxReceiveCount property to limit the number of times a message can be received. Limiting receives potentially reduces cost and increases system reliability (When should I use a dead-letter queue?).
  4. DLQs are beneficial when applications do not depend on the sequence of messages (When should I use a dead-letter queue?).

Cons​

  1. DLQs must match the type (FIFO or standard) of their parent queues (How do dead-letter queues work?).
  2. DLQs and their associated queues need to be created within the same AWS account and region (How do dead-letter queues work?).
  3. Message expiration in a DLQ relies on the original enqueue timestamp, necessitating a sufficiently extended retention period to prevent premature deletion (How do dead-letter queues work?).
  4. DLQs are unsuitable for situations where continuous retrying of message transmission is required (When should I use a dead-letter queue?).
  5. DLQs are not advisable for FIFO queues when the precise order of messages is critical (When should I use a dead-letter queue?).