What is Amazon SNS?

A topic separates publishers from subscribers

Publishers address a topic rather than every consumer. Subscribers can be added or changed without modifying the producer, which makes SNS useful for fanout when several systems need the same notification.

Name a topic for a stable business fact or distribution purpose. If unrelated message types share one topic, permissions, filtering, schemas, ownership, and incident diagnosis become harder.

Use queues for durable independent fanout

A common pattern subscribes one SQS queue per consuming workload. Each consumer then has its own backlog, concurrency, retries, and dead-letter policy while SNS performs the initial fanout.

Direct Lambda or HTTP delivery can be useful when an additional queue is unnecessary, but compare the retry, buffering, availability, and backpressure behavior before choosing the shorter path.

Filter without hiding unclear contracts

Subscription filter policies can deliver only relevant messages based on attributes or payload fields. This reduces unnecessary invocations and lets consumers express interest independently.

Filtering is not a substitute for versioned event contracts. Producers must still document fields and meaning, and consumers need a plan for new event types, missing attributes, and schema evolution.

Plan endpoint-specific delivery behavior

Retries, dead-letter support, ordering, encryption, and failure visibility vary by endpoint and topic type. FIFO topics can preserve order and deduplication when paired with compatible subscribers; Standard topics emphasize broad, flexible fanout.

Monitor failed deliveries and test subscriber outages. Publishing successfully only confirms that SNS accepted the message, not that every downstream business action completed.