How to Use SQS to Fan Out SNS Messages (Step-by-Step AWS Tutorial)

Most developers who learn AWS in isolation hit the same wall: they understand SQS, they understand SNS, but they build systems where one slow downstream service holds up every other service. The fan-out pattern fixes that. One SNS message lands in two separate SQS queues at the same time, and each queue’s consumer runs independently. Once you see it work in your own AWS console, the architecture clicks in a way no diagram can fully capture.

This tutorial walks the exact hands-on steps from the Mastering AWS series: create an SNS topic, spin up two standard SQS queues, subscribe both to the topic, publish one test message, and confirm it lands in both queues simultaneously. By the end you will have run the fan-out pattern yourself and know precisely when to reach for it in a real project.

What You’ll Walk Out With

A working SNS topic connected to two active SQS queues inside your AWS account
A clear mental model of the SNS fan-out pattern and why it beats a single-queue setup
A step-by-step console walkthrough you can repeat in under ten minutes
The exact difference between publishing to an SNS topic versus sending a message directly to an SQS queue
Real-world use cases for fan-out: order processing, user registration flows, IoT events, multi-region replication
Honest drawbacks of the pattern so you know when to reach for Kinesis instead
A free 60-second quiz that tells you which cloud skill is the fastest path to your first freelance contract — finder.platformproof.com

What SNS and SQS Actually Are

AWS gives these two services names that almost explain themselves. SNS — Simple Notification Service — is a pub/sub system. You publish a message to a topic, and every subscriber to that topic receives a copy. Think of it like a group text: one send, many recipients. SQS — Simple Queue Service — is a message queue. A producer puts a message in, a consumer pulls it out and processes it. One message, one consumer, one destination.

On their own, each service is useful. Together they become something more powerful. SNS handles the broadcasting side — making sure a single event reaches multiple downstream systems. SQS handles the reliable delivery side — making sure each system processes that event at its own pace without dropping messages. The fan-out pattern is what you get when you wire them together correctly.

Why Fan-Out Messaging Matters

Picture an e-commerce platform. A customer places an order. That single event needs to trigger multiple downstream actions in parallel: the inventory service needs to reserve stock, the fulfillment service needs to create a shipment, the email service needs to send a confirmation, and the analytics service needs to log the sale. If you send that order event to a single SQS queue with one consumer processing everything sequentially, you have created a bottleneck. One slow service holds up all the others.

Fan-out solves this. Publish one message to an SNS topic. Every SQS queue subscribed to that topic gets its own independent copy. The inventory service, fulfillment service, email service, and analytics service each have their own queue. They process in parallel, at their own speed, with no knowledge of each other. One slow service no longer blocks the rest. Adding a new downstream service means adding a new queue and a new subscription — zero changes to the publisher code. That is the core value of the SNS plus SQS fan-out pattern.

Step 1: Create Your SNS Topic

Log into your AWS console and open Simple Notification Service. The first thing you need is a topic — the central broadcast point your queues will subscribe to. Click Create topic.

In this tutorial, the topic name is set to udemy and the display name is also set to udemy. For your own projects, choose a name that reflects the events this topic will broadcast — something like order-placed or user-registered makes the purpose immediately clear to anyone reading your architecture diagram. Click Create topic to confirm. AWS creates the topic and assigns it an Amazon Resource Name (ARN) — a unique identifier you will see pre-filled whenever you publish a message. That ARN is what ties everything together downstream.

Step 2: Create Two SQS Queues

Open Simple Queue Service. You are going to create two queues — both standard queues with all defaults. Standard queues offer maximum throughput and at-least-once delivery, which is exactly right for most fan-out use cases.

Click Create queue. Name the first queue sq1, leave the type as Standard, and accept all default settings. Click Create queue. The queue appears in your list. Repeat the same steps for a second queue named sq2. Now you have two independent queues sitting in SQS, each with their own URL and ARN, each ready to receive messages independently of the other.

A note on production configuration: this tutorial uses all-default settings, which is correct for learning the pattern. In a production system you would configure a few things more carefully. The visibility timeout — how long a message is hidden from other consumers while one consumer is processing it — should match your maximum processing time. The message retention period — how long SQS holds an unprocessed message — should reflect how critical each message is to your business. And a dead-letter queue is almost always worth adding to capture messages that fail to process after multiple retries. For understanding fan-out, defaults are fine. For production workloads, those three settings deserve attention before you go live.

Step 3: Subscribe Both Queues to the SNS Topic

Here is where the fan-out wiring happens. With both queues selected in the SQS console, you subscribe them to the SNS topic you created. In this tutorial both sq1 and sq2 are subscribed to the udemy topic. The console gives you a subscription result confirming the connection. A quick refresh shows both subscriptions listed and active.

