Introduction

Welcome to this lesson on integrating applications with Amazon SQS, Amazon SNS, and Amazon EventBridge—three core services that support event-driven architecture on AWS.

In this chapter, you'll not only learn how each service works individually, but also how to wire them together using the AWS CLI to build a simple event pipeline. This approach forms the backbone of scalable, loosely coupled, and reactive systems in the cloud.

What is Event-Driven Architecture?

This model allows:

• Loose coupling between services;
• Independent scaling of producers and consumers;
• Enhanced fault tolerance and system flexibility.

Producers do not need to know who the consumers are or what they do. They simply emit an event to a service like SNS, SQS, or EventBridge. Consumers subscribe or poll for events and act accordingly.

Amazon SNS (Simple Notification Service)

Amazon SNS is a fully managed pub/sub (publish/subscribe) messaging service. It allows you to broadcast a single message to multiple subscribers simultaneously. SNS can deliver messages to:

• SQS queues;
• Lambda functions;
• HTTP/S endpoints;
• Email and SMS recipients.

Use SNS when multiple systems or components need to be notified of the same event. For example, a new order placed might trigger:

• A confirmation email to the user;
• A warehouse system to begin processing;
• A billing system to generate an invoice.

Amazon SQS (Simple Queue Service)

Amazon SQS is a fully managed message queuing service. Unlike SNS, which pushes messages, SQS stores messages in a queue until a consumer pulls them. This enables:

• Reliable message processing;
• Decoupling between producers and consumers;
• Scaling consumers independently from producers.

You can choose between two queue types:

• Standard queues, which offer high throughput and best-effort ordering;
• FIFO queues, which ensure messages are processed in the exact order they were sent.

Amazon EventBridge

EventBridge is AWS's modern event bus and routing system. It receives events from:

• AWS services;
• Custom applications;
• Third-party SaaS providers.

EventBridge routes events based on rules and filtering logic to:

• Lambda functions;
• Step Functions;
• SQS queues or other targets.

Unlike SNS or SQS, EventBridge emphasizes content-based routing and filtering rather than delivery alone. This makes it ideal for complex, multi-system workflows and external integrations (e.g., webhooks from Stripe or Auth0).

Event-Driven Pattern Example

A common pattern in AWS event-driven architectures:

1. An application publishes an event to an SNS topic;
2. Multiple SQS queues subscribe to the SNS topic;
3. Lambda functions poll from each SQS queue and process the message;
4. EventBridge may also route other system events or SaaS events to Lambda, Step Functions, or queues based on event content.

This pattern ensures decoupling, scalability, and real-time responsiveness.

CLI Demo: Wiring SNS → SQS

Let's walk through a simple event pipeline using the AWS CLI:

1. Create an SNS Topic

aws sns create-topic --name MyTopic

This returns the SNS topic ARN, which you'll need for subscriptions and permissions.

2. Create an SQS Queue

aws sqs create-queue --queue-name MyQueue

This returns the queue URL. To subscribe the queue to the topic, you'll also need the queue ARN.

3. Retrieve the Queue ARN

aws sqs get-queue-attributes \
  --queue-url <QueueURL> \
  --attribute-names QueueArn

4. Subscribe SQS to SNS

aws sns subscribe \
  --topic-arn <TopicARN> \
  --protocol sqs \
  --notification-endpoint <QueueARN>

This creates a subscription between the SNS topic and SQS queue.

5. Apply Access Policy to Allow SNS to Send Messages to SQS

SNS needs permission to send messages to the SQS queue. Here's a sample policy (sqs-policy.json):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow-SNS-SendMessage",
      "Effect": "Allow",
      "Principal": {
        "Service": "sns.amazonaws.com"
      },
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:us-east-2:<acc-id>:MyQueue",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:us-east-2:<acc-id>:MyTopic"
        }
      }
    }
  ]
}

Stringify and attach it to the queue using the CLI:

aws sqs set-queue-attributes \
  --queue-url <QueueURL> \
  --attributes Policy="file://sqs-policy.json"

6. Publish a Message to the SNS Topic

aws sns publish \
  --topic-arn <TopicARN> \
  --message "Hello Event World"

7. Receive the Message from SQS

aws sqs receive-message \
  --queue-url <QueueURL>

You'll see the full message body along with metadata like:

• Message ID;
• Receipt Handle;
• MD5 hash of the body;
• Timestamp and Signature Version.

Summary & Exam Tips

• Use SNS for broadcasting messages to multiple consumers;
• Use SQS for reliable queuing and decoupling;
• Use EventBridge for content-based event routing, filtering, and external integrations;
• Ensure proper permissions between SNS and SQS via queue policies;
• SQS requires polling, whereas SNS and EventBridge push messages directly;
• Know how to create topics, queues, subscriptions, and publish/consume messages using the CLI.