What Is Amazon SNS? Pub/Sub Messaging in Plain English

Amazon SNS is a broadcast service. You create a topic, publish one message to it, and SNS delivers a copy to everything subscribed — queues, functions, web endpoints, email addresses, phones. Use it when one event has to reach several places at once.

Now the part that catches nearly everyone, including people who have used it for years.

SNS does not store your message. If nothing is subscribed to that topic at the instant you publish, the message is delivered to nobody and then it is gone. Not queued. Not retried later. Gone — and the publish call returns success, because from SNS's point of view it did its job perfectly.

The name is genuinely misleading here. "Simple Notification Service" sounds like something that notifies people, and notification implies arrival. It is closer to a megaphone: it shouts once, and whoever is in the room hears it. SQS, which we covered last time, is the mailbox — it holds a message until somebody collects it.

If you have lost a message this way, you did not misconfigure anything. You used a service exactly as its name suggests, and the design is the surprise. The fix is one setting, and it is below.

The Alert Nobody Got

Jake's shop runs a small stock system that a friend built for him. When a phone model drops below two units, it publishes a message to an SNS topic, and Jake gets an email so he can reorder before he loses a sale.

It worked for months. Then he sold his last three units of a popular model over one weekend and no email arrived. He found out on Tuesday, from a customer who wanted one.

The obvious suspects were all innocent. The stock system had run. The publish had succeeded — it was there in the logs, a clean 200 response. The email address had not changed. Nothing had errored anywhere.

What had happened was that Jake's friend, tidying up the AWS console a fortnight earlier, had removed an email subscription that looked like a leftover from testing. The topic still existed. The publish still succeeded. There was simply nobody subscribed to receive it, and SNS considers that a completed job rather than a problem.

Ethan's summary, when Jake described it: "It's not that it failed quietly. It's that it succeeded, correctly, at delivering to nobody. Those aren't the same thing, and SNS is one of the few services where you have to hold that distinction in your head."

Two clicks fixed it permanently — an SQS queue subscribed to the topic, so a copy waits in a queue whatever else is or is not listening. But nobody would think to do that until they know the message is not being kept anywhere, and nothing in the name suggests it.

A Megaphone, Not a Mailbox

Three words carry the whole model.

A topic is the channel. You create one, give it a name, and it exists whether or not anybody uses it. A publisher sends a message to that topic and does not know or care who receives it. A subscriber registers to receive whatever arrives on the topic from that point on.

The publisher and subscriber never meet. That is the entire value: your stock system does not need to know that an email goes to Jake and a copy goes to an inventory queue and a third copy triggers a function. It publishes one message. SNS handles the rest, and you can add a fourth subscriber next year without touching the code that publishes.

	Megaphone (SNS)	Mailbox (SQS)
Who receives it	Everyone listening, all at once	One consumer, who then deletes it
If nobody is there	The message is gone	It waits, for up to 14 days
Direction	Push — SNS delivers to you	Pull — you ask for messages
Good for	Fanning one event out to many places	Work that must be done exactly once
Bad for	Anything you cannot afford to lose	Telling five different systems at once

Notice that the second row is the only one that ever hurts anybody. Everything else is a design choice you make deliberately. That row is the one you find out about by accident, usually on a Tuesday.

SNS or SQS? Almost Always Both

This is the most-asked question about either service, and it is slightly the wrong question. They are not competitors and choosing between them is rarely the right move. But if you genuinely need one alone:

SNS alone suits things where missing one is survivable and reach matters more than certainty. A deployment notification to a chat channel. A "your order shipped" text. An alarm that fires again in five minutes if the condition persists.

SQS alone suits work that must happen exactly once, where exactly one worker should pick up each item. Resizing an uploaded image. Charging a card. Generating an invoice.

Both together suits nearly everything else, and that is not a compromise — it is the pattern AWS expects you to use, and the next section is about it.

If you are new to this series, the SQS post covers queues properly, including visibility timeouts and why a message can be delivered twice. Reading the two together gives you most of what AWS messaging is.

The Fanout Pattern, Which Fixes the Problem Above