After confirming the subscriptions, you will see both listed under the topic in the SNS console. Each subscription has its own ARN, confirming that SNS knows to deliver a copy of every published message to both queues. The architecture is now fully wired: SNS topic in the center, two SQS queues on the receiving end, ready to process independently.

Under the hood, what AWS is doing is straightforward. When a message arrives at the SNS topic, SNS iterates over all confirmed subscriptions and delivers a copy to each one. For SQS subscriptions, this means making an API call to the SQS SendMessage endpoint for each subscribed queue. The delivery happens in the same moment from your application’s perspective — both queues receive the message without any coordination required from your code.

One thing to know about permissions: when you subscribe an SQS queue to an SNS topic through the AWS console, the console automatically adds a resource policy to the SQS queue that allows SNS to call sqs:SendMessage on it. If you create subscriptions programmatically or through CloudFormation, you need to set this policy manually. Missing this policy is one of the most common reasons SNS deliveries silently fail — the SNS publish succeeds but nothing arrives in the queue because SNS lacks permission to write to it.

Step 4: Publish a Message and Verify Fan-Out

Head back to the SNS console, find your udemy topic, and click Publish message. The topic ARN is pre-filled. The tutorial publishes a simple test message: “this is a test that should work.” Click Publish. The console confirms the publish was successful.

Now go back to SQS. Check the message count on both sq1 and sq2. You will see two messages available — one in each queue. Click into sq1, click View messages, then Poll for messages, and the message appears: “this is a test that should work.” Click More details to see the full message body. The same message is sitting in sq2, independently, waiting for its own consumer to process it.

That is the fan-out pattern working exactly as designed. One SNS publish, two SQS deliveries, zero coordination required between downstream consumers. If you had subscribed ten queues to the topic, you would see ten copies of the same message — each in its own queue, each ready for its own independent consumer.

The Difference Between SNS Fan-Out and Direct SQS Messaging

The tutorial demonstrates a distinction that is easy to overlook. After confirming the fan-out, the instructor sends a message directly to sq2 — bypassing SNS entirely. The message is “this is the second message.” After sending, checking the queue counts reveals the result clearly: only sq2 received the new message. sq1 has zero new messages.

This is expected, but it is worth pausing on. When you send directly to an SQS queue, you are talking to one service and one destination. When you publish to an SNS topic, you are broadcasting to every subscriber simultaneously. The SNS layer is what creates the fan-out behavior. Remove SNS from the equation and SQS is just a point-to-point queue — reliable and useful, but not broadcast-capable.

In practice this means your application code should almost never send directly to an SQS queue when the intent is to notify multiple systems. Publish to SNS and let SNS handle the fan-out. This keeps your publisher decoupled from the number and identity of downstream consumers. Add a new subscriber queue without touching a single line of application code. Remove a subscriber without any risk of breaking the publisher. That decoupling is what makes the pattern so durable as systems grow.

Not sure which cloud or tech skill is the fastest path to your first $3,000 online?

Take the free 60-second quiz at finder.platformproof.com and get a personalized recommendation based on the skills you already have.

Real-World Use Cases for This Pattern

The SQS plus SNS fan-out pattern appears in production systems across almost every industry once you know to look for it. Here are the most common scenarios where engineers reach for it:

Order processing in e-commerce. A single “order placed” event needs to trigger inventory reservation, shipment creation, customer email, and analytics logging — all independently and in parallel. One SNS topic, four SQS queues, four independent microservices. Each processes at its own pace. A transient delay in the email service does not hold up the inventory service or the analytics pipeline.

User registration workflows. When a new user signs up, the system might need to send a welcome email, add the user to a CRM, trigger an onboarding drip sequence, and log the event for analytics. Fan-out handles all four without any of the downstream services knowing about each other. The signup service publishes one event; everything else reacts to it.

IoT device events. A sensor publishing a temperature reading might need to trigger an alerting system, a data archiving pipeline, and a real-time dashboard update all at once. SNS fan-out is ideal because the sensor does not need to know how many downstream systems are listening, and adding a new downstream consumer is as simple as creating a new queue and a new subscription.

Multi-region replication. Publish to an SNS topic and subscribe SQS queues in multiple AWS regions. Each queue drives a replication worker that keeps regional data in sync. Expanding to a new region means adding a new subscription — no changes to the publishing service, no deployment required on the publisher side.

Honest Drawbacks of the SNS + SQS Fan-Out Pattern

No architecture pattern is right for every situation. Here is where SNS plus SQS fan-out creates genuine friction:

Cost scales with subscribers. Every SNS delivery to an SQS queue costs money. If you publish millions of messages per day to a topic with ten subscribers, you are paying for ten times as many SQS receives and SNS deliveries. At very high volumes, Kinesis Data Streams is often more cost-effective because you pay for shard capacity rather than per-message delivery.

