SQS vs SNS vs EventBridge vs Kinesis: Which to Use When

Choose by the shape of the need, not by the service name: SQS for a point-to-point command that needs buffering and backpressure, SNS for broadcast push fan-out, EventBridge for domain events that need content routing with archive and replay, and Kinesis for ordered, high-throughput streams read by several consumers, each at its own position. No single service replaces the other three. Combining them is normal: an EventBridge rule feeding an SQS queue consumed by Lambda is the default pattern we reach for.

What are SQS, SNS, EventBridge and Kinesis each for?

SQS is a queue: a producer hands work to one logical consumer, with retries, visibility timeouts and backpressure through queue depth. SNS is a broadcaster: one message pushed to every subscriber at once. EventBridge is a router: it matches event content against rules and forwards to chosen targets. Kinesis is a log: an ordered, replayable stream partitioned into shards.

Framing the choice this way ends most service debates before they start. A command that must be executed once is not an event to broadcast, and a click-stream is not a work queue. The SNS and EventBridge documentation both describe pub/sub, which is precisely why teams confuse them.

SQS or SNS: queue a command or announce a fact?

Pick SQS when exactly one consumer must process each message and you want the queue to absorb load spikes: consumers poll at their own rate, failures retry automatically, poison messages land in a dead-letter queue. Pick SNS when several independent subscribers must receive the same message immediately, pushed to them, with no buffering on the topic itself.

Both offer FIFO variants: SQS FIFO queues order messages per message group and deduplicate them, with lower throughput ceilings than standard queues, and SNS FIFO topics deliver in order to SQS FIFO subscribers. In practice the two combine: SNS fans out to one queue per subscriber, so each service keeps its own buffer and retry policy. We covered the queue side in detail in when to use SQS.

SNS or EventBridge: when does routing beat raw fan-out?

Choose EventBridge when subscribers care about different slices of a domain event: rules match on any field of the payload, events can be archived and replayed, and a schema registry documents the contracts. Choose SNS when you need very high fan-out throughput or push delivery to endpoints EventBridge does not reach directly, such as SMS and mobile push.

SNS filter policies match message attributes and, within limits, the message body; EventBridge patterns match the full event natively and route to a wide range of AWS targets and SaaS partners. SNS typically keeps the advantage on latency and throughput ceilings, so telemetry-grade fan-out stays there. For service-to-service domain events, an EventBridge rule feeding SQS then Lambda combines routing, buffering and retries in one composable pattern.

Kinesis or SQS: stream or queue?

Choose Kinesis when order per key matters, when several consumers must read the same records independently, or when you need to rewind: records stay on the stream for a configurable retention period, up to one year, and every reader tracks its own position. Choose SQS when each message is a unit of work to process once and delete.

The consumption models have nothing in common. SQS consumers compete for messages and deletion is global: once processed, the message is gone, and retention tops out at 14 days. Kinesis Data Streams readers walk shards with iterators (or receive records pushed via enhanced fan-out), so adding an analytics consumer next month, replay of yesterday included, requires no coordination with existing readers.

How do ordering, retention and replay compare?

Ordering: SQS FIFO and SNS FIFO guarantee order per message group, Kinesis guarantees order per partition key within a shard, and standard SQS, standard SNS and EventBridge guarantee no order at all. Replay: Kinesis natively by position, EventBridge through archives, SQS and SNS never, once a message has been delivered and deleted.

Retention follows the same dividing line. SQS keeps unconsumed messages up to 14 days, SNS keeps nothing after delivery attempts complete, EventBridge archives retain events for as long as you configure, and Kinesis retains from 24 hours up to 365 days. If an auditor or a reprocessing job will ever ask "what happened last Tuesday", only EventBridge archives and Kinesis retention answer at low cost.

How do consumer models and cost shapes differ?

SQS consumers poll the queue, SNS and EventBridge push to their targets, and Kinesis consumers pull through shard iterators or subscribe to enhanced fan-out push. Cost follows the same lines: SQS and SNS bill per request, EventBridge bills per event published on the bus, and Kinesis bills per shard-hour plus data in provisioned mode, or per gigabyte on demand.

The practical consequence: an idle queue, topic or bus costs close to nothing, while an idle provisioned stream keeps billing by the hour. Sustained volume inverts the picture: per-request billing grows linearly with message count, shard billing does not. Check the current shapes on the Kinesis pricing page before committing a high-volume workload either way.

Side by side: the seven dimensions that decide

One question usually settles the choice: who consumes the message, does order matter, and will anyone ever replay it. The table compresses the four services along the seven axes we check first in any messaging review. Read the last row first, then confirm the rest supports it.

Decision checklist

Run these questions in order and stop at the first yes:

• Multiple readers of the same records, order per key, or replay by position? Kinesis.
• Domain events filtered on content, or a need for archive and replay? EventBridge.
• Same message pushed to many endpoints, SMS or mobile included? SNS.
• One consumer doing work that must survive spikes and failures? SQS.
• Still hesitating? Start with EventBridge routing into SQS: every later option stays open.