Lambda Destinations and Dead Letter Queues

AWS Lambda supports two distinct mechanisms for handling the outcomes of asynchronous function invocations: Lambda Destinations and Dead Letter Queues (DLQs). Both serve to route events based on the execution result (success or failure), but they operate at different stages of the invocation lifecycle and have different capabilities.

The key difference is that Destinations can handle both success and failure, while DLQs handle only failure. Additionally, Destinations provide richer context (the invocation record) and can trigger other Lambda functions or EventBridge rules, enabling complex workflows.

For asynchronous invocations (e.g., from S3, SNS, EventBridge, or API Gateway with async integration), Lambda places the event into an internal queue. Lambda then attempts to execute the function. If the function succeeds, the result is handled by the success destination (if configured). If the function fails (throws an error or times out), Lambda retries the invocation up to two more times (for a total of three attempts), with a delay between retries (starting at 1 minute, increasing exponentially up to about 20 minutes). After exhausting retries, the event is routed to either the DLQ or the failure destination (if configured).

Lambda Destinations work by publishing an invocation record to the configured destination service. The record contains: - version: the function version - timestamp: the time of invocation - requestContext: the request ID and function ARN - responsePayload: the function's return value (for success) or error object (for failure) - responseContext: status code and function error (for failure)

Dead Letter Queues simply send the original event payload to the configured SQS queue or SNS topic. The payload is exactly what was passed to the function, with no additional metadata. This is a key difference: Destinations include the function's output, while DLQs only include the input.

You can configure Destinations and DLQs via the AWS Management Console, AWS CLI, or CloudFormation.

CLI example for Destinations:

aws lambda put-function-event-invoke-config \
  --function-name my-function \
  --destination-config '{"OnSuccess":{"Destination":"arn:aws:sqs:us-east-1:123456789012:my-dest-queue"},"OnFailure":{"Destination":"arn:aws:sns:us-east-1:123456789012:my-dest-topic"}}'

CLI example for DLQ:

aws lambda update-function-configuration \
  --function-name my-function \
  --dead-letter-config TargetArn=arn:aws:sqs:us-east-1:123456789012:my-dlq

Verification:

aws lambda get-function-event-invoke-config --function-name my-function
aws lambda get-function-configuration --function-name my-function | jq '.DeadLetterConfig'

A media company uses S3 to store user-uploaded images. An S3 event triggers a Lambda function to generate thumbnails. Occasionally, the function fails due to corrupt images or timeouts. The team configures a failure destination to an SQS queue. A separate Lambda function polls this queue, logs the error details, and sends a notification to the operations team via SNS. Additionally, a success destination sends the thumbnail metadata to an SQS queue for further processing (e.g., updating a database). This design ensures that both successes and failures are tracked. In production, the queue handles thousands of events per second. The team sets MaximumRetryAttempts to 1 (total 2 attempts) to reduce latency. The DLQ is not used because the failure destination provides richer error context.

An e-commerce platform uses EventBridge to trigger a Lambda function for order validation. The function calls an external payment gateway. If the gateway is down, the function fails. The team configures a DLQ as an SQS queue. The DLQ stores the original order events. A scheduled Lambda function runs every hour to reprocess messages from the DLQ. This is a simpler setup compared to Destinations, but the team loses the error details. They mitigate this by having the function log errors to CloudWatch before failing. In production, the DLQ accumulates messages during outages, and the reprocessing Lambda must handle idempotency. The team sets MaximumEventAge to 2 hours to avoid processing stale orders.