Use Amazon SQS to buffer work for one consumer per message, Amazon SNS to push every message to many subscribers, Amazon EventBridge to route events from AWS services, SaaS apps or your code by their content, and Amazon MQ when an existing application already speaks JMS, AMQP or MQTT and must move without code changes.
Last updated October 2026.
Producers send; consumers poll at their own pace and delete a message once it is processed. A visibility timeout hides a received message from other consumers while one works on it. Add consumers to drain the queue faster.
| Standard queue | FIFO queue | |
|---|---|---|
| Delivery | At least once; duplicates possible | Exactly-once processing with deduplication |
| Order | Best effort | Strict, within each message group |
| Throughput | Nearly unlimited | 300 API calls per second, 3,000 messages with batching; high throughput mode for more |
Queue behavior from the Amazon SQS Developer Guide, checked 27 October 2026.
A publisher sends to a topic and SNS pushes a copy to every subscription: SQS queues, AWS Lambda, HTTP/S endpoints and Amazon Data Firehose for applications, and SMS, email and mobile push for people. A filter policy on a subscription delivers only the messages it matches. SNS pushes and does not hold messages for a subscriber to fetch later, which is why the classic fan-out pattern puts an SQS queue behind each subscriber: every service gets its own durable copy.
SNS FIFO topics paired with SQS FIFO queues keep order and remove duplicates across the fan-out.
An event bus takes events from your applications, from SaaS partners and, on the default bus, from AWS services themselves, such as an EC2 state change, with no publishing code. A rule matches an event pattern against any field of the event's JSON and sends matches to its targets. That content-based routing is what SNS topics cannot do.
Two relatives show up in answers: EventBridge Pipes connect one source to one target with filtering and enrichment, and EventBridge Scheduler runs cron, rate or one-time invocations. AWS now recommends Scheduler over the older scheduled rules.
Amazon MQ runs managed Apache ActiveMQ Classic and RabbitMQ brokers. Because it speaks the industry-standard protocols those brokers use (JMS, AMQP, MQTT, STOMP and others), AWS positions it for migrating existing brokers without rewriting messaging code. For a new cloud-native design, SQS, SNS and EventBridge are serverless and scale without broker sizing, so Amazon MQ is usually the migration answer, not the default.
| Service | Model and receivers | Best signal |
|---|---|---|
| SQS | Queue, pull; one consumer per message | Buffer work, absorb spikes, retry later |
| SNS | Topic, push; every subscriber | Fan-out, alerts to people |
| EventBridge | Bus with rules; targets whose pattern matches | AWS or SaaS events, content routing, schedules |
| Amazon MQ | Broker; its queues and topics | Existing JMS, AMQP or MQTT apps |
They combine. SNS feeding several SQS queues and an EventBridge rule targeting an SQS queue are both common correct answers.
"Decouple the web tier from processing", "workers poll", "absorb a traffic spike", "process in order" (FIFO).
"Several systems each need every message", "fan-out", "email or SMS alert", "each subscriber gets a subset".
"React to an AWS service event", "events from a SaaS provider", "route on fields inside the event", "run on a schedule".
"Existing application uses JMS, AMQP, MQTT or STOMP", "migrate the on-premises broker without code changes".
The tempting wrong answer: one SQS queue that billing, shipping and analytics all poll. A queue gives each message to one consumer, so the three services would split the orders between them instead of each seeing all of them. That requirement is SNS fan-out to three queues.
SQS is a queue: consumers poll it, and each message is processed by one consumer. SNS is a topic: it pushes a copy of every message to all subscribers. Use SNS with an SQS queue per subscriber when several services each need every message.
Use EventBridge when events come from AWS services or SaaS partners, or when routing depends on fields inside the event. SNS fits simple fan-out and notifications to people by email, SMS or mobile push.
Use Amazon MQ when an existing application talks to an ActiveMQ or RabbitMQ broker over JMS, AMQP, MQTT or STOMP and must move to AWS without code changes. For new designs, SQS is serverless and needs no broker to size.
Only FIFO queues do. FIFO queues keep strict order within each message group and provide exactly-once processing. Standard queues offer best-effort ordering and at-least-once delivery, so consumers must handle duplicates.
Chapter 27 of the Certified SAA-C03 course builds the fan-out and event bus patterns step by step, with a scenario question for SNS, EventBridge and Amazon MQ. Chapter 26 covers SQS in depth.
Open Chapter 27 →