SQS vs SNS vs EventBridge vs Kinesis: The AWS Messaging Decision Guide

SQS, SNS, EventBridge and Kinesis overlap, and teams often pick the wrong one. What each is for, and how to choose.

AWS has four primary messaging and event services: SQS, SNS, EventBridge, and Kinesis. They overlap just enough to cause confusion but are designed for fundamentally different patterns. Picking the wrong one is a common architecture mistake, and migrating between them mid-project is painful.

This guide focuses on when to use each, with the honest trade-offs. We will skip the "they are all great!" framing — in most situations, one of these services is clearly the right choice.

The one-line summary

• SQS: a reliable queue for decoupling services. Producer puts a message in, exactly one consumer processes it. Dead-letter queues catch failures.

• SNS: fan-out pub/sub. One message published, multiple subscribers receive it simultaneously. Best for broadcasting events to multiple services.

• EventBridge: event routing with content-based filtering, schema registry, and 90+ AWS service integrations. The backbone for event-driven AWS architectures.

• Kinesis Data Streams: high-throughput, ordered, replayable event streaming. When you need to process events in order, replay them, or fan-out to multiple consumers with independent progress tracking.

Full comparison table

SQS: the workhorse

SQS Standard queues are the right choice for task queues, background job processing, and any pattern where you need reliable delivery to exactly one consumer. The visibility timeout prevents duplicate processing — when a consumer receives a message, it becomes invisible to other consumers until the consumer deletes it (success) or the timeout expires (retry). Configure a dead-letter queue to capture messages that fail repeatedly.

SQS FIFO queues add message ordering and exactly-once delivery, at the cost of lower throughput (3,000 messages/second with batching). Use FIFO when processing order matters — financial transactions, state machine transitions, or any workflow where out-of-order processing produces incorrect results. The MessageGroupId attribute allows parallel processing within a FIFO queue: messages in different groups are processed in parallel, messages in the same group are strictly ordered.

SNS: fan-out to multiple subscribers

The most common SNS pattern is SNS + multiple SQS queues (fan-out). An event is published once to SNS, and SNS delivers it to multiple SQS queues simultaneously. Each queue is consumed independently — your email service, analytics service, and audit service each get the same event without the publisher knowing or caring about the number of consumers.

SNS filter policies allow subscribers to receive only events matching specific message attributes. This is useful but limited compared to EventBridge — you can filter on message attributes but not on message body. SNS also supports Lambda, HTTP endpoints, email, and SMS as subscription targets, making it the right choice for notification fan-out to multiple delivery channels.

EventBridge: the underused gem

EventBridge is architecturally similar to SNS but significantly more powerful for complex routing. The killer features: content-based filtering on any field in the event JSON (route high-severity events to PagerDuty, low-severity to Slack, all events to S3 for archiving), 90+ AWS service integrations (S3, DynamoDB, CodePipeline, GuardDuty, and more all emit native EventBridge events), Schema Registry for documenting and validating event schemas, cross-account and cross-region event routing, and Pipes for point-to-point integrations with enrichment.

EventBridge Scheduler has largely replaced CloudWatch Events for cron-style Lambda triggers — it is more reliable, has timezone support, and can trigger hundreds of different target types. If you are still creating cron-scheduled Lambda functions via CloudWatch Events, migrate to EventBridge Scheduler.

Kinesis: when ordering and replay matter

Kinesis Data Streams is the right choice when you need: strict per-key event ordering (all events for a user ID processed in order), replay capability (reprocess a day's events after fixing a bug), or high-throughput streaming with multiple independent consumer groups each maintaining their own position.

Kinesis Firehose is a simpler delivery service — it buffers data and delivers it to S3, Redshift, OpenSearch, or Splunk. It is not a processing layer; it is a data delivery pipeline. Firehose does not support custom consumers or replay. Use Firehose when you want to land event data in S3 or Redshift without building a consumer.

Amazon MSK (Managed Streaming for Apache Kafka) is the right choice when you need Kafka specifically — existing Kafka consumer applications, Kafka Streams for stateful processing, or the Kafka ecosystem (Kafka Connect, Schema Registry, ksqlDB). MSK is operationally heavier than Kinesis but gives you full Kafka compatibility.

Common patterns

• S3 upload → SNS → multiple SQS queues: when a file lands in S3, fan-out to multiple consumers (virus scanner, thumbnail generator, analytics ingestion) via SNS + SQS

• Microservice event → EventBridge → multiple targets: domain events (OrderPlaced, UserRegistered) published to EventBridge, routed to multiple services based on content

• High-volume IoT telemetry → Kinesis → Lambda: ordered, high-throughput sensor data requiring per-device ordering and replay capability

• Background job queue → SQS + Lambda: reliable task processing with retry, DLQ for failures, and concurrency control via Lambda reserved concurrency