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   │
└──────────────┴──────────────┴───────────────────┴────────────────────┘

Enter fullscreen mode Exit fullscreen mode

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    │
                 └──────────┘

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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"]
  }
}

Enter fullscreen mode Exit fullscreen mode

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│
└─────────────┘        └─────────────────┘        └─────────────┘

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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\"}"
  }
}

Enter fullscreen mode Exit fullscreen mode

Integration Patterns

Pattern 1: Command Queue (SQS)

Use for: async task processing, work distribution

API → SQS → Worker (Lambda/ECS)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Pattern 3: Event Router (EventBridge)

Use for: content-based routing, SaaS integration, cross-account

Services → EventBridge Bus → Rules → Targets (Lambda, SQS, Step Functions)

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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.