SNS Push vs SQS Pull in AWS: When to Use Each Messaging Pattern
SNS push means the service delivers your message immediately to all subscribers the moment it is published. SQS pull means the message waits in a queue until your consumer is ready to process it. The right choice, or the right combination of both, comes down to two questions: who controls the pace, and how many consumers need the same event?
Simple explanation
Think of SNS like a loudspeaker announcement in a building. The moment you press the button, everyone in every room hears it simultaneously. There is no waiting. If someone is away from their desk, they miss the announcement entirely. That is the push model: one broadcast, all listeners notified, right now.
Think of SQS like a physical inbox tray on each person’s desk. You drop a message into the tray and it sits there until the person returns, picks it up, and reads it. If they are on holiday for a week, the message is still there when they come back. That is the pull model: the message waits patiently; the consumer decides when to process it.
Most real architectures use both. SNS handles the broadcasting side: delivering the same event to multiple services at once. SQS handles the resilience side: making sure each service’s work does not disappear if it is busy, restarting, or slow.
If you want a broader comparison of SNS and SQS as services (pricing, feature limits, throughput), see SNS vs SQS in AWS. This page focuses on delivery mechanics: push vs pull, when to combine them, and how to choose the right architecture.
SNS = fire and forget to many. SQS = store until ready, one consumer at a time. When you need both, put SQS queues behind SNS: get the fan-out from SNS and the durability from SQS.
Quick answer
- Use SNS when one event must reach multiple independent consumers immediately: fan-out, alerts, notifications, webhooks.
- Use SQS when a single consumer needs to process work reliably at its own pace: task queues, background jobs, burst absorption, retry-safe processing.
- Use SNS + SQS together when one event needs to reach multiple consumers and each consumer needs durable, buffered delivery. This is the standard fan-out pattern for production systems.
- Use SNS to SQS to Lambda (not SNS to Lambda directly) when the work is business-critical and you cannot afford to lose messages on transient Lambda failures.
How it works
The SNS push model
When a producer publishes a message to an SNS topic, SNS immediately attempts to deliver it to every registered subscriber. The subscriber does not ask for the message; SNS pushes it out. Subscribers can be Lambda functions, SQS queues, HTTP endpoints, email addresses, SMS numbers, or mobile push endpoints.
The delivery is parallel. If you have five SQS queues subscribed to a topic, all five receive the message in the same delivery pass. This is the SNS fan-out model: one publish, many recipients, near-simultaneously.
If a subscriber is unavailable, SNS retries according to a delivery policy. For Lambda subscribers, SNS retries up to three times with exponential backoff. After retries are exhausted, the message is discarded. Configure an SNS dead-letter queue (DLQ) if you need to catch those failures.
The SQS pull model
When a message arrives in an SQS queue (from SNS, a direct publish, or any other source), it stays there. SQS does not push anything. The consumer application calls ReceiveMessage in a polling loop to retrieve messages.
Once a consumer receives a message, SQS marks it as invisible for a configurable period called the visibility timeout. If the consumer successfully processes it and calls DeleteMessage, the message is gone. If the consumer fails or the visibility timeout expires without a delete, the message becomes visible again and can be retried.
Messages persist in SQS for up to 14 days. A consumer can restart, redeploy, or fall behind without losing any work. The queue builds up a backlog and the consumer processes it when ready.
SNS push vs SQS pull: side-by-side comparison
| Property | SNS (push) | SQS (pull) |
|---|---|---|
| Delivery control | SNS pushes immediately; subscriber has no say in timing | Consumer polls on its own schedule |
| Latency | Milliseconds | Seconds (depends on poll interval; long polling reduces this) |
| Message persistence | Not stored; delivered or retried, then discarded | Stored for up to 14 days |
| Number of consumers | Many subscribers receive each message simultaneously | One consumer receives each message |
| Retries on failure | SNS-managed retry policy per subscription protocol | Visibility timeout + consumer retry; DLQ after max attempts |
| Dead-letter handling | SNS DLQ (optional, per subscription) | SQS DLQ (configured on the queue) |
| Fan-out | Native: one message to many subscribers | Not native: one message to one consumer |
| Back-pressure / buffering | None: subscriber must keep up or messages are lost/retried | Built-in: queue absorbs bursts; consumer processes at its own rate |
| Ordering | Best-effort (standard); strict per message group (FIFO topic) | Best-effort (standard); strict per message group (FIFO queue) |
| Delivery guarantee | At-least-once (standard topic) | At-least-once (standard); within-group deduplication (FIFO) |
| Best use case | Fan-out, alerts, notifications, webhooks | Task queues, background jobs, burst buffering |
| Typical consumer model | Lambda, HTTP endpoint, email/SMS | Lambda (event source mapping), EC2 worker, ECS task |
When to use SNS
SNS is the right tool when the event itself is the notification. You want to broadcast something right now, and you do not need the recipient to process it at a deferred time.
- Alerts and incident notifications: a CloudWatch alarm triggers an SNS topic that sends an email, a Slack webhook, and an SMS to an on-call engineer simultaneously.
- Fan-out to independent services: an order is placed; the same event goes to inventory, email confirmation, and fraud detection at the same time. No service waits for another.
- Triggering Lambda for stateless, low-stakes processing: a file upload event triggers a Lambda function to generate a thumbnail. If one invocation fails occasionally, that is acceptable and the SNS delivery policy handles retries.
- Webhook delivery to HTTP endpoints: SNS supports HTTPS subscriptions for pushing events to external services.
- Mobile and email push notifications: SNS supports Apple APNS, Google FCM, and Amazon ADM push protocols natively.
If a subscriber is unavailable when SNS delivers a message, SNS retries briefly and then discards the message. There is no 14-day retention. Do not use SNS alone for work that must not be lost. Put SQS behind SNS if you need durability.
When to use SQS
SQS is the right tool when work needs to happen eventually, reliably, and at whatever pace the consumer can manage.
- Background task queues: generate a PDF invoice, resize an image, send a report. The task should not block the user-facing request. Drop it in a queue and let a worker pick it up.
- Burst absorption: a flash sale generates 50,000 orders in five minutes. Your Lambda worker can handle 1,000 per minute. SQS buffers the 49,000 excess orders without data loss.
- Decoupled microservices: Service A produces work; Service B consumes it. With SQS between them, you can deploy, restart, or scale Service B without losing any messages from Service A.
- Retry-safe processing: if the consumer crashes halfway through, SQS makes the message visible again after the visibility timeout expires. No explicit retry logic needed in the producer.
- Rate limiting: a queue lets you control how fast downstream services receive work, preventing them from being overwhelmed.
Use SQS when your consumer needs to control the pace of work, when failures should be retried without data loss, and when you have a single logical consumer per message.
When to use SNS + SQS together
The SNS + SQS fan-out pattern is one of the most common AWS messaging architectures in production. It gives you both capabilities at once: SNS handles simultaneous delivery to multiple consumers, and SQS gives each consumer its own durable buffer.
Here is what the pattern looks like for an order processing system:
Order Service (publisher)
|
v
SNS Topic: order-events
/ | \
v v v
SQS Queue SQS Queue SQS Queue
(inventory) (email) (analytics)
| | |
v v v
Lambda Lambda Kinesis
(update (send (stream to
stock) receipt) data lake)The order service publishes one message. SNS fans it out to three SQS queues at once. Each queue has its own consumer running independently. If the email Lambda is throttled or the analytics Kinesis stream is slow, those queues build up a backlog without affecting inventory processing at all.
This is why the pattern is so widely used in event-driven architectures: SNS solves the fan-out problem; SQS solves the resilience problem. Using them together means you do not have to compromise between the two.
# 1. Create the SNS topic
aws sns create-topic --name order-events
# 2. Create SQS queues for each consumer
aws sqs create-queue --queue-name inventory-queue
aws sqs create-queue --queue-name email-queue
aws sqs create-queue --queue-name analytics-queue
# 3. Subscribe each SQS queue to the SNS topic
aws sns subscribe \
--topic-arn arn:aws:sns:us-east-1:123456789012:order-events \
--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-events \
--protocol sqs \
--notification-endpoint arn:aws:sqs:us-east-1:123456789012:email-queue
aws sns subscribe \
--topic-arn arn:aws:sns:us-east-1:123456789012:order-events \
--protocol sqs \
--notification-endpoint arn:aws:sqs:us-east-1:123456789012:analytics-queueFor SNS to write to an SQS queue, the queue’s access policy must explicitly grant sqs:SendMessage to the SNS topic ARN. The AWS console handles this automatically when you use the SNS subscription interface. If you are using CloudFormation, Terraform, or the CLI directly, you must add the queue policy yourself. Without it, SNS delivers silently to nothing.
SNS direct vs SNS to SQS to Lambda
Once you decide to use Lambda as your event consumer, you have two options: SNS invokes Lambda directly, or SNS delivers to SQS and Lambda polls the queue via an event source mapping.
Think of it this way. SNS to Lambda directly is like a phone call: it rings immediately, but if nobody answers and the caller hangs up after a few tries, the message is gone. SNS to SQS to Lambda is like leaving a voicemail that gets transcribed and placed in an inbox: slower to reach the recipient, but the message is there waiting however long it takes.
| Property | SNS to Lambda (direct) | SNS to SQS to Lambda (buffered) |
|---|---|---|
| Latency | Milliseconds from publish to Lambda invocation | Seconds from publish to Lambda invocation (queue poll interval) |
| Message persistence | None: Lambda invoked directly by SNS | Message persists in SQS until deleted or DLQ-routed |
| Retry behavior | SNS retries Lambda up to 3 times with backoff, then drops (unless SNS DLQ configured) | SQS visibility timeout + redrive policy; configurable retry count before DLQ |
| Dead-letter queue | Requires configuring SNS DLQ per subscription | SQS DLQ is queue-level and applies automatically after max receive count |
| Concurrency control | None: Lambda scales up immediately with each SNS delivery | SQS event source mapping limits concurrency via batch size and reserved Lambda concurrency |
| Backlog visibility | No backlog: messages are either processed or lost | Queue depth visible in CloudWatch metrics; set alarms on backlog growth |
| Batch processing | Each SNS message = one Lambda invocation | Lambda can process up to 10,000 messages per invocation (configurable batch size) |
| Best for | Low-stakes, low-volume events where latency matters more than guaranteed delivery | Business-critical processing where message loss is unacceptable |
If Lambda is throttled, in the middle of a deployment, or hits a cold start timeout during a traffic burst, SNS exhausts its retry window and discards the message. There is no recovery path unless you have configured an SNS DLQ in advance. For payment processing, order fulfillment, or any workload where losing a message has a business consequence, route through SQS first.
With buffered delivery, the message sits in SQS until Lambda is ready. Lambda’s SQS event source mapping handles scaling, batching, and retry automatically. If Lambda fails, SQS makes the message visible again after the visibility timeout. After a configurable number of failures, SQS moves the message to a DLQ where you can inspect and reprocess it.
Both standard SNS and standard SQS deliver at-least-once. The same message can arrive more than once under certain conditions. Design your Lambda handler to be safe to run twice with the same input: check whether the work was already done before doing it again. FIFO does not remove this requirement entirely.
Common mistakes
Using SNS as a durable work queue. SNS is not a queue. Messages that cannot be delivered to a subscriber are retried briefly and then discarded. If your consumer is unavailable, those messages are gone. For any work that must not be lost, put SQS behind SNS so messages persist.
Forgetting the SQS queue policy for SNS delivery. SNS cannot write to an SQS queue unless the queue policy explicitly grants
sqs:SendMessageto the SNS topic ARN. When the policy is missing, SNS fails silently: no error is thrown by the producer, and messages are simply not delivered. Always verify the queue policy when setting up a new SNS + SQS subscription.Not using long polling on SQS consumers. SQS supports long polling with
—wait-time-seconds 20. Without it, your consumer fires empty ReceiveMessage calls constantly, which increases latency and costs. Enable long polling on the queue or per ReceiveMessage call.Confusing fan-out with buffering. SNS delivers to multiple subscribers simultaneously: that is fan-out. SQS holds messages until a consumer is ready: that is buffering. They solve different problems. SNS alone gives you no buffering; SQS alone gives you no fan-out. You need both if you need both.
Overstating FIFO exactly-once guarantees. FIFO SNS + FIFO SQS provides ordering within message groups and deduplication within a 5-minute window. It does not make your system exactly-once end-to-end. Your Lambda consumer can still fail after deleting the message, or succeed after a timeout that causes a redelivery. Idempotent consumers remain essential regardless of FIFO configuration.
Not configuring a DLQ, visibility timeout, or monitoring. A message that consistently fails processing loops invisibly if you have no DLQ. Set a redrive policy on every SQS queue that processes real work, configure the visibility timeout to be longer than your maximum expected processing time, and set a CloudWatch alarm on
ApproximateNumberOfMessagesNotVisibleto catch stuck consumers early. See SNS Message Delivery Failures in AWS for how to diagnose these.Skipping SNS subscription filter policies. If all subscribers receive all messages but each subscriber only cares about a subset, you are paying for unnecessary SQS deliveries and Lambda invocations. Use SNS subscription filter policies to route only matching messages to each SQS queue.
Summary
- SNS pushes messages immediately to all subscribers; SQS holds messages until a consumer polls for them
- Use SNS for fan-out, real-time notifications, and multi-subscriber delivery
- Use SQS for reliable buffering, back-pressure handling, and retry-safe task processing
- The SNS + SQS fan-out pattern is the standard production choice: SNS delivers to multiple SQS queues, each with its own consumer
- SNS to Lambda is lower latency; SNS to SQS to Lambda is safer for business-critical workloads
- Both standard SNS and standard SQS are at-least-once; idempotent consumers matter regardless of FIFO configuration
- Always set a DLQ, correct visibility timeout, and CloudWatch alarms on queues that process real work
Frequently asked questions
What is the difference between SNS push and SQS pull?
SNS is push-based: when a message is published, SNS immediately delivers it to all subscribers. Subscribers do not ask for messages; they arrive automatically. SQS is pull-based: messages wait in a queue until a consumer calls ReceiveMessage to retrieve them. The consumer controls when and how fast it processes work.
When should I use SNS instead of SQS?
Use SNS when one event needs to reach multiple independent consumers at the same time (fan-out), or when immediate delivery matters: alerts, notifications, webhooks. Use SQS when you have a single consumer that needs to process work at its own pace, survive restarts, or absorb traffic bursts without data loss.
When should I put SQS behind SNS?
Use SNS + SQS together when you need both fan-out and resilience. SNS delivers to multiple SQS queues simultaneously; each queue buffers work for its own consumer. This is the standard production fan-out pattern. It is safer than direct SNS to Lambda for business-critical workloads because messages persist in the queue even if a consumer is down.
Is SNS to Lambda reliable enough for production?
It depends on the workload. SNS retries Lambda invocations on failure, but if all retries are exhausted the message is lost unless you have configured an SNS DLQ. For low-stakes notifications this is acceptable. For business-critical event processing, routing through an SQS queue before Lambda gives you persistence, configurable retries, visibility timeout control, and an automatic DLQ path.
Do FIFO topics and FIFO queues change the decision?
FIFO SNS topics and FIFO SQS queues add ordered, deduplicated delivery within a message group. They remove the most common reason to avoid standard SNS/SQS for ordered work, but they come with lower throughput limits and higher cost. FIFO deduplication applies within a 5-minute deduplication window; it does not make idempotent consumers unnecessary. Use FIFO when strict ordering is a hard requirement, not as a default.