SQS vs SNS vs Kinesis, and Amazon MQ

By the end of this lesson you will be able to

• Compare SQS, SNS and Kinesis Data Streams side by side: push or pull, what happens to a message after it is read, how long data is kept, ordering, duplicates, how many consumers, how each one scales, and replay.
• Pick the right service (or combination) for a scenario from its keywords, including SQS FIFO, SNS + SQS fan-out, Kinesis + Data Firehose, and when the answer is EventBridge or Amazon MSK instead.
• Explain the “core trio” of event-driven AWS, Lambda, SNS and SQS, together with dead-letter queues and the fan-out pattern.
• Explain what Amazon MQ is, which open protocols it speaks (JMS, NMS, AMQP, STOMP, MQTT, OpenWire, WebSocket), and why it is the answer for migrating legacy applications without rewriting them, but not for new cloud-native ones.
• Design Amazon MQ for high availability: ActiveMQ active/standby across two AZs with shared EFS storage, RabbitMQ three-node clusters, and the limits of a broker that runs on servers.

#The chapter on one page

This lesson closes the decoupling chapter. Lesson 13.1 introduced the three models; lessons 13.2 to 13.6 went deep into each service. Here we put them next to each other, so that in an exam question or a design review you can choose in seconds and defend the choice.

A quick reminder of the three models (lesson 13.1):

• Queue (SQS): a producer leaves work; one consumer takes each message, does it, and deletes it.
• Publish/subscribe (SNS): a publisher sends one message; every subscriber gets its own copy, pushed at once.
• Stream (Kinesis Data Streams): producers append records to a log; many consumers read the same records, each at its own position, for as long as the retention period lasts.

The notes put each service in one line:

• Amazon SQS decouples applications. Consumers pull messages from the queue, and a message is deleted for good once a consumer processes it successfully. Use it to give work to a worker tier (video processing, sending email).
• Amazon SNS works on the pub/sub model and pushes data to everyone. A standard topic stores nothing: once sent, the message is finished. Use it when one event must notify many services or users at once (fan-out).
• Amazon Kinesis manages huge volumes of streaming data. Data is not deleted after it is read (there is a retention period), and several consumers can read the same data again and again. Use it for big data and for running different real-time analytics on the same stream.

#SQS vs SNS vs Kinesis side by side

How to read the table:

• Push or pull decides who has to be ready. With SNS, the subscriber must be reachable when SNS calls; with SQS and standard Kinesis consumers, the consumer asks when it is ready, so a slow or offline consumer only builds a backlog.
• What happens after a read is the deepest difference. A queue is a to-do list: done items are removed. A topic is an announcement: nothing to look up later. A stream is a recording: reading it changes nothing, and anyone can rewind.
• Capacity is a reason to prefer SQS and SNS when you can: there is nothing to size. With Kinesis you choose provisioned shards or on-demand mode (lesson 13.5).
• Ordering costs throughput everywhere: FIFO queues and topics have group-level limits (lesson 13.3), and Kinesis orders only inside one shard.

#Myth: “SNS stores no data”

#Where Data Firehose and Amazon MQ fit

The table above is the classic exam triangle. The other services of this chapter fill two gaps:

Firehose is covered in lesson 13.6; its exam trick is “near real time, no code, load into a destination”. Amazon MQ gets its own section below.

#Choosing: a decision guide

1. Is it an existing application that speaks a standard messaging protocol?

   If the app uses JMS, NMS, AMQP, STOMP, MQTT or OpenWire with a broker such as ActiveMQ or RabbitMQ, and must move to AWS without rewriting its messaging code: Amazon MQ. Otherwise, continue.

2. Does each message need to be handled by one worker, or seen by everyone?

   One worker per message (jobs, tasks, orders to process): a queue, SQS. If order per customer or exactly-once processing matters: SQS FIFO. If everyone must see every message, continue.

