Premium Service Bus is the go-to recommendation when you need network isolation. Private endpoints, dedicated capacity, no noisy-neighbour concerns. For a single production namespace, that makes sense. But when you multiply it across four environments, the cost adds up fast.
We found a customer running Premium across DEV, TST, UAT, and PRD for a modest messaging workload. Total cost: roughly $2,400 per month. The workload in three of those environments was barely touching the capacity.
The Numbers
| SKU | Per Namespace/Month | 4 Environments/Month | Annual Cost |
|---|---|---|---|
| Premium | ~$600 | ~$2,400 | ~$28,800 |
| Standard | ~$15 | ~$60 | ~$720 |
| Saving | ~$2,340/month | ~$28,080/year |
The only reason they were on Premium was private endpoints. So we asked: is there another way to restrict network access on Standard?
What Standard Actually Supports
The documentation buries this. Standard SKU does support IP firewall rules. It does not support VNet service endpoints or private endpoints, but you can restrict access to a defined set of IP addresses with a default deny rule.
The critical gotcha: you cannot configure IP firewall rules for Standard SKU through the Azure portal. The portal only exposes the networking blade for Premium namespaces. For Standard, you need ARM templates, Azure CLI, or PowerShell. This trips up teams who check the portal, see no networking options, and assume Standard has no network controls at all.
How We Made It Work
In this environment, all VNet traffic already routed through a central Azure Firewall. Every spoke had a default route pointing to the firewall, so all outbound traffic left via the firewall's public IPs.
We configured Standard Service Bus with IP firewall rules allowing only the Azure Firewall egress IPs. Any request not originating from within the VNet topology gets rejected. The setup took minutes once we had the firewall IPs.
The traffic still traverses the public internet rather than the Microsoft backbone, so this is not identical to a private endpoint. But for the threat model in question (preventing unauthorised access from the internet), it was a pragmatic and effective control.
When You Genuinely Need Premium
Standard with IP firewall rules is not a universal answer.
You need Premium when:
- Compliance mandates private endpoints. If your governance framework explicitly requires PaaS services to use private endpoints with no public network access, Standard will not satisfy that control.
- High message throughput. If you are pushing more than 1,000 messages per second sustained, Premium's dedicated capacity becomes essential.
- Guaranteed message ordering at scale. Premium provides partitioned messaging with ordering guarantees that Standard cannot match under high concurrency.
- Resource isolation. If your workload is latency-sensitive and cannot tolerate the occasional performance variation of a shared tier.
For most development, testing, and moderate production workloads, Standard with IP firewall rules is a perfectly defensible choice.
Want us to review your Azure messaging costs? Our free assessment identifies savings like this across your entire environment.