Publish to an SNS topic. Subscribe SQS queues to that topic. SNS copies the message into every queue, and each queue holds its own copy until its own worker gets to it.

You now have both properties at once: one publish reaches many systems, and each system's copy is stored safely until it is processed. If a worker is offline for an hour, its messages are waiting when it returns. If you add a fifth system next month, you subscribe another queue and change nothing else.

Concretely, an order arrives and gets published once. A billing queue holds a copy. A warehouse queue holds a copy. An analytics queue holds a copy. Jake's phone gets a text. The billing system can be down for maintenance and nothing is lost.

This pairing is worth understanding as the default rather than an advanced technique. Nearly every production AWS system that uses SNS uses it this way, precisely because SNS on its own keeps nothing.

Two practical notes. Give the SNS topic permission to write to each queue, which the console does for you if you subscribe from the SNS side. And turn on raw message delivery if you want the queue to receive your message as-is, rather than wrapped in an SNS envelope your code then has to unwrap.

What Can Listen to a Topic

Subscriber	Use it for	Worth knowing
SQS queue	Anything that must not be lost	The durability answer. Long retry policy.
Lambda function	Running code on an event	Invoked directly. Also gets a long retry policy.
HTTP / HTTPS	Webhooks into your own app	Retries are configurable and can run out. Attach a dead-letter queue.
Email	Alerting a human	Plain text. Recipient must confirm first. Not a mailing service.
SMS	Urgent alerts to a phone	No free tier. Priced per country. Charged for invalid numbers.
Mobile push	App notifications	SNS hands off to Apple or Google, who do the final delivery.

The third row deserves attention if you are wiring SNS into your own application. HTTP subscribers are the ones whose retries genuinely exhaust, and when they do the message is discarded silently. A dead-letter queue on that subscription costs nothing and turns a vanished message into one you can look at.

What It Actually Costs

SNS is cheap for what most people do with it, and the free tier covers a lot of learning. Prices below are from AWS's own pricing page and are worth re-checking before you build anything expensive, because AWS revises them.

What	Free each month	After that
Standard topic requests	1 million	$0.50 per million
FIFO topic requests	1 million	$0.60 per million
Mobile push deliveries	1 million	$0.50 per million
HTTP / HTTPS deliveries	100,000	$0.60 per million
Email deliveries	1,000	$2.00 per 100,000
SMS	Nothing	By country. Around $0.00645 per message to a US number.

Now the line that explains most surprised invoices. A request is not a message. Requests are billed in 64 KB chunks. A message at the 256 KB maximum therefore counts as four requests, not one.

So a million large messages bill as four million requests. If your invoice reads roughly four times what you expected and you have been counting messages, that is almost certainly the reason — and nothing has gone wrong with your account. It is simply that the unit being counted is not the unit you were thinking in, and AWS's own console reinforces the message-shaped mental model everywhere else.

Keeping payloads small is therefore a cost decision as well as a design one. If you are moving something large, put it in S3 and publish a pointer.

SMS Is Where the Money Goes

Everything else in SNS is priced in fractions of a cent per thousand. SMS is priced per message, per country, and it has no free allowance whatsoever.

At roughly $0.00645 to a US number, a thousand texts is about $6.45 — still small. Ten thousand a month is $64.50, and now it is the largest line on a small project's bill. Send to countries with higher carrier fees and the same volume costs considerably more.

The detail worth guarding against: you are charged for attempts to invalid numbers. A list with dead numbers in it costs real money delivering nothing. If you are texting a customer list, cleaning it is a cost-saving exercise and not just tidiness.

Before switching SMS on for anything at volume, set a Budget with an alert. Our post on AWS billing and Budgets covers that, including the uncomfortable fact that AWS has no spending cap that stops charges. An alert tells you; it does not stop anything.

Why SNS Email Is Not a Mailing List

SNS can send email, so people reasonably try to use it for customer email. It goes badly, and not because you have done anything wrong — it is simply built for a different job.

Every subscriber must click a confirmation link before anything reaches them, which is unworkable for a customer list. The message is plain text with no branding and no HTML worth speaking of. There is an unsubscribe footer you do not control. And you get no deliverability tooling — no bounce handling, no complaint tracking, none of the machinery that keeps mail out of spam folders.

