What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Amazon SQS, Amazon SNS, and Amazon EventBridge all move messages between AWS components, but each answers a different question. Use SQS when a consumer should pull work from a durable queue at its own pace. Use SNS when one publication should be pushed to many subscribers, including email, SMS, and mobile push endpoints. Use EventBridge when producers should publish events to a bus and rules should route each event according to its content. The three are often combined, and AWS documents patterns such as sending events to SQS for buffering and to SNS for fan-out.
How the three services differ
The table below uses the comparison axes from AWS’s decision guide for messaging services, last updated in November 2025. Treat the values as of that date and check the current AWS documentation before you design around a specific limit.
| Decision axis | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| Communication model | Pull: consumers poll the queue and control their own processing pace. | Push (publish/subscribe): a publisher sends to a topic, and the topic delivers to subscribers. | Event bus: rules match event content and route events to targets. |
| Persistence and delivery | Messages persist until they are processed or expire, with retention of up to 14 days. Delivery is at least once, so duplicate processing is possible. | Push-oriented, described by AWS as real-time delivery rather than a persistent queue. Standard and FIFO topics are available. | Events are processed in real time. AWS says target delivery is at least once and can be retried. |
| Ordering | FIFO queues support ordered processing. | FIFO topics support ordering per message group. | AWS states that EventBridge does not guarantee message ordering. |
| Filtering and routing | Consumers receive from one queue. Combine with SNS filtering when subscribers need selective fan-out. | Subscription filter policies let each subscriber select the messages it receives. | Event patterns provide content-based routing, with routing logic centralized on the bus. |
| Destinations and strengths | EC2 and Lambda consumers. Strongest for buffering work and letting consumers run at independent rates. | SQS, Lambda, HTTP/S, email, SMS, mobile push, and Data Firehose. Strongest for broad fan-out and notifications. | AWS services, supported SaaS integrations, and API destinations. Strongest for event-driven routing across services. |
| Cost drivers named in the guide | API requests and data transferred. | API requests, notifications delivered, and data transferred. SMS is billed through AWS End User Messaging. | Events published and target invocations. |
Pricing depends on region, endpoint type, event volume, data transfer, and workload, so no one service can be declared the cheapest without your own volumes.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →What each service does
Amazon SQS: a queue that consumers pull from
SQS holds messages until a consumer receives and deletes them. Consumers on EC2 or Lambda poll the queue, so a slow consumer does not force the producer to slow down, and a backlog simply grows until consumers catch up. Long polling, which AWS documents with waits of up to 20 seconds, reduces empty responses and the number of requests a consumer makes while waiting for work.
#1 Best Overall
Choose SQS when work should wait safely for processing, when producer and consumer rates differ, or when a failed consumer should not lose the message.
Amazon SNS: a topic that pushes to subscribers
SNS receives a message on a topic and pushes a copy to every subscription. Subscriber types include SQS queues, Lambda functions, HTTP/S endpoints, email addresses, SMS numbers, mobile push endpoints, and Amazon Data Firehose. AWS’s overview describes fanning out to SQS queues so that parallel consumers can process the same publication independently.
SNS is the right fit when the same event must reach several destinations, or when a person needs a notification on a phone or inbox. Because SNS pushes rather than stores, a subscriber that is unavailable depends on the delivery and retry behavior of its endpoint type, which is why SNS is often paired with an SQS queue for any subscriber that must not miss work.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteAmazon EventBridge: a bus with content-based rules
EventBridge receives events on a bus. Each rule contains an event pattern that matches on event content, and matching events are sent to targets. Producers publish events without knowing which consumers exist, and consumers subscribe by adding rules. This keeps routing decisions in one place rather than spread across producers.
EventBridge also supports scheduled rules, for time-based invocation, and EventBridge Pipes, for point-to-point integrations between a source and a target. By default, AWS’s decision guide reports that target delivery retries for up to 24 hours and up to 185 attempts.
Ordering, duplicates, and retries
All three services can deliver a message more than once or out of step with other messages, depending on configuration, so ordering and duplicate handling must be designed explicitly.
Rank #3
- Need strict order? Use an SQS FIFO queue or an SNS FIFO topic. Ordering on FIFO topics applies per message group, so unrelated groups are not ordered relative to each other.
- Not sure? Do not assume EventBridge preserves order. AWS says it does not guarantee ordering.
- Standard queues and at-least-once targets? Make consumers idempotent. A common approach is to record the ID of each processed message in a store and skip any ID already seen.
Filtering, routing, and how the services combine
Filtering happens in different places. SNS filter policies sit on individual subscriptions, so each subscriber declares which messages it wants. EventBridge keeps filtering on the bus, in rules shared across the account. SQS does not filter by itself; it delivers from one queue, so selective delivery usually comes from SNS or EventBridge placed in front of it.
AWS’s guidance describes the following combinations.
EventBridge routes to SQS for buffering
When a rule matches events that a downstream service must process at its own rate, point the rule’s target at an SQS queue. EventBridge handles routing, and the queue absorbs bursts.
SNS fans out to several SQS queues
Subscribe several SQS queues to one SNS topic. Each queue then gets its own copy of every message and can be consumed at its own pace, which suits parallel workflows such as billing, search indexing, and analytics handling the same order event.
EventBridge and SNS for broad fan-out
When events need to reach many recipients, including user-facing channels, route them to an SNS topic as an EventBridge target. Use EventBridge for content-based selection and SNS for distribution to many subscribers.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.AWS Prescriptive Guidance: “Using an event bus enables you to decouple producers from consumers and consolidate your routing and delivery logic.” The guidance names AWS Prescriptive Guidance as its author, without naming an individual.
Choosing a service
- Choose SQS when a backlog can accumulate, producers and consumers run at different rates, and work must stay queued until a consumer finishes it.
- Choose SNS when one publication must reach many subscribers, or when the endpoint is an email address, SMS number, or mobile device.
- Choose EventBridge when producers should not embed routing logic, consumers should subscribe through content-based rules, or events come from AWS services or supported SaaS integrations.
- Combine services when one requirement is not enough, such as EventBridge routing into SQS for buffering or SNS fanning out to SQS queues.
- Add FIFO when ordering is a hard requirement, and design consumers to tolerate duplicates in every case.
Limits and costs
The figures below are service behavior or quotas, not adoption or market statistics. Each is shown with its source and date, and each can change.
| Figure | Value | Source and date | Scope |
|---|---|---|---|
| SQS message retention | Up to 14 days | AWS decision guide, last updated November 2025 | Configurable retention window for queued messages |
| SQS long polling wait | Up to 20 seconds | AWS decision guide, last updated November 2025 | Maximum wait per receive request |
| EventBridge target delivery retries | Up to 24 hours and up to 185 attempts by default | AWS decision guide, last updated November 2025 | Default behavior for target delivery |
| SNS standard topic subscriptions | Default limit of 12.5 million subscriptions | AWS Prescriptive Guidance; publication date not stated on the page | Default quota for a standard topic, not a usage figure |
Cost comparisons should start with your own numbers: expected request counts for SQS and SNS, notification counts and endpoint types for SNS, event volume and target invocations for EventBridge, and the data transferred by each. Estimate retries and duplicate processing as well, because they add requests and invocations. Check regional pricing on the AWS pricing pages before you commit to a design.
For the current behavior of any service, the AWS documentation and the decision guide are the primary references.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
