SQS vs SNS vs EventBridge vs Kinesis

Amazon SQS, Amazon SNS, Amazon EventBridge and Amazon Kinesis Data Streams all move data between parts of an application, which is why exam questions love to mix them up. The trick is to read the requirement: does one consumer pull work from a buffer, should many subscribers get a copy, should events be routed by content, or is it a continuous stream that several apps read and replay?

This page turns that into a quick decision table, a side-by-side comparison and the traps that show up in SAA-C03 and DVA-C03 (DVA-C02 until Nov 30) questions. You will also see where Amazon Data Firehose fits in the Kinesis vs Firehose question, and where Apache Kafka (Amazon MSK) comes in when someone asks SQS vs Kafka.

Reviewed against the AWS documentation

At a glance

Amazon SQS

A hosted message queue that decouples producers from consumers. Consumers pull messages, process them and delete them.

  • Buffering work so a slow or failing consumer does not lose messages
  • Spreading jobs across a pool of workers
  • Strict ordering within a message group (FIFO queues)
AWS docs

Amazon SNS

A publish/subscribe service. Publishers send to a topic and SNS pushes a copy to every subscriber, including other applications and people.

  • Fanout: one message to many SQS queues, Lambda functions or HTTP endpoints
  • Alerts by email, SMS or mobile push
  • Filtering so each subscriber receives only the messages it cares about
AWS docs

Amazon EventBridge

A serverless event router. Events from AWS services, your own apps or SaaS providers go to an event bus, and rules (or subscribers on the newer Custom Event Bus) send matching events to targets.

  • Reacting to AWS service events (for example an EC2 state change)
  • Content-based routing from many sources to many targets
  • Archiving and replaying events, and scheduled tasks with EventBridge Scheduler
AWS docs

Amazon Kinesis Data Streams

A service for collecting and processing large streams of records in real time. Records are stored in shards and stay readable for a retention period.

  • Clickstreams, logs and metrics that need real-time processing
  • Several independent applications reading the same data
  • Re-reading records within the retention period
AWS docs

Which one does the question want?

If the question saysPickWhy
Buffer orders so a slow backend does not drop requests, and one worker handles each orderSQSA queue holds messages until a consumer receives and deletes them, so producers and consumers can run at different speeds. Docs
One order event must reach billing, shipping and analytics at the same timeSNSPublishing to a topic replicates the message to every subscriber. The classic pattern is SNS fanout to several SQS queues. Docs
Send an email or SMS when a CloudWatch alarm firesSNSSNS delivers application-to-person messages straight to email, SMS and mobile push subscribers, and CloudWatch alarms notify people through an SNS topic. Docs
Run a Lambda function whenever an EC2 instance changes stateEventBridgeAWS services send events to the default event bus, and a rule with an event pattern sends the matching ones to a target such as Lambda. Docs
Route events by their content to different targets and replay them later after a bug fixEventBridgeRules match on event patterns, and an archive lets you replay events to the bus that received them. The newer Custom Event Bus keeps events itself, so a subscriber can start again from an earlier point. Docs
Ingest clickstream data in real time and let several apps read it, each at its own paceKinesisRecords stay in the stream for the retention period, and multiple applications can read the same stream independently. Docs
Process messages in the exact order they were sent, per customerSQSFIFO queues deliver messages in order within each message group and support deduplication. Docs
Each subscriber should only receive messages that match its own filterSNSA filter policy on each subscription decides which messages that subscriber receives. Docs

SQS vs SNS

SQS is a queue: messages wait until a consumer pulls them, and each message is handled by one consumer and then deleted. SNS is publish/subscribe: SNS pushes a copy of every message to every subscriber straight away and does not hold messages for consumers to pull (only FIFO topics can archive messages and replay them).

If one piece of work needs one worker, pick SQS. If one event needs to reach several systems or people, pick SNS. Many exam answers use both: an SNS topic fanning out to one SQS queue per consumer.