SNS email is built for one thing: telling a small number of people, usually you, that something happened. An alarm fired. A budget threshold was crossed. A deployment finished. For that it is excellent and free for the first thousand a month.

For anything a customer reads, Amazon SES is the service designed for it. Using the right one saves an afternoon of fighting the wrong one.

Making SNS Reliable

Three settings turn SNS from something that loses messages into something that does not. None is difficult and all three are easy to not know about.

1. Subscribe an SQS queue, even if a Lambda function is doing the actual work. The queue is your safety net and it costs almost nothing.
2. Attach a dead-letter queue to each subscription. This is a subscription setting, not a topic setting, so it has to be done per subscriber. Anything SNS gives up on lands there instead of vanishing.
3. Set the retry policy on HTTP subscribers rather than accepting the default. AWS endpoints retry generously; your own web endpoint does not, and its retries can run out during an outage of ordinary length.

Then check the topic has subscribers before you rely on it. Ethan's habit, which Jake now copies: "If a topic matters, put a queue on it that nothing reads. It costs nothing and it's proof. When somebody swears the message was never published, you go and look, and the argument's over in ten seconds."

Making Your First Topic

1. Open the SNS console and choose Topics, then Create topic. Pick Standard unless you know you need ordering.
2. Give it a name that says what it carries — stock-low-alerts beats topic1 when you meet it again in a year.
3. Create a subscription. Choose Email for a first test, enter your address, and create it.
4. Go and confirm the email. Nothing arrives until you click the link, and this is where most first attempts appear to fail.
5. Back in the console, choose Publish message, type anything, and send. It should arrive within seconds.
6. Now do the useful bit: create an SQS queue, subscribe it to the same topic, publish again, and look at the queue. Your message is sitting in it. That is the durability you just added.

Step 6 is worth doing even though the tutorial works without it, because seeing the message waiting in a queue is what makes the megaphone-and-mailbox distinction stick.

Keep an eye on permissions as you go — a topic that a service cannot write to fails in ways that look like the service being broken. Our IAM post covers the permission model if that part is new.

If You Are Here for the Certification

SNS turns up in the Solutions Architect Associate and Developer Associate exams, and it is one of the more predictable topics on them, because the exam tests the same distinction this page is built around.

What gets asked: SNS versus SQS and when each fits; the fanout pattern as the answer to "notify several systems about one event"; the fact that SNS does not store messages; FIFO topics requiring FIFO queues; and dead-letter queues as the fix for undelivered messages.

What is worth doing rather than memorizing: build the fanout above, once, with two queues. Twenty minutes of clicking teaches the distinction better than any number of practice questions, and it stays with you afterwards.

Your Questions, Answered Straight

What is Amazon SNS in simple terms?

It is a broadcast service. You publish one message to a topic and SNS delivers a copy to everything subscribed to that topic at that moment — queues, functions, web endpoints, email addresses, phones. You publish once and SNS handles the copying and the sending, so the publisher never needs to know who is listening.

What happens to an SNS message if nothing is subscribed?

It is gone. SNS does not store messages, so publishing to a topic with no subscribers succeeds and delivers to nobody, and you are not told anything is wrong. The same applies if a subscriber is down and the retries run out. If you need the message kept until something processes it, subscribe an SQS queue to the topic.

What is the difference between SNS and SQS?

SNS pushes to many subscribers at once and keeps nothing. SQS holds messages in a queue until one consumer collects and deletes them. SNS is one-to-many and immediate; SQS is one-to-one and durable. Most real systems use both together rather than choosing between them.

What is the SNS to SQS fanout pattern?

You publish to an SNS topic and subscribe several SQS queues to it. SNS copies the message to every queue, and each queue holds its copy until its own worker processes it. You get the one-to-many reach of SNS and the durability and retry behavior of SQS, which is why this pairing is the standard building block rather than a clever trick.

How much does Amazon SNS cost?

