AWS SNS vs SQS vs EventBridge — When to Use Which?

Three AWS messaging services, and they're constantly confused with each other. SNS, SQS, and EventBridge all move messages — but they're built for different problems.

The One-Line Difference

SNS (Simple Notification Service) — Push messages to multiple subscribers at once. Fan-out.

SQS (Simple Queue Service) — Store messages in a queue. Workers pull and process them. Decoupling.

EventBridge — Route events based on rules. Event bus for AWS services and custom apps.

SQS — The Decoupling Queue

SQS is a queue. Messages sit in it until a consumer polls and processes them.

Producer → [Queue] → Consumer

Key characteristics:

• Consumer pulls messages (not pushed)
• Messages processed once (by one consumer)
• Messages stored up to 14 days
• Scales automatically
• Dead-letter queue (DLQ) for failed processing
• Visibility timeout prevents double-processing

When to use SQS:

• Background job processing (resize image, send email, process payment)
• Decoupling a slow consumer from a fast producer
• Rate limiting — queue absorbs bursts, consumer processes at its own pace
• Retry logic — failed messages go to DLQ for inspection

# Producer (Lambda, EC2, ECS)
import boto3
sqs = boto3.client('sqs')
 
sqs.send_message(
    QueueUrl='https://sqs.ap-south-1.amazonaws.com/123456789/orders',
    MessageBody=json.dumps({
        'order_id': '12345',
        'action': 'process_payment'
    })
)
 
# Consumer (worker Lambda or EC2)
response = sqs.receive_message(
    QueueUrl=queue_url,
    MaxNumberOfMessages=10,
    WaitTimeSeconds=20  # Long polling
)
# Process message, then delete it
sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=msg['ReceiptHandle'])

SQS types:

• Standard Queue — At-least-once delivery, best-effort ordering
• FIFO Queue — Exactly-once processing, strict ordering (but lower throughput)

SNS — Fan-Out Notifications

SNS is a topic. When you publish to it, all subscribers receive a copy.

Producer → [Topic] → Subscriber 1 (Lambda)
                  → Subscriber 2 (SQS Queue)
                  → Subscriber 3 (Email)
                  → Subscriber 4 (HTTP endpoint)

Key characteristics:

• Push-based — SNS pushes to subscribers
• All subscribers get a copy of every message
• No storage — if subscriber is unavailable, message is lost (unless subscriber is SQS)
• Supports: Lambda, SQS, HTTP/S, Email, SMS, Mobile push

When to use SNS:

• Notifying multiple systems about the same event
• Triggering parallel processing of the same message
• Email/SMS alerts to humans

sns = boto3.client('sns')
 
sns.publish(
    TopicArn='arn:aws:sns:ap-south-1:123456789:order-events',
    Message=json.dumps({'order_id': '12345', 'status': 'placed'}),
    Subject='New Order Placed'
)

SNS + SQS Fan-Out Pattern

The most common real-world pattern: SNS publishes, multiple SQS queues subscribe.

New Order Event
      ↓ (SNS Topic)
      ├─→ SQS: Payment Service Queue
      ├─→ SQS: Inventory Service Queue
      ├─→ SQS: Notification Service Queue
      └─→ Lambda: Analytics (immediate)

This gives you fan-out (all services notified) with durability (SQS stores messages if a service is down).

EventBridge — Event Routing

EventBridge is an event bus with rules. Events are matched against rules, and matching events are sent to targets.

AWS Service events  ──→
Custom app events   ──→  [Event Bus]  ──rule-match──→  Target
SaaS partner events ──→

Key characteristics:

• Filters events based on content (not just topic)
• Routes to many targets: Lambda, SQS, SNS, ECS tasks, Step Functions, API Gateway, etc.
• Built-in schema registry
• Receives events from 200+ AWS services natively
• Scheduled events (cron-like) via EventBridge Scheduler

When to use EventBridge:

• Reacting to AWS service events (S3 upload, EC2 state change, RDS events)
• Complex event routing with content-based filtering
• Connecting SaaS tools (Salesforce, Zendesk, GitHub) to AWS
• Replacing CloudWatch Events (EventBridge is the successor)
• Event-driven microservices with rich filtering

// EventBridge rule — only trigger for EC2 instances stopping
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped", "terminated"]
  }
}

events = boto3.client('events')
 
# Put custom event
events.put_events(
    Entries=[{
        'Source': 'myapp.orders',
        'DetailType': 'Order Placed',
        'Detail': json.dumps({'order_id': '12345', 'amount': 599}),
        'EventBusName': 'default'
    }]
)

Side-by-Side Comparison

Decision Guide

Use SQS when:

• You need to decouple a producer from a slow consumer
• You want exactly-once or at-least-once processing
• Background jobs, async processing
• You need the queue to buffer bursts

Use SNS when:

• One event needs to reach multiple destinations
• You need fan-out pattern
• Alerting humans (email/SMS)
• No complex filtering needed

Use EventBridge when:

• You want to react to AWS service events
• You need content-based routing rules
• You're building event-driven microservices
• You're connecting SaaS tools to AWS
• You need scheduled tasks (cron)

The most common production pattern:

EC2 state change / S3 upload / etc.
    → EventBridge (captures AWS events, filters)
    → SNS Topic (fan-out to multiple teams)
    → SQS Queues (per-service, reliable processing)
    → Lambda Workers (actual processing)

For hands-on AWS messaging labs and SAA-C03 exam prep, KodeKloud covers SNS, SQS, and EventBridge with real scenarios.