Amazon SNS via SDK: Your First Topic

Q: Why didn't my email subscriber get the message?

Email subscriptions must be confirmed first and stay in PendingConfirmation until the recipient clicks the confirmation link. Messages published before confirmation are not delivered to them.

Q: How do I let a subscriber receive only some messages?

Set a FilterPolicy on the subscription and publish messages with matching MessageAttributes. Each subscriber then receives only the messages whose attributes satisfy its policy.

Q: Why can't SNS deliver to my SQS queue?

The queue needs a policy allowing the SNS service (sns.amazonaws.com) to SendMessage to it. Without that permission, SNS delivery to the queue is denied.

Q: Can a CloudWatch alarm publish to a topic?

Yes. Set the alarm's AlarmActions to a topic ARN. When the alarm fires, CloudWatch publishes to the topic, which then notifies all subscribers.

Amazon SNS is a pub/sub service: publish one message to a topic and it fans out to every subscriber.

This page creates a topic, subscribes two different endpoints to it, publishes a message that reaches both, then cleans up. It is the push half of AWS messaging - SQS is the pull half.

Recipe

Quick-reference recipe card - copy-paste ready.

# --- Python (boto3) ---
import boto3
 
sns = boto3.client("sns", region_name="us-east-1")
arn = sns.create_topic(Name="order-events")["TopicArn"]
sns.publish(TopicArn=arn, Subject="Order", Message="order o-100 placed")
print("published to", arn)

// --- TypeScript (AWS SDK v3) ---
import { SNSClient, CreateTopicCommand, PublishCommand } from "@aws-sdk/client-sns";
 
const sns = new SNSClient({ region: "us-east-1" });
const { TopicArn } = await sns.send(new CreateTopicCommand({ Name: "order-events" }));
await sns.send(new PublishCommand({ TopicArn, Subject: "Order", Message: "order o-100 placed" }));
console.log("published to", TopicArn);

When to reach for this:

Notifying several independent consumers of the same event at once.
Fanning an event out to email, a queue, and a function together.
Decoupling a producer from a changing set of subscribers.
Sending operational alerts (for example, from CloudWatch alarms).

Working Example

Create a topic, subscribe an email address and an SQS queue, publish a message that fans out to both, list the subscriptions, then delete the topic.

# --- Python (boto3) ---
import boto3
 
sns = boto3.client("sns", region_name="us-east-1")
 
# 1. Create the topic (idempotent - same name, same ARN).
arn = sns.create_topic(Name="order-events")["TopicArn"]
 
# 2. Subscribe two endpoints. Email must be confirmed by the recipient;
#    SQS is confirmed automatically.
sns.subscribe(TopicArn=arn, Protocol="email", Endpoint="ops@example.com")
sns.subscribe(TopicArn=arn, Protocol="sqs",
    Endpoint="arn:aws:sqs:us-east-1:111122223333:order-queue")
 
# 3. Publish once; SNS delivers a copy to every confirmed subscriber.
sns.publish(TopicArn=arn, Subject="Order placed",
    Message="order o-100 placed",
    MessageAttributes={"eventType": {"DataType": "String", "StringValue": "placed"}})
 
# 4. Inspect subscriptions, then clean up.
subs = sns.list_subscriptions_by_topic(TopicArn=arn)["Subscriptions"]
print([(s["Protocol"], s["SubscriptionArn"]) for s in subs])
sns.delete_topic(TopicArn=arn)

// --- TypeScript (AWS SDK v3) ---
import {
  SNSClient, CreateTopicCommand, SubscribeCommand, PublishCommand,
  ListSubscriptionsByTopicCommand, DeleteTopicCommand,
} from "@aws-sdk/client-sns";
 
const sns = new SNSClient({ region: "us-east-1" });
 
// 1. Create the topic (idempotent - same name, same ARN).
const { TopicArn } = await sns.send(new CreateTopicCommand({ Name: "order-events" }));
 