Message ordering is not guaranteed with standard queues. Standard SQS queues do not guarantee that messages arrive in the order they were published. If your downstream systems require strict ordering, you need FIFO queues paired with a FIFO SNS topic. FIFO queues have lower throughput limits and different pricing, so this is a trade-off that needs deliberate evaluation.

At-least-once delivery means duplicate messages happen. Standard SQS queues deliver each message at least once, but occasionally more than once. Your consumers need to be idempotent — processing the same message twice should produce the same result as processing it once. This requirement is easy to underestimate when first learning the pattern and can cause subtle bugs in production if not addressed upfront.

Debugging fan-out failures involves more layers. When a message published to SNS does not appear in an expected SQS queue, the failure could be in the SNS topic configuration, the subscription setup, the SQS queue’s resource policy, or the consumer. The extra layer of indirection means more places to check. CloudWatch Logs and X-Ray tracing become important tools once you move beyond test environments into production workloads.

Find Your X

AWS cloud skills — messaging patterns, serverless architecture, infrastructure as code — rank among the most in-demand capabilities in the current job market. Knowing AWS broadly and knowing which specific AWS skill to build first are two different questions. The second question is the one that actually gets you paid, whether that means a new job, a salary bump, or your first freelance contract.

If you want a clear answer on which skill matches your background and offers the fastest path to income, take the free quiz at finder.platformproof.com. It takes about 60 seconds and gives you a specific, personalized recommendation rather than a generic “learn cloud” suggestion.

Frequently Asked Questions

What is the SNS fan-out pattern?

Fan-out is an architecture pattern where one message published to an SNS topic is automatically delivered to every SQS queue that is subscribed to that topic. Instead of one message reaching one destination, one message reaches many destinations at once. Each subscribed queue gets its own independent copy, and each queue’s consumer processes that copy without any knowledge of the other consumers.

What is the difference between SNS and SQS?

SNS is a pub/sub service — you publish a message to a topic and all subscribers receive it simultaneously. SQS is a message queue — a producer puts a message in and a single consumer pulls it out. SNS is built for broadcasting to multiple receivers; SQS is built for reliable, sequential delivery to a single consumer. Used together, you get the best of both: reliable delivery to multiple independent consumers.

Why subscribe SQS queues to SNS instead of sending directly to each SQS queue?

Subscribing through SNS decouples your publisher from your consumers. You can add or remove subscriber queues without changing any publisher code. Sending directly to individual SQS queues means your publisher must know about every downstream consumer — which creates tight coupling and makes the system harder to extend or modify as requirements change.

Does every SQS queue subscribed to an SNS topic receive every message?

Yes, by default every confirmed subscription receives a copy of every message published to the topic. SNS also supports message filtering — you can attach a filter policy to a subscription so that particular queue only receives messages matching specific attributes. This is useful when you want specialized consumers that only care about certain event types while ignoring others.

Should I use Standard or FIFO queues for fan-out?

Standard queues work with SNS fan-out for most use cases and offer higher throughput. FIFO queues guarantee message ordering and exactly-once processing, but require the SNS topic to also be a FIFO topic, have lower throughput limits, and cost more. Use standard queues unless your consumers genuinely require strict ordering or exactly-once delivery semantics.

Do I need to set any SQS permissions for SNS to deliver messages?

Yes. When you subscribe via the AWS console, AWS automatically adds a resource policy to the SQS queue granting SNS permission to call sqs:SendMessage on it. If you create subscriptions programmatically or via CloudFormation, you must set this policy manually. Missing this policy is one of the most common causes of silent SNS delivery failures — the publish succeeds but nothing ever arrives in the queue.

What happens if an SQS queue is unavailable when SNS tries to deliver?

SNS retries delivery to SQS with exponential backoff when delivery fails. If a queue is unavailable for an extended period, SNS will eventually stop retrying and the message will be lost for that subscription. For critical workloads, monitor SNS delivery failures via CloudWatch alarms and configure a dead-letter queue on the SQS side to capture messages that fail to process after your defined retry count.

When should I use Kinesis instead of SNS plus SQS fan-out?

Kinesis is better suited for very high-throughput streaming data where strict ordering matters and you need the ability to replay past events. If you are processing millions of events per second, need guaranteed ordering within a stream, or need consumers to re-read historical events, Kinesis Data Streams is the right tool. For most event-driven architectures with moderate throughput where decoupling and reliable delivery are the primary goals, SNS plus SQS fan-out is simpler to operate and cheaper to run at typical volumes.

Sources

Mastering AWS — How to use SQS to fan out SNS messages (2018): https://youtu.be/MIyoB-tIXPI
AWS Documentation: Amazon Simple Notification Service — https://docs.aws.amazon.com/sns/
AWS Documentation: Amazon Simple Queue Service — https://docs.aws.amazon.com/sqs/
AWS Documentation: Fanout to Amazon SQS queues — https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html