Event-Driven Architecture on AWS: SQS vs SNS vs EventBridge vs Kinesis - Patterns, Anti-Patterns, and When to Use What

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 mult