Busca en todas las páginas de la documentación
The Core Services intro covers one topic and one queue in isolation. This page covers what happens when you put them together: an SNS topic with several SQS queues subscribed to it, so one publish reaches every queue at once.
This pattern is called fan-out. It is one of the most common shapes in event-driven AWS systems, and it is worth understanding on its own before moving into FIFO ordering, dead-letter queues, and filtering - the topics covered in the rest of this section.
A single SNS topic can have many subscribers. When a subscriber is an SQS queue, SNS writes a copy of the published message into that queue on every publish. Subscribe three queues to a topic and one Publish call results in three independent messages, one per queue, each with its own lifecycle.
This differs from sending directly to one queue. A direct SendMessage to a queue reaches exactly that queue and nothing else. Fan-out exists precisely because a producer often does not know, or should not need to know, how many consumers care about an event.
# --- Python (boto3) ---
import boto3
sns = boto3.client("sns", region_name="us-east-1")
sqs = boto3.client("sqs", region_name="us-east-1")
topic_arn = sns.create_topic(Name="order-events")["TopicArn"]
billing_arn = sqs.get_queue_attributes(
QueueUrl=sqs.get_queue_url(QueueName="billing-queue")["QueueUrl"],
AttributeNames=["QueueArn"])["Attributes"]["QueueArn"]
sns.subscribe(TopicArn=topic_arn, Protocol="sqs", Endpoint=billing_arn)
sns.publish(TopicArn=topic_arn, Message="order o-100 placed")// --- TypeScript (AWS SDK v3) ---
import { SNSClient, CreateTopicCommand, SubscribeCommand, PublishCommand } from "@aws-sdk/client-sns";
import { SQSClient, GetQueueUrlCommand, GetQueueAttributesCommand } from "@aws-sdk/client-sqs";
const sns = new SNSClient({ region: "us-east-1" });
const sqs = new SQSClient({ region: "us-east-1" });
const { TopicArn } = await sns.send(new CreateTopicCommand({ Name: "order-events" }));
const { QueueUrl } = await sqs.send(new GetQueueUrlCommand({ QueueName: "billing-queue" }));
const attrs = await sqs.send(new GetQueueAttributesCommand({ QueueUrl, AttributeNames: ["QueueArn"] }));
await sns.send(new SubscribeCommand({ TopicArn, Protocol: "sqs", Endpoint: attrs.Attributes?.QueueArn }));
await sns.send(new PublishCommand({ TopicArn, Message: "order o-100 placed" }));Note the queue's ARN, not its URL, is what Subscribe needs as the endpoint. The URL identifies the queue for SendMessage/ReceiveMessage calls; the ARN identifies it for cross-service permissions and subscriptions.
Two things make SQS-as-subscriber different from email or HTTPS subscribers: automatic confirmation and a required queue policy.
Automatic confirmation. Email and HTTPS subscriptions sit in PendingConfirmation until a human or endpoint confirms them. SQS (and Lambda) subscriptions confirm automatically the moment they are created, so they can receive messages right away with no manual step.
The queue policy. SNS delivering to SQS is a cross-service call, and SQS denies writes by default from anything other than the queue owner. Each subscribed queue needs a resource policy that grants the sns.amazonaws.com service principal sqs:SendMessage, typically scoped with a SourceArn condition matching the topic's ARN so only that topic can write to it.
Once both pieces are in place - subscription and queue policy - the flow per publish looks like this:
Publish once on the topic.SendMessage on that queue using its own permissions.If one worker's queue backs up or one worker crashes, the other queues are unaffected - each is a separate buffer with its own visibility timeout and its own dead-letter policy.
Fan-out combines the strengths of both services: SNS's push-to-many with SQS's durable, replayable buffering. Without SQS in the mix, SNS delivery is best-effort - a failed HTTPS or email delivery can eventually be dropped after retries. With SQS in the mix, a message sits in the queue until a worker explicitly deletes it, so a temporarily offline consumer does not lose events.
This pattern also decouples the number and identity of consumers from the producer. Adding a fourth queue to the order-events topic requires no change to the code that publishes order events - only a new Subscribe call and queue policy. That is the core value proposition: producers publish business facts, and consumers subscribe to the facts they care about.
Combine this with message attributes and subscription filter policies (covered later in this section) to let each queue receive only a relevant subset of messages, rather than every message published to the topic. And combine it with FIFO topics and queues when the order of related events within a group matters, since standard fan-out makes no ordering guarantee across queues or even within one queue.
SendMessage; without it, SNS's deliveries fail silently from the producer's point of view (the Publish call still succeeds).SQS subscriptions confirm automatically and receive messages durably until a worker deletes them. Email subscriptions require the recipient to confirm first, and delivery is best-effort with no retry buffer beyond SNS's own retries.
The most common cause is a missing queue policy. The queue must explicitly grant the sns.amazonaws.com principal permission to call SendMessage, usually scoped to the specific topic ARN.
Yes, each queue receives its own copy of the exact same published message body and attributes, unless a subscription filter policy narrows what that particular queue receives.
You pay for each SendMessage SNS performs on your behalf, one per subscribed queue, plus the original Publish. For a handful of queues this is usually negligible next to the operational benefit of decoupled consumers.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 25 jul 2026