SQS vs SNS vs EventBridge vs Kinesis: The SAA-C03 Decision Guide

Introduction

On the AWS Certified Solutions Architect – Associate (SAA-C03) exam, application-integration questions almost never ask "what is SQS?" They hand you a scenario — a traffic spike, a fan-out requirement, a third-party webhook, a real-time analytics pipeline — and four answers that all look plausible. The skill being tested is matching the pattern to the service.

Amazon SQS (Simple Queue Service), Amazon SNS (Simple Notification Service), Amazon EventBridge, and Amazon Kinesis overlap enough to blur together and differ enough that the exam can always build a question where exactly one is correct. This guide gives you the decision framework first, then the properties that matter for each, then the head-to-head distinctions that trip people up.

The 10-second mental model

• SQS is a buffer. One component drops work in; another picks it up when it is ready. It decouples components and absorbs spikes.
• SNS is a megaphone. One message goes to many subscribers, delivered at once. This is fan-out.
• EventBridge is a router. Events arrive; rules decide which targets they go to, based on the content of the event. It is the glue for event-driven systems and SaaS integration.
• Kinesis is a pipe for streams. Ordered, replayable, high-volume data that multiple consumers read independently. This is real-time analytics.

If a scenario is about not losing work under load, think SQS. About telling several systems the same thing at once, think SNS. About reacting to events with routing or filtering logic, or to a schedule or a SaaS source, think EventBridge. About ingesting and analysing a continuous high-volume stream, think Kinesis.

How Do You Choose Between SQS, SNS, EventBridge and Kinesis?

Ask these four questions in order and stop at the first "yes":

1. Is it a continuous, high-volume stream you need to process in real time — in order, and possibly replay later? Use Kinesis Data Streams. If you only need that stream delivered to Amazon S3, Amazon Redshift, or Amazon OpenSearch Service with no code to write, use Kinesis Data Firehose.
2. Does one event need to reach multiple independent consumers? If the targets are chosen by the event's content, or the source is an AWS service state change, a schedule, or a SaaS partner, use EventBridge. If you need high-throughput, low-latency fan-out, or delivery to SMS, email, or mobile push, use SNS — typically SNS publishing to several SQS queues so each consumer has its own durable copy.
3. Do you just need to decouple two components so work is not lost when the consumer is slow or down? Use SQS.
4. Does that decoupled work need strict ordering and exactly-once processing? Use an SQS FIFO queue.

Amazon SQS in Depth

SQS is a fully managed message queue. A producer sends a message; it sits in the queue (retention is 1 minute to 14 days, default 4 days) until a consumer polls for it, processes it, and deletes it. If the consumer is slow, the queue simply gets longer — nothing is lost.

Exam-relevant properties:

• Standard vs FIFO. Standard queues give near-unlimited throughput, at-least-once delivery, and best-effort ordering. FIFO queues guarantee strict order and exactly-once processing, at lower throughput (hundreds to a few thousand messages per second, higher with high-throughput mode).
• Visibility timeout. While one consumer is processing a message, it is hidden from others. If processing fails and the timeout expires, the message reappears for retry.
• Dead-letter queue. After a set number of failed processing attempts, a message is moved aside so it stops blocking the queue and can be inspected.
• Long polling reduces empty responses and cost versus short polling.
• Maximum message size is 256 KB; larger payloads go in S3 with the message carrying a pointer.

What SQS does not do is fan-out. Each message is consumed by exactly one consumer. If two systems both need every message, you need SNS or EventBridge in front, or two queues fed separately.

The classic SQS pattern is load levelling: put a queue between a spiky front end and a processing tier that can only handle a steady rate.

Amazon SNS in Depth

SNS is publish/subscribe. Publishers send a message to a topic; the topic immediately pushes it to every subscriber. Subscribers can be SQS queues, AWS Lambda functions, HTTP/S endpoints, email, SMS, mobile push, and Kinesis Data Firehose.

Exam-relevant properties:

• Fan-out. One publish, many deliveries. The durable version of this is SNS to multiple SQS queues: SNS handles the one-to-many, and each SQS queue guarantees its consumer will not miss anything even if it is down for a while.
• Message filtering. Subscribers can attach a filter policy so they only receive messages whose attributes match — basic content filtering, less expressive than EventBridge's.
• No replay. SNS does not store messages for a consumer to pick up later. Failed deliveries are retried per a retry policy, then sent to a dead-letter queue if you configured one; otherwise they are dropped.
• FIFO topics exist and pair with FIFO SQS queues when ordered fan-out is required.
• SNS is the service for SMS, email, and mobile push notifications.

Amazon EventBridge in Depth

EventBridge (the former CloudWatch Events, expanded) is a serverless event bus. Events flow onto a bus; rules match them with event patterns and send matching events to targets such as Lambda, SQS, SNS, AWS Step Functions, Kinesis, and Amazon ECS tasks.

Exam-relevant properties:

• AWS service events. Most AWS services emit events to the default bus — EC2 instance state changes, Auto Scaling actions, S3 events, and so on. EventBridge is how you react to "something changed in my account".
• Scheduled rules run a target on a cron or rate schedule — the modern replacement for wiring cron to Lambda.
• SaaS partner sources. Third parties such as Datadog, Zendesk, and PagerDuty can deliver events straight onto a partner event bus in your account.
• Content-based routing. Event patterns match on the structure and values of the event payload — richer than SNS filter policies.
• Archive and replay. You can archive matched events and replay them later, which SNS cannot do.
• Trade-off. EventBridge has higher latency (roughly half a second) and lower throughput than SNS, and costs more per event at scale. You pay that for the routing, filtering, scheduling, and SaaS integration.

