Try for free Book a demo

Azure Event Hubs vs Service Bus

Microsoft Azure

11 Mins Read | Last modified on March 4th, 2024



Event Hubs and Service Bus – What’s the difference between the two messaging services? When should we use what? These are some of the common questions raised when the discussion is on Azure Messaging Services. So, this blog will help its readers not only find a solution to the above questions but also identify the strengths and unique capabilities of the two mentioned services. So, hang on tight as we are about to jump in!

Azure Event Hubs

Azure Event Hubs is a data streaming service that streamlines the data pipeline for the users allowing them to catch a better look at the insights received from various locations. It receives and processes millions of events per second with high throughput and low latency.  The basic definition for it is that it decouples multiple event-producers from event-receivers.

Azure Event Hubs

Event Hub is one of the messaging systems in Azure that provides a key capability of multiple sender/receiver concept. So, what it basically does which differentiates from other messaging systems is that it allows the “Senders” to pass a message with high throughput and streamlines it in the partitions which are available in the Event Hubs. It may have single or multiple consumer groups to receive those messages.

 Event Hubs also has the unique ability to ingest massive volume of data (1 million messages per second) in an unmatchable speed. It easily incorporates with other Azure Services like;

  • Stream Analytics
  • Power BI
  • Azure storage

Some common scenarios where Event Hubs can play a crucial role includes;

  • Logging and telemetry
  • Data archiving
  • Capturing and storing the data in Azure storage
  • Transaction processing

Azure Service Bus

Azure Service Bus acts as a messaging backbone for any application available in the cloud. So, what Service Bus basically does is that it connects any devices, application or services running in the cloud to any other applications or services and transfers data between them. The data being transferred can be in XML, JSON, or text format.

Service Bus Namespace – Can be referred to as the heart of the Service Bus. It serves as the application container and has the ability to hold multiples queues and topics. A namespace can be created using platforms like Azure portal and Service Bus Explorer.

Some of the common messaging scenarios where Service Bus is the need to implement are;

Messaging – Allows users to transfer business data

Decouple applications – Helps users improve reliability and scalability

Topics and subscriptions – Helps to build an end-to-end relationship between message senders (publishers) and message receivers (subscribers)

Azure Service Bus provides three forms of pricing tier which is the basic, standard and premium plan. Some of the differences between the cost models are;




Shared Capacity

Shared Capacity

Dedicated Capacity

Max Messaging Size: 256 KB

Max Messaging Size: 256 KB

Max Messaging Size: 1 MB

Queues: Supported

Queues: Supported

Queues: Supported

Topics: Not Supported

Topics: Supported

Topics: Supported

Messaging Operations: NA

Messaging Operations: 12.5M Ops/Month

Messaging Operations: Free

Variable Pricing

Variable Pricing

Fixed Pricing

Azure Service Bus Fundamentals

Azure Service Bus Relies on the following two concepts;

  • Queues
  • Topics


Queues work based on one-to-one communication model. It enables you to store messages until the receiver is available to receive and process them i.e. the message passed to the queue by the sender will be stored in it until the receiver comes online to collect and process it. So, each queue acts as a broker that stores the sent message until they are collected by the receiver (client).

Messages in queues are delivered in “pull” mode which means that the receiver must ask for the particular message they need. It also works based on the FIFO (First-In-First-Out) model enabling the receiver to pick the messages in the front of the queue.

Azure Service Bus Queue


Topics in Service Bus work as a one-to-many communication model. There will be multiple subscribers on the receiving side who can access the same message passed by the sender. One unique capability of Service Bus Topics is that it enables the subscribers at the receiving end to apply filters. The filter option enables the subscribers to subscription-based on a certain criterion enabling them to only receive the message they care about.

Azure Service Bus Topic

Topics vary from Queues in a way where the subscribers will be notified when a message of their interest arrives whereas the receiver from the queue will not be notified.

Azure Event Hubs vs Service Bus

Both the messaging systems have a unique architectural advantage and are built for certain purposes, let’s take a look at the significant difference in the internal working of the services and their real-time use cases.

Use Case

Azure Event Hubs focuses more on event streaming whereas Azure Service Bus is more focused on high-value enterprise messaging, which means the later is focused on messages rather than events.

If you are implementing a pattern which uses a Request/Reply message, then probably you should use Azure Service Bus.

Azure Event Hubs is more likely to be used if you’re implementing patterns with Event Messages. If you want a reliable event ingestor which can deal massive scale of event messages, then preferably you should go for Event Hubs.

Internal Working

Receiver Side

Let’s now consider, the aspect of how a receiver will receive the messages in both the messaging platforms.

In Event Hubs, the messages received from various event producers will be stored in a single stream from where the receivers can look but cannot remove it. Whereas, in Service Bus, the receivers can get their own copy of the message which means that it works based on the receive/delete model for collecting message.  

Messaging Concepts

In the messaging scenario, Service Bus provides many useful capabilities like Dead-lettered queues, property-based routing and more, but Event Hubs lacks all these features because it serves the sole purpose of allowing the event platform to handle the large volume of messages.

Time to Live and Retention

Service Bus messaging supports a message property ‘Time to Live’ which supports defining when a message can be moved to the dead letter queue by enabling dead lettering on expiry.

Event Hubs provides a slightly different capability, there is no specific time to live for an event but there is a retention policy on the hub. The default retention period is 7 days and can be extended if required.

Message session

Azure Service Bus has the concept of message session. It allows relating messages based on their session-id property. It supports achieving rich integration patterns.

Event Hubs do not have message session property, but events can be related by consolidating them in the same partition.

Message Replay