3. Must every receiver get it now, and is it acceptable that nobody can read it later?

   Notifications to people and endpoints (email, SMS, mobile push, HTTP webhooks): SNS. If each receiver is a system that must not lose a message while it is down: SNS + SQS fan-out, one queue per receiver.

4. Do several consumers need the same data at their own pace, or a replay?

   High-volume events (clickstreams, logs, IoT readings, transactions) read by several independent apps, real-time analytics, or reprocessing after a bug: Kinesis Data Streams. If you only need to load the stream into storage without writing code: Data Firehose (directly, or reading from a Kinesis data stream).

5. Do the events come from AWS services or SaaS apps, routed by rules?

   “When an EC2 instance changes state…”, “when someone calls this API…”, events from a partner SaaS, content-based rules to many targets, scheduled events: Amazon EventBridge (chapter 19, lesson 19.5). And if the team already runs Apache Kafka, the managed answer is Amazon Managed Streaming for Apache Kafka (lesson 17.7).

#The keyword map

Try it with real scenarios before you read the reasons:

#Combined patterns

Most real systems use more than one of these services. The four patterns below appear again and again, in architectures and in exam answers.

#SNS + SQS fan-out

Publish once to an SNS topic, subscribe one SQS queue per consumer. SNS gives every queue its own copy; each queue then gives its consumer buffering, retries, a DLQ and its own pace. Adding a consumer means adding a queue, with no change to the producer. Each queue’s access policy must allow the topic to send to it; cross-account and cross-Region subscriptions work; a filter policy on a subscription lets that queue receive only some messages; and SNS FIFO + SQS FIFO keeps order through the fan-out. All of this is lesson 13.4.

#S3 events through SNS

An S3 event notification (lesson 10.7) can target SQS, SNS or Lambda, but one event type on one prefix can have only one destination. When an upload must start several independent jobs (thumbnails, virus scan, indexing), the destination is an SNS topic that fans out to several queues. The alternative is sending S3 events to EventBridge, which can route them to many targets.

#Kinesis Data Streams + Data Firehose

A Kinesis data stream takes the high-volume events once. Real-time consumers (Lambda, an app using the KCL, Managed Service for Apache Flink) read it within a second for dashboards and alerts, while Data Firehose reads the same stream and loads it in batches into S3, Redshift or OpenSearch. The stream gives replay and several readers; Firehose gives storage with no code (lesson 13.6).

#SQS in front of a database

During a spike the queue absorbs the burst and the workers (or Lambda) write at a rate the database can take. The producer stays fast, nothing is lost, and the database never sees the wall of traffic (lesson 13.1).

#The core trio: Lambda, SNS and SQS

The notes call these three the foundation of event-driven architecture on AWS:

• SQS is a message queue that decouples applications. It is pull-based: the consumer (an EC2 worker, or Lambda) takes messages from the queue.
• SNS is pub/sub and push-based: when a message is published, every subscriber (email, SMS, SQS, Lambda…) gets it at once.
• Lambda is serverless compute: it runs your code automatically when an event happens, for example a new message in SQS or a notification from SNS.

One correction that the exam likes: Lambda is not pushed to by SQS. The Lambda service runs an event source mapping that polls the queue (with long polling), hands your function a batch, and deletes the messages when the function succeeds. With SNS it is the other way round: SNS invokes the function. Lambda and event source mappings are covered in depth in chapter 15 (lesson 15.1).

#Dead-letter queues in one paragraph

When SQS, SNS or Lambda fails to process a message again and again (the maximum retries are used up), the message is moved to a separate queue so it is not lost and does not block the rest: the dead-letter queue (DLQ). Developers inspect it later to debug. On SQS you configure it with a redrive policy on the source queue, which names the DLQ and sets maxReceiveCount; when a message has been received that many times without being deleted, SQS moves it. A FIFO queue’s DLQ must also be FIFO, the DLQ must be in the same account and Region, and its retention should be longer than the source queue’s. After the fix you can redrive the messages back to the source. For SNS, a DLQ is an SQS queue attached per subscription. Details and the retention trap are in lesson 13.2.

