SQS vs SNS vs EventBridge

Introduction¶

AWS has three messaging services that overlap enough to confuse. The short version: SQS for work queues, SNS for fan-out notifications, and EventBridge for event-driven routing between services with content-based rules.

SQS — work queue¶

A durable queue. Producers send messages; consumers poll and delete after processing.

• Standard — at-least-once delivery, best-effort ordering, near-unlimited throughput. Handle duplicates (idempotent consumers).
• FIFO — exactly-once processing, strict ordering per MessageGroupId, capped at ~3,000 msg/s with batching. Use when order matters (per-user event sequence) or dups are unacceptable.
• Visibility timeout — after a consumer receives a message it's hidden for N seconds; if not deleted in time, it reappears (assume the consumer died). Set it above your max processing time.
• DLQ — after maxReceiveCount failed deliveries, the message moves to a dead-letter queue for inspection.
• Long polling (WaitTimeSeconds=20) — fewer empty receives, lower cost.

Use for: decoupling a producer from a slow/spiky consumer, retry with backoff, buffering, work distribution across a fleet.

SNS — pub/sub fan-out¶

A topic. Publishers send; all subscribers get a copy, pushed to them.

• Subscribers: SQS queues, Lambda, HTTP(S) endpoints, email, SMS, mobile push, Kinesis Firehose.
• Standard and FIFO (FIFO SNS → FIFO SQS only).
• Message filtering — subscribers set a filter policy; SNS only delivers matching messages.
• No storage/replay — if a subscriber is down (and not an SQS queue), the message is lost after retries.

Use for: one event, many independent reactions. The classic pattern is SNS → multiple SQS queues (fan-out with durability): each team owns a queue, adds/removes without touching the publisher.

EventBridge — event bus + router¶

A bus that receives events (from AWS services, your apps, or SaaS partners) and routes them to targets based on rules matching the event content.

• Rules match on any field of the JSON event (source, detail-type, detail.status, etc.) — richer than SNS filter policies.
• Targets: Lambda, SQS, SNS, Step Functions, another bus, API destinations (call an external HTTP API), 20+ AWS services.
• Schema registry + code bindings, archive & replay of events, input transformers to reshape the event before the target sees it.
• Native events from ~200 AWS services (an EC2 state change, an S3 object created, a CodePipeline stage) with zero setup.
• Higher latency than SNS/SQS (~half a second), lower throughput ceilings.

Use for: routing domain events, reacting to AWS service events, SaaS integrations, anything where the routing logic is content-based and evolves.

Choosing¶

Common combined pattern: EventBridge rule → SNS topic → several SQS queues → Lambda/ECS consumers. EventBridge for routing, SNS for fan-out, SQS for durability and backpressure.

Verification and troubleshooting¶

aws sqs get-queue-attributes --queue-url ... --attribute-names All
aws sqs receive-message --queue-url ... --wait-time-seconds 5
aws sns list-subscriptions-by-topic --topic-arn ...
aws events list-rules; aws events test-event-pattern --event-pattern ... --event ...

• SQS messages "stuck" / reprocessed forever — consumer isn't calling DeleteMessage (bug, or crashes before deleting), or visibility timeout is shorter than processing time so they reappear. Check the DLQ and ApproximateReceiveCount.
• SNS → Lambda not firing — subscription not confirmed (HTTP), Lambda permission (lambda:InvokeFunction for sns.amazonaws.com), or a filter policy excluding the message. MessageAttributes (not the body) drive SNS filtering.
• SNS → SQS: queue empty despite publishes — the SQS queue policy doesn't allow sns.amazonaws.com to SendMessage, or "raw message delivery" mismatch (with it off, the body is wrapped in SNS JSON).
• EventBridge rule not matching — the pattern must match the event's actual shape; test-event-pattern with a real event. AWS events nest the payload under detail.
• FIFO throughput too low — one MessageGroupId serialises everything; use many group IDs (per-entity) and enable high-throughput mode.
• Duplicate processing on Standard SQS/SNS — at-least-once is the contract. Dedup with an idempotency key in your store.
• EventBridge target not invoked — the rule's IAM role lacks permission to invoke the target, or the target is in another account/region without a resource policy / event-bus permission.

Related tools and reading¶

• On-site: JSON formatter.
• Related posts: Lambda cold starts and how to cut them, MQTT QoS levels explained.