Event-driven architecture (EDA) is how modern distributed systems communicate at scale. Instead of services calling each other directly (tight coupling), services emit events ("this happened") and interested consumers react independently.
On AWS, four messaging services form the EDA backbone — but they solve different problems. Choosing wrong means either over-engineering a simple notification into a Kinesis stream, or under-engineering a high-throughput data pipeline onto SQS.
This guide maps each service to its sweet spot, covers the integration patterns that work in production, and highlights the anti-patterns that waste money and create operational pain.
The Four Messaging Services
┌──────────────────────────────────────────────────────────────────────┐
│ AWS MESSAGING LANDSCAPE │
├──────────────┬──────────────┬───────────────────┬────────────────────┤
│ SQS │ SNS │ EventBridge │ Kinesis │
│ │ │ │ │
│ Queue │ Pub/Sub │ Event Bus │ Stream │
│ (1:1) │ (1:many) │ (content-route) │ (ordered, replay) │
│ │ │ │ │
│ Decouple │ Fan-out │ Route + Filter │ Real-time data │
│ + buffer │ broadcast │ + transform │ high throughput │
└──────────────┴──────────────┴───────────────────┴────────────────────┘
Quick Decision Matrix
| If you need... | Use... |
|---|---|
| Decouple producer/consumer, buffer load | SQS |
| Send one event to many subscribers | SNS |
| Route events based on content/attributes | EventBridge |
| Receive events from SaaS (Stripe, Auth0, Shopify) | EventBridge |
| Process ordered, replayable data stream | Kinesis Data Streams |
| High-throughput ingestion (100K+ events/sec) | Kinesis |
| Fan-out + per-consumer buffering | SNS → SQS (combined) |
| Transform/enrich events between services | EventBridge Pipes |
| Schedule future events (cron) | EventBridge Scheduler |
Amazon SQS: The Queue
What it is: Point-to-point message queue. One producer puts messages, one consumer processes them. Messages are buffered until consumed.
Two Flavors
| Feature | Standard Queue | FIFO Queue |
|---|---|---|
| Ordering | Best-effort (may reorder) | Strict FIFO guaranteed |
| Deduplication | At-least-once (may duplicate) | Exactly-once processing |
| Throughput | Unlimited | 3,000 msg/sec (with batching: 30,000) |
| Use case | High throughput, order doesn't matter | Financial transactions, command sequences |
When to Use SQS
- Load leveling — smooth bursty traffic (e.g., API receives 10K requests/sec, worker processes at 1K/sec)
- Decoupling — producer doesn't need to know about consumer (or if it's running)
- Retry/DLQ — failed messages automatically route to Dead Letter Queue for investigation
- Batch processing — Lambda polls SQS, processes in batches of up to 10
SQS Architecture Pattern: Work Queue
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ API GW │────→│ SQS │────→│ Lambda / ECS │
│ (burst) │ │ (buffer)│ │ (steady) │
└──────────┘ └──────────┘ └──────────────┘
│
▼ (after 3 failures)
┌──────────┐
│ DLQ │
└──────────┘
Amazon SNS: Pub/Sub Fan-Out
What it is: Publish-subscribe messaging. One publisher sends to a topic, multiple subscribers receive copies.
Subscriber Types
- SQS queues (most common — adds buffering per consumer)
- Lambda functions (direct invocation)
- HTTP/HTTPS endpoints (webhooks)
- Email / SMS (notifications)
- Kinesis Data Firehose (streaming delivery)
- Mobile push (iOS/Android)
When to Use SNS
- Fan-out — one event needs to trigger multiple independent actions
- Notifications — email alerts, SMS, mobile push
- Decoupled fan-out — SNS → multiple SQS queues (each consumer has its own queue)
SNS + SQS: The Fan-Out Pattern
┌──── SQS (Email Service) ──→ Lambda: send email
│
Producer ──→ SNS Topic ──┼──── SQS (Analytics) ──→ Lambda: track metrics
│
└──── SQS (Inventory) ──→ Lambda: update stock
Each consumer gets its own SQS queue with independent retry and DLQ. One consumer's failure doesn't affect others.
Amazon EventBridge: The Event Router
What it is: Serverless event bus with content-based routing. Events flow in, rules match patterns, and events route to targets — all without code.
Why EventBridge Over SNS
| Feature | SNS | EventBridge |
|---|---|---|
| Filtering | Basic attribute filtering | Rich content-based rules (any JSON field) |
| Schema | None | Schema registry + discovery |
| SaaS integration | No | 30+ SaaS partners (Stripe, Auth0, Zendesk) |
| Archive & replay | No | Yes (replay events from any point in time) |
| Cross-account | Complex | Native (event bus sharing) |
| Transforms | No | Input transformer (reshape events before delivery) |
| Pipes | No | EventBridge Pipes (filter → enrich → transform → deliver) |
| Pricing | Per publish + delivery | Per event ingested ($1/million) |
When to Use EventBridge
- Content-based routing — route events based on any field in the event body
- SaaS events — receive events from third-party services without polling
- Cross-account event sharing — centralized event bus for multi-account architectures
- Event replay — archive events and replay when debugging or reprocessing
- Schema enforcement — discover and validate event schemas automatically
EventBridge Rule Example
{
"source": ["com.myapp.orders"],
"detail-type": ["OrderCreated"],
"detail": {
"amount": [{"numeric": [">", 1000]}],
"region": ["eu-west-1", "eu-central-1"]
}
}
This rule matches only: orders > $1000 from EU regions. Everything else is ignored. No code needed.
EventBridge Architecture Pattern: Event Mesh
┌─────────────┐ ┌─────────────────┐ ┌─────────────┐
│ Order Service│──emit──→│ EventBridge │──rule──→│ Payment Svc │
└─────────────┘ │ (Central Bus) │ └─────────────┘
│ │
┌─────────────┐ │ Rules: │ ┌─────────────┐
│ Auth0 (SaaS)│──emit──→│ • OrderCreated │──rule──→│Warehouse Svc│
└─────────────┘ │ • UserSignedUp │ └─────────────┘
│ • PaymentFailed│
┌─────────────┐ │ │ ┌─────────────┐
│ Stripe(SaaS)│──emit──→│ │──rule──→│ Notification│
└─────────────┘ └─────────────────┘ └─────────────┘
Amazon Kinesis: The Data Stream
What it is: Real-time data streaming for high-throughput, ordered, replayable event processing.
Kinesis Family
| Service | Purpose |
|---|---|
| Kinesis Data Streams | Custom real-time stream processing (you control consumers) |
| Kinesis Data Firehose | Managed delivery to S3, Redshift, OpenSearch (zero code) |
| Kinesis Data Analytics | SQL/Flink on streaming data (real-time analytics) |
When to Use Kinesis Over SQS/EventBridge
| Requirement | SQS/EventBridge | Kinesis |
|---|---|---|
| Ordering guarantee | FIFO SQS (limited) | Per-shard ordering (scalable) |
| Event replay | EventBridge archive | Native (24h-365d retention) |
| Multiple consumers on same stream | ❌ (SNS fan-out) | ✅ (multiple consumers, each at own position) |
| Throughput | Millions/sec (SQS) | 1MB/sec per shard (scale shards) |
| Real-time analytics | Not designed for | Built for this |
| Use case | Application events, notifications | IoT telemetry, clickstream, logs, financial ticks |
Kinesis Architecture Pattern: Real-Time Analytics
┌────────────┐ ┌─────────────┐ ┌───────────────────┐
│ IoT Devices│────→│ Kinesis │────→│ Lambda (real-time) │
│ Clickstream│ │ Data Stream │ │ Anomaly detection │
│ App Logs │ │ (ordered) │ └───────────────────┘
└────────────┘ └──────┬──────┘
│
├────→ Firehose → S3 (data lake)
└────→ Flink (windowed aggregations)
EventBridge Pipes: Connect + Transform
EventBridge Pipes (launched 2023) connects sources to targets with optional filtering, enrichment, and transformation — without writing Lambda glue code.
Source → Filter → Enrich → Transform → Target
Example:
SQS Queue → filter (only "critical") → Lambda (add metadata) → reshape JSON → EventBridge Bus
Supported Sources & Targets
Sources: SQS, Kinesis, DynamoDB Streams, Kafka (MSK), Self-Managed Kafka
Targets: Lambda, Step Functions, ECS Task, EventBridge Bus, API Gateway, SQS, SNS, Kinesis, and more
When to Use Pipes vs Lambda
| Scenario | Pipes | Lambda |
|---|---|---|
| Filter + route (no business logic) | ✅ No code | Overkill |
| Simple field transformation | ✅ Input transformer | Overkill |
| Complex business logic | ❌ | ✅ Needed |
| Enrich from external API | ✅ (enrichment step) | Also works |
EventBridge Scheduler
For time-based events, EventBridge Scheduler replaces CloudWatch Events (cron):
- One-time schedules — "send reminder email in 48 hours"
- Recurring schedules — "run cleanup every day at 2 AM"
- Rate-based — "trigger every 5 minutes"
- Timezone-aware — handles DST correctly (CloudWatch Events doesn't)
- At-scale — millions of individual schedules (one per user/order/entity)
// Schedule a one-time future event
{
"ScheduleExpression": "at(2026-08-20T14:00:00)",
"Target": {
"Arn": "arn:aws:lambda:...:send-reminder",
"Input": "{\"orderId\": \"order-123\", \"action\": \"follow-up\"}"
}
}
Integration Patterns
Pattern 1: Command Queue (SQS)
Use for: async task processing, work distribution
API → SQS → Worker (Lambda/ECS)
Pattern 2: Fan-Out (SNS → SQS)
Use for: one event, multiple independent reactions
Service → SNS → SQS(A) → Consumer A
→ SQS(B) → Consumer B
→ SQS(C) → Consumer C
Pattern 3: Event Router (EventBridge)
Use for: content-based routing, SaaS integration, cross-account
Services → EventBridge Bus → Rules → Targets (Lambda, SQS, Step Functions)
Pattern 4: Streaming Pipeline (Kinesis)
Use for: real-time ordered data, multiple consumers, replay
Producers → Kinesis → Consumer A (real-time alerts)
→ Consumer B (S3 archive via Firehose)
→ Consumer C (analytics via Flink)
Pattern 5: Choreography (EventBridge, cross-service)
Use for: loosely coupled microservice workflows
Order Created → (event) → Payment Service reacts
Payment Succeeded → (event) → Shipping Service reacts
Shipping Completed → (event) → Notification Service reacts
No orchestrator. Each service reacts independently to relevant events.
Pattern 6: Orchestration + Events (Step Functions + EventBridge)
Use for: complex workflows with visibility + event-driven triggers
EventBridge detects event → triggers Step Function →
Step Function orchestrates multi-step workflow →
emits completion event back to EventBridge
Anti-Patterns to Avoid
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Using Kinesis for simple notifications | Expensive, complex for low throughput | SQS or SNS |
| SQS for fan-out (multiple consumers) | Only one consumer per message | SNS → SQS pattern |
| EventBridge for 100K+ events/sec | Soft limits, cost adds up | Kinesis for high throughput |
| Synchronous chains disguised as events | Hidden coupling, hard to debug | True async with DLQs |
| No Dead Letter Queue | Lost messages on failure | Always configure DLQ |
| Giant event payloads (>256KB) | Exceeds size limits | Store payload in S3, pass reference |
| No event schema/contract | Breaking consumers on format change | EventBridge Schema Registry |
| Ignoring idempotency | Duplicate processing causes data corruption | Design consumers to be idempotent |
Cost Comparison
| Service | Pricing Model | Cost at 10M events/month |
|---|---|---|
| SQS Standard | $0.40/million requests | ~$4 |
| SQS FIFO | $0.50/million requests | ~$5 |
| SNS | $0.50/million publishes + delivery costs | ~$5-15 |
| EventBridge | $1.00/million events | ~$10 |
| Kinesis (1 shard) | $0.015/hr + $0.014/million PUT | ~$15 |
| Kinesis (10 shards) | $0.15/hr + $0.014/million PUT | ~$110 |
Takeaway: SQS is cheapest for simple queuing. EventBridge costs 2.5x SQS but provides routing, filtering, schema, archive, and replay. Kinesis is the most expensive but provides ordering, replay, and real-time stream processing.
Summary
Event-driven architecture on AWS comes down to four services with distinct strengths:
- SQS — queue + buffer. Decouple producer and consumer. Simple, cheap, reliable.
- SNS — fan-out. One event to many subscribers. Combine with SQS for durability.
- EventBridge — intelligent routing. Content-based filtering, SaaS integration, archive/replay, cross-account. The "default choice" for new EDA designs.
- Kinesis — ordered stream. High throughput, multiple consumers, real-time processing. Use for data pipelines, not application events.
The default starting point in 2026: EventBridge for routing + SQS for buffering. Add Kinesis only when you need ordering, replay at volume, or real-time analytics. Use SNS when you need mobile push or email notifications.
Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS infrastructure automation and event-driven cloud architecture. Connect on LinkedIn.
Top comments (0)