Amazon Kinesis in Depth

Kinesis is a family of services for streaming data. Two matter most for the associate exam.

Kinesis Data Streams ingests and stores an ordered stream. Data is split across shards; order is guaranteed within a shard. Retention runs from 24 hours up to 365 days, and multiple consumers can read the same data independently and replay it from any point in the retention window. Consumers include Lambda, the Kinesis Client Library, and Amazon Managed Service for Apache Flink. Capacity is either provisioned (you manage shard count) or on-demand (it scales for you).

Kinesis Data Firehose is fully managed delivery. It takes a stream and lands it in S3, Redshift, OpenSearch, Splunk, or an HTTP endpoint, with an optional Lambda transform on the way. It buffers (minimum around 60 seconds, so "near real time", not real time), does not store data for replay, and has no consumer code to write or infrastructure to manage.

Reach for Kinesis over SQS when the scenario mentions real-time analytics, ordered data, replay, multiple independent consumers, or high-volume clickstream, log, or IoT ingestion.

The Four Distinctions the Exam Actually Tests

SNS vs SQS

SQS stores each message until a consumer processes and deletes it; a slow or offline consumer just means a longer queue. SNS pushes immediately and stores nothing for later pickup — failed deliveries retry, then go to a dead-letter queue or are lost. That is why durable fan-out is SNS publishing to several SQS queues. Exam tell: "multiple consumers" and "must not lose messages" points to SNS plus SQS, not SNS alone.

EventBridge vs SNS

Both fan out. Choose EventBridge when you need to route on the content of the event, the source is an AWS service state change, you need a schedule, you are integrating a SaaS product, or you want archive and replay. Choose SNS when you need maximum throughput and lowest latency, or you are sending SMS, email, or mobile push. EventBridge trades latency, throughput, and cost for far better routing.

Kinesis vs SQS

Both decouple. Kinesis keeps an ordered, replayable log that many consumers read independently; SQS deletes each message once one consumer handles it. Tell: "real-time analytics", "replay", "each consumer needs the full stream", "clickstream / IoT / logs", or "in order" points to Kinesis. Just "decouple these two components" or "smooth out the load" points to SQS.

Kinesis Data Streams vs Firehose

Data Streams is sub-second, you provide the consumer logic, it retains and replays data, and you (or on-demand mode) manage shards. Firehose is near real time (buffered around 60 seconds minimum), fully managed delivery to S3, Redshift, OpenSearch, or Splunk, with an optional Lambda transform, no replay, and nothing to build. Tell: "load streaming data into S3 with no administration" points to Firehose. "Process in real time, replay it, custom consumers" points to Data Streams.

Seven Worked Scenarios

1. A retail app sees 10x traffic during flash sales and the order-processing tier is dropping requests. Use SQS. Queue the orders; the processing tier consumes at its own rate. This is load levelling.
2. When a user uploads a photo, three services must each act — thumbnails, search index, audit log — and none can miss an event. Use an SNS topic publishing to three SQS queues, one per service. This is fan-out with per-consumer durability.

3. Run a cleanup Lambda every night at 02:00, and also whenever an S3 object is tagged expired. Use EventBridge: a scheduled rule for the nightly job, and an event-pattern rule on the S3 event for the tag.
4. Ingest a clickstream of millions of events per minute, run real-time analytics, and be able to reprocess the last 7 days if the logic changes. Use Kinesis Data Streams with 7-day retention, replay, and multiple consumers.
5. Deliver application logs to S3 and OpenSearch for analysis, with no streaming infrastructure to manage. Use Kinesis Data Firehose.
6. Process financial transactions exactly once, in the order received. Use an SQS FIFO queue.
7. A third-party monitoring SaaS should trigger an incident workflow in your account when it emits a critical alert. Use EventBridge with the partner event source.

Why Practice Exams Alone Do Not Move Your Score

Reading comparisons gets you to "I recognise these four." The exam needs "I can pick the right one, fast, on a scenario written to nudge me toward the wrong one." That only comes from doing scenario questions and then reviewing your misses by why you missed them — did you reach for SNS when durability made it SNS plus SQS? Did you pick SQS when the word replay made it Kinesis?

That review step is where most people stall. They take practice exam after practice exam and plateau, because they never categorise their mistakes. If you want a structured way to study, start with our realistic 6-week SAA-C03 study plan, then use practice tests to find and drill your weak domains.

Key Takeaways

• SQS: a buffer for decoupling and load levelling. One consumer per message. Use FIFO for strict order and exactly-once processing.
• SNS: fan-out, one-to-many, push. No replay. Pair with SQS for durable fan-out. It is also the service for SMS, email, and push.
• EventBridge: content-based routing, AWS service events, schedules, SaaS integration, and archive/replay. Higher latency, richer rules.
• Kinesis: ordered, replayable, high-volume streams with multiple independent consumers. Use Firehose when you only need managed delivery to S3, Redshift, or OpenSearch.