// 2. Subscribe two endpoints. Email must be confirmed by the recipient;
//    SQS is confirmed automatically.
await sns.send(new SubscribeCommand({ TopicArn, Protocol: "email", Endpoint: "ops@example.com" }));
await sns.send(new SubscribeCommand({ TopicArn, Protocol: "sqs",
  Endpoint: "arn:aws:sqs:us-east-1:111122223333:order-queue" }));
 
// 3. Publish once; SNS delivers a copy to every confirmed subscriber.
await sns.send(new PublishCommand({ TopicArn, Subject: "Order placed",
  Message: "order o-100 placed",
  MessageAttributes: { eventType: { DataType: "String", StringValue: "placed" } } }));
 
// 4. Inspect subscriptions, then clean up.
const out = await sns.send(new ListSubscriptionsByTopicCommand({ TopicArn }));
console.log((out.Subscriptions ?? []).map((s) => [s.Protocol, s.SubscriptionArn]));
await sns.send(new DeleteTopicCommand({ TopicArn }));

What this demonstrates:

CreateTopic is idempotent, so re-running returns the existing topic's ARN.
Different protocols (email, sqs, lambda, https) subscribe to the same topic.
A single Publish fans out to every confirmed subscriber.
Message attributes travel with the message and enable subscriber filter policies.

Deep Dive

How It Works

A topic is the named channel producers publish to and subscribers listen on, addressed by its ARN.
A subscription binds an endpoint to a topic via a protocol - email, SMS, SQS, Lambda, or HTTPS.
SNS is push: it actively delivers each message to every subscriber, unlike SQS where a worker pulls.
Email and HTTPS subscriptions require confirmation and sit in PendingConfirmation until the recipient confirms; SQS and Lambda subscriptions confirm automatically.
Delivery is best-effort with retries; pair a topic with an SQS queue when you need durable buffering.

Filtering So Subscribers Get Only What They Want

A filter policy lets one subscriber receive only messages whose attributes match, so you do not need a topic per event type.

# --- Python (boto3) ---
import json
 
# This subscription only receives messages where eventType == "placed".
sns.set_subscription_attributes(
    SubscriptionArn="arn:aws:sns:us-east-1:111122223333:order-events:sub-id",
    AttributeName="FilterPolicy",
    AttributeValue=json.dumps({"eventType": ["placed"]}),
)

// --- TypeScript (AWS SDK v3) ---
import { SetSubscriptionAttributesCommand } from "@aws-sdk/client-sns";
 
// This subscription only receives messages where eventType == "placed".
await sns.send(new SetSubscriptionAttributesCommand({
  SubscriptionArn: "arn:aws:sns:us-east-1:111122223333:order-events:sub-id",
  AttributeName: "FilterPolicy",
  AttributeValue: JSON.stringify({ eventType: ["placed"] }),
}));

With filter policies, one topic serves many event types and each subscriber gets only its slice.

The classic design is SNS to multiple SQS queues: one publish, several durable queues, each drained by its own worker at its own pace. This combines SNS fan-out with SQS buffering and is the backbone of many event-driven systems.

Gotchas

Expecting email subscribers to receive immediately - email and HTTPS stay PendingConfirmation until confirmed. Fix: have the recipient click the confirmation link before publishing.
Publishing to an empty topic - a publish with no confirmed subscribers succeeds but reaches no one. Fix: confirm subscriptions exist, and treat SNS as best-effort delivery.
No queue policy for SQS subscribers - SNS cannot deliver to a queue that does not allow it. Fix: add a queue policy granting sns.amazonaws.com permission to SendMessage.
Assuming ordering - standard topics do not guarantee order across messages. Fix: use a FIFO topic with a FIFO queue when order matters.
Recreating topics for each event type - a topic per event multiplies management. Fix: use one topic with message attributes and per-subscription filter policies.
Relying on SNS alone for durability - a failed HTTP/email delivery can be dropped after retries. Fix: subscribe an SQS queue for durable, replayable delivery.

Alternatives

