Question

Difficulty: Very hardDebugging Lambda Execution and Configuration Issues

A developer is troubleshooting an application where an AWS Lambda function processes batch orders from an Amazon SQS standard queue. The Lambda function is configured with a timeout of 45 seconds and a batch size of 10 messages. The SQS queue is configured with a visibility timeout of 60 seconds and a redrive policy targeting a Dead-Letter Queue (DLQ) with a maxReceiveCount of 3. During peak hours, the developer observes that some messages are processed multiple times by different Lambda invocations, and the DLQ receives an increased number of messages, even though no errors are logged by the function code. CloudWatch Logs indicate that some executions time out at 45 seconds under heavy database load, while others complete in under 5 seconds. Which of the following changes should the developer make to resolve these issues?

  1. Enable 'Report Batch Item Failures' on the Lambda event source mapping, modify the function to return a list of failed message IDs in the response, and increase the SQS queue's visibility timeout to 270 seconds.Answer
  2. B
    Deploy the Lambda function in a VPC with private subnets, configure an interface VPC Endpoint for Amazon SQS, and update the function's IAM execution role to allow SQS DeleteMessage actions.
  3. C
    Decrease the SQS queue's visibility timeout to 15 seconds to trigger faster retries when the database is congested, and increase the Lambda function memory size to 3008 MB.
  4. D
    Implement a global SQS client helper outside the Lambda handler to manually delete processed messages from the queue, and increase the Lambda function timeout to 90 seconds.

Answer

Enable 'Report Batch Item Failures' on the Lambda event source mapping, modify the function to return a list of failed message IDs in the response, and increase the SQS queue's visibility timeout to 270 seconds.
Enabling 'Report Batch Item Failures' on the event source mapping and returning the `batchItemFailures` array containing the failed message IDs ensures that SQS deletes the successfully processed messages and only retries the ones that failed. Furthermore, increasing the SQS visibility timeout to 270 seconds aligns with the AWS recommendation of setting the visibility timeout to at least 6 times the Lambda function timeout (6×45=2706 \times 45 = 270 seconds) to accommodate processing delays and retries.

Step-by-Step Solution

1
Analyze the relationship between the Lambda timeout and the SQS visibility timeout.
The current visibility timeout is 60 seconds, which is only slightly higher than the Lambda timeout of 45 seconds. AWS best practice recommends that SQS visibility timeout should be configured to at least 6 times the Lambda function's timeout (6×45=2706 \times 45 = 270 seconds) to prevent messages from becoming visible again during retry cycles.
Ensuring the visibility timeout is appropriately scaled prevents duplicate processing of active invocations.
2
Analyze the cause of duplicate processing when Lambda times out on a batch of SQS messages.
By default, if a Lambda function times out or throws an error while processing a batch, SQS considers the entire batch of 10 messages to have failed. Consequently, successfully processed messages in that same batch are not deleted and will be reprocessed, causing duplicate writes.
Identifying why successfully processed messages are being sent back to the queue.
3
Determine the solution for handling partial batch failures.
Enabling 'Report Batch Item Failures' in the SQS event source mapping allows the Lambda function to return a list of failed message IDs (under the keys `batchItemFailures` and `itemIdentifier`). SQS then deletes only the successful messages from the queue and retries only the failed ones.
Configuring the Lambda function to safely handle partial failures without reprocessing successful messages.

Key Concept

SQS Event Source Mapping, Partial Batch Failures, and Visibility Timeout Alignment.
Estimated Time:3m 0s
Rate this question