E ExamMaster

AWS Cloud Architect & Developer · AWS Cloud Architecture

SQS, SNS and EventBridge

Decoupling applications with queues, pub sub notifications and event routing.

Six concepts on decoupling with queues, pub/sub fan-out, and rule-based routing — the services the Solutions Architect exam uses when one slow component must not block the rest.

  • AWS Cloud Architect & Developer
  • Medium level
  • 6 concepts
  • 5 practice questions

1SQS decoupling

Amazon SQS is a fully managed message queue that sits between a producer and a consumer. The producer sends a message to the queue and moves on; the consumer polls the queue and pulls work only when it is ready. Messages wait safely in the buffer during traffic spikes or downstream outages instead of being dropped.

The exam trap is treating SQS like a synchronous API call. SQS is pull-based: nothing is processed until a worker explicitly receives a message. That is why a web tier can accept orders instantly while a slow fulfillment service catches up from the queue at its own pace.

Figure. The web tier enqueues and returns immediately. Workers poll when ready; excess work stays in the queue instead of being rejected.

How it works

  1. EnqueueThe producer calls SendMessage. The queue stores the payload and returns success without waiting for processing.
  2. BufferIf consumers are busy or offline, messages accumulate in the queue (retention defaults to four days, up to fourteen).
  3. Poll and processWorkers call ReceiveMessage, process the payload, then DeleteMessage when done. Throughput scales with the number of polling consumers.

Absorbing an order spike

A checkout API receives 500 orders in one minute, but fulfillment can process only 200 orders per minute. How does an SQS queue between them change the outcome?

  • Orders arriving in 1 min500
  • Processed in 1 min at 200/min200
  • Remaining in queue after 1 min300 (buffered, not dropped)

Pro tip. The API returns fast because it only enqueues. The 300 waiting orders are safe until workers drain them — that is decoupling for resilience.

A web app must accept uploads immediately even when the virus-scan service is temporarily down. Which change decouples the tiers?
  1. Have the web tier call the scanner synchronously and retry on timeout
  2. Write each upload as a message to an SQS queue that scan workers poll
  3. Store uploads only in the web server's local disk until the scanner returns
  4. Replace the scanner with a larger instance so it never fails

SQS buffers work between producer and consumer. The web tier enqueues and returns; scan workers pull when ready. Synchronous retries still couple failure modes, local disk is not shared or durable, and bigger instances do not remove the coupling.

2Standard vs FIFO queues

SQS offers two queue types with opposite trade-offs. Standard queues maximize throughput with nearly unlimited scaling, but delivery is at-least-once with best-effort ordering — duplicates and reordering are possible. FIFO queues guarantee strict order within a message group and exactly-once processing, but at lower throughput.

The exam trap is reaching for FIFO whenever order matters a little. FIFO is for workloads that cannot tolerate duplicates or out-of-order processing — financial transactions, strictly sequenced inventory updates. High-volume telemetry or image jobs that can tolerate reordering belong on Standard.

Figure. Standard maximises throughput with at-least-once delivery; FIFO adds ordering and exactly-once processing.

How it works

  1. StandardMessages may arrive out of order or more than once. Multiple consumers can scale horizontally with no ordering contract.
  2. FIFOQueue name must end in .fifo. Messages carry a MessageGroupId; order is preserved within each group. Content-based deduplication or a DeduplicationId prevents duplicates.
  3. Throughput capFIFO defaults to 300 messages per second per queue; batching of up to 10 messages per API call raises that to 3,000 messages per second. Separate high-throughput FIFO mode is a later, higher ceiling — do not confuse it with batching.
Queue type picker
NeedChooseWhy
Maximum throughput, reordering OKStandardAt-least-once, best-effort order
Strict order, no duplicatesFIFOExactly-once within a message group
Name ends in .fifo, deduplication IDFIFORequired FIFO queue naming
Bursty analytics eventsStandardThroughput beats strict sequencing

FIFO throughput with batching

A FIFO queue uses the maximum batch size of 10 messages. How many messages per second can it accept at the default throughput quota?

  • API calls per second (default FIFO quota)300
  • Messages per batch10
  • 300 × 103,000 messages/s

Pro tip. Without batching the same default quota tops out at 300 messages per second — ten times lower. High-throughput FIFO mode is a different, higher limit, not this 300 × 10 product.

A payment processor must apply transactions in exact order with no duplicate charges. Which queue type fits?
  1. SQS Standard queue with multiple consumers
  2. SQS FIFO queue with MessageGroupId per account
  3. SNS topic with email subscriptions
  4. EventBridge rule with a Lambda target

FIFO guarantees order within a message group and exactly-once processing. Standard allows duplicates and reordering. SNS and EventBridge route events but do not replace an ordered, deduplicated work queue.

3SNS pub/sub

Amazon SNS is a publish-subscribe notification service. A publisher sends one message to a topic, and SNS pushes copies to every subscribed endpoint — SQS queues, Lambda functions, HTTP endpoints, email, SMS, and more. One publication fans out to many independent receivers.