Alternative	Use When	Don't Use When
SNS (this page)	Push one message to many subscribers	One worker should pull and process each message
SQS	Durable buffering for a single consumer group	You need immediate fan-out to many endpoints
SNS + SQS fan-out	Many durable consumers of one event	A single simple notification
EventBridge	Rich event routing, schemas, many AWS sources	Simple pub/sub to a few endpoints
Kinesis / Kafka	High-throughput ordered streaming and replay	Low-volume notifications

FAQs

What is the difference between SNS and SQS?

SNS pushes a copy of each message to every subscriber (fan-out). SQS holds messages in a queue for a worker to pull when ready (buffering). They are complementary, not substitutes.

Is CreateTopic safe to call repeatedly?

Yes. It is idempotent: calling it with the same name returns the existing topic's ARN rather than erroring or creating a duplicate.

Why didn't my email subscriber get the message?

Email subscriptions must be confirmed first and stay in PendingConfirmation until the recipient clicks the confirmation link. Messages published before confirmation are not delivered to them.

Do SQS and Lambda subscriptions need confirmation?

No. Unlike email and HTTPS, SQS and Lambda subscriptions confirm automatically when created, so they can receive messages right away.

How do I let a subscriber receive only some messages?

Set a FilterPolicy on the subscription and publish messages with matching MessageAttributes. Each subscriber then receives only the messages whose attributes satisfy its policy.

What is the fan-out pattern?

Publishing to an SNS topic that has several SQS queues subscribed. One publish reaches all queues, and each queue's worker processes at its own pace with durable buffering.

Why can't SNS deliver to my SQS queue?

The queue needs a policy allowing the SNS service (sns.amazonaws.com) to SendMessage to it. Without that permission, SNS delivery to the queue is denied.

Does SNS guarantee message order?

Standard topics do not. If you need strict ordering and exactly-once delivery, use a FIFO topic paired with a FIFO queue.

Is SNS delivery guaranteed?

It is best-effort with retries. For durability and replay, subscribe an SQS queue so messages persist until a worker processes and deletes them.

Can a CloudWatch alarm publish to a topic?

Yes. Set the alarm's AlarmActions to a topic ARN. When the alarm fires, CloudWatch publishes to the topic, which then notifies all subscribers.

Amazon SQS via SDK: Your First Queue - the pull half, and the durable end of fan-out.
Amazon CloudWatch via SDK: Metrics & Alarms - a common publisher to SNS topics.
AWS Lambda via SDK: Your First Function - a subscriber that runs code per message.
Core AWS Services Best Practices - messaging defaults.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

This page creates a topic, subscribes two different endpoints to it, publishes a message that reaches both, then cleans up. It is the push half of AWS messaging - SQS is the pull half.

Recipe

Quick-reference recipe card - copy-paste ready.

# --- Python (boto3) ---
import boto3
 
sns = boto3.client("sns", region_name="us-east-1")
arn = sns.create_topic(Name="order-events")["TopicArn"]
sns.publish(TopicArn=arn, Subject="Order", Message="order o-100 placed")
print("published to", arn)

// --- TypeScript (AWS SDK v3) ---
import { SNSClient, CreateTopicCommand, PublishCommand } from "@aws-sdk/client-sns";
 
const sns = new SNSClient({ region: "us-east-1" });
const { TopicArn } = await sns.send(new CreateTopicCommand({ Name: "order-events" }));
await sns.send(new PublishCommand({ TopicArn, Subject: "Order", Message: "order o-100 placed" }));
console.log("published to", TopicArn);

When to reach for this:

Notifying several independent consumers of the same event at once.
Fanning an event out to email, a queue, and a function together.
Decoupling a producer from a changing set of subscribers.
Sending operational alerts (for example, from CloudWatch alarms).

Working Example

Create a topic, subscribe an email address and an SQS queue, publish a message that fans out to both, list the subscriptions, then delete the topic.

# --- Python (boto3) ---
import boto3
 
sns = boto3.client("sns", region_name="us-east-1")
 
# 1. Create the topic (idempotent - same name, same ARN).
arn = sns.create_topic(Name="order-events")["TopicArn"]
 
