Skip to content

Kinesis vs SQS vs SNS

Published 2 October 2026

AWS has three messaging services that look alike and solve different problems. Pick the wrong one and you end up rebuilding what the right one gives you for free.

SNS broadcasts, SQS buffers work, Kinesis keeps an ordered, replayable log.

Kinesis vs SQS

Kinesis Data Streams is an ordered log, like Kafka. SQS is a queue: one consumer gets each message, and it's deleted once processed.

Kinesis Data Streams SQS
Consumption Retained 24 h to 365 days; every consumer reads the whole stream at its own position One consumer per message, deleted after processing
Ordering Per shard, by partition key Standard: best effort. FIFO: strict per message group
Scaling Shards (~1 MB/s in, 2 MB/s out each) cap parallelism Standard scales with nothing to manage
Replay Yes, from a sequence number or timestamp No; failures go to a dead-letter queue
Failure handling Checkpoint a position in the shard Per-message ack, retries, DLQ
Cost Per shard-hour, even when idle Per request

Why not Kinesis everywhere

Kinesis ties parallelism and failure handling to the shard; SQS ties them to the message. For a work queue, such as resizing uploaded images, that difference decides everything:

  • Parallelism: 4 shards means 4 busy workers, however many jobs are waiting. SQS lets 500 workers pull at once and autoscale on queue depth.
  • Head-of-line blocking: a slow or poison record stalls its whole shard. In SQS it just reappears after its visibility timeout and lands in a DLQ after N failures.
  • Idle cost: shard-hours bill at 3 AM; SQS costs next to nothing when quiet.

Kinesis wins when order matters (all events for one user), when many consumers need the same data (analytics, fraud, archival), or when you need replay.

The deciding question: is this a stream of facts several readers process in order (Kinesis), or a pile of independent tasks done once by whoever is free (SQS)?

Where SNS fits

SNS is pub/sub. A publisher sends to a topic and SNS pushes a copy to every subscriber: SQS queues, Lambda, HTTP, email, SMS, mobile push. It stores nothing; a subscriber that stays down loses messages to a DLQ or the floor, and there is no replay. FIFO topics and attribute-based message filtering are available.

The common pattern is SNS → one SQS queue per subscriber:

                               ┌──► SQS: billing   ──► billing workers
"order placed" ──► SNS topic ──┼──► SQS: shipping  ──► shipping workers
                               └──► SQS: email     ──► email workers

Every service gets its own durable copy and its own retries and DLQ. That gives you Kinesis-style "many consumers of one event" with SQS's per-message work-queue behaviour.

Two brokers, two patterns

Both are message brokers, but SQS is point-to-point (three workers on a queue, one gets each message; messages wait if nobody reads) and SNS is publish/subscribe (three subscribers on a topic, all three get a copy; nothing is buffered). RabbitMQ offers both in one system; AWS split them, which is why they're so often used together.

Summary

Need Use
Independent jobs done once by a worker pool SQS
Broadcast one event to many systems SNS, usually → SQS per subscriber
Ordered, high-throughput stream with replay and many readers Kinesis