SNS + SQS Fan-out
One publish, N independent subscribers, fully decoupled.
The canonical AWS pub/sub pattern. Each downstream service owns its own queue and can fail, scale, and retry independently.
Pattern overview
Amazon SNS allows publishers to send messages to multiple subscribers through topics. Subscribing SQS queues to an SNS topic creates a fan-out pattern: each queue receives its own copy of every published message.
- Producer → SNS topic → N SQS queues → N independent consumers.
- Each subscriber scales, retries, and dead-letters independently.
Why SQS + SNS together
SNS alone pushes to endpoints immediately — if a subscriber is offline, messages can be lost unless you integrate with SQS. SQS decouples delivery in time: messages persist until a consumer processes them.
Filter policies
Use SNS subscription filter policies so each queue receives only relevant messages. Without filters, every queue gets every message — cost and noise scale with subscriber count.
{
"eventType": ["order.placed"],
"region": ["us-east-1"]
}Raw message delivery
By default, SQS receives an SNS envelope (Type, MessageId, TopicArn, Message, etc.). Enable raw message delivery on the subscription so consumers receive only the published payload.
Permissions
The SQS queue policy must allow sns.amazonaws.com to SendMessage. If the policy is wrong, messages are silently dropped — test IAM before production.
- Queue policy: allow SNS service principal.
- SNS subscription: confirm queue ARN matches.
- !Without filter policies, every queue sees every message — cost grows quickly.
- !If a queue policy doesn't allow SNS to send, messages silently disappear.
- !FIFO SNS → FIFO SQS requires matching queue types on subscriptions.