AWS SNS Cost Calculator

Separate publishes from deliveries before trusting the total

SNS estimates become misleading when teams model only publishes. The bill usually follows deliveries, and deliveries are shaped by topic fan-out, filter-policy match rates, protocol mix, and retry behavior.

• Count publishes and deliveries as separate drivers instead of assuming one publish equals one billable event.
• Estimate matched subscribers per topic after filtering, not just total subscriptions configured.
• Decide whether transfer matters for your path; if not, keep this as a publish-and-delivery estimate only.

Where SNS costs usually drift

• Fan-out growth: adding subscribers or broadening filter matches can multiply deliveries quickly.
• Retry bursts: failing HTTP endpoints and unstable consumers can inflate delivery attempts during incidents.
• Protocol mix: email, HTTP, Lambda, and queue endpoints do not all behave the same operationally.
• Downstream confusion: SQS, Lambda, logging, and endpoint-side processing costs do not belong in this page's total.

How to reconcile the estimate with production behavior

1. Compare estimated publishes and deliveries with topic metrics over a representative period.
2. Check whether a small number of topics are responsible for most fan-out or retry noise.
3. Review endpoint failures and redelivery behavior before changing the pricing assumptions.
4. Run a separate incident scenario when alerts, retries, or emergency fan-out make the peak month structurally different.

What to do if the bill is higher than expected

If deliveries dominate, inspect fan-out discipline, filter policies, and failing subscribers first. If transfer dominates, examine payload size and delivery path. If the SNS line item looks reasonable but the messaging program total does not, move next to SQS, Lambda, or endpoint-specific downstream costs.

Next steps