Description
Without a retention path for events discarded after Lambda asynchronous retries or event-age limits, investigation and reprocessing become harder. A DLQ is one option; its absence alone does not establish event loss when another failure destination or recovery path exists.
Potential impact
- Processing gaps can be difficult to recover if discarded events are not retained.
- Failures may go unnoticed when delivery and follow-up processing are not monitored.
Remediation
Configure a DLQ or failure destination according to asynchronous recovery requirements. For dead_letter_config, use a standard SQS queue or standard SNS topic ARN and grant delivery permissions to the execution role. Monitor delivery errors and test retention and reprocessing.
Examples
These excerpts cover asynchronous failure handling. Set var.lambda_runtime to a supported runtime compatible with the deployment file. Prepare the execution role, SNS topic, and subscribers separately. For an SQS event source, configure the DLQ on the queue itself.
Before
resource "aws_lambda_function" "example" {
function_name = "lambdaWithoutDLQ"
role = aws_iam_role.lambda_exec_role.arn
handler = "index.handler"
runtime = var.lambda_runtime
filename = "lambda.zip"
}
After
resource "aws_lambda_function" "example" {
function_name = "lambdaWithoutDLQ"
role = aws_iam_role.lambda_exec_role.arn
handler = "index.handler"
runtime = var.lambda_runtime
filename = "lambda.zip"
dead_letter_config {
target_arn = "arn:aws:sns:us-east-1:123456789012:my-dlq-topic"
}
}
The revision adds an SNS DLQ to the same function. SNS relays failed events to subscribers, so verify the receiving and retention path. Permissions or size limits can prevent delivery; configuration alone does not guarantee retention.