Why doesn't my Amazon SQS queue receive EventBridge notifications?

Resolution

Check the EventBridge rule metrics for invocation failures

Check the Amazon CloudWatch console for the TriggeredRules, Invocations, and FailedInvocations EventBridge metrics.

If there's no data for TriggeredRules, then the EventBridge rule didn't run. To resolve this issue, check your source configuration to make sure that you configured it to send events. Also, make sure that your source configuration matches the rule's event pattern. For more information, see How do I troubleshoot issues with EventBridge rules?

If you see data for both Invocations and FailedInvocations, then the invocation failed. This typically occurs because of missing AWS Identity and Access Management (IAM) permissions. To troubleshoot this issue, proceed to the next section.

Note: To check whether your queue receives notifications, check the NumberOfMessagesSent metric.

Confirm that EventBridge has the required permissions to send messages to your queue

The resource-based policy for your queue must allow EventBridge to send messages to the queue. Make sure that you enter events.amazonaws.com as the Service and sqs:SendMessage as the Action.

Make sure that your execution role has the required permissions

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

If you use an execution role, then make sure that the role has permission to invoke the queue. If you used the EventBridge console to create the role, then the console automatically adds the required permissions to the rule's attached IAM role. If you used the AWS CLI, an AWS SDK, or AWS CloudFormation to create a rule, then you must manually add the role permissions.

To check the execution role permissions, complete the following steps:

1. Open the EventBridge console.
2. Choose Rules, and then choose the EventBridge rule.
3. Choose the Target tab, and then choose the IAM role for the rule.
4. Under Permissions, review the policy and trust relationship.
   Example policy that allows the role to invoke the queue:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sqs:SendMessage"
               ],
               "Resource": [
                   "arn:aws:sqs:region:account-id:queue-name"
               ]
           }
       ]
   }

   Example trust relationship that allows the role to invoke the queue:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "TrustEventBridgeService",
               "Effect": "Allow",
               "Principal": {
                   "Service": "events.amazonaws.com"
               },
               "Action": "sts:AssumeRole",
               "Condition": {
                   "StringEquals": {
                       "aws:SourceAccount": "account-id",
                       "aws:SourceArn": "arn:aws:events:region:account-id:rule/bus-name/rule-name"
                   }
               }
           }
       ]
   }

   Note: Replace arn:aws:sqs:region:account-id:queue-name with your queue Amazon Resource Name (ARN), account-id with your AWS account ID, and arn:aws:events:region:account-id:rule/bus-name/rule-name with your rule ARN.

You can also use the GetRole API to check the IAM policy. Or, run the following get-role AWS CLI command:

aws iam get-role \
          --role-name Test-SQS-Role

Note: Replace Test-SQS-Role with your role name.

If the IAM role is missing permissions, then update the role's trust policy or permissions policy.

Confirm that your encrypted queue has the required AWS KMS permissions

If your queue is encrypted, then you must create a customer managed AWS Key Management Service (AWS KMS) key. Then, use the custom key to configure server-side encryption (SSE).