Chapter 18: AWS Messaging Comparison
AWS Messaging Services Comparison — the big ones people confuse all the time: SQS, SNS, EventBridge, Kinesis Data Streams, Amazon MSK (Managed Kafka), and Amazon MQ.
This is the lesson where it all clicks: “Which one do I actually pick for my project?”
We’ll go step-by-step like a real whiteboard session — what each is best at, key differences in 2026, when to choose what (with Hyderabad/India real examples), and a big comparison table. No fluff — just practical guidance.
1. Quick “One-Liner” for Each Service (Memorize These!)
- Amazon SQS → Reliable queue for decoupling & background tasks (pull-based, “process when ready”).
- Amazon SNS → Fast fan-out notifications (push-based broadcast, “tell everyone now”).
- Amazon EventBridge → Smart event bus for routing & filtering events (push-based, advanced logic + SaaS).
- Amazon Kinesis Data Streams → High-volume real-time streaming (pull-based, multiple consumers replay data).
- Amazon MSK (Managed Streaming for Apache Kafka) → Enterprise-grade streaming platform (high throughput, long retention, complex processing).
- Amazon MQ → Managed traditional broker (ActiveMQ / RabbitMQ) for legacy protocols.
2. Core Comparison Table (2026 Reality – From AWS Docs & Real Usage)
| Feature / Aspect | SQS | SNS | EventBridge | Kinesis Data Streams | Amazon MSK (Kafka) | Amazon MQ |
|---|---|---|---|---|---|---|
| Primary Model | Queue (point-to-point) | Pub/Sub (fan-out) | Event Bus (routing + filtering) | Streaming (real-time logs/data) | Streaming platform | Broker (pub/sub + queues) |
| Delivery Style | Pull (poll) | Push | Push | Pull | Pull (consumers) | Both (push/pull) |
| Ordering | Standard: best-effort FIFO: strict | No strict order | No strict order | Strict per shard/partition | Strict per partition | Varies by protocol |
| Delivery Guarantee | At-least-once (Standard) Exactly-once (FIFO) | At-least-once | At-least-once | At-least-once | At-least-once | Varies |
| Deduplication | FIFO only | No | No (use content filtering) | No (use app logic) | App-level | Varies |
| Throughput (approx) | Millions TPS (Standard) | Millions TPS | Millions events/sec | 1–10 MB/s per shard (scale shards) | Tens of GB/s | Lower (broker limits) |
| Message Retention | 1 min – 14 days | Seconds (transient) | Transient | 1–365 days | Configurable (days/weeks) | Configurable |
| Multiple Consumers | Yes (competing) | Yes (fan-out) | Yes (multiple targets/rules) | Yes (multiple consumer groups) | Yes (consumer groups) | Yes |
| Filtering | No (poll & filter yourself) | Basic attribute | Advanced content + metadata | No (consumer-side) | Consumer-side | Varies |
| SaaS / External Integration | Limited | Limited | Native 20+ SaaS partners | Limited | Limited | Limited |
| Typical Latency | Seconds | Milliseconds | Milliseconds | Milliseconds | Milliseconds | Milliseconds |
| Pricing Driver | Per request | Per publish + delivery | Per event + rule invocation | Per shard-hour + PUT payload | Broker instance + storage | Broker instance + storage |
| Best For | Background jobs, decoupling | Alerts, notifications, fan-out | Event-driven EDA, SaaS routing | Real-time analytics, logs | High-scale streaming, Kafka apps | Legacy migration, JMS/AMQP |
3. When to Choose Which One? (Decision Guide – Hyderabad Lens)
| Your Need / Scenario | Recommended Service(s) | Why? + Real Hyderabad Example |
|---|---|---|
| Need reliable background task processing (e.g., resize image after upload, send email after order) | SQS (Standard or FIFO) | Decouples frontend from heavy work. Example: Food delivery app → order placed → SQS queue → workers process payment + notify rider. |
| Need to broadcast one event to many places (fan-out: SMS + push + email + backend) | SNS (often + SQS for buffering) | Real-time notifications. Example: Order confirmed → SNS topic → SMS to customer + push to rider app + SQS for analytics. |
| Need smart routing/filtering of events (e.g., only Hyderabad orders to one Lambda) + SaaS integration | EventBridge (Pipes or rules) | Event-driven with logic. Example: Edtech app → quiz completed → EventBridge filters “Hyderabad students” → triggers score calc + parent SMS + CRM update. |
| Need real-time streaming + multiple consumers reading same data (logs, metrics, clickstream) | Kinesis Data Streams | Replayable data. Example: E-commerce site → user clicks → Kinesis → analytics team + recommendation engine + fraud detection all read same stream. |
| Need high-scale, long-retention streaming with Kafka ecosystem (complex processing, Flink/Spark) | Amazon MSK | Enterprise streaming. Example: Large fintech → transaction logs → MSK → real-time fraud ML + compliance archiving + multiple teams consume. |
| Need traditional protocols (RabbitMQ, ActiveMQ, JMS, MQTT) for legacy apps | Amazon MQ | Compatibility. Example: Bank migrating old Java app → keep JMS queues → Amazon MQ instead of self-managed broker. |
4. Common Patterns in 2026 (Real-World Combos)
- SNS + SQS → Fan-out + buffering (classic: SNS topic → multiple SQS queues + Lambda).
- EventBridge + Pipes → No-code integrations (DynamoDB stream → Pipe → enrich → SQS or Step Functions).
- EventBridge → Kinesis/MSK → Route AWS events to streaming for analytics.
- SQS + Lambda → Serverless background processing (poll-free with event source mapping).
- SNS + Mobile Push → App notifications (huge in India for OTP, delivery updates).
5. Quick Cost & Scale Reality Check (Hyderabad Projects)
- SQS / SNS / EventBridge → Very cheap for most startups (free tier + pennies per million).
- Kinesis → Shard-hour cost → good for steady streams, expensive if idle.
- MSK → Instance-based → more expensive, but worth it for Kafka teams.
- Amazon MQ → Broker instance cost → use only when needed for protocols.
Most Hyderabad startups (edtech, fintech, e-commerce) start with SQS + SNS + EventBridge combo — covers 80–90% needs before touching Kinesis/MSK.
6. Summary – Teacher’s Final Cheat Sheet
- Need simple, reliable task queue? → SQS
- Need fast broadcast / notifications? → SNS
- Need smart event routing + filtering + SaaS? → EventBridge
- Need real-time streaming with replay? → Kinesis
- Need full Kafka power at scale? → MSK
- Need legacy broker compatibility? → Amazon MQ
Pick based on ordering needs, fan-out vs point-to-point, retention, and integration complexity.
Got it? This is the “now I know which button to press” lesson.
Want next:
- Deep dive on one combo (e.g., SNS + SQS fan-out architecture)?
- How to migrate from SNS/SQS to EventBridge?
- Or real cost calculation for a Hyderabad food app?
Tell me — next class starts whenever you’re ready! 🚀📬
