AWS SQS lambda trigger disabled automatically

Question

I have created aws SQS with lambda trigger. The issue I facing, is when message is send from sqs the lambda trigger automatically disconnected and also no log is generated in cloudwatch (log stream is generated). Anyone have any idea?

Lum

Does AWS SQS have the permission to invoke your AWS Lambda? – Roldan

If you Enable it, then manually send a message to the SQS queue, what happens? – Hilten

"the lambda trigger automatically disconnected" ...what does this mean? Disconnected, how, and evidenced by what? – Designation

aah, resolved it, I had set condition in my trust relationship that cause to disable lambda trigger. – Lum

@VaibhavPatil how did you figure out this condition? How did you disable this condition? – Gossett

Answer 1

For SQS Lambda triggers,

Your Amazon SQS role must include the following permissions:

1. lambda:CreateEventSourceMapping
2. lambda:ListEventSourceMappings
3. lambda:ListFunction

Your Lambda role must include the following permissions:

1. sqs:ChangeMessageVisibility
2. sqs:DeleteMessage
3. sqs:GetQueueAttributes
4. sqs:ReceiveMessage

Also Note,

• Your queue and Lambda function must be in the same AWS Region.
• FIFO queues don't support Lambda function triggers.
• You can associate only one queue with one or more Lambda functions.

For logs, check if your lambda has below cloudwatch permissions for generating logs

• logs:CreateLogGroup
• logs:CreateLogStream
• logs:PutLogEvents

Bilberry

Answer 2

I encountered this also. Ultimately the 'disabled' SQS/Lambda trigger seems like a symptom that could result from multiple root causes.

In my case it wasn't a permissions issue. The root cause was an issue with the 'event source mapping' that maps your SQS queue's 'EventSourceArn' to your Lambda function's 'FunctionArn'. I had deleted and recreated SQS queue with the same name. The result of this was the trigger being automatically disabled by AWS when the first SQS queue was deleted, but the mapping persisting in its 'disabled' state when the new queue was created.

The workaround here was just to manually delete the event source mapping. Once this was done, the 'disabled' trigger no longer persisted. There's a good answer/explanation on a related question here - https://mcmap.net/q/1773650/-aws-lambda-sqs-trigger-not-firing-after-queue-recreation

Binford

Answer 3

If your permissions are in place as explained by other solution here and it still doesn't work, this is what we found

Our SQS messages were encrypted via KMS keys which Lambda did not have access to , AWS marks it as disable out of box.

Matney

Answer 4

Following on from the @Oisín answer, for me this happened after I had deleted and recreated a queue that had a lambda function attached to it. On re-creation, the queue already had the lambda attached to it in a disabled state.

If you go the lambda's configuration page and the Triggers section you can delete the triggers. Then go back to your SQS Queue and the lambda reference should have disappeared. You can then re-attach it

Kieger

Answer 5

I know this is an old question but I figure I'd share as a related experience.

I had a lambda deployed and working (with three SQS triggers established and enabled). I later re-deployed the same lambda but changed the VPC, subnets, security groups and KMS key.

This caused one of the lambda triggers to disable itself. I'm guessing that during the deployment there was a blip which caused some issues with the event source mapping and AWS auto disabled it. All I had to do was manually enable it and things started working again as normal.

I had three triggers setup for three different queues on the same lambda. Only one of them auto-disabled and it only happened in 2 out of 6 regions. This queue was the main queue getting most of the events and these two regions were the most used regions. So I have a feeling it was just because of the higher traffic and more invocations that caused a confusion.

Good thing my retention policy on the queue was long enough for me to spot the issue and fix it.

Corwin