Azure Service Bus pricing: estimate messaging cost from operations, retries, and payload
Messaging cost estimation is "count the events". The biggest mistakes are underestimating retries and ignoring fan-out (one publish to a topic can become many deliveries). This guide gives you a simple model you can refine with real telemetry.
0) Pick the right pricing model (what you actually pay for)
Service Bus deployments are typically priced based on capacity/tier and usage. Even if your plan is not purely per-message, the modeling workflow is the same: separate baseline (fixed capacity) from usage drivers (operations, connections, throughput).
- Baseline: fixed cost for the tier/capacity and "always-on" resources.
- Usage: message operations, deliveries, and throughput patterns.
1) Estimate message volume (per month)
Start from messages/second or messages/day and convert to monthly volume. If your system bursts (batch jobs, cron runs), model peak windows separately instead of averaging them away.
Tools: Rate to monthly volume, Request math.
- If you have multiple queues/topics, estimate each stream separately (one hot stream often dominates).
- Keep baseline and peak message volumes as two explicit scenarios.
2) Deliveries and retries (the hidden multiplier)
The true driver is often deliveries, not unique messages. Retries, redeliveries, and DLQ reprocessing can multiply the effective operation count.
- Retry multiplier: if the average message is delivered 1.3× due to retries, your effective volume is 1.3×.
- DLQ replay: a bad deploy can create a burst of replays (second spike).
- Timeouts: slow consumers cause lock/visibility timeouts and extra deliveries.
3) Fan-out (topics and subscriptions)
Fan-out is the most common reason teams underestimate cost. A single publish can become N deliveries if a topic has N subscriptions. Model fan-out explicitly.
- Effective deliveries ~= publishes × subscriptions × deliveries per subscription (including retries)
- Treat "broadcast" topics differently from point-to-point queues; their cost curves are different.
4) Payload size (when bytes matter)
Message size matters in two ways: (1) big payloads increase throughput and may affect tiering/capacity needs, and (2) big messages often imply downstream data transfer (e.g., consumers fetch an object from storage per message).
Tools: Transfer estimator, Egress cost, Units.
- If payloads are large, consider sending references (object keys) and fetching from storage (but then model storage + egress).
- Model peak payload behavior; one rare huge payload can dominate bytes.
Worked estimate template (copy/paste)
- Messages/month = baseline + peak
- Fan-out factor = avg subscriptions per publish stream
- Retry multiplier = 1 + retry_rate (apply to affected streams)
- Effective deliveries/month ~= messages/month × fan-out × retry multiplier
- GB/month (if relevant) ~= effective deliveries × avg payload bytes ÷ 1e9
Common pitfalls
- Modeling messages but forgetting retries/timeouts (deliveries are the bill driver).
- Ignoring fan-out: one publish becomes many deliveries.
- DLQ replay spikes after a bad deploy (second peak).
- Assuming payloads are always small without sampling real messages.
- Over-optimizing too early: first find the dominant stream and fix that one.
How to validate
- Validate incoming/outgoing message counts over a representative week (baseline + peak).
- Validate retries and lock/timeout behavior during incident windows.
- Validate subscription counts and topic fan-out per stream.
- Sample payload sizes and estimate bytes; do not guess a single average across all streams.