Intermediate 15 min read

Choosing Between SQS, SNS, and EventBridge

By the end of this lesson, you'll be able to:

  • Summarize what SQS, SNS, and EventBridge are each best suited for
  • Choose an appropriate integration service for a described scenario
  • Explain why the choice should be driven by the actual requirement, not a fixed rule

Prerequisites: "Amazon EventBridge and Event-Driven Systems"

The three services, side by side

This module has now covered all three integration services this course focuses on. Bringing them together:

Side-by-side comparison of SQS holding messages for worker-pool processing, SNS publishing once to every current subscriber for fan-out, and EventBridge routing events to targets using content-based rules.
No single service is "always" the right choice — the fit depends on the architecture's actual requirements.
  • SQS — good for buffering work in front of one or more workers that process it, especially when the sender doesn't need an immediate result (Lesson 2).
  • SNS — good for fanning one publication out to a fixed, known set of subscribers (Lesson 3).
  • EventBridge — good when many different kinds of events, from many different producers, each need routing to different targets based on their content (Lesson 4).

Choose by requirement, not by familiarity

The single most important habit this module can leave you with: choose an integration service based on the application's actual communication requirement, not because a service name is the one you've heard of most. A quick gut-check that holds up well in practice:

  • Does work need to wait for a worker to become available, with retry/DLQ handling built in? Lean SQS.
  • Does one event need to reach a fixed, known set of independent subscribers? Lean SNS.
  • Do many different event types, from many different sources, need routing to different targets based on their content? Lean EventBridge.

Real architectures often combine more than one — exactly like the SNS-plus-SQS fan-out pattern from Lesson 3 — rather than treating the choice as forcing exactly one service for an entire system.

Exercise

For each scenario, choose SQS, SNS, or EventBridge, and briefly justify your choice: (1) a background worker pool processing report-generation jobs at its own pace, with failed jobs needing a dead-letter queue, (2) a payment-completed event that a fixed set of three internal systems (billing, shipping, notifications) all need a copy of, (3) a platform ingesting many different kinds of events from several different AWS services, each needing to be routed to a different target based on its specific type.

Show hint

Match each scenario to the service whose core strength (buffering, fixed-subscriber fan-out, or content-based routing) fits best.

Choosing Between SQS, SNS, and EventBridge Quiz

1. A background worker pool needs to process report-generation jobs at its own pace, with failed jobs isolated in a dead-letter queue for investigation. Which service best fits?

2. One AWS integration service is always the correct choice regardless of the application's actual requirements.

Log in to submit the quiz and save your score.

My Notes

Log in to keep private notes on this lesson.

Questions about this lesson

No questions yet — be the first to ask.

Log in to ask a question about this lesson.

Summary

SQS (queuing and buffering for worker processing), SNS (publish/subscribe fan-out to a fixed set of subscribers), and EventBridge (content-based routing across many event sources and targets) solve genuinely different shapes of the same underlying integration problem, and choosing between them should come from the application's actual requirements rather than a rule that one service is always correct.

Log in to track progress
❬ Previous Next ❭