When an SQS queue fails to receive messages from an SNS topic, the issue almost always comes down to permissions, subscription configuration, or message filtering. This is a common integration challenge in AWS, and the root cause can be subtle. This article walks through each possible cause with concrete diagnostic steps and fixes.

How SNS-to-SQS Integration Works

Amazon SNS (Simple Notification Service) publishes messages to topics. Subscribers to those topics receive the messages. When an SQS queue subscribes to an SNS topic, SNS pushes messages directly into the queue. This requires three things to be correct: the subscription must be confirmed, the SQS queue policy must allow SNS to send messages, and the message format must be compatible.

Cause 1: SQS Access Policy Missing SNS Permission

This is the most common cause. The SQS queue must have a resource policy that explicitly allows the SNS topic to send messages to it. Without this policy, SNS silently drops the messages with no error visible on the SNS side.

Check the current queue policy:

aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-queue \
  --attribute-names Policy

If the policy is empty or does not reference your SNS topic, set the correct policy:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Principal": {
7        "Service": "sns.amazonaws.com"
8      },
9      "Action": "sqs:SendMessage",
10      "Resource": "arn:aws:sqs:us-east-1:123456789012:my-queue",
11      "Condition": {
12        "ArnEquals": {
13          "aws:SourceArn": "arn:aws:sns:us-east-1:123456789012:my-topic"
14        }
15      }
16    }
17  ]
18}

Apply it with the CLI:

aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-queue \
  --attributes '{"Policy":"{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"sns.amazonaws.com\"},\"Action\":\"sqs:SendMessage\",\"Resource\":\"arn:aws:sqs:us-east-1:123456789012:my-queue\",\"Condition\":{\"ArnEquals\":{\"aws:SourceArn\":\"arn:aws:sns:us-east-1:123456789012:my-topic\"}}}]}"}'

Cause 2: Subscription Not Confirmed

SNS subscriptions require confirmation. When you subscribe an SQS queue to an SNS topic through the AWS Console, confirmation is automatic. However, if you create the subscription via CLI or SDK, check the subscription status:

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic

Look for the SubscriptionArn field. If it shows PendingConfirmation, the subscription was never confirmed. For SQS subscriptions, confirmation should be automatic as long as the queue policy permits it. If it is stuck, delete and recreate the subscription:

1aws sns subscribe \
2  --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic \
3  --protocol sqs \
4  --notification-endpoint arn:aws:sqs:us-east-1:123456789012:my-queue

Cause 3: Cross-Account or Cross-Region Misconfiguration

SNS and SQS must be in the same region for a direct subscription. Cross-region delivery is not supported natively. If your topic is in us-east-1 and your queue is in eu-west-1, the subscription will fail silently.

For cross-account setups, the SQS queue policy must explicitly allow the SNS topic from the other account:

1{
2  "Effect": "Allow",
3  "Principal": {
4    "Service": "sns.amazonaws.com"
5  },
6  "Action": "sqs:SendMessage",
7  "Resource": "arn:aws:sqs:us-east-1:111111111111:my-queue",
8  "Condition": {
9    "ArnEquals": {
10      "aws:SourceArn": "arn:aws:sns:us-east-1:222222222222:their-topic"
11    }
12  }
13}

Cause 4: Subscription Filter Policy Blocking Messages

If the subscription has a filter policy, messages that do not match the filter attributes are silently discarded. Check the filter policy:

aws sns get-subscription-attributes \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:my-topic:abc-123

Look for the FilterPolicy attribute. If it exists, verify that the messages you are publishing include the required message attributes:

1aws sns publish \
2  --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic \
3  --message "Test message" \
4  --message-attributes '{"eventType":{"DataType":"String","StringValue":"order_created"}}'

To remove the filter for testing, set it to an empty JSON object:

1aws sns set-subscription-attributes \
2  --subscription-arn arn:aws:sns:us-east-1:123456789012:my-topic:abc-123 \
3  --attribute-name FilterPolicy \
4  --attribute-value '{}'

Cause 5: SQS Queue Encryption with KMS

If the SQS queue uses server-side encryption with a customer-managed KMS key, SNS must have permission to use that key. Add the following statement to your KMS key policy:

1{
2  "Effect": "Allow",
3  "Principal": {
4    "Service": "sns.amazonaws.com"
5  },
6  "Action": [
7    "kms:Decrypt",
8    "kms:GenerateDataKey"
9  ],
10  "Resource": "*"
11}

Without this, SNS receives an access denied error when trying to encrypt the message before placing it in the queue, and the message is lost.

Diagnostic Checklist

When messages are not arriving, work through these steps in order:

1. Verify the subscription is confirmed (not PendingConfirmation).
2. Check the SQS queue access policy for sqs:SendMessage permission from sns.amazonaws.com.
3. Confirm both resources are in the same region.
4. Look for a filter policy on the subscription and verify message attributes match.
5. If the queue uses KMS encryption, check the key policy.
6. Publish a test message and immediately poll the queue to isolate timing issues.
7. Check CloudWatch metrics for NumberOfMessagesPublished on the SNS topic and NumberOfMessagesSent on the SQS queue.

Common Pitfalls

Using Raw Message Delivery on the subscription changes the message format. Without it, SNS wraps the message in a JSON envelope that includes the topic ARN, message ID, and other metadata. Consumers that parse the raw message body without accounting for this envelope will fail to extract the actual content.

Another subtle issue is the SQS visibility timeout. If another consumer is processing messages from the same queue, messages may not be visible to your polling process. Check if there are other consumers attached to the queue that might be receiving and not deleting the messages.

Summary

When SQS is not receiving SNS messages, start with the SQS queue access policy, since a missing sqs:SendMessage permission for sns.amazonaws.com is the most common root cause. Then verify subscription confirmation, check for filter policies, confirm both services are in the same region, and review KMS key policies if encryption is enabled. Use CloudWatch metrics to confirm whether SNS is successfully delivering messages or encountering errors.