Amazon Simple Notification Service (SNS) looks straightforward on the surface — publish a message, deliver it to subscribers — but the gap between a topic that "works in dev" and one that is production-ready is surprisingly wide. Silent delivery failures, over-notification storms, runaway costs from unfiltered fan-out, and security misconfigurations all hide behind an API that never throws an obvious error.
This guide covers seven areas of SNS excellence, each derived from real-world production patterns and common failure modes. It assumes you are comfortable with the basics of SNS and focuses on the why behind each practice as much as the how.
Topic Design
Choose the Right Topic Type: Standard vs FIFO
What it is: SNS offers two topic types: Standard and FIFO.
Standard topics are designed for maximum throughput and broad compatibility across subscriber types. They provide at-least-once delivery and best-effort ordering, making them suitable for high-volume event distribution and fan-out architectures.
FIFO topics are designed for workloads where message ordering and deduplication are critical. They provide ordered delivery per message group and support deduplication within a 5-minute deduplication window using either content-based or explicit deduplication IDs. FIFO topics support FIFO SQS queues and Lambda subscribers, but not the full range of endpoint types available to Standard topics (such as email, SMS, or mobile push).
FIFO throughput is lower than Standard throughput, but AWS supports high-throughput FIFO mode, where throughput scales significantly when messages are distributed across multiple message groups and batching is used.
Why it matters: Teams often default to Standard topics and later attempt to reconstruct ordering guarantees in application code — a difficult and error-prone problem in distributed systems. Conversely, teams sometimes choose FIFO topics without understanding the operational trade-offs around throughput, subscriber compatibility, and message group design
| Characteristic |
Standard |
FIFO |
| Throughput |
Very high / effectively unlimited |
Lower than Standard; scalable with high-throughput FIFO and batching |
| Delivery guarantee |
At-least-once |
Ordered delivery with deduplication support |
| Message ordering |
Best-effort |
Strict per message group |
| Supported subscribers |
SQS, Lambda, HTTP/S, email, SMS, mobile push |
FIFO SQS, Lambda |
| Right choice when... |
High fan-out, heterogeneous subscribers, maximum scalability |
Ordering and duplicate prevention are critical |
Even with FIFO topics, downstream consumers should still be designed to be idempotent. Deduplication guarantees apply only within the deduplication window and do not eliminate all duplicate-processing scenarios across distributed systems.
If you choose Standard topics, assume duplicate delivery can occur during normal operation — not just during failures or retries. Consumer idempotency is a production requirement, not an optional optimization.
Define Topic Granularity Intentionally
What it is: Topic granularity is the decision of how broadly or narrowly a single SNS topic is scoped. You can publish all events from an entire system to one topic, one topic per aggregate type (e.g., order-events), or one topic per specific event type (e.g., order-placed, order-cancelled).
Why it matters: A "God topic" that receives every event type from every service creates three problems: consumers must subscribe to a firehose and filter locally; subscription filter policies become complex and fragile; and the topic becomes a hidden coupling point between every producer and every consumer in the system. Conversely, a topic per event type creates operational overhead with hundreds of nearly identical resources.
The right model is typically one topic per aggregate or bounded context (e.g., orders-topic, inventory-topic). Consumers use subscription filter policies to receive only the event types they care about.
Topic proliferation is easier to recover from than a God topic. You can always merge two topics later. Splitting a God topic requires coordinating every producer and consumer simultaneously.
Understand the 256 KB Payload Limit and Plan for Large Messages
What it is: SNS has a hard limit of 256 KB per published message. For larger payloads, the standard pattern is to store the data in S3 and publish a reference message containing the S3 object key (the "claim check" pattern). The AWS SNS Extended Client Library for Java and other languages automates this transparently.
Why it matters: A PublishRequest for a payload exceeding 256 KB throws an InvalidParameterException at runtime — there is no graceful degradation. More subtly, even messages under 256 KB that carry full data blobs inflate costs (SNS charges per 64 KB chunk) and create unnecessarily fat events. SNS messages should be event notifications, not data transfer objects.
# Lambda consumer reading the claim-check reference
# The S3 key in the message body points to the full payload
{
"eventType": "ReportGenerated",
"correlationId": "abc-123",
"payloadBucket": "my-events-bucket",
"payloadKey": "reports/2026/05/abc-123.json"
}
A well-designed SNS message carries enough context to route, log, and act on — not the full data record. Load the full payload from the source of truth in the consumer.
Message Design
Use an Event Envelope
What it is: An event envelope is a standard outer structure that wraps every message published to SNS, regardless of the event type. It typically contains metadata fields — event type, event version, source service, timestamp, and correlation ID — in a consistent, predictable schema.
Why it matters: Without an envelope, every producer invents its own message shape. Consumers must handle N different schemas, logging pipelines cannot extract common metadata without per-event-type parsing, and schema evolution (adding a field to "OrderPlaced") requires coordinating every consumer. An envelope makes all of that uniform at zero cost to the producer.
public record EventEnvelope<T>
{
public string EventId { get; init; } = Guid.NewGuid().ToString();
public string EventType { get; init; } = typeof(T).Name;
public string Source { get; init; } = string.Empty;
public string Version { get; init; } = "1.0";
public DateTime OccurredAt { get; init; } = DateTime.UtcNow;
public string CorrelationId { get; init; } = string.Empty;
public T Payload { get; init; } = default!;
}
var envelope = new EventEnvelope<OrderPlaced>
{
Source = "order-service",
CorrelationId = Activity.Current?.TraceId.ToString() ?? Guid.NewGuid().ToString(),
Payload = new OrderPlaced { OrderId = orderId, CustomerId = customerId }
};
await snsClient.PublishAsync(new PublishRequest
{
TopicArn = _topicArn,
Message = JsonSerializer.Serialize(envelope),
MessageAttributes = new Dictionary<string, MessageAttributeValue>
{
["EventType"] = new MessageAttributeValue
{
DataType = "String",
StringValue = "OrderPlaced"
}
}
});
Include Correlation IDs in Every Message
What it is: A correlation ID is a unique identifier that travels with a request through every system it touches — from the originating API call through SNS, into every subscriber, and onward to downstream services. It is stored both in the message attributes (for filtering and routing) and in the event envelope (for body-level logging).
Why it matters: Without correlation IDs, debugging a failed event processing chain across a fan-out topology means manually matching log timestamps across multiple services and guessing at causality. With correlation IDs, one value pulls every log line related to one request across every subscriber in seconds. In a fan-out scenario where one SNS publish triggers five Lambda functions, the correlation ID is the only thread connecting them.
Use Message Attributes for Filtering Metadata — Not Body Fields
What it is: SNS supports message attributes as typed key-value metadata attached to a message. In practice, the total message size (256 KB), including attributes, is the primary constraint. Subscription filter policies can evaluate these attributes to decide whether a subscriber receives a given message. Attributes are readable without deserializing the body.
Why it matters: SNS subscription filter policies can filter on message attributes or on the top-level keys of a JSON message body. Filtering on body keys requires raw message delivery to be disabled and forces SNS to parse the JSON body for every delivery attempt. Filtering on message attributes is cheaper, faster, and decouples the subscription routing logic from the message body schema. If your routing metadata could ever change its name or nest deeper in the body, message attributes isolate subscribers from that change.
MessageAttributes = new Dictionary<string, MessageAttributeValue>
{
["EventType"] = new MessageAttributeValue
{
DataType = "String",
StringValue = "OrderPlaced"
},
["Region"] = new MessageAttributeValue
{
DataType = "String",
StringValue = "US-EAST"
},
["Priority"] = new MessageAttributeValue
{
DataType = "Number",
StringValue = "1"
}
}
Design for Schema Evolution
What it is: Schema evolution is the practice of changing event schemas (adding fields, deprecating fields, splitting events) without breaking existing subscribers. The two main strategies are: additive-only changes with a version field in the envelope, or multiple parallel event versions published simultaneously.
Why it matters: SNS fan-out means a single schema change can break N subscribers simultaneously — and in a micro-services architecture, those subscribers are often owned by different teams with different deployment cadences. Publishing both OrderPlaced/v1 and OrderPlaced/v2 in parallel allows teams to migrate on their own schedule. Consumers that only read fields they know about and ignore unknown fields (Postel's Law) tolerate additive changes without any coordination.
Never remove or rename a message attribute used by a subscription filter policy without auditing all subscriptions first. A filter that no longer matches silently drops all messages for that subscriber.
Publishers
Use PublishBatch to Reduce API Calls and Cost
What it is: The PublishBatch API sends up to 10 messages to the same topic in a single API call. SNS pricing is per API request (per 64 KB chunk), regardless of whether the call publishes 1 or 10 messages.
Why it matters: A producer publishing 1,000 individual events makes 1,000 API calls. The same producer using PublishBatch makes 100 calls — a 10x reduction. For an event-driven system publishing millions of events per day, batching can significantly reduce publisher-side API request overhead and may reduce SNS publish costs for high-volume workloads. Batching also reduces the number of network round trips, improving throughput for high-volume producers.
var batchEntries = messages.Select((msg, index) => new PublishBatchRequestEntry
{
Id = index.ToString(),
Message = JsonSerializer.Serialize(msg),
MessageAttributes = new Dictionary<string, MessageAttributeValue>
{
["EventType"] = new MessageAttributeValue
{
DataType = "String",
StringValue = msg.EventType
}
}
}).ToList();
var response = await snsClient.PublishBatchAsync(new PublishBatchRequest
{
TopicArn = _topicArn,
PublishBatchRequestEntries = batchEntries
});
Handle Partial Failures in Batch Publishes
What it is: Like SQS.SendMessageBatch, SNS.PublishBatch does not throw an exception when individual messages in the batch fail. It returns a Failed collection alongside the Successful collection. Callers that ignore Failed silently lose events.
Why it matters: Partial batch failures are easy to miss in testing because they surface only under specific conditions — throttling, oversized payloads, transient network errors — that rarely appear in low-volume dev environments. Always inspect the Failed collection, log the Code and Message for each failure, and retry only the failed entries (not the whole batch) to avoid duplicates for the entries that succeeded.
var response = await snsClient.PublishBatchAsync(request);
foreach (var failure in response.Failed)
{
_logger.LogError(
"SNS publish failed for message {Id}: [{Code}] {Message}",
failure.Id, failure.Code, failure.Message);
if (failure.SenderFault == false) // Throttling/server error — retryable
{
retryQueue.Add(batchEntries.First(e => e.Id == failure.Id));
}
// SenderFault == true means the message itself is invalid — do not retry
}
Use Message Group IDs and Deduplication IDs for FIFO Topics
What it is: FIFO topics require a MessageGroupId per publish — this defines the ordering stream, analogous to a partition key. All messages with the same group ID are delivered in order. A MessageDeduplicationId (explicit or content-based) prevents duplicate delivery within the 5-minute deduplication window.
Why it matters: A FIFO topic where every message uses the same group ID processes messages strictly serially — effectively one at a time. For a system tracking events by customer, using customerId as the group ID means each customer's events are ordered while events for different customers are processed in parallel. Use explicit MessageDeduplicationId values tied to a business key (not content hash) to avoid silently dropping two legitimate identical events within the same deduplication window.
await snsClient.PublishAsync(new PublishRequest
{
TopicArn = _fifoTopicArn,
Message = JsonSerializer.Serialize(envelope),
MessageGroupId = customerId,
MessageDeduplicationId = eventId // Unique business key, not content hash
});
Subscriptions
Use Subscription Filter Policies to Reduce Unnecessary Deliveries
What it is: A subscription filter policy is a JSON document attached to an SNS subscription that specifies which messages should be delivered to that subscriber. Messages that do not match the policy are silently dropped at the SNS layer — the subscriber is never invoked.
Why it matters: Without filter policies, every subscriber receives every message published to the topic, regardless of relevance. In a fan-out topology with 10 subscribers on a single topic, publishing 1 million events means 10 million delivery attempts — most of which result in Lambda functions that immediately discard the message after deserializing it. Filter policies eliminate this wasted work at the infrastructure level, reducing Lambda invocations, SQS delivery counts, and downstream processing costs.
MySubscription:
Type: AWS::SNS::Subscription
Properties:
TopicArn: !Ref MyTopic
Protocol: sqs
Endpoint: !GetAtt MyQueue.Arn
FilterPolicy:
EventType:
- OrderPlaced
- OrderCancelled
FilterPolicyScope: MessageAttributes # Filter on attributes, not body
A filter policy that matches all possible values of an attribute is equivalent to no filter — but it adds latency and complexity. Only attach a filter policy when you genuinely want a subset of messages.
Enable Raw Message Delivery for SQS Subscribers
What it is: By default, SNS wraps every message in an SNS envelope before delivering to SQS — adding metadata fields like MessageId, TopicArn, Timestamp, and UnsubscribeURL around your actual payload. With raw message delivery enabled, SNS delivers only your original message body, without wrapping.
Why it matters: The default SNS envelope forces every SQS consumer to unwrap the SNS structure before accessing the payload — adding boilerplate to every consumer and coupling them to the SNS delivery format. With raw message delivery, the consumer sees exactly what was published, making it easier to reuse consumer code across direct SQS sends and SNS-triggered deliveries.
MySubscription:
Type: AWS::SNS::Subscription
Properties:
TopicArn: !Ref MyTopic
Protocol: sqs
Endpoint: !GetAtt MyQueue.Arn
RawMessageDelivery: true # Consumer receives the original message body
Raw message delivery cannot be used with SNS subscription filter policies that filter on message body fields. If you enable both, filtering falls back to attribute-only matching. Use message attributes for filtering metadata (as covered in Message Design) and raw delivery works correctly.
What it is: An SNS subscription DLQ is an SQS queue that receives messages when SNS exhausts all delivery retry attempts to a subscriber. This is configured at the subscription level — not the topic level — because delivery failures are subscriber-specific (a healthy Lambda subscriber and a failing HTTP endpoint share the same topic, but only the HTTP endpoint's failures should land in a DLQ).
Why it matters: Without a subscription DLQ, messages that fail delivery after all retries are permanently and silently lost. SNS will retry HTTP/S endpoints for up to 23 days using exponential backoff, but SQS and Lambda subscribers have a much shorter retry window. A subscription DLQ captures those failures and gives you a chance to investigate and replay.
MySubscription:
Type: AWS::SNS::Subscription
Properties:
TopicArn: !Ref MyTopic
Protocol: sqs
Endpoint: !GetAtt MyQueue.Arn
RedrivePolicy:
deadLetterTargetArn: !GetAtt SubscriptionDLQ.Arn
SubscriptionDLQ:
Type: AWS::SQS::Queue
Properties:
QueueName: my-subscription-dlq
MessageRetentionPeriod: 1209600 # 14 days
SubscriptionDLQPolicy:
Type: AWS::SQS::QueuePolicy
Properties:
Queues:
- !Ref SubscriptionDLQ
PolicyDocument:
Statement:
- Effect: Allow
Principal:
Service: sns.amazonaws.com
Action: sqs:SendMessage
Resource: !GetAtt SubscriptionDLQ.Arn
Condition:
ArnEquals:
aws:SourceArn: !Ref MyTopic
The subscription DLQ is separate from any DLQ configured on the downstream SQS queue. The subscription DLQ captures SNS delivery failures; the queue's own DLQ captures consumer processing failures. Both are needed.
What it is: For HTTP/S subscriptions, SNS supports a customizable delivery retry policy that defines the number of retries, the backoff function (linear, exponential, or geometric), the minimum and maximum delay between retries, and a maximum total retry duration.
Why it matters: The default SNS retry policy for HTTP/S is 3 immediate retries, then 20 retries with 20-second delay, then 17 retries with linear backoff, then exponential backoff — up to 23 days total. For most production HTTP/S endpoints, this default is either too aggressive (overwhelming a recovering endpoint) or the 23-day retention is longer than your incident response window. Tune it to reflect the SLA of your endpoint.
{
"healthyRetryPolicy": {
"numRetries": 10,
"minDelayTarget": 20,
"maxDelayTarget": 300,
"numMinDelayRetries": 3,
"numMaxDelayRetries": 5,
"backoffFunction": "exponential"
},
"throttlePolicy": {
"maxReceivesPerSecond": 10
}
}
Prefer Fan-Out via SNS → SQS → Lambda Over Direct SNS → Lambda Subscriptions
What it is: In the SNS fan-out pattern, each subscriber is typically an SQS queue rather than a Lambda function directly. Lambda functions then consume messages from the queue asynchronously. This introduces a durable buffering layer between message delivery and message processing.
Why it matters: Direct SNS → Lambda subscriptions are operationally simple and work well for many lightweight workloads, but they tightly couple message delivery to Lambda availability and concurrency behavior. SNS invokes Lambda asynchronously and retries failed deliveries automatically, but retry behavior is finite and offers less operational control than a queue-based architecture.
The SNS → SQS → Lambda pattern provides stronger durability and backpressure handling. SQS can buffer messages for up to 14 days, absorb traffic spikes, smooth bursty workloads, and isolate publishers from downstream processing delays. It also enables operational features that direct SNS → Lambda subscriptions do not provide as cleanly, including:
Configurable visibility timeouts
Consumer-level DLQs
Controlled concurrency scaling
Batch processing
Replay and redrive workflows
Independent retry behavior per consumer
This pattern is especially valuable for business-critical event processing where message durability, replayability, and operational resilience matter more than minimal infrastructure complexity.
Direct SNS → Lambda subscriptions are still appropriate for simpler workloads, lightweight notifications, or low-criticality event flows where the operational overhead of introducing SQS is not justified.
Security
Apply Least-Privilege IAM Policies Per Role
What it is: IAM policies control which principals can publish to, subscribe to, or manage SNS topics. Publishers need sns:Publish. Subscribers need sns:Subscribe and sns:Unsubscribe. Administrative operations (sns:CreateTopic, sns:DeleteTopic, sns:SetTopicAttributes) should be reserved for infrastructure automation roles, never application runtime roles.
Why it matters: A Lambda publisher with sns:* on * can delete your topics, change encryption settings, or add unauthorized subscriptions. Scope each role to the exact actions and topic ARNs it requires at runtime.
PublisherRole:
Type: AWS::IAM::Role
Properties:
Policies:
- PolicyName: SNSPublisherPolicy
PolicyDocument:
Statement:
- Effect: Allow
Action:
- sns:Publish
Resource: !Ref MyTopic # Specific topic ARN, not *
Enable Server-Side Encryption (SSE)
What it is: SNS supports two SSE options: SSE-SNS (AWS-managed keys, no additional cost) and SSE-KMS (customer-managed CMK). SNS SSE encrypts messages at rest within SNS. Message delivery in transit uses TLS for supported protocols.
Why it matters: SNS topics often carry PII, financial events, or internal business data. SSE-SNS is free, zero-configuration, and satisfies most compliance baselines. Use SSE-KMS only when your compliance requirements demand customer-managed key control, key rotation auditability, or cross-account key sharing.
MyTopic:
Type: AWS::SNS::Topic
Properties:
TopicName: my-topic
KmsMasterKeyId: alias/aws/sns # SSE-SNS (free, AWS-managed)
# For SSE-KMS: KmsMasterKeyId: !Ref MyKMSKey
When using customer-managed KMS keys, ensure the SNS service principal and downstream consumers have the required KMS permissions (kms:Decrypt, kms:GenerateDataKey, etc.), or deliveries may fail.
Restrict Topic Access with a Resource-Based Policy
What it is: An SNS topic policy (resource-based policy) defines which AWS accounts, IAM principals, or services are allowed to publish to or subscribe to the topic — independently of the caller's IAM identity policy. It is the primary mechanism for cross-account access and for restricting which services can publish.
Why it matters: Without a restrictive topic policy, any principal in your AWS account with sns:Publish in their IAM identity policy can publish to your topic — including services and roles that were never intended to do so. Always scope the aws:SourceArn condition to the specific resource (e.g., a specific API Gateway, EventBridge rule, or Lambda function) that is authorized to publish.
MyTopicPolicy:
Type: AWS::SNS::TopicPolicy
Properties:
Topics:
- !Ref MyTopic
PolicyDocument:
Statement:
- Sid: AllowPublishFromOrderService
Effect: Allow
Principal:
AWS: !GetAtt OrderServiceRole.Arn
Action: sns:Publish
Resource: !Ref MyTopic
- Sid: DenyPublishFromOtherAccounts
Effect: Deny
Principal: "*"
Action: sns:Publish
Resource: !Ref MyTopic
Condition:
StringNotEquals:
aws:PrincipalAccount: !Ref AWS::AccountId
Use VPC Endpoints for SNS
What it is: An SNS VPC Interface Endpoint routes traffic between your VPC resources (EC2, ECS, Lambda in VPC) and SNS privately within the AWS network, without traversing the public internet or requiring a NAT Gateway.
Why it matters: Without a VPC endpoint, a VPC-attached Lambda or ECS task publishing to SNS must route through a NAT Gateway, incurring data processing charges. For a high-volume publisher, this can be significant. VPC endpoints also remove the requirement to allow outbound internet access for SNS traffic, reducing attack surface and simplifying security group rules.
Enable Data Protection Policies for PII
What it is: SNS Data Protection Policies allow you to define rules that audit, mask, or block messages containing sensitive data (PII, financial data, health information) based on managed or custom data identifiers. Data protection is configured at the topic level and applies to both inbound publishes and outbound deliveries.
Why it matters: In a fan-out topology, a single misconfigured publisher can leak PII to every subscriber — including HTTP endpoints, email addresses, and mobile push — without any subscriber being able to intercept it. Data protection policies act as a centralized control point: you can audit where PII flows, mask sensitive fields before delivery, or block publishes that contain unexpected sensitive data entirely.
MyTopic:
Type: AWS::SNS::Topic
Properties:
DataProtectionPolicy:
Name: PIIProtectionPolicy
Description: Audit and mask PII in transit
Version: "2021-06-01"
Statement:
- Sid: AuditPII
DataDirection: Inbound
Principal:
AWS: "*"
DataIdentifier:
- arn:aws:dataprotection::aws:data-identifier/EmailAddress
- arn:aws:dataprotection::aws:data-identifier/CreditCardNumber
Operation:
Audit:
FindingsDestination:
CloudWatchLogs:
LogGroup: !Ref PIIAuditLogGroup
Observability & Cost
Monitor the Right CloudWatch Metrics
What it is: SNS publishes several CloudWatch metrics out of the box. The most operationally important are:
| Metric |
What it tells you |
NumberOfNotificationsDelivered |
Successful delivery count per protocol |
NumberOfNotificationsFailed |
Failed deliveries after all retries — the critical one |
NumberOfNotificationsFilteredOut |
Messages dropped by subscription filter policies |
NumberOfNotificationsFilteredOut-InvalidAttributes |
Messages dropped due to malformed attributes — publisher bugs |
NumberOfNotificationsFilteredOut-NoMessageAttributes |
Messages dropped because no attributes were present |
PublishSize |
Message size distribution — alerts to unexpectedly large payloads |
SMSSuccessRate |
Delivery success rate for SMS subscriptions |
Why it matters: NumberOfNotificationsFailed is the single most important metric — it represents events permanently lost after SNS exhausted all retry attempts. This metric has no alarm by default. A spike in NumberOfNotificationsFilteredOut-InvalidAttributes indicates a publisher bug where message attributes are malformed, silently dropping messages for all subscribers with filter policies.
Enable Delivery Status Logging
What it is: SNS delivery status logging writes a CloudWatch Logs entry for every delivery attempt — successful or failed — for SQS, Lambda, HTTP/S, and other subscription protocols. It is configured per protocol at the topic level by specifying a success and failure sample rate and a CloudWatch Logs IAM role.
Why it matters: Without delivery status logging, you know SNS delivered N messages (from the metric) but you cannot determine which messages failed, why they failed, or when the failure occurred. Delivery status logs give you per-message visibility: the status, statusCode, responseBody, dwellTimeMs, and destination for every attempt. This is essential for diagnosing intermittent HTTP endpoint failures or Lambda throttling events.
Set the success sample rate to 5–10% and the failure sample rate to 100%. You want full visibility on failures without paying for logging every successful delivery at high throughput.
Set Alarms on Delivery Failures and Filtered-Out Messages
What it is: CloudWatch Alarms can trigger notifications (via another SNS topic, PagerDuty, Slack via EventBridge) when SNS delivery metrics breach thresholds. At minimum, alarm on NumberOfNotificationsFailed greater than 0 per protocol.
Why it matters: A delivery failure is a lost event. Unlike a queue with a DLQ, SNS delivery failures (for subscribers without a subscription DLQ) are permanent and unrecoverable. A zero-tolerance alarm fires the moment the first event is lost, rather than when a silent backlog has accumulated.
SNSDeliveryFailureAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: !Sub "${MyTopic}-SQS-DeliveryFailures"
MetricName: NumberOfNotificationsFailed
Namespace: AWS/SNS
Dimensions:
- Name: TopicName
Value: !GetAtt MyTopic.TopicName
Statistic: Sum
Period: 60
EvaluationPeriods: 1
Threshold: 0
ComparisonOperator: GreaterThanThreshold
TreatMissingData: notBreaching
AlarmActions:
- !Ref OpsAlertTopic
FilteredOutInvalidAttributesAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: !Sub "${MyTopic}-InvalidAttributesDropped"
MetricName: NumberOfNotificationsFilteredOut-InvalidAttributes
Namespace: AWS/SNS
Dimensions:
- Name: TopicName
Value: !GetAtt MyTopic.TopicName
Statistic: Sum
Period: 300
EvaluationPeriods: 1
Threshold: 0
ComparisonOperator: GreaterThanThreshold
TreatMissingData: notBreaching
AlarmActions:
- !Ref OpsAlertTopic
Tag Topics for Cost Allocation
What it is: AWS resource tags applied to SNS topics can be activated as Cost Allocation Tags in the Billing console, enabling AWS Cost Explorer to break down SNS spending by team, service, or environment.
Why it matters: In a shared account with dozens of topics, SNS costs appear as a single line item without tagging. High-volume topics — especially those driving SMS notifications or large-payload deliveries — can drive surprising costs. Tags make per-team or per-service SNS cost accountability possible and support chargeback models in platform teams.
MyTopic:
Type: AWS::SNS::Topic
Properties:
Tags:
- Key: Team
Value: order-service
- Key: Environment
Value: production
- Key: CostCenter
Value: platform-engineering
Operations
Define Topics and Subscriptions with Infrastructure as Code
What it is: SNS topics, subscriptions, topic policies, subscription filter policies, DLQ configurations, and alarms should all be defined in CloudFormation, SAM, CDK, or Terraform — not created manually through the console. Topic ARNs should be passed to publishing services as environment variables, never hardcoded.
Why it matters: Manually created topics accumulate configuration drift, have no change history, and cannot be reliably recreated after an accidental deletion. IaC also makes it trivial to enforce consistent settings (SSE, subscription DLQ, delivery logging, alarms) across all topics by using shared templates or constructs. A hardcoded topic ARN in a Lambda environment variable is a silent misconfiguration waiting to surface in a disaster recovery scenario.
Have a Cross-Account Subscription Strategy
What it is: SNS supports cross-account subscriptions, where a topic in Account A delivers to an SQS queue or Lambda in Account B. This requires both a topic policy in Account A (allowing the other account to subscribe) and a queue/Lambda resource policy in Account B (allowing SNS to deliver from Account A's topic).
Why it matters: Cross-account fan-out is a common pattern in platform/product account models, where a platform team owns the event bus (SNS topic) and product teams consume from it in their own accounts. Without correctly scoped policies on both sides, delivery fails silently — SNS reports the subscription as active, but delivery attempts fail with authorization errors that only appear in delivery status logs. Always lock down aws:SourceAccount and aws:SourceArn conditions on both sides.
# In the subscriber account — SQS queue policy allowing SNS from Account A
QueuePolicy:
Type: AWS::SQS::QueuePolicy
Properties:
Queues:
- !Ref SubscriberQueue
PolicyDocument:
Statement:
- Effect: Allow
Principal:
Service: sns.amazonaws.com
Action: sqs:SendMessage
Resource: !GetAtt SubscriberQueue.Arn
Condition:
ArnEquals:
aws:SourceArn: !Sub "arn:aws:sns:us-east-1:PUBLISHER_ACCOUNT_ID:my-topic"
Verify Subscription Confirmation for HTTP/S Endpoints
What it is: When an HTTP/S endpoint is subscribed to an SNS topic, SNS sends a SubscriptionConfirmation request to the endpoint URL containing a confirmation token. The endpoint must call ConfirmSubscription with that token within 3 days or the subscription is automatically deleted.
Why it matters: An HTTP/S subscription that is never confirmed is silently inactive — SNS will not deliver messages to it. In automated deployments, the confirmation step is easy to miss: the CloudFormation stack creates the subscription successfully (from the IaC perspective), but the endpoint never confirms, and SNS silently removes the subscription. Implement confirmation handling in every HTTP/S subscriber and add a SubscriptionConfirmed log entry at startup to detect missing confirmations early.
Quick Reference
Must = required for any production topic regardless of workload. Optional = strongly advisable but context-dependent.
| # |
Practice |
Priority |
When to apply |
| Topic Design |
|
|
|
| 1 |
Choose Standard vs FIFO intentionally |
Must |
Always — never default without considering ordering, throughput, and subscriber types |
| 2 |
Define topic granularity (per domain/aggregate, not God topic) |
Must |
All production architectures |
| 3 |
Plan for 256 KB limit — use claim-check for large payloads |
Must |
Any topic where payload size is variable |
| Message Design |
|
|
|
| 4 |
Use a consistent event envelope |
Optional |
Always — across all producers |
| 5 |
Include correlation IDs in every message |
Must |
Always |
| 6 |
Use message attributes for routing/filtering metadata |
Must |
Any topic with multiple subscribers that need different subsets |
| 7 |
Design for schema evolution |
Must |
All topics expected to outlive a single sprint |
| Publishers |
|
|
|
| 8 |
Use PublishBatch for high-volume publishers |
Must |
Always for high-volume producers |
| 9 |
Handle partial failures in batch publishes |
Must |
Any code that calls PublishBatch |
| 10 |
Use MessageGroupId and explicit MessageDeduplicationId for FIFO |
Must |
All FIFO topic publishers |
| Subscriptions |
|
|
|
| 11 |
Use subscription filter policies |
Must |
Any subscriber that cares about fewer than all events on the topic |
| 12 |
Enable raw message delivery for SQS subscribers |
Must |
All SQS and Lambda subscriptions |
| 13 |
Configure a DLQ for every subscription |
Must |
All subscriptions |
| 14 |
Configure delivery retry policy for HTTP/S endpoints |
Must |
All HTTP/S subscriptions |
| 15 |
Prefer SNS → SQS → Lambda over direct SNS → Lambda |
Must |
Any subscriber where durability matters |
| Security |
|
|
|
| 16 |
Apply least-privilege IAM per publisher/admin role |
Must |
Always |
| 17 |
Enable Server-Side Encryption (SSE-SNS or SSE-KMS) |
Must |
Always — SSE-SNS is free |
| 18 |
Restrict topic with resource-based policy |
Must |
Any topic in a multi-team or multi-account environment |
| 19 |
Use VPC endpoints for SNS |
Optional |
Any VPC-attached publisher calling SNS at high volume |
| 20 |
Enable Data Protection Policies for PII topics |
Must |
Any topic that may carry PII, PHI, or financial data |
| Observability & Cost |
|
|
|
| 21 |
Monitor NumberOfNotificationsFailed per protocol |
Must |
Always — at minimum this one metric |
| 22 |
Enable delivery status logging (100% failure, 5–10% success) |
Optional |
All production topics |
| 23 |
Set alarms on delivery failures and invalid attribute drops |
Must |
All production topics — alarm on failures > 0 |
| 24 |
Tag topics with cost allocation tags |
Must |
Any shared or multi-team AWS account |
| Operations |
|
|
|
| 25 |
Define topics and subscriptions in IaC |
Must |
Always |
| 26 |
Document cross-account subscription policy on both sides |
Optional |
Any cross-account fan-out topology |
| 27 |
Implement and verify HTTP/S subscription confirmation |
Must |
All HTTP/S subscriptions |
The current checklist is a starting point. Adapt it to your team's context, add items that reflect your specific compliance requirements or architectural patterns, and remove items that genuinely do not apply to your workload. The goal is not a perfect score — it is a shared, team-maintained definition of what a production-ready SNS topic looks like for your organization. Thanks, and happy coding.
