Estimate SNS deliveries per month (messages x subscribers)

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

This page is the delivery-measurement workflow, not the bill-boundary page: the goal is to turn publishes, matched fan-out, and retries into a defendable delivery model.

If you still are not sure which costs and traffic belong inside the SNS bill, go back to the pricing guide first.

Delivery estimate inputs

• Publishes/month: per topic baseline volume.
• Matched fan-out: subscribers x match rate.
• Retry factor: failed deliveries multiply requests.

Step 1: estimate publishes per month

• Split by topic (a few topics usually dominate).
• Separate prod vs non-prod (test topics can create noise).
• Keep a peak scenario if alerts are a major use case.

Step 2: estimate matched fan-out (subscriptions that actually receive messages)

Use matched subscribers per publish, not "total subscriptions". If filter policies exist, only some subscriptions match each message.

• Matched fan-out = total subscriptions x match rate
• Example: 100 subscriptions with a 20% match rate -> 20 matched deliveries per publish

Step 3: compute baseline deliveries

• Deliveries/month ~ publishes/month x matched fan-out
• Do it per topic first; then sum across topics.

Step 4: add retry multiplier for failures (the hidden cost driver)

Delivery failures and slow endpoints can cause repeated attempts. The easiest way to model this is a multiplier:

• Effective deliveries ~ baseline deliveries x (1 + retry factor)
• Retry factor depends on endpoint reliability and your retry behavior.
• Keep an "incident week" scenario; it can dominate monthly variance.

Step 5: sanity-check with downstream signals

• SQS subscriptions: queue ingress volume can approximate deliveries.
• HTTP/S endpoints: request logs show delivery attempts (including retries).
• Email/SMS: treat as separate because operational behavior differs (deliverability and retries).

Worked example (structure)

• Publishes/month: 10M
• Subscriptions: 50
• Filter match rate: 40% -> matched fan-out = 20
• Baseline deliveries/month ~ 10M x 20 = 200M
• Incident retry factor: +10% -> 220M effective deliveries

Turn deliveries into cost

Use AWS SNS cost calculator with publishes/month, deliveries/month, and your effective per-1M pricing assumptions.

Validation checklist

• Validate publishes and deliveries from a representative week (and keep a separate incident sample).
• Confirm filter policies are actually reducing matched fan-out as intended.
• Track failure rate; if it's non-trivial, include retries in the model.
• Re-check after architecture changes (topic splits, new subscribers, new endpoints).

Evidence pack for a defendable SNS delivery model

• Publish source: where publishes per topic came from, including prod versus non-prod and incident windows.
• Matched fan-out source: how subscriber count, filter policies, and match rate were measured instead of guessed.
• Retry source: where failure rate and repeated delivery attempts were observed for each protocol.
• Open uncertainty: anything still modeled loosely, such as alert-storm intensity, endpoint reliability, or duplicated topics.

Related guides

What this page should hand off next

• Hand off to SNS pricing if your measurement work changes what you think belongs in the SNS bill versus the downstream system bill.
• Hand off to SNS cost optimization once the delivery model is stable enough to judge before and after changes.
• Do not move into optimization with only guessed match rate or guessed retry factor if the biggest topic is still unclear.

Sources

• AWS SNS pricing
• SNS monitoring with CloudWatch (metrics for validation)

Related guides

Related calculators

FAQ