# 2. Subscribe two endpoints. Email must be confirmed by the recipient;
#    SQS is confirmed automatically.
sns.subscribe(TopicArn=arn, Protocol="email", Endpoint="ops@example.com")
sns.subscribe(TopicArn=arn, Protocol="sqs",
    Endpoint="arn:aws:sqs:us-east-1:111122223333:order-queue")
 
# 3. Publish once; SNS delivers a copy to every confirmed subscriber.
sns.publish(TopicArn=arn, Subject="Order placed",
    Message="order o-100 placed",
    MessageAttributes={"eventType": {"DataType": "String", "StringValue": "placed"}})
 
# 4. Inspect subscriptions, then clean up.
subs = sns.list_subscriptions_by_topic(TopicArn=arn)["Subscriptions"]
print([(s["Protocol"], s["SubscriptionArn"]) for s in subs])
sns.delete_topic(TopicArn=arn)

// --- TypeScript (AWS SDK v3) ---
import {
  SNSClient, CreateTopicCommand, SubscribeCommand, PublishCommand,
  ListSubscriptionsByTopicCommand, DeleteTopicCommand,
} from "@aws-sdk/client-sns";
 
const sns = new SNSClient({ region: "us-east-1" });
 
// 1. Create the topic (idempotent - same name, same ARN).
const { TopicArn } = await sns.send(new CreateTopicCommand({ Name: "order-events" }));
 
// 2. Subscribe two endpoints. Email must be confirmed by the recipient;
//    SQS is confirmed automatically.
await sns.send(new SubscribeCommand({ TopicArn, Protocol: "email", Endpoint: "ops@example.com" }));
await sns.send(new SubscribeCommand({ TopicArn, Protocol: "sqs",
  Endpoint: "arn:aws:sqs:us-east-1:111122223333:order-queue" }));
 
// 3. Publish once; SNS delivers a copy to every confirmed subscriber.
await sns.send(new PublishCommand({ TopicArn, Subject: "Order placed",
  Message: "order o-100 placed",
  MessageAttributes: { eventType: { DataType: "String", StringValue: "placed" } } }));
 
// 4. Inspect subscriptions, then clean up.
const out = await sns.send(new ListSubscriptionsByTopicCommand({ TopicArn }));
console.log((out.Subscriptions ?? []).map((s) => [s.Protocol, s.SubscriptionArn]));
await sns.send(new DeleteTopicCommand({ TopicArn }));

What this demonstrates:

CreateTopic is idempotent, so re-running returns the existing topic's ARN.
Different protocols (email, sqs, lambda, https) subscribe to the same topic.
A single Publish fans out to every confirmed subscriber.
Message attributes travel with the message and enable subscriber filter policies.

Deep Dive

How It Works

A topic is the named channel producers publish to and subscribers listen on, addressed by its ARN.
A subscription binds an endpoint to a topic via a protocol - email, SMS, SQS, Lambda, or HTTPS.
SNS is push: it actively delivers each message to every subscriber, unlike SQS where a worker pulls.
Email and HTTPS subscriptions require confirmation and sit in PendingConfirmation until the recipient confirms; SQS and Lambda subscriptions confirm automatically.
Delivery is best-effort with retries; pair a topic with an SQS queue when you need durable buffering.

Filtering So Subscribers Get Only What They Want

A filter policy lets one subscriber receive only messages whose attributes match, so you do not need a topic per event type.

# --- Python (boto3) ---
import json
 
# This subscription only receives messages where eventType == "placed".
sns.set_subscription_attributes(
    SubscriptionArn="arn:aws:sns:us-east-1:111122223333:order-events:sub-id",
    AttributeName="FilterPolicy",
    AttributeValue=json.dumps({"eventType": ["placed"]}),
)

// --- TypeScript (AWS SDK v3) ---
import { SetSubscriptionAttributesCommand } from "@aws-sdk/client-sns";
 
