SNS vs SQS
Amazon SNS is a publish/subscribe service that pushes each message to every subscriber of a topic the moment it is published. Amazon SQS is a queue that stores messages until a consumer asks for them and deletes them. SNS fans one message out to many destinations and keeps nothing; SQS holds a message until exactly one worker has finished with it.
How SNS delivers
You publish to a topic, and SNS immediately pushes a copy to every subscription on it. Subscribers can be SQS queues, Lambda functions, HTTPS endpoints, Kinesis Data Firehose streams, email, SMS, or mobile push. The publisher knows nothing about who is listening, which is the point: adding a fourth consumer to an existing event is a subscription, not a code change.
SNS does not store messages. Once a delivery attempt succeeds or exhausts its retry policy, the message is gone. Retry behavior depends on the protocol: delivery to SQS and Lambda retries aggressively over a long window, while HTTPS subscriptions follow a retry policy you configure and can be given a dead letter queue to catch what never lands. Subscription filter policies let each subscriber receive only the messages whose attributes it cares about, so a topic carrying every order event can feed a queue that only sees refunds.
How SQS delivers
You send a message to a queue, and it sits there, for four days by default and up to fourteen, until a consumer polls for it. Receiving a message does not remove it: SQS makes it invisible for the duration of the visibility timeout while the consumer works, and only an explicit delete removes it for good. If the consumer crashes, the timeout expires and the message becomes available again.
That model gives you buffering and backpressure for free. A traffic spike grows the queue rather than overwhelming the workers, and you scale consumers on queue depth. It also gives you a natural failure path: after a configurable number of receives, SQS moves a message that keeps failing to a dead letter queue instead of redelivering it forever, which our guide to SQS dead letter queues covers in detail.
Standard queues deliver at least once with best-effort ordering and effectively unlimited throughput. FIFO queues preserve order within a message group and deduplicate, at the cost of a per-queue throughput ceiling unless you enable high throughput mode. Our comparison of FIFO and standard queues goes through that tradeoff.
The differences that actually decide it
Fan-out is the first one. One SNS publish reaches every subscriber; one SQS message is consumed by one worker. If two teams need the same event, SQS alone forces you to send it twice, and every new consumer means another publisher change.
Retention is the second. SNS is push-and-forget, so a subscriber that is down when the retries run out never sees the message. SQS keeps it for days, so a consumer can be offline for an afternoon and catch up. This is why SNS on its own is a poor fit for anything that must not be lost.
Direction is the third. SNS pushes, so consumers need to be reachable and fast enough to accept the rate SNS sends. SQS pulls, so consumers set their own pace. A slow downstream service behind SNS gets hammered; behind SQS it just falls behind and catches up.
Both services cap messages at 256 KB and both charge per request, with SNS also charging for each delivery it makes.
Using them together
The common production answer is not either one. Publish to an SNS topic, subscribe several SQS queues to it, and each consuming service gets its own durable copy of every event it filtered for. Fan-out comes from SNS, retention and retry come from SQS, and the publisher stays unaware of the consumers. Our walkthrough of connecting SNS to SQS covers the topic policy and subscription setup, and Kafka vs SNS and Kinesis vs SQS compare the same jobs against AWS's streaming services.
Choosing between SNS and SQS
Use SNS when one event has several interested parties and you want the publisher decoupled from all of them. Use SQS when work needs to be distributed across workers, absorbed during spikes, or retried until it succeeds. Use both when you need fan-out with a durable copy per consumer, which is most event-driven systems on AWS once they grow past one consumer.
If those consumers are outside your account, neither service is quite the right shape. An SNS HTTPS subscription looks like a webhook, but you still owe your users signed payloads, per-endpoint retry policies, delivery logs, and a way to replay what failed. Svix provides that layer, so your internal events stay on SNS and SQS while customer-facing delivery is handled for you.