Our platform runs about forty services on AWS, and an inventory last quarter found all three managed messaging services in use, often for the same kind of job. One team used SNS where they needed a buffer, another used SQS where several services needed the same event, and a third built EventBridge rules for a single high-volume point-to-point flow and then wondered about cost and latency. None of these choices were wrong enough to cause outages. They were wrong enough to cause duplicate code, awkward retries and confusing on-call.

This guide compares Amazon SQS, Amazon SNS and Amazon EventBridge on the properties that actually differ, then lists the combinations we standardised on. It reflects the services as of late 2025.

The one-line version

  • SQS is a queue. Consumers pull. Each message is processed by one consumer and deleted. It buffers work and absorbs bursts.
  • SNS is a topic. It pushes each message to every subscriber, immediately. It fans out.
  • EventBridge is an event bus. It matches events against rules and routes them to targets. It fans out with content-based routing, cross-account delivery, archive and replay, and many AWS and SaaS sources.

Most production designs use two of them together, not one.

Delivery model

SQS SNS EventBridge
Model Pull (consumer polls) Push to subscribers Push to rule targets
Consumers per message One (competing consumers) Every subscription Every matching rule target
Storage if consumer is down Yes, up to 14 days retention No; retries, then optional DLQ No; retries, then optional DLQ
Back-pressure Natural: consumers read at their pace None: subscriber must keep up None: target must keep up

The storage row is the one we see misunderstood most. SNS and EventBridge are not queues. If an HTTP subscriber or Lambda target is down or throttled, they retry for a while and then give up (to a DLQ if configured). SQS keeps the message until a consumer deletes it or retention expires.

That is why "SNS to SQS" and "EventBridge to SQS" are such common pairs: the topic or bus fans out, and each consumer gets its own durable buffer.

Fan-out and filtering

SQS has no fan-out. Two services reading one queue compete for messages; each message goes to one of them.

SNS fans out to many subscriptions (SQS, Lambda, HTTP/S, email, SMS, mobile push, Firehose). Each subscription can have a filter policy, matching message attributes or the message body:

{
  "event_type": ["InvoicePaid", "InvoiceRefunded"],
  "amount_cents": [{ "numeric": [">=", 100000] }]
}

aws sns set-subscription-attributes \
  --subscription-arn "$SUB_ARN" \
  --attribute-name FilterPolicyScope --attribute-value MessageBody
aws sns set-subscription-attributes \
  --subscription-arn "$SUB_ARN" \
  --attribute-name FilterPolicy --attribute-value file://filter.json

EventBridge rules use event patterns that match any field in the event, with prefix, suffix, numeric, exists and anything-but operators. Each rule can have up to five targets, and targets include SQS, Lambda, Step Functions, API destinations (any HTTP endpoint with managed auth), other event buses, including in other accounts, and many more AWS services. An input transformer can reshape the event per target.

{
  "source": ["billing.invoices"],
  "detail-type": ["InvoicePaid"],
  "detail": {
    "currency": ["EUR"],
    "amount_cents": [{ "numeric": [">=", 100000] }]
  }
}

If routing logic is the main requirement, EventBridge does it with the least code. If you just need "every subscriber gets everything, fast", SNS is simpler.

Ordering and duplicates

SQS standard SQS FIFO SNS standard SNS FIFO EventBridge
Ordering Best effort Per message group Best effort Per message group Not guaranteed
Duplicates Possible (at-least-once) Deduplicated within a 5-minute window Possible Deduplicated within a 5-minute window Possible

If you need ordered processing per entity on AWS-native services, the path is SNS FIFO to SQS FIFO, or SQS FIFO alone, with MessageGroupId set to the entity id. EventBridge does not preserve order. Whatever you choose, consumers should still be idempotent: FIFO deduplication covers a five-minute window on send, not redelivery after a consumer times out.

