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

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

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

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

When to Use Kinesis Over SQS/EventBridge

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

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

Cost Comparison

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.