Amazon SNS Pricing: Why a Single Publish Can Bill as Four Charges

Amazon SNS looks straightforward on the pricing page: $0.50 per million publishes for Standard topics, $0.30 per million for FIFO. The bill is almost never that simple. SNS separates publishing from delivery, and the delivery side bills at a different per-protocol rate for each subscriber type — HTTP at $0.60 per million, email at $2 per hundred thousand, SMS at variable per-country rates that can exceed $0.50 per single message in long-tail countries. A topic fanning out one publish to four protocols generates four separate billable lines, before counting cross-region data transfer.

This post is the bill story. For SNS architecture patterns — fanout, filtering, retry semantics, and DLQ wiring — the event-driven async messaging guide covers the design side. For the queue side of SNS-to-SQS fanout, the SQS pricing post covers the receiving end.

The Two-Layer SNS Bill: Publish + Delivery

The biggest source of SNS bill surprises is forgetting that publish and delivery are billed separately. A single Publish call costs the per-million publish rate. Every subscriber that receives that publish then bills separately at the per-protocol delivery rate.

The Four-Charge Publish: A Worked Example

Consider an order-confirmation topic with four subscribers: SQS (for downstream processing), Lambda (for analytics), Email (for the customer), and Mobile Push (for the app notification). One publish, four deliveries:

• 1 publish × $0.50/M = base cost
• SQS delivery: free
• Lambda delivery: free
• Email delivery: $2/100K = $0.00002 per delivery
• Mobile push: $0.50/M = $0.0000005 per delivery

For 10M publishes/month with this fanout:

• Publish: $5
• SQS delivery: $0
• Lambda delivery: $0
• Email delivery: $200 (10M × $0.00002)
• Mobile push: $5

Email dominates the bill at 40× the publish rate. This is invisible if you only think about the publish line — and it gets dramatically worse with SMS.

The SMS Trap

SMS is the highest-variance line item in SNS. United States rates are reasonable (~$0.00645/SMS). International rates vary by country and carrier from ~$0.04 to over $0.50 per single message. A B2C app sending two-factor authentication SMS to 100K global users daily can produce a bill in the high four or low five figures per month depending on user geography.

The common patterns to mitigate:

1. Cap global rate per recipient. A user receiving five SMS in a minute is almost always a misconfiguration; rate-limit at the application layer.
2. Use Pinpoint or a dedicated SMS provider for high-volume SMS. Pinpoint offers carrier-grade routing, rate negotiation for high volumes, and dedicated short codes that reduce per-message rates. SNS is fine for low-volume operational alerts; it is rarely the right primitive for high-volume customer SMS.
3. Default to mobile push or email for app-installed users. Push at $0.50/M is roughly 13,000× cheaper than long-tail-country SMS for the same notification.
4. Set a monthly SMS spend limit per AWS account via the SNS SMS spend limit configuration. This is a hard cap; once hit, further SMS is dropped until the next month or you raise the limit.

HTTP Delivery and Retry Storms

HTTP and HTTPS delivery at $0.60/M is the most expensive non-user-facing protocol (Kinesis Firehose is more expensive but rarely used at this junction). The cost driver is rarely the happy-path delivery — it is retries against failing endpoints.

SNS retries failed HTTP deliveries with an exponential backoff that, by default, runs for 20 days. Every retry attempt is a billable delivery. A topic with an HTTP subscription pointed at a chronically failing endpoint can quietly generate tens of thousands of retry deliveries per day with no successful messages reaching the subscriber.

Message Filtering: Free but Mandatory at Scale

SNS message filtering lets a subscription declare a filter policy (a JSON expression over message attributes) so only matching publishes are delivered. The filter evaluation is free — but the publish still bills. The saving is on the delivery side.

For a topic with 100 subscribers where each publish is only relevant to one subscriber, no filtering means 100× delivery charges per publish. With filtering, only the matching subscriber receives the delivery. On high-fanout topics with mixed-interest subscribers, filtering routinely cuts the delivery bill by 90%+.

When to Use SNS vs Alternatives

A 30-Day SNS Bill Cleanup Plan

Week 1 — Audit SMS spend. Check the SNS SMS spend limit per account; set a sensible hard cap if not set. Identify topics sending SMS by reviewing NumberOfMessagesPublished by protocol per topic. Migrate any high-volume customer SMS to Pinpoint or a third-party provider.

Week 2 — Add filter policies. For each topic with multiple subscribers, audit whether subscribers receive all publishes or only relevant ones. Add filter policies where subscribers should only receive a subset. This is often a quick code/IaC change with significant delivery-cost saving.

Week 3 — Add DLQs for HTTP and Email subscriptions. For every HTTP and email subscription, configure a redrive policy targeting an SQS DLQ. Add CloudWatch alarms on NumberOfNotificationsFailed.

Week 4 — Cross-region pattern audit. Map every cross-region SNS-to-SQS pattern against the actual consumer footprint. Disable cross-region fanout to regions with no active consumers.

What This Post Doesn’t Cover

• Pinpoint pricing for high-volume customer messaging — Pinpoint has its own pricing model with per-event, per-endpoint, and per-channel charges; covered in a separate post.
• SES email vs SNS email — SES at $0.10/1K is dramatically cheaper than SNS email for marketing or transactional email at any volume; covered in the SES guides.
• CloudWatch Events to EventBridge migration — EventBridge is the modern replacement for CloudWatch Events; covered in the EventBridge pricing post.
• Mobile push delivery setup — APNS/FCM/ADM credential management is operational, not billing-relevant.

If You Only Do One Thing This Week

Set the SNS SMS monthly spend limit on every production account to a sensible cap. The default is unlimited, which combined with the high per-SMS rates in long-tail countries creates the single biggest risk of a runaway SNS bill. Run aws sns get-sms-attributes per account, then aws sns set-sms-attributes --attributes MonthlySpendLimit=<dollar-amount> to set the cap. Pair with a CloudWatch alarm on the SNS SMS spend metric and you have a hard ceiling that prevents the worst-case bill spike.

For the receiving end of SNS-to-SQS fanout patterns, the SQS pricing post covers the polling, FIFO, and chunking details that compound with the SNS publish line.