Applies toAmazon SQS (standard, FIFO), Amazon SNS (standard, FIFO), Amazon EventBridge (event buses, Pipes, Scheduler), Amazon Kinesis Data Streams, Amazon MSK
What are you sending?
| Message kind | Service |
|---|---|
| Work item that one consumer must process reliably | SQS (FIFO if order/dedup per group matters) |
| Notification to many subscribers at once | SNS (often SNS → SQS per subscriber) |
| Business/system event routed by content to many targets, across accounts/SaaS | EventBridge event bus |
| Ordered stream with replay, many consumers reading independently | Kinesis Data Streams |
| Kafka ecosystem, existing Kafka apps, connectors | Amazon MSK |
Comparison
| SQS | SNS | EventBridge | Kinesis Data Streams | MSK | |
|---|---|---|---|---|---|
| Model | Queue (pull) | Pub/sub (push) | Event router (rules) | Sharded log | Kafka log |
| Ordering | FIFO queues per message group | FIFO topics | Not guaranteed | Per shard (partition key) | Per partition |
| Replay | No (once consumed) | No | Archive + replay | Yes, within retention | Yes, within retention |
| Filtering | Consumer-side | Subscription filter policies | Rich content-based rules | Consumer-side | Consumer-side |
| Retry/DLQ | DLQ with redrive | Per-subscription DLQ | Retry policy + DLQ | Consumer logic (Lambda: bisect, on-failure destination) | Consumer logic |
| Operations | Serverless | Serverless | Serverless | On-demand or provisioned shards | Brokers or MSK Serverless |
Check message size and throughput limits for your design.
Decision questions
- Must exactly one worker do the job, with retries? → SQS.
- Do many independent systems need the same message? → SNS fan-out to SQS queues, or EventBridge rules.
- Do targets need routing by event content, across accounts, or from SaaS sources? → EventBridge.
- Do you need ordered processing per key and replay? → Kinesis (or MSK if you're a Kafka shop).
- Point-to-point integration between a source and target with filtering/enrichment? → EventBridge Pipes.
Common combinations
Order service ─► EventBridge bus ─► rule: billing → SQS → billing worker
└─ rule: analytics → Firehose → S3
S3 upload ─► EventBridge / S3 notification ─► SQS ─► Lambda (batch, DLQ)
Clickstream ─► Kinesis Data Streams ─► Lambda / Flink ─► OpenSearch / S3
Alert ─► SNS ─► email, chat, SQS for automation
Putting SQS in front of consumers gives buffering, retries, DLQs and controlled concurrency, even when EventBridge or SNS is the router.
Failure handling to design
| Service | Must-haves |
|---|---|
| SQS | Visibility timeout > processing time, maxReceiveCount + DLQ, DLQ alarms, redrive process |
| SNS | DLQ per subscription, delivery retries understood per protocol |
| EventBridge | Target retry policy, DLQ, archive for replay of important buses |
| Kinesis/Lambda | BisectBatchOnFunctionError, MaximumRetryAttempts, on-failure destination, iterator age alarm |
| MSK | Consumer lag monitoring, poison message handling in code |
All of them are at-least-once in practice. Make consumers idempotent.
Operational signals
- SQS:
ApproximateAgeOfOldestMessage,ApproximateNumberOfMessagesVisible, DLQ depth. - EventBridge:
FailedInvocations,InvocationsSentToDlq, throttled rules. - Kinesis:
GetRecords.IteratorAgeMilliseconds,WriteProvisionedThroughputExceeded. - MSK: consumer lag, under-replicated partitions, disk usage.
Warning
SNS without a durable subscriber (SQS) loses messages when HTTP endpoints or Lambda targets fail beyond retries. For business-critical events, land them in a queue or archive first.
Checklist
- Message kind identified
- Ordering, replay and fan-out needs answered
- Limits checked
- DLQs, retries and replay designed
- Idempotent consumers
- Backlog/lag alarms in place