SQS vs SNS vs EventBridge

When you build serverless systems, you stop calling services directly and start sending them messages. Decoupling like this lets parts of your app fail, scale, and deploy independently. AWS gives you three core messaging services for this — SQS, SNS, and EventBridge — and they look similar enough that people pick the wrong one. This page explains what each does, when to reach for it, and how they combine.

The three services in one sentence each

• Amazon SQS (Simple Queue Service) — a queue that holds messages until one consumer pulls them and processes them at its own pace. This is point-to-point: one message, one worker.
• Amazon SNS (Simple Notification Service) — a pub/sub (publish/subscribe) topic that pushes a copy of each message to many subscribers at once. This is fan-out: one message, many receivers.
• Amazon EventBridge — an event bus that routes and filters events from your apps, other AWS services, and SaaS products (third-party software like Stripe or Datadog) to the right targets based on rules.

The single most common mistake is choosing SNS when you needed EventBridge, or the reverse. Read the “SNS vs EventBridge” section below before you decide.

When to use SQS

Use SQS when one set of workers needs to pull work and process it at their own speed. The queue acts as a buffer (a holding area) that smooths out spikes: producers can dump 10,000 messages in a second, and your workers drain them steadily without falling over.

Use SQS when:

• Exactly one consumer should handle each message (a job runs once).
• Consumers are slower than producers and you need back-pressure.
• You want automatic retries and a dead-letter queue (a DLQ — a second queue that catches messages that keep failing).

Do not use SQS when many different systems each need a copy of the same message — that is fan-out, and SQS alone cannot do it.

SQS has two flavors: Standard (nearly unlimited throughput, at-least-once delivery, best-effort ordering) and FIFO (First-In-First-Out — strict ordering and exactly-once processing, up to 3,000 messages/second with batching).

Console steps to create a Standard queue:

1. Open the Amazon SQS console and choose Create queue.
2. Pick Standard, name it orders-queue.
3. Set Visibility timeout to 30 seconds (how long a message is hidden while a worker processes it).
4. Under Dead-letter queue, enable it and set Maximum receives to 5.
5. Choose Create queue.

CLI equivalent:

aws sqs create-queue \
  --queue-name orders-queue \
  --attributes VisibilityTimeout=30

Output:

{
    "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/orders-queue"
}

When to use SNS

Use SNS when you publish a message once and want several independent subscribers to each get a copy, immediately and pushed to them. Classic example: an order is placed, and you want to (a) email the customer, (b) update inventory, and (c) trigger shipping — all at the same time.

Use SNS when:

• You need simple, high-throughput fan-out to many endpoints.
• Targets are Lambda functions, SQS queues, HTTP/S webhooks, email, or SMS.
• You do not need complex matching rules on the message content.

Do not use SNS when you need to route events differently based on what’s inside the event, or when the source is a SaaS product or a scheduled timer — that’s EventBridge territory.

Console steps:

1. Open the Amazon SNS console, choose Topics, then Create topic.
2. Pick Standard, name it order-events, choose Create topic.
3. Choose Create subscription, set Protocol to Amazon SQS, and paste the queue ARN (Amazon Resource Name — the unique ID of an AWS resource).

CLI equivalent:

aws sns create-topic --name order-events

Output:

{
    "TopicArn": "arn:aws:sns:us-east-1:123456789012:order-events"
}

When to use EventBridge

Use EventBridge when you need a smart router. It reads each event and uses rules to send it only to the targets that care, based on the content of the event (content-based filtering). It can also ingest events directly from over 200 AWS services, from SaaS partners, and on a schedule.

Use EventBridge when:

• You need content-based filtering (e.g. only route orders where amount > 1000).
• The event source is a SaaS product (Stripe, Shopify, Datadog).
• You need scheduling (run a target every hour, like a cron job).
• You want archive and replay — store events and re-run them later to debug or backfill.

Do not reach for EventBridge when all you need is plain fan-out to a few endpoints with no filtering and the highest possible throughput — SNS is simpler and cheaper there.

CLI: create a rule that matches large orders and targets a Lambda function:

aws events put-rule \
  --name large-orders \
  --event-pattern '{"source":["my.orders"],"detail":{"amount":[{"numeric":[">",1000]}]}}'

Output:

{
    "RuleArn": "arn:aws:events:us-east-1:123456789012:rule/large-orders"
}

SNS vs EventBridge vs SQS — decision table

Need	SQS	SNS	EventBridge
Delivery style	Pull (poll)	Push, fan-out	Push, routed
Consumers per message	One	Many	Many (filtered)
Content-based filtering	No	Limited (message attributes)	Yes, rich rules
SaaS / partner sources	No	No	Yes
Scheduled events (cron)	No	No	Yes
Archive & replay	No	No	Yes
Raw throughput	Very high	Highest	High (lower than SNS)
Latency	Pull-dependent	Lowest	Slightly higher
Built-in retries + DLQ	Yes	Yes (to DLQ)	Yes (to DLQ)

Combining them

These services are not rivals — the strongest designs chain them. A very common pattern is SNS or EventBridge in front, SQS behind each consumer:

1. A producer publishes an OrderPlaced event.
2. EventBridge (or SNS) fans it out to several SQS queues — one per downstream service.
3. Each service polls its own queue at its own pace, with its own retries and DLQ.

This gives you fan-out (from SNS/EventBridge) and buffering plus independent failure handling (from SQS). The “fan-out to SQS” pattern is the backbone of most serverless event architectures.

# Subscribe an SQS queue to an SNS topic
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:order-events \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:us-east-1:123456789012:orders-queue

Cost note: SQS and SNS both cost about $0.40–$0.50 per million requests, and SNS gives 1 million publishes free per month. EventBridge custom-bus events cost about $1.00 per million. For very high-volume simple fan-out, SNS is the cheapest option; pay EventBridge’s premium when you actually use its filtering, SaaS, or replay features.

Best practices

• Always attach a dead-letter queue to SQS, SNS subscriptions, and EventBridge targets so failed messages are never silently lost.
• Use SQS FIFO only when ordering truly matters — Standard queues are far cheaper and scale higher.
• Put an SQS queue between a fan-out source and any Lambda consumer to absorb spikes and control concurrency.
• Prefer EventBridge as your default event bus for new event-driven apps — it grows with you (filtering, SaaS, replay) without re-architecting.
• Use SNS when you only need fast, simple fan-out at the highest throughput and lowest cost.
• Set a sensible visibility timeout on SQS: a little longer than your worker’s processing time, or messages get reprocessed mid-flight.
• Turn on EventBridge archive in production so you can replay events when debugging or backfilling data.

Related Topics

• Amazon SQS
• Amazon SNS
• EventBridge
• Lambda triggers
• What is serverless