// This subscription only receives messages where eventType == "placed".
await sns.send(new SetSubscriptionAttributesCommand({
  SubscriptionArn: "arn:aws:sns:us-east-1:111122223333:order-events:sub-id",
  AttributeName: "FilterPolicy",
  AttributeValue: JSON.stringify({ eventType: ["placed"] }),
}));

With filter policies, one topic serves many event types and each subscriber gets only its slice.

The Fan-Out Pattern

Gotchas

Expecting email subscribers to receive immediately - email and HTTPS stay PendingConfirmation until confirmed. Fix: have the recipient click the confirmation link before publishing.
Publishing to an empty topic - a publish with no confirmed subscribers succeeds but reaches no one. Fix: confirm subscriptions exist, and treat SNS as best-effort delivery.
No queue policy for SQS subscribers - SNS cannot deliver to a queue that does not allow it. Fix: add a queue policy granting sns.amazonaws.com permission to SendMessage.
Assuming ordering - standard topics do not guarantee order across messages. Fix: use a FIFO topic with a FIFO queue when order matters.
Recreating topics for each event type - a topic per event multiplies management. Fix: use one topic with message attributes and per-subscription filter policies.
Relying on SNS alone for durability - a failed HTTP/email delivery can be dropped after retries. Fix: subscribe an SQS queue for durable, replayable delivery.

Alternatives

Alternative	Use When	Don't Use When
SNS (this page)	Push one message to many subscribers	One worker should pull and process each message
SQS	Durable buffering for a single consumer group	You need immediate fan-out to many endpoints
SNS + SQS fan-out	Many durable consumers of one event	A single simple notification
EventBridge	Rich event routing, schemas, many AWS sources	Simple pub/sub to a few endpoints
Kinesis / Kafka	High-throughput ordered streaming and replay	Low-volume notifications

FAQs

What is the difference between SNS and SQS?

SNS pushes a copy of each message to every subscriber (fan-out). SQS holds messages in a queue for a worker to pull when ready (buffering). They are complementary, not substitutes.

Is CreateTopic safe to call repeatedly?

Yes. It is idempotent: calling it with the same name returns the existing topic's ARN rather than erroring or creating a duplicate.

Why didn't my email subscriber get the message?

Email subscriptions must be confirmed first and stay in PendingConfirmation until the recipient clicks the confirmation link. Messages published before confirmation are not delivered to them.

Do SQS and Lambda subscriptions need confirmation?

No. Unlike email and HTTPS, SQS and Lambda subscriptions confirm automatically when created, so they can receive messages right away.

How do I let a subscriber receive only some messages?

Set a FilterPolicy on the subscription and publish messages with matching MessageAttributes. Each subscriber then receives only the messages whose attributes satisfy its policy.

What is the fan-out pattern?

Publishing to an SNS topic that has several SQS queues subscribed. One publish reaches all queues, and each queue's worker processes at its own pace with durable buffering.

Why can't SNS deliver to my SQS queue?

The queue needs a policy allowing the SNS service (sns.amazonaws.com) to SendMessage to it. Without that permission, SNS delivery to the queue is denied.

Does SNS guarantee message order?

Standard topics do not. If you need strict ordering and exactly-once delivery, use a FIFO topic paired with a FIFO queue.

Is SNS delivery guaranteed?

It is best-effort with retries. For durability and replay, subscribe an SQS queue so messages persist until a worker processes and deletes them.

Can a CloudWatch alarm publish to a topic?

Yes. Set the alarm's AlarmActions to a topic ARN. When the alarm fires, CloudWatch publishes to the topic, which then notifies all subscribers.

Amazon SQS via SDK: Your First Queue - the pull half, and the durable end of fan-out.
Amazon CloudWatch via SDK: Metrics & Alarms - a common publisher to SNS topics.
AWS Lambda via SDK: Your First Function - a subscriber that runs code per message.
Core AWS Services Best Practices - messaging defaults.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Amazon SNS via SDK: Your First Topic

Buscar en la documentación

Amazon SNS via SDK: Your First Topic