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 every environment, the cost adds up fast.
A common pattern: Premium running across all four environments (dev, test, UAT, production) for a modest messaging workload, at roughly $600 per namespace per month. The workload in the non-production environments is 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 |
Often the only reason for Premium is private endpoints. So the question is whether there's 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.
Making It Work on Standard
In a typical hub-spoke topology, all VNet traffic already routes through a central Azure Firewall. Every spoke has a default route pointing to the firewall, so all outbound traffic leaves via the firewall's public IPs.
You can configure 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 takes minutes once you have 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 that threat model (preventing unauthorised access from the internet), it's 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.