Retries and failure handling

  • SQS: the consumer controls retries through the visibility timeout. After maxReceiveCount receives, the redrive policy moves the message to a dead-letter queue. DLQ redrive back to the source queue is available in the console and API.
  • SNS: retries delivery with a policy that depends on the protocol. For HTTP/S you can tune the delivery policy; for AWS-managed endpoints like SQS and Lambda the policy is fixed. A subscription-level DLQ (an SQS queue) catches messages that exhausted retries.
  • EventBridge: retries delivery to each target with exponential backoff for up to 24 hours and up to 185 attempts by default; both are configurable per target. A per-target DLQ catches failures.

In all three, a dead-letter queue nobody watches is the same as dropping data. We alarm on ApproximateNumberOfMessagesVisible above zero for every DLQ.

Replay and history

Only EventBridge has built-in replay: an archive stores events matching a pattern for a retention period, and a replay sends them back to the bus for a time range. We use it after fixing a consumer bug, to rerun the last six hours of events into the corrected rule.

aws events start-replay --replay-name invoices-fix-2025-11-30 \
  --event-source-arn arn:aws:events:eu-west-1:123456789012:archive/billing-archive \
  --event-start-time 2025-11-30T06:00:00Z --event-end-time 2025-11-30T12:00:00Z \
  --destination '{"Arn":"arn:aws:events:eu-west-1:123456789012:event-bus/billing"}'

SQS messages are gone once deleted, and SNS keeps nothing. If replay is a hard requirement beyond what an archive gives you, a log such as Kafka or Kinesis is the better tool.

Limits and latency worth knowing

SQS SNS EventBridge
Max payload 1 MiB (raised from 256 KB in 2025) 256 KB 256 KB
Typical latency Depends on polling; long polling up to 20 s wait Low, push Higher than SNS; usually fine for business events
Large payloads Store in S3, send a pointer Same Same
Schema tooling None None Schema registry and discovery

We do not design around exact throughput quotas, because they differ by region and change over time; check the current Service Quotas page. In practice SQS standard and SNS standard scale further than most workloads need, FIFO variants have per-group throughput limits, and EventBridge has per-region PutEvents quotas that high-volume telemetry can hit.

On cost, EventBridge charges per event published to custom buses and per replay; for very high-volume, single-consumer flows, a direct SQS queue is usually cheaper and lower latency.

The combinations we standardised on

Need Our choice
One producer, one consumer, buffer bursts SQS alone
Background jobs with retries and DLQ SQS + Lambda or ECS workers
One event, several services, each with own pace SNS to SQS per consumer
Ordered processing per entity SNS FIFO to SQS FIFO, or SQS FIFO alone
Domain events across teams and accounts, routed by content EventBridge custom bus to SQS per consuming service
Reacting to AWS service events (EC2, ECS, S3, CodePipeline) EventBridge default bus
SaaS webhooks into AWS EventBridge partner source or API destination for outbound
Scheduled triggers EventBridge Scheduler

The last column of the EventBridge rows almost always ends in SQS. Putting a queue in front of each consumer gives it a buffer, its own retry policy and its own DLQ, and keeps the bus from pushing faster than the consumer can handle.

Questions to ask before choosing

  1. Does more than one service need this message? If no, start with SQS.
  2. Must consumers keep working through their own downtime? Then each consumer needs a queue.
  3. Is routing by content a core requirement, or are teams and accounts separated? EventBridge.
  4. Is strict per-entity order required? FIFO variants, with idempotent consumers.
  5. Will you need to reprocess past events? EventBridge archive, or a log-based service.
  6. Is latency in the tens of milliseconds critical? Prefer SNS or direct SQS over EventBridge.

Key takeaways

  • SQS buffers and load-levels; SNS fans out fast; EventBridge routes by content and integrates across accounts and SaaS.
  • SNS and EventBridge do not store messages for offline consumers; put an SQS queue behind each consumer that must not lose data.
  • Only FIFO variants give ordering, and only per message group; EventBridge gives none.
  • EventBridge archive and replay is the only built-in replay among the three.
  • Every DLQ needs an alarm, and every consumer needs idempotency, whichever service delivers the message.

References