#The fan-out pattern in one paragraph

One SNS topic, several SQS queues subscribed to it. A message published to the topic fans out to all queues at once, so the same message can drive completely different work in parallel: one queue’s worker saves the order to the database, another’s sends the email. Exam phrase: “a single event needs to trigger multiple independent workflows concurrently without data loss” → SNS + multiple SQS.

#Amazon MQ

#Why a broker, when SQS and SNS exist

SQS and SNS are cloud-native services with AWS’s own API: you call them over HTTPS with the AWS SDK or CLI. They do not speak the open messaging protocols that the rest of the industry has used for decades.

Many companies still run applications on premises that talk to a message broker such as Apache ActiveMQ, RabbitMQ or IBM MQ through standard protocols and APIs: JMS, NMS, AMQP, STOMP, MQTT, OpenWire, WebSocket. Moving such an application to SQS or SNS means rewriting every send and receive, changing how acknowledgements, transactions, topics and selectors work, and testing it all again.

Amazon MQ is a managed message broker service for Apache ActiveMQ and RabbitMQ. AWS runs the broker for you (provisioning, patching, backups, failover), and it speaks those same protocols, so the application keeps its code and only its connection string changes. That is the whole reason it exists: the notes’ “no time or budget to rewrite for SQS/SNS”.

#The open protocols

All endpoints use TLS. Amazon MQ for RabbitMQ speaks AMQP 0-9-1 (port 5671), and since November 2025 RabbitMQ 4.2 on Amazon MQ adds native AMQP 1.0; it also offers the RabbitMQ web console. (Side note: RabbitMQ 4.2 runs on the Graviton mq.m7g instances and uses quorum queues as its only replicated queue type; the exam does not go into versions.)

#Two engines

Both engines offer queues (point to point, like SQS) and topics or exchanges (publish/subscribe, like SNS) in one broker. That is how traditional brokers have always worked, and why one Amazon MQ broker can replace both halves of a legacy setup.

#It runs on servers

Amazon MQ is managed, but it is not serverless:

• You choose a broker instance type (for example mq.t3.micro for tests, mq.m5.large and bigger, or the Graviton mq.m7g family) and a deployment mode. You pay per broker-hour plus storage per GB-month, whether messages flow or not.
• A broker has fixed limits: ActiveMQ allows up to 2,000 connections per wire-level protocol on the large instance types (300 on micro), 200 GB of storage on mq.m5 brokers, and 200 brokers per Region by default.
• To handle more load you move to a bigger instance type (applied with a reboot, which on active/standby is a short failover) or build a network of brokers. It does not “scale” the way SQS and SNS do, which the slides point out directly.
• The broker lives in your VPC subnets with security groups. It can be private (reached over VPN or Direct Connect from the office) or publicly accessible. Messages are encrypted at rest with KMS and in transit with TLS; ActiveMQ users authenticate with a username and password or through LDAP.

#High availability

The slides draw the ActiveMQ picture: an active broker in one AZ, a standby broker in another AZ of the same Region, both connected to Amazon EFS as storage, and the client failing over from one to the other.