AspectSQSSNS
Delivery model Pull: consumers poll the queuePush: SNS delivers to each subscriber
Who gets each message One consumer processes it, then deletes itEvery subscriber gets a copy, unless its filter policy drops it
Keeps messages Default 4 days, 1 minute to 14 daysStandard topics: no, they deliver and do not store. FIFO topics can archive messages for up to 365 days and replay them
Ordering FIFO queues: in order within a message groupFIFO topics: in order to subscribed SQS queues
Subscribers or consumers Your workers, Lambda functions or other services that pollSQS queues, Lambda functions, HTTP endpoints, Firehose, email, SMS and mobile push
Slow or failing consumer Messages wait in the queue; the visibility timeout hides one while it is processedSubscribe an SQS queue to buffer, or add a dead-letter queue to the subscription

Kinesis Data Streams vs Firehose

Kinesis Data Streams stores records for a retention period so your own applications can read them, several at once and more than once. Amazon Data Firehose has no consumers to write: it buffers incoming data and delivers it to a destination such as Amazon S3, Amazon Redshift, OpenSearch Service, Splunk or an HTTP endpoint.

If the question needs custom real-time processing or replay, pick Kinesis Data Streams. If it says "load streaming data into S3 or Redshift with no code to manage", pick Firehose. They also chain: a Firehose stream can read from a Kinesis data stream.

AspectKinesis Data StreamsFirehose
Job Hold a stream that your consumers readDeliver data to a destination, with nothing to write or manage
Who reads the data Your consumers: KCL apps, Lambda, Managed Service for Apache Flink or FirehoseNobody: Firehose writes it to the destination you choose
Replay Re-read records any time within retention (default 24 hours, up to 365 days)No replay: it buffers, then delivers
Latency Real time: consumers read records as they arriveBuffers by size or time (for S3 the default is 300 seconds); a zero buffering interval delivers within a few seconds
Capacity On-demand or provisioned shardsFully managed; no capacity to choose
Transforming data In your consumer codeOptional Lambda transform, and JSON to Parquet or ORC conversion before S3

Side by side

AspectSQSSNSEventBridgeKinesis
Model Queue: consumers pull messagesTopic: SNS pushes to subscribersEvent bus: rules route events to targetsStream: consumers read records from shards
Who receives a message One consumer gets a message while it is being processed, then it is deletedEvery subscriber gets a copy (unless filtered out)Every target of every matching rule (up to five per rule); on the newer Custom Event Bus, every matching subscriberSeveral applications can read the same records independently and at the same time
Management Fully managed, scales without provisioningFully managedServerlessManaged; you choose on-demand or provisioned capacity
Ordering Standard: best effort. FIFO: in order within a message groupStandard topics: best effort. FIFO topics: strict order to subscribed SQS queuesDefault bus and classic custom buses: no ordering. The newer Custom Event Bus: FIFO subscribers deliver in order within an event groupRecords with the same partition key go to the same shard, where they are ordered by sequence number
Delivery guarantee Standard: at-least-once. FIFO: exactly-once processingFIFO topics deliver each message once to subscribed SQS queues; a standard queue subscriber can still see duplicatesRetries failed deliveries and can send undelivered events to an SQS dead-letter queue; the Custom Event Bus can also deduplicate at publish timeRecords stay available until retention expires, so consumers can re-read them
How long data is kept Default 4 days, 1 minute to 14 daysStandard topics: not a store, they deliver to subscribers. FIFO topics can archive messages for up to 365 days and replay themDefault and classic buses keep nothing unless you add an archive (kept indefinitely by default). The Custom Event Bus retains events 1 to 365 daysDefault 24 hours, up to 365 days
Message or record size Up to 1 MiB; larger payloads via the Extended Client Library with S3Default 256 KiB; topics can be set up to 1 MiB (SQS, Lambda and Firehose subscribers only)A PutEvents request must be under 1 MB in total, and one event can use all of it. The Custom Event Bus also accepts Avro, Protobuf and raw bytes1 MiB per record by default; a stream can be set to accept records up to 10 MiB
Capacity and pricing model Nothing to provision; scales automatically and you pay per requestNothing to provision; you pay per message published and per notification deliveredNothing to provision; you pay for the events you publish, and archives (or Custom Event Bus retention and deliveries) are chargedProvisioned: pay per shard per hour. On-demand: pay per GB written and read
Failure handling Visibility timeout (default 30 seconds) and dead-letter queuesSubscriptions can have an SQS dead-letter queue; subscribing SQS queues adds bufferingRetries, a per-target SQS dead-letter queue, and replay from an archiveRe-read records from the stream within retention
Typical use Decoupling, work queues, bufferingFanout, alerts, notificationsEvent-driven routing, SaaS and AWS service events, schedulesReal-time analytics, logs, clickstreams