The exam trap is confusing SNS with SQS. SQS is one message pulled by consumers from a queue; SNS is one message pushed to many subscribers. SNS does not buffer work for a single consumer — it delivers immediately to each subscription. When a subscriber needs retry buffering, subscribe an SQS queue and let workers poll that queue.

Figure. One Publish call reaches every subscriber. SNS pushes; it does not wait for consumers to poll.

How it works

  1. Create topicDefine an SNS topic as the broadcast channel — for example order-placed or image-uploaded.
  2. Subscribe endpointsEach downstream system registers as a subscriber: its own SQS queue, a Lambda ARN, an HTTPS URL, or an email address.
  3. Publish onceThe producer calls Publish with one payload. SNS delivers a separate copy to every subscription without the publisher knowing the subscriber list.
An alarm must simultaneously email on-call engineers and invoke a Lambda remediation function when a metric breaches threshold. Which service publishes the alert?
  1. SQS Standard queue polled by both email and Lambda
  2. SNS topic with email and Lambda subscriptions
  3. EventBridge custom bus with no rules
  4. A single Lambda that sends email and then calls itself

SNS fans one published message out to many subscriber types. SQS would make email and Lambda compete for the same messages. EventBridge could route by rule, but the classic one-to-many notification pattern is SNS.

4SNS fan-out to SQS

When one event must reach several independent consumers, publish once to an SNS topic and subscribe one SQS queue per consumer. SNS pushes a copy to each subscribed queue endpoint; each worker polls its own queue at its own pace. That is the fan-out pattern: one publication, many durable buffers, no shared backlog.

The exam trap is treating SNS as the consumer. SNS delivers to the queue (push), but every worker still pulls from SQS (poll). A slow analytics pipeline therefore does not block thumbnail generation — each queue holds its own copy until that service is ready.

Figure. One publication hits the topic; SNS pushes a copy into each subscribed queue. Workers never share a backlog — each polls only its own buffer, which is why a slow analytics job cannot stall thumbnails.

How it works

  1. Publish onceThe producer sends one message — for example an image-uploaded notification — to an SNS topic.
  2. Fan outSNS delivers a separate copy to each subscribed SQS queue. Add more consumers by subscribing another queue, not by changing the publisher.
  3. Consume independentlyEach downstream service polls only its own queue. Throughput and retries are per consumer; one backlog does not stall the others.
  4. Isolate failuresAttach a Dead-Letter Queue to each subscribed queue so poison messages for one service are quarantined without blocking the shared topic.
An image upload must trigger both a thumbnail generator and an analytics pipeline. Neither service should wait on the other, and each needs its own retry buffer. Which architecture fits?
  1. One SQS queue polled by two worker fleets sharing the same messages
  2. An SNS topic with two SQS queue subscriptions — one queue per service
  3. A Lambda chain where the thumbnail function synchronously invokes analytics
  4. EventBridge sending every event to one shared queue both services poll

SNS fan-out delivers one copy per subscribed queue, so each service polls independently with its own backlog and DLQ. A single shared queue makes the two fleets compete for the same messages — one consumer type can starve the other — and a synchronous Lambda chain couples their failure modes.

5Visibility timeout and DLQ

When a consumer receives an SQS message, the message becomes invisible to other consumers for the visibility timeout — default 30 seconds, configurable up to 12 hours. If processing finishes in time, DeleteMessage removes it permanently. If processing takes longer than the timeout, the message becomes visible again and another worker may receive a duplicate copy.

Messages that fail repeatedly should not block the queue forever. A Dead-Letter Queue (DLQ) captures poison messages after maxReceiveCount failed receives on a redrive policy. Operators inspect the DLQ without stopping healthy traffic on the main queue.

Figure. Receive hides the message for the visibility window. Failures beyond maxReceiveCount redrive to the DLQ instead of blocking the main queue.

How it works

  1. Receive hidesReceiveMessage returns a message and starts the visibility timer. Other consumers cannot see it until the timeout expires or it is deleted.
  2. Finish or expireDeleteMessage on success. If the worker crashes or runs past the timeout, the message reappears for retry.
  3. Redrive to DLQSet maxReceiveCount on the source queue's redrive policy. After that many failed receives, SQS moves the message to the configured DLQ.

Visibility shorter than processing

A worker needs 90 seconds to process an order message, but the queue visibility timeout is still at the 30-second default. What goes wrong, and what should you set?

  • Processing time90 s
  • Visibility timeout (default)30 s — message visible again while first worker still holds it
  • Set timeout > processing time, e.g. 120 sOne active consumer per message

Pro tip. Set visibility timeout longer than your p99 processing time, and extend it with ChangeMessageVisibility for long jobs. Pair with maxReceiveCount so repeated failures land in a DLQ instead of looping forever.

Messages on an order queue are processed twice by different workers even though each worker succeeds. The most likely misconfiguration is
  1. Visibility timeout shorter than processing time
  2. Message retention set to 14 days instead of 4
  3. Using SNS instead of SQS for the queue
  4. FIFO queue name missing the .fifo suffix

