SQS SNS Fan-Out Pattern: Multiple Queue Subscribers (2026)

The SQS SNS Fan-Out pattern lets one message trigger multiple independent SQS queues, each processed by a different consumer.

Let’s see it in action. Imagine an e-commerce order system. When an order is placed, a single message needs to go to several services: one to process payment, another to update inventory, and a third to send a confirmation email.

Here’s the setup:

1. The SNS Topic:

This is the central hub. We’ll create an SNS topic named order-processing-topic.

aws sns create-topic --name order-processing-topic

This command returns a TopicArn. Let’s say it’s arn:aws:sns:us-east-1:123456789012:order-processing-topic.

2. The SQS Queues:

We need three separate SQS queues for our consumers:

• payment-queue
• inventory-queue
• email-queue

aws sqs create-queue --queue-name payment-queue
aws sqs create-queue --queue-name inventory-queue
aws sqs create-queue --queue-name email-queue

These commands return QueueUrls. We’ll need the QueueArn for each. You can get this using aws sqs get-queue-attributes --queue-url <queue-url> --attribute-names QueueArn.

Let’s assume:

• payment-queue-arn = arn:aws:sqs:us-east-1:123456789012:payment-queue
• inventory-queue-arn = arn:aws:sqs:us-east-1:123456789012:inventory-queue
• email-queue-arn = arn:aws:sqs:us-east-1:123456789012:email-queue

3. Subscribing Queues to the Topic:

Now, we link each SQS queue to the SNS topic. This tells SNS to deliver any message published to order-processing-topic to these queues.

aws sns subscribe \
    --topic-arn arn:aws:sns:us-east-1:123456789012:order-processing-topic \
    --protocol sqs \
    --notification-endpoint arn:aws:sqs:us-east-1:123456789012:payment-queue

aws sns subscribe \
    --topic-arn arn:aws:sns:sns:us-east-1:123456789012:order-processing-topic \
    --protocol sqs \
    --notification-endpoint arn:aws:sqs:us-east-1:123456789012:inventory-queue

aws sns subscribe \
    --topic-arn arn:aws:sns:us-east-1:123456789012:order-processing-topic \
    --protocol sqs \
    --notification-endpoint arn:aws:sqs:us-east-1:123456789012:email-queue

4. Granting SNS Access to SQS:

Crucially, SNS needs permission to send messages to your SQS queues. This is done via an SQS Queue Policy. For each queue, you’ll attach a policy like this (replace YOUR_ACCOUNT_ID and YOUR_REGION):

{
  "Version": "2012-10-17",
  "Id": "QueuePolicyForSNSTopic",
  "Statement": [
    {
      "Sid": "AllowSNSSendMessage",
      "Effect": "Allow",
      "Principal": {
        "Service": "sns.amazonaws.com"
      },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:us-east-1:123456789012:payment-queue",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:us-east-1:123456789012:order-processing-topic"
        }
      }
    }
  ]
}

You’ll need to run aws sqs set-queue-attributes --queue-url <queue-url> --attributes '{"Policy": "<json_policy_string>"}' for each queue.

5. Publishing Messages:

Now, when an order is placed, your application publishes a single message to the SNS topic:

aws sns publish \
    --topic-arn arn:aws:sns:us-east-1:123456789012:order-processing-topic \
    --message '{"orderId": "ORD12345", "status": "placed"}'

This single publish action results in the message appearing in payment-queue, inventory-queue, and email-queue almost simultaneously. Each consumer service polls its respective queue and processes the message independently.

The mental model here is one-to-many. SNS is the broadcaster, and SQS queues are the listeners. Each listener gets a copy of the broadcast. The key problem this solves is decoupling producers from consumers. The order service doesn’t need to know how many downstream services need to be notified, nor does it need to call each one directly. It just shouts into the SNS topic, and the rest is handled.

The aws sns subscribe command actually creates a subscription resource within SNS. This subscription links the topic to the endpoint (your SQS queue) and includes the necessary permissions configuration for SNS to deliver messages. When you delete a subscription, you’re telling SNS to stop sending messages to that specific endpoint from that topic.

The next step is handling message ordering and deduplication across multiple consumers when the order of operations matters.