BUSted! A quick comparison of Azure Service Bus and Service Bus for Windows Server


A while ago I was asked to do a simple comparison between Service Bus for Windows Server (SBWS) and Azure Service Bus (ASB) so I thought I’d share this with you all.   Most of this stuff is probably obvious.  A more detailed comparison is available here and is well worth a read.

Installation and support

  • ASB: Since ASB is a cloud-based service there is no software to install and support is provided by Microsoft. OS and application patching and updating is also handled by Microsoft. Storage is provided by and managed by Microsoft. Backups and business continuity of ASB itself is managed by Microsoft.
  • SBWS: SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.

Message Relays

  • ASB: ASB’s relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.
  • SBWS: At the time of this writing SBWS did not support relayed messaging.


  • ASB: Solutions deployed in Azure using ASB can make use of Azure’s security token service known as ACS (Access Control Service). ACS is a cloud-based authentication and authorization service that integrates with standards-based identity providers such as enterprise Active Directory, and web identities like Windows Live ID, Google, Yahoo!, and Facebook.
  • SBWS: Solutions deployed on-premises using SBWS can make use of the Service Bus Security Token Service (SBSTS) which is fully integrated with the Windows security model. SBSTS can issue self-signed Simple Web Tokens (SWTs) using Windows identities.

Quotas/runtime settings

  • ASB: Options regarding message and queue sizes are fixed due to the multi-tenant nature of ASB.  ASB Queue/Topic sizes can be up to 5 GB.  Messages can be up to 256K.  See here for specifics on ASB quotas.
  • SBWS: SBWS provides much greater freedom for configuring runtime settings and message and queue sizes.   SBWS Queue/Topic sizes can be up to 10 GB.  Messages can be up to 50MB.    See here for specifics on SBWS quotas.

Network latency

  • ASB: Network and security latencies may impact performance, especially when moving messages from on-premises to cloud or cloud to on-premises. Throughput could also be impacted by unexpected spikes in unrelated internet traffic.
  • SBWS: Administrators have much more control over their own network’s traffic and routing, thereby enabling more efficient bandwidth usage and throughput.

Addressing schemas

  • ASB: ASB Namespaces are fixed – all endpoints have a Service Bus postfix added to the URL to ensure uniqueness.
  • SBWS: SBWS uses fully qualified domain names (FQDN) or a mapped DNS entry to represent service namespaces.


  • ASB: In ASB there is only one "instance" of the service available and it is managed by Microsoft.
  • SBWS: With SBWS it is possible to have several on-premises SBWS servers via self-hosted servers or third-party providers.