What Is Amazon Simple Notification Service? SNS, Queues and Email

TL;DR

• Amazon Simple Notification Service, or SNS, distributes a published message to subscribers. It is useful when several systems need to react to the same event.
• SNS, SQS and SES solve different problems: distribution, queued work and email delivery. An application can use all three in one notification workflow.
• Direct SNS email subscriptions suit internal alerts. A customer email usually needs a separate worker, template, recipient rules and email provider.
• Define duplicate handling, failure recovery and delivery evidence before launch. A successful publish response does not prove that someone received an email.

What is Amazon Simple Notification Service?

Amazon SNS is a managed publish/subscribe service. A producer publishes a message to a topic, and subscriptions determine where copies go. Supported destinations include Amazon SQS, Lambda, HTTP endpoints and email addresses. AWS describes this distribution to multiple subscribers as fanout. See the SNS introduction.

Consider an application that finishes building a customer report. Its report service could call the email service, audit service and billing service individually. That makes completion depend on three separate integrations. Alternatively, the service can emit a report-ready event and allow each interested system to react independently.

The important design question is what the event means. “Report 482 is ready” describes a business fact. “Send this HTML to this address” describes a delivery instruction. A business event is often easier for multiple consumers to reuse, provided each consumer has permission to access the referenced data.

SNS does not decide whether the report should be emailed, whether a recipient opted out of optional notices, or which language to use. Those decisions still belong to your application.

SNS vs SQS vs SES: choose the responsibility

The similar abbreviations can hide very different responsibilities. SQS is a queue service: applications send work to a queue and consumers receive and process it. Its standard queues can deliver a message more than once, so consumers need appropriate duplicate handling. See the SQS introduction.

SES is an email platform for sending and receiving email using your domains and addresses. It supports application email through an API or SMTP. See the SES introduction.

These are complementary choices. A small application with one email consumer may only need its existing job queue and email provider. Add fanout when independent consumers make it useful; do not add a topic merely because notifications are involved.

Can SNS send email directly?

Yes, but direct email subscriptions have limits that matter for customer communication. AWS states that message-body customization is unsupported and positions this feature for internal system alerts, rather than marketing messages. Direct email subscriptions use standard topics and require confirmation. Review the email subscription documentation.

An internal report saying “the nightly export failed” may be perfectly serviceable as an alert. A customer receipt may need branded HTML, accessible plain text, localization, an authenticated sender, a support link and a specific attachment policy. Treat that as an application email job.

Also distinguish a topic subscriber from your application's contact list. A mailing list or shared mailbox is not automatically a reliable model for individual notification preferences. Decide who owns the subscription and how a change affects the people relying on it.

For MailBlastr, the useful architectural boundary is the email-sending step. An application worker can call the selected provider after deciding what to send. This article does not claim that MailBlastr has a native SNS connector; verify the current sending interface in the product's documentation before implementing that connection.

A worked report-ready notification design

Imagine a fictional analytics app with three requirements: retain an audit record, update its dashboard, and email the report owner. An illustrative event might contain these fields:

{
  "eventId": "evt_report_482_ready_v1",
  "eventType": "report.ready",
  "schemaVersion": 1,
  "tenantId": "tenant_example",
  "reportId": "report_482",
  "occurredAt": "2026-09-14T08:00:00Z"
}

This is an original example, not a required SNS message schema. Avoid putting private report contents or email credentials into a broadly distributed event. The email worker should load the current report and recipient under the correct tenant authorization.

Use a durable application outbox if the event must follow a database change reliably. Save the completed report state and an outbox row in one database transaction. A dispatcher publishes the outbox event and records its outcome. A crash after publishing but before recording success can publish the event again, so the event identifier must remain stable on retry.

Give independent consumers separate queues when they need separate processing and recovery. The audit consumer should not compete with the email consumer for the same single work item. In the email consumer, create a notification record keyed by the business event, recipient and channel before attempting delivery.

Keep “notification requested,” “provider accepted” and “delivery outcome” as separate states. They answer different support questions. A provider may accept the message and later report a bounce; a customer may still not find a delivered message in the inbox.

Duplicate protection must include the send boundary

A unique database key prevents two workers from creating the same logical notification record. It does not, by itself, make the external send atomic with that record.

The awkward case is a timeout after the provider accepted the message. Blindly sending again could duplicate the email. Marking it delivered without evidence could lose the message. Where the provider supports idempotency, reuse the same key for retries of the same intended send and respect its documented retention window. Otherwise, retain the uncertain state and use the provider's lookup or reconciliation capabilities where available.

Do not hold a database transaction open while waiting on a slow network call. Use a claim with an expiry, record attempts separately, and define how another worker can recover an abandoned claim. Test two workers trying to claim the same notification, not just a single successful run.

If the report changes and the business requires a new email, decide whether that is a new event version or a new notification. Accidentally reusing the old identifier can suppress a legitimate update. Accidentally changing it on every retry can create duplicates.

Failure recovery needs two separate checks

First, can SNS deliver to the subscription? AWS applies protocol-specific retry policies. When those retries are exhausted, an attached subscription dead-letter queue can retain otherwise undeliverable messages. HTTP/S has configurable policies; other protocols have service-defined policies. See SNS delivery retries.

Second, can the application successfully process a message already placed on its work queue? A valid subscription does not prove that your email template renders or that the recipient lookup succeeds. Give the worker its own failure handling, retry budget and review process.

For the report example, classify failures before retrying:

• A short provider outage may justify a delayed retry.
• A missing template version needs a code or configuration fix.
• A deleted recipient may be a terminal business outcome.
• An invalid event schema needs investigation before replay.
• A timed-out send with an unknown provider outcome needs reconciliation.

An alert about a nonempty dead-letter queue is only useful if someone owns the investigation. Record the reason, affected event identifiers and corrective action before replaying a batch.

Validate the workflow before sending real notifications

Run an isolated fixture through each boundary. Publish one event and verify the intended subscribers receive it. Publish the same event twice and check the number of logical notification records and external sends. Stop a worker after claiming a job, then confirm another worker can recover it without an unbounded retry loop.

Next, remove a permission in the test environment and confirm the failure becomes visible. Restore it and follow the documented replay process. Submit an event for another tenant and prove it cannot expose that tenant's report. Finally, simulate a provider timeout after acceptance and inspect how the uncertain result appears to an operator.

This is a proposed acceptance exercise, not a claim that this sample has been deployed to AWS. Record actual results in your environment, including timing and permission configuration.

What should you measure and budget?

Measure event publication failures, queue age, worker retry counts, unresolved sends, dead-letter backlog and provider outcomes. An average queue age can conceal a small set of very old jobs, so include the oldest item and a count above your delivery target.

For budgeting, count both business events and fanout. In an illustrative month, 100,000 report events with three subscribers create up to 300,000 destination delivery attempts before retries. That arithmetic is a workload model, not an AWS price estimate. Requests, delivery protocols, payload sizes, queue operations and downstream processing can have different charges.

Start with the responsibility you actually need. Use SNS to distribute events, a queue to manage work, and an email service to deliver customer messages. Then make the state transitions observable enough that “we sent a notification” has a precise, supportable meaning.