Aws Sqs To Sns

Aws Sqs To Sns

Reading time1 min
#Cloud#AWS#Messaging#SQS#SNS#EventDriven

Maximizing Event-Driven Architectures by Integrating AWS SQS with SNS for Scalable Messaging

Most developers treat Amazon SQS (Simple Queue Service) and Amazon SNS (Simple Notification Service) in isolation—what if you could harness both in tandem to design resilient, decoupled systems that handle peak loads gracefully without sacrificing message integrity?

Combining AWS SQS and SNS lets you leverage the best of both worlds: reliable, durable message queues with flexible, fan-out pub/sub notification patterns. This integration forms a scalable backbone for event-driven applications, enabling asynchronous workflows to operate robustly under varied load conditions.

In this post, I’ll walk you through how to integrate SNS with SQS practically—complete with examples—so you can immediately apply these patterns in your own projects.


Why Integrate SNS with SQS?

  • SNS acts as a highly available pub/sub system that pushes messages to multiple subscribers simultaneously.
  • SQS acts as a durable buffer that decouples your application components, ensuring messages are processed reliably even if downstream systems go offline or slow down.

By subscribing an SQS queue to an SNS topic:

  • You gain fan-out messaging: one event broadcasted by SNS is delivered to multiple queues, which can represent different services or processing domains.
  • You ensure message durability and retry guarantees, since SQS persists messages until consumed.
  • You build loosely coupled microservices architectures capable of handling spiky traffic with backpressure and retry mechanisms baked-in.

Step-by-Step Guide: Connecting SNS to SQS

1. Create an SNS Topic

Go to the AWS Management Console → SNS → Create Topic.

Use the following parameters:

  • Type: Standard (for at-least-once delivery)
  • Name: myAppEvents

2. Create an SQS Queue

Navigate to AWS Console → SQS → Create Queue.

Choose:

  • Type: Standard Queue (FIFO is also supported but requires additional considerations)
  • Name: myAppProcessingQueue

Make sure your queue's access policy allows SNS to send messages. You’ll modify this next.

3. Allow the SNS Topic to Publish Messages to the Queue (SQS Policy)

Update the queue's access policy so that only your SNS topic can send messages. Example IAM policy attached to the queue:

{
    "Version": "2012-10-17",
    "Id": "policy-id-example",
    "Statement": [
        {
            "Sid": "Allow-SNS-SendMessage",
            "Effect": "Allow",
            "Principal": {"Service": "sns.amazonaws.com"},
            "Action": "sqs:SendMessage",
            "Resource": "arn:aws:sqs:us-east-1:123456789012:myAppProcessingQueue",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:sns:us-east-1:123456789012:myAppEvents"
                }
            }
        }
    ]
}

This ensures secure messaging between services.

4. Subscribe the SQS Queue to Your SNS Topic

Back on the SNS Console → Topics → Select myAppEvents → Create Subscription:

  • Protocol: SQS
  • Endpoint: full ARN of your queue (arn:aws:sqs:us-east-1:123456789012:myAppProcessingQueue)

Confirm subscription if needed (usually automatic for SQS).


How It Works — With a Simple Example

Imagine you have an e-commerce system where:

  • The order service publishes “OrderPlaced” events via SNS.
  • Inventory and shipping services consume these events separately.

You can set up two separate queues subscribed to the same topic, each processed by different microservices.

Publishing Messages (Sample Python boto3 snippet)

import boto3
import json

sns = boto3.client('sns')

topic_arn = 'arn:aws:sns:us-east-1:123456789012:myAppEvents'

message = {
    'orderId': '12345',
    'status': 'placed',
    'items': [
        {'sku': 'abc', 'qty': 2},
        {'sku': 'xyz', 'qty': 1}
    ]
}

response = sns.publish(
    TopicArn=topic_arn,
    Message=json.dumps(message),
    MessageAttributes={
        'eventType': {
            'DataType': 'String',
            'StringValue': 'OrderPlaced'
        }
    }
)

print("Message published with ID:", response['MessageId'])

Processing Messages from SQS

Your worker service polls the queue and processes events independently of one another:

import boto3
import json

sqs = boto3.client('sqs')

queue_url = 'https://sqs.us-east-1.amazonaws.com/123456789012/myAppProcessingQueue'

def process_messages():
    response = sqs.receive_message(
        QueueUrl=queue_url,
        MaxNumberOfMessages=10,
        WaitTimeSeconds=20
    )
    
    if 'Messages' not in response:
        print("No messages")
        return
    
    for message in response['Messages']:
        body = json.loads(message['Body'])
        # Incoming message from SNS is wrapped; actual message is in 'Message'
        sns_message = json.loads(body['Message'])
        
        print("Processing order ID:", sns_message['orderId'])
        
        # TODO: process order...
        
        # Delete message after successful processing
        sqs.delete_message(
            QueueUrl=queue_url,
            ReceiptHandle=message['ReceiptHandle']
        )

if __name__ == "__main__":
    process_messages()

Advanced Tips

Dead-Letter Queues (DLQ)

Attach DLQs to your SQS queues so failed messages can be quarantined for later inspection without blocking processing.

FIFO Compatibility

If strict ordering matters, use FIFO topics and queues—but note that FIFO SNS topics were released recently and have specific requirements.

Message Filtering on Subscription

SNS supports filtering policies on subscriptions so each queue only receives relevant event types. For example, one queue only gets OrderPlaced while another gets OrderCancelled.

Example filter policy on subscription:

{
  "eventType": ["OrderPlaced"]
}

This reduces unnecessary downstream processing.


Conclusion

Integrating AWS HTTP push-style notifications via SNS with reliable, durable queuing via SQS unlocks highly scalable event-driven architectures. This pattern lets you simultaneously broadcast events while gracefully managing consumer load and reliability concerns—building resilient applications that can scale as your business grows.

Try it out today by connecting your own SNS topics and SQS queues—we rely on this strategy for all asynchronous workflows worth their salt!


If you want me to share some Terraform or CloudFormation resources for automating this setup or patterns for multi-region deployments, let me know!