Skip to content

Lab 6 · SQS, SNS & EventBridge

Resilient · Est. time: 25–30 min · Cost: ✅ effectively Free — SQS, SNS, and EventBridge all have generous free tiers; this lab's handful of messages costs nothing. Clean up anyway.

Goal. Build the SNS → SQS fan-out pattern and see a message delivered to multiple durable queues, then create an EventBridge rule — the decoupling core of Topic 6.

Step 1 — Create two SQS queues

SQS → Create queue (Standard). Make orders-email and orders-analytics. Leave defaults (visibility timeout 30s, retention 4 days).

Q1=$(aws sqs create-queue --queue-name orders-email --query QueueUrl --output text)
Q2=$(aws sqs create-queue --queue-name orders-analytics --query QueueUrl --output text)

Step 2 — Create an SNS topic and subscribe both queues (fan-out)

  1. SNS → Topics → Create topic (Standard), name orders.
  2. Create subscription on orders: protocol Amazon SQS, endpoint = orders-email ARN. Repeat for orders-analytics.
  3. When prompted, allow SNS to send to the queues (it adds the necessary queue access policy).
TOPIC=$(aws sns create-topic --name orders --query TopicArn --output text)
Q1_ARN=$(aws sqs get-queue-attributes --queue-url $Q1 --attribute-names QueueArn --query Attributes.QueueArn --output text)
Q2_ARN=$(aws sqs get-queue-attributes --queue-url $Q2 --attribute-names QueueArn --query Attributes.QueueArn --output text)
aws sns subscribe --topic-arn $TOPIC --protocol sqs --notification-endpoint $Q1_ARN
aws sns subscribe --topic-arn $TOPIC --protocol sqs --notification-endpoint $Q2_ARN
# (also add a queue policy allowing SNS to SendMessage — the console does this for you)

Step 3 — Publish once, receive twice

  1. SNS → orders → Publish message. Body: {"orderId":123}.
  2. SQS → open each queue → Send and receive messages → Poll. The same message appears in both queues. One publish, two independent consumers — fan-out.
aws sns publish --topic-arn $TOPIC --message '{"orderId":123}'
aws sqs receive-message --queue-url $Q1   # message present
aws sqs receive-message --queue-url $Q2   # same message present

Why SNS → SQS, not SNS alone

Each SQS queue durably buffers the message so a down consumer loses nothing. SNS alone pushes once with limited retry. This fan-out-to-queues pattern is a very common exam answer.

Step 4 — An EventBridge rule (bonus)

  1. EventBridge → Rules → Create rule on the default bus.
  2. Schedule → fixed rate 5 minutes (or an event pattern matching an AWS service event).
  3. Target: the orders SNS topic (or a Lambda). Create.
  4. This shows EventBridge's role: rules route events (by schedule or content) to targets — richer filtering and more sources than SNS.
aws events put-rule --name lab-schedule --schedule-expression "rate(5 minutes)"
aws events put-targets --rule lab-schedule --targets "Id"="1","Arn"="$TOPIC"

Teardown

Delete the EventBridge rule, the SNS topic (removes subscriptions), and both SQS queues.

aws events remove-targets --rule lab-schedule --ids 1
aws events delete-rule --name lab-schedule
aws sns delete-topic --topic-arn $TOPIC
aws sqs delete-queue --queue-url $Q1
aws sqs delete-queue --queue-url $Q2

✅ What you should understand now

  • SQS = a durable queue; each message is processed by one consumer then deleted.
  • SNS = pub/sub; one publish is pushed to all subscribers.
  • SNS → multiple SQS queues = durable fan-out: one event, several independent consumers, nothing lost if one is down.
  • EventBridge routes events by schedule or content-based rules from many AWS/SaaS sources — reach for it over SNS when routing depends on event content.
  • Visibility timeout, DLQs, and retention (4 days default) are the SQS knobs the exam probes.

Related: Learn — Decoupling & DR