AWS SQS vs SNS vs EventBridge: Picking the Right Messaging Service

What and Why

AWS gives you three flagship messaging services and they look superficially similar. SQS is a durable queue. SNS is pub/sub on topics. EventBridge is a smarter pub/sub bus with content-based routing and a schema registry. They are not interchangeable, and picking the wrong one bakes pain into your architecture.

The choice matters because messaging shapes coupling. Pick a queue and you get backpressure. Pick a topic and you get fan-out. Pick a bus and you get routing rules that let you add consumers without redeploying producers.

Mental Model

• SQS is a buffer between exactly one producer side and exactly one consumer side. Messages wait until a worker pulls them. Great for decoupling and rate smoothing.
• SNS is a broadcast: one message goes to many subscribers (email, SMS, Lambda, SQS, HTTP). No persistence beyond a short retry window; if a subscriber is down too long, messages drop.
• EventBridge is a bus where producers emit JSON events and rules route them to targets based on event content. It supports archive, replay, and schema discovery.

SQS:        Producer -> [ Queue ] -> Worker (poll)

SNS:        Producer -> ( Topic ) -+-> Lambda
                                 +-> SQS
                                 +-> Email

EventBridge: Producer -> [ Bus ] --rules--+-> Lambda  (source = "orders")
                                        +-> SQS    (detail.amount > 100)
                                        +-> StepFn (detail-type = "refund")

Hands-on Example

Imagine an e-commerce order flow. The order service publishes an event. Inventory, billing, and analytics all care, plus a slow legacy CRM that must not lose messages.

Use EventBridge as the entry point and let consumers attach themselves. The CRM gets its own SQS queue so it can lag without dropping events.

# SAM template excerpt
Resources:
  OrdersBus:
    Type: AWS::Events::EventBus
    Properties: { Name: orders-bus }

  CrmQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: crm-orders
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt CrmDLQ.Arn
        maxReceiveCount: 5

  CrmRule:
    Type: AWS::Events::Rule
    Properties:
      EventBusName: !Ref OrdersBus
      EventPattern:
        source: ["app.orders"]
        detail-type: ["OrderPlaced"]
      Targets:
        - Arn: !GetAtt CrmQueue.Arn
          Id: crm

Publishing an event:

aws events put-events --entries '[{
  "Source":"app.orders",
  "DetailType":"OrderPlaced",
  "EventBusName":"orders-bus",
  "Detail":"{\"orderId\":\"o-42\",\"amount\":120.50}"
}]'

The CRM worker polls the queue with long polling and processes at its own pace. Add a high-value rule that only matches orders over a threshold:

{ "source": ["app.orders"], "detail": { "amount": [{ "numeric": [">", 500] }] } }

Common Pitfalls

• Using SNS where you need durability. If a Lambda subscriber fails and the retry window expires, the message is gone. Subscribe an SQS queue to the topic so retries can be controlled.
• Forgetting DLQs. Every queue and rule target should have a dead letter queue or you will silently lose messages on poison pills.
• EventBridge cross-account quirks. You must put a resource policy on the bus AND grant the target permission. Two-sided IAM trips up teams.
• Polling overhead. Short-polling SQS bills per empty receive. Always set ReceiveMessageWaitTimeSeconds to 20.
• Ordering assumptions. Standard SQS and SNS do not guarantee order. Use FIFO variants with a message group ID when order matters.

Production Tips

• For multi-team architectures, EventBridge is the default. It lets you add consumers without producer changes and gives you replay via archives.
• For background job queues with strict at-least-once and visibility timeouts, SQS is unbeatable. Pair it with Lambda for serverless workers, or with ECS for long-running jobs.
• SNS shines for two cases: SMS/email notifications, and the classic fan-out-to-SQS pattern (one publish, many durable queues).
• Tune visibility timeout to roughly 6x your p99 processing time, then redrive to a DLQ after 3 to 5 attempts.
• Use EventBridge Pipes to plug a source (SQS, Kinesis, DynamoDB stream) directly into a target with optional enrichment - it removes glue Lambdas.

Wrap-up

Pick SQS for buffering, SNS for fan-out broadcasts, and EventBridge for content-routed event-driven architectures. In practice, mature systems combine them: EventBridge as the bus, SQS queues per consumer for durability, and SNS where you genuinely need broadcast to non-AWS endpoints. Get the topology right early and your services stay loosely coupled as the system grows.