Standard topics are free for the first 1 million requests a month, then $0.50 per million. FIFO topics are $0.60 per million after the same free million. Deliveries are priced separately by type: mobile push is free for the first million then $0.50 per million, HTTP/S is free for the first 100,000 then $0.60 per million, and email is free for the first 1,000 then $2.00 per 100,000.

Why is my SNS bill higher than my message count suggests?

Because requests are billed in 64 KB chunks rather than per message. A message at the 256 KB maximum counts as four requests, not one, so a million large messages bill as four million requests. Nothing is wrong with your account and you have not been overcharged — the unit is the chunk, and almost nobody realizes that until the invoice arrives.

Does SNS have a free tier for SMS?

No, and this is the part that surprises people most. SMS has no free allowance at all, prices vary by destination country, and a message to a US number costs around $0.00645. You are also charged for attempts to invalid numbers, so a bad phone list costs money even when nothing is delivered.

Can I use SNS to send emails to my customers?

You can send email through SNS, but you should not use it as a mailing service. SNS email is plain and unbranded, carries an unsubscribe link you do not control, and every recipient must confirm their subscription before anything reaches them. For transactional or marketing email, Amazon SES is the service built for that job.

What can subscribe to an SNS topic?

SQS queues, Lambda functions, HTTP and HTTPS endpoints, email addresses, SMS numbers, mobile push notifications, Kinesis Data Firehose, and AWS Event Fork Pipelines. A single topic can mix them, which is the point — one publish can wake a function, fill three queues and text somebody at the same time.

What is the maximum SNS message size?

256 KB for a standard message. If you need to move something larger, the usual pattern is to put the payload in S3 and publish only a pointer to it. Remember that a 256 KB message bills as four requests, so large messages cost more than their count implies.

When should I use a FIFO topic instead of a standard one?

When order matters and duplicates would cause harm — a sequence of account transactions, for instance. FIFO topics preserve ordering and remove duplicates, cost $0.60 per million requests rather than $0.50, and can only deliver to SQS FIFO queues. Standard topics are the right default for almost everything else.

Does SNS retry a failed delivery?

It depends on the subscriber type, and the retry behavior is far weaker than people assume. AWS endpoints such as SQS and Lambda get a long retry policy. HTTP and HTTPS endpoints get a configurable one that can be exhausted. Once retries are finished the message is discarded unless you have attached a dead-letter queue, which is the safety net worth adding.

What is a dead-letter queue in SNS?

It is an SQS queue attached to a subscription that catches messages SNS could not deliver after its retries. Without one, an undeliverable message simply disappears. Adding a dead-letter queue is the single cheapest thing you can do to stop silent message loss, and it is a subscription setting rather than a topic setting.

Is SNS the same as push notifications on a phone?

It can send them, but it is not itself the phone notification system. SNS hands your message to Apple's or Google's push service, which does the final delivery to the device. That means delivery to a handset depends on those platforms and their rules, not only on SNS, and troubleshooting sometimes lands there rather than in AWS.

How do I stop SNS costing more than I expect?

Set a Budget with an alert before you build anything, keep messages under 64 KB where you can, avoid SMS unless it is genuinely necessary, and check whether a subscriber is receiving messages nobody reads. The requests themselves are cheap; the costs that surprise people come from SMS and from large payloads billed in chunks.

Do I need SNS if I am just learning AWS?

It is worth an afternoon, because it appears everywhere else. CloudWatch alarms notify through SNS, Budgets alert through SNS, and countless tutorials assume you have a topic already. Learning it early means the rest of AWS stops referring to something you have not met.

Next in the Learn AWS Series

Next stop: Amazon CloudWatch — how AWS watches everything you have built, and why almost every alarm it raises reaches you through the SNS topic you just made.

A note on the numbers. Published August 22, 2026. Every price here comes from AWS's own pricing pages as they stood on that date, and AWS revises them — check the current figures before you build anything where the cost matters, particularly SMS, which varies by country and changes most often. If something on this page does not match what you see in your console, please write in and tell us, because that is how these stay accurate. And if you arrived here after a message went missing: nothing you configured was wrong. A service called Simple Notification Service that quietly discards notifications is a genuinely surprising thing, and everybody meets it the same way you did.