Exam traps

  • Choosing SQS when many consumers each need every message

    An SQS message is processed by one consumer and then deleted, so several consumers share the work rather than each getting a copy. For a copy to each, publish to SNS and subscribe one SQS queue per consumer (fanout), or use Kinesis if they need to read the same records independently.

    AWS docs

  • Picking SNS for ordered processing without FIFO

    Standard SNS topics and standard SQS queues only give best-effort ordering, and standard queues deliver at least once. When order matters, look for SQS FIFO queues, or an SNS FIFO topic feeding SQS FIFO queues, which delivers in order and only once.

    AWS docs

  • Kinesis Data Streams vs Amazon Data Firehose

    Kinesis Data Streams stores records so your own consumers can read and re-read them. Amazon Data Firehose has no consumers to write: it buffers data and delivers it to destinations such as S3, Redshift or OpenSearch Service. If the question says "load into S3 with no custom code", think Firehose.

    AWS docs

  • Forgetting EventBridge for AWS service events and schedules

    When a requirement says "when an AWS resource changes state" or "run on a schedule", EventBridge is usually the answer: AWS services send events to the default event bus, and EventBridge Scheduler runs cron, rate and one-time schedules. SNS is for notifying subscribers, and SQS does not generate events on its own.

    AWS docs

  • SQS vs Kafka: reaching for Amazon MSK when the question is about simple decoupling

    Amazon MSK runs open-source Apache Kafka, which fits teams that already use Kafka tooling. For plain decoupling on AWS with nothing to manage, SQS is the simpler answer; for AWS-native real-time streaming, Kinesis is.

    AWS docs

Practice it

DVA-C03 serverless drill (6 questions)SAA-C03 high-availability drill (10 questions)

Frequently Asked Questions

What is the difference between SQS and SNS?

SQS is a queue: consumers pull messages and each message is processed by one consumer. SNS is publish/subscribe: SNS pushes a copy of each message to every subscriber. They work well together, with an SNS topic fanning out to several SQS queues.

When do I use EventBridge instead of SQS?

Use EventBridge when you need to route events by their content from AWS services, your apps or SaaS providers to targets, or run schedules. Use SQS when you need a durable buffer that consumers pull from at their own pace. The two combine well, because SQS can be an EventBridge target.

What is the difference between Kinesis Data Streams and Firehose?

Kinesis Data Streams keeps records for a retention period (24 hours by default, up to 365 days) so you can build consumers that read them, even several at once. Amazon Data Firehose is a delivery service that buffers streaming data and loads it into destinations like S3 without you writing consumer code.

How does SQS compare with Kafka?

SQS is a fully managed queue with nothing to size, while Amazon MSK is a managed Apache Kafka service that runs open-source Kafka, so existing Kafka applications work unchanged. On SAA-C03, pick SQS for simple decoupling and MSK when the question mentions Kafka. MSK is not on the DVA-C03 service list, so expect SQS, SNS, EventBridge and Kinesis there.

Which service guarantees message ordering?

SQS FIFO queues keep order within a message group. SNS FIFO topics deliver in order to SQS FIFO queue subscribers. In Kinesis Data Streams, the partition key decides the shard, and records with the same partition key are ordered there by sequence number. On EventBridge, only the newer Custom Event Bus offers ordering, through FIFO subscribers and event groups.