Why isn't my Lambda function that's configured with SQS as the event source invoked?

Resolution

Prerequisites

• Confirm that the Lambda function is configured with Amazon SQS as the event source.
• Confirm that the Lambda function's AWS Identity and Access Management (IAM) role has the permissions that it needs to fetch messages from the SQS queue.
• Check the Amazon CloudWatch metrics for your function for invocations and SQS queue to confirm that there are messages available in the queue. If messages aren't visible or sent to the SQS queue, then make sure that the producer has the necessary permissions. The user or role must have the following Amazon SQS and AWS Key Management Service (AWS KMS) permissions:
  sqs:SendMessage
  kms:GenerateDataKey
  kms:Decrypt

Note: If the queue isn't encrypted, then you don't need AWS KMS permissions.

Check that the Lambda function and SQS queue URLs are correct

Confirm that the Lambda function Amazon Resource Name (ARN) and the SQS queue URL in the event source mapping on the Lambda function are correct. Also, turn on event source mapping.

1. Open the Lambda console.
2. In the navigation pane, choose Functions.
3. Select the function that you want to check.
4. Choose the SQS trigger and expand it to check that the SQS queue URL is correct. Also, confirm that the trigger status is turned on. For more information, see Why did my Lambda Amazon SQS trigger get disabled?

To perform these checks, you can also run the list-event-source-mapping command.

Example:

aws lambda list-event-source-mappings --function-name <my-function> --region <region-name>

Note: Replace <my-function> with the name of your Lambda function, and replace <region name> with your AWS Region.

Check the Lambda function permissions

If the Lambda IAM role has permissions to poll messages from the SQS queue, then check the SQS queue's access policy. Look for deny rules that might restrict the Lambda function.

1. Open the Amazon SQS console.
2. In the navigation pane, choose Queues.
3. Select the SQS queue, and then choose the Access Policy tab.
4. Review the policies for any deny policies that might block Lambda traffic. If there's a policy that blocks traffic, then add a condition in the deny statement to ignore requests that come from Lambda.

Your Lambda function IAM must have the following permissions:

• DeleteMessage
• GetQueueAttributes
• ReceiveMessage

Check the encryption settings for the queue

If the queue is encrypted, then the Lambda function's IAM role needs the permissions to perform AWS KMS actions. Without the necessary permissions, the Lambda function can't consume messages from the SQS queue. If the Amazon SQS queue is configured with AWS KMS encryption, then complete the following tasks:

• Make sure that the AWS KMS key exists.
• Make sure that the Lambda function role has kms:Decrypt permissions.
• Make sure that the AWS KMS key policy permissions are configured to allow actions from the Lambda role.

Note: Amazon SQS queues with the default key (AWS KMS key for Amazon SQS) can't invoke a Lambda function in a different AWS account.

Check if the specific Lambda function is throttled

Lambda has a Regional concurrency limit. If other functions in the AWS Region actively use this capacity to its maximum, then throttles can occur on the function. This can happen even if the function itself doesn't reach the maximum capacity.

If you set a reserved concurrency to 0 on the function, then no invocations occur on the function. All messages from Amazon SQS are throttled. Check the Regional ConcurrentExecutions (maximum) metric and the function's Throttle (SUM) metrics in Amazon CloudWatch. Verify whether the Regional capacity is reached and whether there are any throttles on the function. Make sure that there's enough capacity to invoke the function and process SQS messages.

Confirm that there are no other active consumers on the same SQS queue

If there's more than one active customer on the SQS queue, then these customers might consume your messages. SQS messages are designed for one customer to consume the messages at a time. If another customer consumes the SQS queue, then your Lambda function might not receive any messages when it polls the SQS queue. Use the Amazon SQS console to verify that there aren't any other Lambda invokes or Amazon SQS invokes active.

Note: Other customers might pull messages from the SQS queue programmatically. These pulls don't appear in the console.

Check if the SQS event source is configured with filters

Check if the SQS event source is configured with any filters. If your SQS event source is configured with filters, then make sure you don't filter out any Amazon SQS messages.

1. Open the Lambda console.
2. In the navigation pane, choose Functions.
3. Select the function that you want to check.
4. Choose the SQS trigger, and then verify the Filter criteria. If the trigger configuration doesn't show they key name, then no filter is configured. If a filter criteria is configured, then review the filter to confirm that it allows Lambda to process valid messages. To temporarily remove the filter criteria, choose Edit.
5. If the function is invoked after you remove the filter, then modify the filter criteria to match your use case.

For more information, see Filtering with Amazon SQS and Best practices for implementing Lambda event filtering.

Related information

Using Lambda with Amazon SQS

Why isn't my Lambda function with an Amazon SQS event source scaling optimally?

Why is my Lambda function retrying valid Amazon SQS messages and placing them in my dead-letter queue?