SNS Topics and Fan-Out Architecture

Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service. Publishers send messages to an SNS topic, and SNS immediately delivers those messages to all subscribers. Unlike SQS (pull-based), SNS is push-based—it delivers messages to subscribers as soon as they are published. This makes SNS ideal for broadcasting events to multiple downstream systems simultaneously.

Like SQS, SNS has two topic types: Standard topics offer best-effort message ordering, at-least-once delivery, and nearly unlimited throughput—they can deliver to SQS, Lambda, HTTP endpoints, email, SMS, and mobile push. FIFO topics guarantee strict ordering and exactly-once delivery to FIFO SQS subscribers only. FIFO topics support up to 3,000 messages per second with batching and are used when the order of events must be preserved across multiple subscribers.

SNS supports multiple protocol-based subscriber types:

• SQS: durable queuing (most common for async processing)
• Lambda: direct invocation (synchronous from SNS's perspective)
• HTTP/HTTPS: webhook delivery to external endpoints
• Email / Email-JSON: human notification
• SMS: text message delivery
• Mobile Push: FCM, APNs via platform applications
• Firehose: stream to S3 or Redshift via Kinesis Data Firehose

Fan-out is the core SNS pattern: publish one message to a topic and SNS simultaneously delivers it to all subscribers. For example, a new order event fans out to: an SQS queue for warehouse fulfilment, another SQS queue for inventory update, a Lambda function for fraud detection, and an email subscription for the ops team. Each subscriber processes the event independently with no coupling between them. This is far more scalable than a single consumer routing to multiple systems.

The recommended pattern combines SNS and SQS: publish to SNS, which fans out to multiple SQS queues. This provides:

• Durability: if a consumer is down, messages queue in SQS
• Independent scaling: each consumer processes at its own pace
• Decoupling: new consumers just subscribe to SNS without changing the publisher
• Retry resilience: SQS provides visibility timeout and DLQ

Direct Lambda subscribers lack the buffering that SQS provides, making SNS→SQS→Lambda the more resilient three-tier pattern.

When SNS fails to deliver to a subscriber (HTTP endpoint returns 5xx, Lambda throws, SQS is unavailable), it retries with an exponential backoff strategy. The retry policies differ by protocol: HTTP endpoints get up to 4 immediate retries plus exponential backoff over 23 days; Lambda and SQS get retries managed by their own retry mechanisms. Configure an SNS Topic DLQ to capture messages that exhaust all delivery retries, ensuring no events are silently lost.

Publish to SNS using the AWS SDK or CLI. Each message can include a Subject (for email), a Message body (up to 256 KB), and Message Attributes for routing. For different subscriber types (SQS vs email vs mobile), you can use Message Structure to send different content to each protocol—JSON with protocol-specific keys lets you tailor the payload per subscriber type.

Subscription filter policies let each subscriber receive only the messages relevant to it, based on message attributes. Without filtering, all subscribers receive all published messages. With a filter policy, a subscriber specifies which attribute values it cares about. For example, a 'PREMIUM' order queue subscribes with a filter {"orderType": ["PREMIUM"]}; a 'STANDARD' queue filters for ["STANDARD"]. Each subscriber handles only its relevant subset, reducing unnecessary processing.

SNS supports direct mobile push notifications to iOS (APNs) and Android (FCM/GCM) devices. You register device tokens as platform endpoint ARNs, then publish directly to an endpoint or to a topic with platform application subscribers. For large-scale direct-to-device notification (millions of devices), combine SNS with SQS fan-out: SNS routes the notification event to SQS, and a worker service handles bulk token resolution and delivery at scale.

Protect SNS messages with server-side encryption using AWS KMS. This encrypts messages at rest within SNS infrastructure. Access control uses both resource-based policies (who can publish to or subscribe from the topic) and IAM policies. To allow an S3 bucket to publish notifications to an SNS topic, grant sns:Publish to the S3 service principal in the topic's resource policy. Always restrict publishing to authorised sources to prevent unauthorised event injection.

SNS and SQS are complementary, not alternatives. SNS (push) is for broadcasting to multiple consumers immediately—use it when multiple systems must react to an event. SQS (pull) is for reliable, durable single-consumer processing with retry and DLQ—use it when one consumer must process each message exactly once at its own pace. The SNS→SQS fan-out pattern gives you both: broadcast delivery from SNS and durable, retriable processing from SQS. This combination appears frequently in SAA-C03 exam scenarios.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: SNS topics provide push-based pub/sub broadcasting to subscribers including SQS, Lambda, HTTP, SMS, and email simultaneously, fan-out architecture uses one SNS topic feeding multiple SQS queues to achieve durable, independently scalable multi-consumer event processing, and subscription filter policies reduce unnecessary processing by routing only relevant events to each subscriber based on message attributes. Next up we explore SQS message filtering and SNS + SQS integration in depth.