This is one of the unique capabilities of Event Hubs. Since the messages are not removed from the stream by the receiver. The messages in the stream can be processed by simply adjusting the index that the receiver points to.

This capability is not available in Azure Service Bus. Since the messages are pulled out by the receiver, the message cannot be processed again.

Poison Message

There is a chance for the generation of messages that cannot be processed. In Azure Service Bus, these messages can either be sent to dead lettered queue or abandoned.

In Event Hubs, you may handle these scenarios at the receiver side. But you can’t remove a corrupted message from the stream. It must be processed like every other message in the stream.


In Azure Service Bus messaging you can scale up the receivers of a message by using Competing consumer pattern.

In Event Hubs, you will need to increase the partitions and assign a single processor for each partition.


Event Hubs and Service Bus integrates with several Microsoft feature to do exciting things with the events/messages received. So, Event Hubs works along  with the following list of Azure services;

  • Azure SQL DB
  • Azure Storage
  • Stream analytics
  • Power BI
  • Machine learning

Whereas, Service Bus can integrate  with;

  • Azure Functions
  • Azure Logic Apps
  • Azure Event Grid
  • Stream Analytics
  • Dynamic 365


The Cost Model between both the Azure Services varies according to the pricing tier which the user chooses. There are three pricing tiers in both the Azure service. They are the Basic tier, Standard tier, and Premium/Dedicated tier. All the Pricing Models follows three basic rules;

  • No upfront cost
  • No termination fees
  • Pay only for what you use

So, the cost model for Event Hubs (in dollars) is as follows;





Ingress Events

$0.028 per million events

$0.028 per million events



$0.10 per hour


Throughput Unit (1 MB/s ingress, 2 MB/s ingress)

$0.015 per hour

$0.03 per hour

Billed per capacity unit

Extended retention


$0.28/GB/month (84 GB included per TU)

$0.12/GB/month (10 TB included per CU)

The cost model for Azure Service Bus can be classified for Messaging operations, Brokered connection, and Hybrid connections;

Messaging Operations




Operations: $0.05 per million operations

Basic Charge: $0.0135 per hour

Hourly: $0.928/hour


First 13M ops/month: Included



Next 87M ops (13M-100M)/month: $0.80 per million operations



Next 2400M ops (100M-2500M)/month: $0.50 per million operations



Over 2500M ops/month: $0.20 per million operations


Brokered Connections



First 1K/month: Included

Not Charged

Next 99K (1k-100k)/month: $0.03 per connection/month


Next 400k (100k-500k)/month: $0.025 per connection/month


Over 500k/month: $0.015 per connection/month


Hybrid Connections

Connection charges (includes 5 GB data/month)

$9.782 per listener

Data transfer coverage (data exceeding the included 5 GB/month)


Monitoring options for Azure Service Bus and Event Hubs

There are several monitoring options available on Azure Service Bus and Event Hubs in the Azure portal. To monitor an application composed of these services requires significant knowledge on the available monitoring options in the Azure. Or as an alternative, you buy an off the shelve product, Turbo360, to fulfill the monitoring requirements of the operations team.

Azure Monitor

  • Metrics
  • Alerts
  • Service Health


Metrics in Azure Monitor are stored in a time-series database which is optimized for analyzing time-stamped data. This makes metrics particularly suited for alerting and fast detection of issues. They can tell you how your system is performing but typically need to be combined with logs to identify the root cause of issues.

Azure Monitor Metrics


Metric alerts in Azure Monitor provide a way to get notified when one of your metrics cross a threshold. Metric alerts work on a range of multi-dimensional platform metrics, custom metrics, Application Insights standard, and custom metrics. 

Azure Monitor Alerts

Service Health

Azure Service Health is a suite of experiences that provide personalized guidance and support when issues in Azure services affect you. Azure Service Health can notify you, help you understand the effect of an issue, and keep you updated as the issue resolves. Azure Service Health also can help you prepare for planned maintenance and changes that could affect the availability of your resources.

Azure Monitor Service Health

Turbo360 offers extensive monitoring capabilities for Event Hub and Service Bus.

Turbo360 (Extensive off the shelf product)

In Turbo360, it is possible to monitor the performance, status, metrics and more for Azure Service Bus and Event Hubs with various types of monitors. For Event Hubs and Service Bus, Turbo360 offers three types of monitors;

  • Data Monitor
  • Threshold monitor
  • Status Monitor

Data Monitor

When there is a need to monitor the availability, performance, Incoming and outgoing requests, and connection state, the better solution would be data monitor. With the extensive set of metrics, it is possible to monitor the above needs and even more. This data monitor provides a historical record of alerts in a calendric view.

Turbo360 Data Monitor

Threshold monitor

When there is a need to monitor the entities when the message count gets increased certain limit or when the state of an Event Hubs will not be in an expected state, Threshold monitor would be a right solution. In this we can configure the violation persists time and number of alerts per violation. It can even be scheduled. It is also possible to monitor the Topic subscription for Service Bus as well as Partitions for Event Hubs.

Turbo360 Threshold Monitor

Status monitor

This status monitor can be used when there is a need to get a consolidated report in alert at defined intervals say every hour. This status monitor can monitor Service Bus and Event Hubs based on some basic properties and their state. Similar to the Threshold monitor it is also possible to monitor the Topic subscription for Service Bus as well as Partitions for Event Hubs.

Turbo360 Status Monitor

Wrap Up

Hope this blog provides a better understanding to the readers on the difference in capabilities of Azure Service Bus and Azure Event Hub. Both the messaging platforms of Azure discussed in this blog, Service Bus and Event Hub have specific business use cases in real-time business scenarios.

This article was originally published on Aug 5, 2019. It was most recently updated on Mar 4, 2024.

Related Articles