• Single-instance (ActiveMQ or RabbitMQ): one broker in one AZ, storage on EBS (or EFS for ActiveMQ). Cheap and fine for development; if the AZ or the broker fails, the broker is unavailable until AWS recovers it.
• Active/standby (ActiveMQ): two brokers in two AZs as a redundant pair, sharing one message store on Amazon EFS, which stores data redundantly across AZs. Only one broker is active. When it fails, or during the weekly maintenance window, Amazon MQ promotes the standby, which opens the same store, so persisted messages are not lost; a reboot failover takes only seconds. Each protocol has two endpoints (-1 and -2), and clients must use the failover transport with both, for example failover:(ssl://b-…-1.mq…:61617,ssl://b-…-2.mq…:61617).
• Cluster (RabbitMQ): three nodes in three AZs behind a Network Load Balancer, sharing users, queues and state; messages are replicated across the nodes. Maintenance is done one node at a time, and clients must reconnect automatically.
• Network of brokers (ActiveMQ): several brokers (each single or active/standby) linked together, for scale or for different sites.

#Amazon MQ vs SQS and SNS

#What goes wrong

#Messaging in system design

• Default to SQS and SNS for new services: no capacity to plan, pay per use, and the integrations (Lambda, S3 events, ASG scaling, Beanstalk worker environments from lesson 9.4) are built in.
• Queue per consumer, topic per event type. Publish domain events (“order placed”, “payment received”) to SNS topics, and give every consuming service its own SQS queue with its own DLQ. Services can then be deployed, scaled and broken independently.
• Kinesis for data, SQS for work. Events that several teams analyse, or that you may need to replay, belong in a stream; jobs that must be done once belong in a queue. Many systems have both, fed from the same producer.
• Firehose at the end of the stream for the data lake, and Managed Service for Apache Flink or Lambda for real-time results (chapter 17).
• Amazon MQ as a bridge. Lift and shift a legacy app onto Amazon MQ to meet the migration deadline, then build new consumers on SQS/SNS, and retire the broker when the old app goes. AWS migration patterns are in chapter 23 (server migration).
• Idempotency everywhere. Standard SQS, SNS, Kinesis and a broker failover can all deliver a message more than once; consumers should be safe to run twice.
• Watch the backlog. ApproximateNumberOfMessagesVisible for queues, GetRecords.IteratorAgeMilliseconds for streams, DLQ depth for every queue: these tell you a consumer is falling behind before customers do (CloudWatch, chapter 19).
• Events across the account: when the source is AWS itself (an instance state change, an API call recorded by CloudTrail) or a SaaS partner, use EventBridge; lesson 24.1 collects the event-processing architectures.

#Try it yourself

The same “order placed” event through each service. Account 111122223333, Region ap-southeast-1; outputs are shortened.

# 1. SQS: send, receive, delete (one consumer takes it)
aws sqs create-queue --queue-name orders-example
#   "QueueUrl": "https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example"
Q=https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example
aws sqs send-message --queue-url $Q --message-body '{"orderId":"A-1001","area":"Dhanmondi"}'
aws sqs receive-message --queue-url $Q --wait-time-seconds 20 --max-number-of-messages 10
#   "Messages": [{ "MessageId": "5fea7756-…", "ReceiptHandle": "AQEB…", "Body": "{\"orderId\":\"A-1001\",…}" }]
aws sqs delete-message --queue-url $Q --receipt-handle "AQEB…"
aws sqs receive-message --queue-url $Q --wait-time-seconds 5     # nothing: it is gone

# 2. SNS: publish once, every subscriber gets a copy (fan-out to the queue above)
aws sns create-topic --name order-events-example
#   "TopicArn": "arn:aws:sns:ap-southeast-1:111122223333:order-events-example"
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example \
  --protocol sqs --notification-endpoint arn:aws:sqs:ap-southeast-1:111122223333:orders-example
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example \
  --protocol email --notification-endpoint ops@example.com
aws sns publish --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example \
  --message '{"orderId":"A-1002"}'
#   "MessageId": "a1b2c3d4-…"   (the queue needs an access policy that allows this topic to send)

# 3. Kinesis: put a record, read it twice, replay from a time
aws kinesis create-stream --stream-name order-stream-example --stream-mode-details StreamMode=ON_DEMAND
aws kinesis put-record --stream-name order-stream-example --partition-key Dhanmondi \
  --data '{"orderId":"A-1003"}' --cli-binary-format raw-in-base64-out
#   "ShardId": "shardId-000000000002", "SequenceNumber": "49654…"
IT=$(aws kinesis get-shard-iterator --stream-name order-stream-example --shard-id shardId-000000000002 \
  --shard-iterator-type AT_TIMESTAMP --timestamp 2026-10-26T09:00:00Z --query ShardIterator --output text)
aws kinesis get-records --shard-iterator $IT      # the record is still there, as often as you like

# 4. Amazon MQ: an ActiveMQ active/standby broker in two subnets (two AZs), EFS storage
aws mq create-broker --broker-name orders-mq-example --engine-type ACTIVEMQ --engine-version 5.18 \
  --deployment-mode ACTIVE_STANDBY_MULTI_AZ --host-instance-type mq.m5.large --storage-type EFS \
  --no-publicly-accessible --auto-minor-version-upgrade \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example --security-groups sg-0ccc3333example \
  --users Username=orders-admin,Password='use-a-long-secret-here',ConsoleAccess=true
#   "BrokerId": "b-1234abcd-56ef-78ab-90cd-1234567890ab"
aws mq describe-broker --broker-id b-1234abcd-56ef-78ab-90cd-1234567890ab \
  --query 'BrokerInstances[].Endpoints'
#   [ ["ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:61617",
#      "amqp+ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:5671",
#      "stomp+ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:61614",
#      "mqtt+ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:8883",
#      "wss://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:61619"],
#     ["ssl://b-1234abcd-…-2.mq.ap-southeast-1.amazonaws.com:61617", … ] ]
aws mq reboot-broker --broker-id b-1234abcd-56ef-78ab-90cd-1234567890ab   # watch the client fail over

# 5. Clean up (the broker costs money every hour, even idle)
aws mq delete-broker --broker-id b-1234abcd-56ef-78ab-90cd-1234567890ab
aws kinesis delete-stream --stream-name order-stream-example
aws sns delete-topic --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example
aws sqs delete-queue --queue-url $Q

The legacy app only changes its broker URL to the failover form of the two ssl:// endpoints. Notice the contrast in step 4: you chose an instance type, two subnets and a deployment mode, none of which SQS or SNS ever asked you for.

#Summary

Key takeaways

• SQS = queue, pull, one consumer per message, deleted after processing, kept up to 14 days, no capacity planning, order only with FIFO, per-message delay. Worker tiers and buffering.
• SNS = pub/sub, push to up to 12,500,000 subscriptions per topic, standard topics keep nothing (retries, subscription DLQ, FIFO archive and replay are the exceptions), up to 100,000 topics, no capacity planning, FIFO topics for order. Notifications and fan-out.
• Kinesis Data Streams = stream, standard consumers pull (2 MB/s per shard shared), enhanced fan-out pushes (2 MB/s per shard per consumer), records stay 24 hours to 365 days, replay, order per shard, provisioned or on-demand. Real-time big data, analytics, ETL.
• Data Firehose loads streams into S3, Redshift, OpenSearch and more, near real time, no code, no replay. EventBridge routes AWS and SaaS events by rules (lesson 19.5); Amazon MSK is managed Kafka (lesson 17.7).
• Patterns: SNS + SQS fan-out (one event, many independent workflows, no loss), S3 → SNS → SQS, Kinesis + Firehose, SQS in front of a database.
• The core trio: SQS pulls, SNS pushes, Lambda runs code (Lambda polls SQS through an event source mapping). DLQ via a redrive policy for poison messages.
• Amazon MQ = managed ActiveMQ / RabbitMQ broker speaking JMS, NMS, AMQP, STOMP, MQTT, OpenWire, WSS: the answer for migrating existing apps without rewriting, not for new cloud-native apps. It has queues and topics, runs on broker instances and does not scale like SQS/SNS.
• Amazon MQ HA: ActiveMQ active/standby in two AZs with shared EFS storage and the failover transport; RabbitMQ three-node cluster across three AZs; single-instance has no failover.

Self-check: Choosing SQS, SNS, Kinesis and Amazon MQ32 questions