Should I disable lambda retry when using SQS and DLQ?

Question

I deployed a lambda, SQS standard queue and Dead letter queue on AWS. And I configured maxReceiveCount in the queue to retry before putting events to DLQ. Lambda pulls events from SQS queue in batch and process each event sequently. My question is about how retry works in case of error. There are two retries, one is on lambda maximumRetryAttempts, the other is on SQS and DLQ. Should I disable the lambda one?

In function, when it processes one event it calls deleteMessage on sqs to delete it. If there is any event that throws exception, the function throws it to lambda to make the retry happen so that it won't retry the success events.

But lambda itself has a maximumRetryAttempts and should I set it to 0? otherwise, will it retry before return to SQS? If I don't disable it, will the retry to process the whole batch of events including the success one?

Answer 1

Not sure which maximumRetryAttempts on lambda you are referring to. But When you use SQS with Lambda through event source mapping, as its done by default, there is no any retry parameter on lambda.

The only retry that applies is set at SQS, not lambda.

The retry option for lambda I can think of, and maybe you are thinning off as well, is for asynchronous invocation. This does not apply for SQS, as your lambda is invoked synchronously with SQS:

Lambda polls the queue and invokes your Lambda function synchronously with an event that contains queue messages.

Answer 2

Lambda Function can be invoked in three different ways:

1. Lambda reads from and invokes function. Ex: From SQS, Kinesis, etc.
2. Function invoked synchronously. Ex: From ApiGateway, ELB, etc.
3. Function invoked asynchronously. Ex: From S3 Events, SNS, Cloudwatch events etc.

Below Retry attempts is applicable for Asynchronous invocations(option 3 above)

For SQS Failures, we have two options:

1. DLQ on SQS itself.
2. Destination on Lambda. This could be SNS, another lambda, event bridge and another SQS queue. With this option, we can send both failures and success events.

Note: We don't need to call deleteMessage within lambda, lambda poller will delete message from SQS, when lambda returns success.