SNS pricing: what to model (publishes, deliveries, fan-out)

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Use this page when you need to decide what belongs inside the SNS bill model before you argue about optimization.

This guide is about bill boundaries: publishes, deliveries, fan-out and retry-driven SNS cost, and the adjacent downstream costs that should be tracked beside SNS rather than confused with it.

What to include in the model

• Publishes/month: how many messages you publish
• Deliveries/month: how many messages are delivered to endpoints
• Fan-out: average matched subscribers per publish (after filter policies)
• Protocol mix: different subscription protocols can have different effective rates
• Retry multiplier: delivery failures cause repeated attempts

Tool: AWS SNS cost calculator

Inside the SNS bill vs outside the SNS bill

• Inside the SNS bill: publish requests, delivery attempts, fan-out expansion, and retry-driven SNS usage during failure windows.
• Usually outside the SNS bill: downstream SQS, HTTP, logging, or application processing costs that happen after SNS has already delivered or attempted delivery.
• Why that boundary matters: teams often blame SNS for the whole notification workflow bill when the real multiplier sits in subscriber design or downstream systems.

Step 1: estimate publishes

• Split by topic: a few topics often dominate publishes.
• Separate prod vs non-prod (test topics can be noisy).
• Keep an “incident day” scenario if alerts are a big use case.

Step 2: estimate deliveries (fan-out is the multiplier)

A fast first-pass formula:

• Deliveries/month ≈ publishes/month × matched subscribers per publish
• Use matched subscribers, not “subscribers total” (filter policies reduce effective fan-out).

Workflow: estimate SNS deliveries

Step 3: add the retry/alert-storm scenarios

• Retry scenario: failing endpoints multiply delivery attempts.
• Alert storm scenario: incident triggers high-frequency publishes to high-fan-out topics.
• Downstream coupling: if SNS fans out to SQS/HTTP endpoints, failures can cascade and amplify retries.

Common pitfalls

• Modeling publishes and forgetting deliveries (fan-out is where cost grows).
• Using “subscribers per topic” instead of “matched subscribers per publish”.
• Ignoring retries and treating failures as “rare” (incidents can dominate monthly variance).
• Broadcasting large payloads to many subscribers instead of sending pointers (object links).
• Not separating non-prod traffic (test loops can create high publish/delivery volume).

How to validate after you deploy

• Compare publishes and deliveries from a representative week to your baseline model.
• Check delivery failure rate; if failures are non-trivial, expect higher effective deliveries.
• Validate fan-out after filters: are you delivering broadly when you intended narrow topics?

When this is not the right page

• If your main problem is turning publishes, matched subscribers, and retries into a defendable delivery model, go to Estimate SNS deliveries per month.
• If the delivery model is already believable and you now need production changes, go to SNS cost optimization.
• If the real question is whether downstream consumers or topic design are creating the cost, use the estimate workflow before treating SNS pricing as solved.

Worked estimate template (copy/paste)

• Publishes/month = Σ publishes by topic
• Matched fan-out = subscriptions × filter match rate
• Baseline deliveries = publishes × matched fan-out
• Peak deliveries = baseline deliveries × (1 + retry factor) during incident/busy hours
• Monthly cost = publishes priced + deliveries priced (use blended per-1M rates)

If you don’t know match rate or retry factor, model scenarios (e.g., 20%/50%/80% match; 0%/5%/20% retries) and validate later.

Related guides

Sources

• AWS SNS pricing
• Amazon SNS Developer Guide

Related guides

Related calculators

FAQ