When visibility expires before processing finishes, the message becomes visible again and another worker receives a copy — duplicate processing. Retention length, SNS choice, and FIFO naming do not cause this symptom.

6EventBridge routing

Amazon EventBridge is a serverless event bus that routes events from AWS services, SaaS partners, and custom applications to targets using rules. Each rule matches events on a pattern — source, detail-type, or field values — and forwards matching events to one or more targets such as Lambda, SQS, SNS, or Step Functions.

The exam trap is picking SNS when the question asks for content-based filtering across many AWS services. SNS broadcasts every message to all subscribers; EventBridge evaluates rules and sends each event only to the targets whose patterns match. Use EventBridge for event-driven glue; use SNS fan-out when every subscriber should get every message.

Figure. Events land on the bus once; each rule filters by pattern and forwards only to its targets.

How it works

  1. Emit eventA source puts an event on the bus — for example S3 Object Created or a custom application event with a detail JSON payload.
  2. Match rulesEventBridge evaluates each rule's event pattern. Non-matching rules ignore the event; matching rules fire.
  3. Invoke targetsMatched rules deliver the event to configured targets. One event can trigger several targets across different rules.
When an object lands in an uploads/ prefix of an S3 bucket, only virus-scan Lambda should run; objects in logs/ should trigger a separate archival Lambda. Which service fits?
  1. SNS topic with both Lambdas subscribed to every publish
  2. EventBridge rule on the default bus matching bucket and prefix per target
  3. One SQS queue polled by both Lambdas
  4. SNS fan-out to two SQS queues with no filtering

EventBridge rules filter on event content — bucket name, key prefix, detail-type — and route only to the matching target. SNS and unfiltered fan-out deliver every message to every subscriber, so both Lambdas would see both prefixes.

Notes

  • SQS Queues: A fully managed message queue for decoupling producers and consumers; Standard queues give at-least-once delivery with best-effort ordering, FIFO queues give exactly-once processing and strict ordering.
  • SNS Pub/Sub: Simple Notification Service pushes a message to many subscribers (fan-out) such as SQS queues, Lambda, HTTP endpoints, and email.
  • Fan-Out Pattern: Publish once to an SNS topic that delivers to multiple SQS queues so several services process the same event independently.
  • EventBridge: An event bus that routes events from AWS services, SaaS apps, and custom sources to targets using content-based rules and schemas.
  • Visibility Timeout & DLQ: After a consumer receives an SQS message it is hidden for the visibility timeout; messages that fail repeatedly move to a Dead-Letter Queue for inspection.

Formulas

  • SQS message retention: default 4 days, configurable from 60 seconds up to 14 days.
  • SQS message size: up to 256 KB; larger payloads use the S3 extended client (up to 2 GB by reference).
  • SQS FIFO throughput: up to 300 messages/sec (or 3,000 with batching), 10 messages per batch.
  • SQS visibility timeout: default 30 seconds, configurable up to 12 hours.
  • SNS: supports up to 12,500,000 subscriptions per topic and 100,000 topics per account (default).

Exam traps & shortcuts

  • Need strict ordering and no duplicates (e.g., financial transactions) => SQS FIFO; need max throughput and can tolerate reordering => Standard.
  • One event, many independent consumers => SNS fan-out to multiple SQS queues (durable buffering per consumer).
  • If Lambda consumers are overwhelmed by bursts, buffer with SQS in front to smooth the rate.
  • For routing/filtering events across many AWS services with rules and schemas, choose EventBridge over SNS.

Reference tables

These numbers appear in scenario questions — match the limit to the service, not to a guess.

Service limits to remember
ServiceLimitExam hook
SQS message size256 KB (2 GB via S3 extended client)Large payloads need S3 pointer
SQS retention4 days default; 60 s – 14 daysBuffer duration during outage
SQS visibility30 s default; up to 12 hoursMust exceed processing time
SQS FIFO throughput300 API calls/s default (3,000 msg/s batched)Batching ≠ high-throughput FIFO mode
SNS subscriptionsUp to 12.5M per topicFan-out scale, not queue depth

Recap

Decoupling is the theme — match the pattern before you match the logo.

SQS
Pull-based buffer between producer and consumer. Spikes wait in the queue; workers poll when ready.
Queue type
Standard for throughput and at-least-once; FIFO for strict order and exactly-once within a message group.
SNS
Push pub/sub — one publish, many subscribers. Add an SQS queue per consumer when you need durable retry buffering.
Fan-out
SNS topic → one SQS queue per service. Push to the queue, poll from the worker; backlogs never merge.
Reliability
Visibility timeout must exceed processing time. maxReceiveCount sends poison messages to a DLQ.
EventBridge
Rule-filtered routing across AWS and custom sources — not a blind broadcast like SNS.

Practise SQS, SNS and EventBridge

Reading is free and needs no account. Practice, mocks and progress live in the app.

  • 5 exam-style questions on this topic, with explanations
  • A 5-question practice set that ends the chapter
  • Timed mocks scored with the real marking scheme
  • Readiness tracked per topic, kept on your device
Continue with Google — freeNo card, no trial. Works offline once installed.