Amazon SNS

What SNS is

SNS (Simple Notification Service) is managed publish/subscribe messaging. A publisher sends one message to a topic, and SNS pushes a copy to every subscriber — SQS queues, Lambda functions, HTTP(S) endpoints, email addresses, or phone numbers over SMS. The publisher never knows or cares who’s listening.

The point is fan-out: one event, say “order placed,” reaches several independent consumers at once — bill the customer, update inventory, send a receipt — without wiring each one to the source. Design Beaver models SNS as a regional, API-accessed service rather than something that sits inside a VPC subnet, and validates as you draw which services can subscribe and what each subscription needs to be correct.

When to use SNS (and when not to)

Reach for SNS when one message needs to reach multiple independent subscribers at once, when you want push delivery to Lambda or SQS instead of making consumers poll, or when you need to notify people by email or SMS as well as, or instead of, other systems.

Don’t reach for it for point-to-point work where a single consumer should process at its own pace and retry durably — send to an SQS queue directly. It’s also the wrong tool for rich event routing and filtering across many sources and targets, where EventBridge fits better. And remember that a bare SNS subscriber that’s down can drop deliveries — if messages must sit durably until pulled, put an SQS queue in the path to buffer them.

Variants: standard vs FIFO topics

The choice between a standard and a FIFO topic isn’t just about ordering — it changes which endpoints the topic can deliver to at all.

SNS pricing

You pay per request to publish, plus a delivery charge that depends on where each message goes — and the split that matters for architecture is that deliveries to SQS and Lambda have no per-message charge, while HTTP and email deliveries are billed per notification.

How SNS connects to other services

A topic on a canvas is just a box until you know what actually subscribes to it and what that subscription requires — the IAM policy, the direction, the FIFO-vs-standard match. Design Beaver models each of these edges, so it knows what SNS can deliver to and what makes that delivery correct.

• →SQS

  Fan-out: an SQS queue subscribes to the topic, so every published message is copied into the queue for a consumer to process on its own schedule — the canonical SNS + SQS durable fan-out pattern

• →Lambda

  A Lambda function subscribes to the topic and is invoked with each published message's payload — push-based processing with no polling

What SNS can’t connect to

Some edges look reasonable on a canvas but aren’t real AWS integrations — SNS is a messaging topic, not a database, storage bucket, or HTTP origin. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕SES

  SNS delivers its own email notifications directly; it does not hand off to SES. The real relationship runs the other way — SES publishes bounce/complaint/delivery events TO an SNS topic — so this is an SES -> SNS edge, not SNS -> SES.

• ✕S3

  S3 is not an SNS subscriber type — SNS can't deliver a message straight into a bucket. (S3 publishes event notifications TO SNS, which is the reverse direction.) To land a message in S3, subscribe a Lambda that writes it.

• ✕DynamoDB

  DynamoDB is not an SNS subscriber type — SNS can't write to a table directly. Subscribe a Lambda function that writes the item instead.

• ✕RDS

  SNS is a pub/sub messaging service, not a database client — it has no way to deliver a message into RDS. A subscribed consumer (Lambda or an app on EC2) would write to the database.

• ✕CloudFront

  SNS is not an HTTP content origin — CloudFront caches content from origins like S3 or ALB, never a messaging topic.

• ✕Route 53

  A topic has no DNS-addressable hostname a Route 53 record would point at — publishers reach it through the SNS API by topic ARN, not a domain name.

Anti-patterns Design Beaver catches

These are the SNS mistakes that pass a diagram review but bite under load — the ones the validation engine flags as you draw.

Gotchas that bite in production

• A direct subscriber that’s down can lose messages. SNS’s retry for direct HTTP and Lambda subscribers is limited. For anything you can’t afford to drop, subscribe an SQS queue to the topic so each consumer gets a durable buffer, retries, and a dead-letter queue.
• FIFO topics can’t email or HTTP. They only deliver to SQS, and to Lambda via an SQS subscription. If you need ordering and email or HTTP delivery, you’re combining two things that don’t combine — rethink the design.
• SNS is fan-out, not a queue. If only one consumer will ever handle each message, SNS is a hop with no benefit. Send to SQS directly.
• Subscribers get everything unless you filter. Without a subscription filter policy, every subscriber receives every message on the topic. Filter policies let consumers receive only what they care about — and cut delivery cost at the same time.

Further reading

• Official AWS documentation
• Why we built a validation engine