Tallan Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

Why Should You Use Azure IoT Suite Over Event Hub?

With the introduction of Azure IoT Suite and IoT Hub, Microsoft is making a serious play for the millions of devices and billions of messages that are already out there, or will be as the Internet of Things takes off. The future of IoT is very bright, but it is also extremely disorganized — security and proper design of device architecture is a major concern and liability, as can be seen in numerous recent hacks. The creation of IoT Hub is a strong play to better facilitate the communication methods with, security of, and administration for a large-scale IoT network.

IoT Suite is, at its core, a package of functionality built on top of the IoT Hub, which is similar to the Azure Event Hub platform that already exists. Azure Event Hub is a proven method of pushing large amounts of data from many devices, but on its own it provides only ingress/egress messaging, and none of the functionality that is required to maintain a secure, diverse network of IoT devices. IoT Suite assists by providing some of the following features:

  • Device registration
  • Protocol adaptation
  • Device administration
  • Scalability

Additionally, since IoT Hub behaves similarly to Event Hub, you have the same access to hot-path and cold-path event processing, such as to Azure Stream Analytics.

Now I’ll quickly break down some of the features and components of IOT Hub:

Bi-Directional Communications

The Azure IoT Hub supports both HTTP and AMQP out of the box. With these two technologies, any IP-capable field devices are able to communicate with the hub (if they don’t, a field gateway can also be used to facilitate communication). For many devices, however, HTTP/AMQP are not sufficient; Azure therefore provides the ability to provision and utilize specialized Cloud Protocol Gateways by deploying a specialized Cloud Service worker role.

As part of Microsoft’s newfound love of open source, they work with the Apache Proton team (Apache Qpid), among other technologies, to ensure that devices with stringent memory requirements running on C or other languages can use the Proton library to communicate with IoT Hub.

Device Provisioning and Management

Azure IoT suite also allows for powerful administration of devices. Maintaining device metadata is crucial, and Azure supports storing JSON metadata for each device, and updating it at will. IoT Suite is flexible enough to support devices using many different device service models, and allows for easy device provisioning and familiar definitions of access control policies. C2D and D2C (cloud-to-device and device-to-cloud) endpoints are provided to allow solutions to communicate with devices, and endpoints for the IoT Suite itself are exposed to perform administration tasks and device provisioning.

The vast array of functionality that Azure provides also aids in the complete administration of IoT devices: firmware updates can be downloaded by devices from a storage account or Azure CDN; access control can be administered through Azure Active Directory; error reporting and analysis can be done with the hot- and cold-path routes made available with technologies like Azure Stream Analytics and Azure HDInsight; and Azure provides SDK’s and quickstart template code for quickly prototyping and implementing various device administration tasks.

Device Identity Management and Security

Azure IoT hub maintains a device registry containing information about each device, including a deviceId, generationId, status, and other metadata. When a message is sent from a device to the cloud, the message is stamped with some of these properties to prevent spoofing. Refer to the developer guide for more information.

Secure transmission with HTTP and AMQP is supported, with a token in the auth header for HTTP messages, and SASL Plain or Claims-Based Security for AMQP.


It is important to keep in mind that IoT hub is built for massive scalability: while Event Hub is more constrained in terms of simultaneous device connectivity — each event hub can support only 5,000 simultaneous AMQP connections, for example — each IoT hub can scale up to a maximum of 2,000 “units”, for a total of one million simultaneous devices per hub. On top of that, there can be up to 10 IoT hubs per subscription. The potential is certainly there for Azure and IoT Hub to handle tremendous numbers of devices.


IoT Hub Pricing

IoT Hub Pricing, per unit (max 2,000)






Event Hub Pricing

Event Hub Pricing

Because of the different natures of the two platforms, pricing is naturally different. Event Hub is priced on ingress/egress, and is noticeably cheaper than IoT Hub, which is $25 for a single low-frequency IoT Hub unit (the number of hub units is specified when provisioning an IoT Hub, with the cost scaling up with per unit). The added cost of IoT Hub comes both from the large amount of additional functionality provided, the handling of D2C and C2D messaging, and from drastically increased scalability.


It is difficult to make an apples-to-apples comparison between IoT Suite/Hub and Azure Event Hub; in a sense, IoT Suite contains the majority of the functionality of Event Hub (except as regards device partitions as used in Event Hub), but it provides a large suite of complementary features, and orders of magnitude more simultaneous connections available.

Using IoT Suite is certainly not for everyone — in some cases, administration of IoT devices may be implemented by the device vendor already in different ways, or significant portions of IoT suite are simply not needed for a solution. But in the cases where a complete, robust, and scalable solution for provisioning, communicating with, updating, and administering large numbers of disparate devices is required — I know there are many, and there will be many more as the Internet of Things continues to take off — it would be tough to find a better complete end-to-end solution than Azure and IoT Hub.

Learn more about Tallan or see us in person at one of our many Events!

Share this post:

6 Comments. Leave new

could you please make an example when it is better to use Event Hub rather than IoT Hub? As it looks like Event Hub is loosing over all metrics apart from price.

Stephen Kimble
February 9, 2016 10:36 am

Good question. IoT Hubs are intended for large numbers of simultaneous connected devices, to a larger extent than event hubs. At its core, IoT Hub is built on a similar platform to event hub, but with numerous additional features. If you don’t need what IoT hub provides (additional protocol support, 1000’s more devices connected, a device registry, explicit bi-directional communication), there’s no need to use it.

Event hubs are intended for a pure publish-subscribe model; one example where I’ve used an Event Hub is having numerous separate computers reading information from numerous geographically separated databases. These computers (running a C# program and the Azure SDK) periodically published new rows from these far-flung databases into an Event Hub as a central collection point. From here multiple consumers (Stream Analytics, etc) collected the data. In this case I had a relatively small number of simple clients running HTTPS communications, so there was no need to use IoT Hub, but I still wanted the performance and easy connectivity to Stream Analytics that Event Hub provides.

John Billingsly
February 9, 2016 1:43 pm

Continuing the comparison, when would you use Service Bus vs. Event Hub?

Stephen Kimble
February 9, 2016 2:17 pm

For a while, I remember Event Hub technically belonging under the aegis of Service Bus, along with Queues and Topics. It is now under its own offering in the portal, under the category of IoT. The difference lies in pricing and how messages are consumed. A quick comparison of the three:

Event Hub: Intended for high throughput. Cheaper per message than Service Bus topics/queues. Allows for easy partitioning of consumers for horizontal scale. Can have multiple outputs for Event Hub that all receive messages (Stream Analytics, HDInsight, etc).

Service Bus Queue: Guaranteed first-in, first-out behavior. Doesn’t operate at same scale as Event Hub. each message is pulled off the queue by a consumer and isn’t given to other consumers of the Queue (can even peek at a message on the queue and lock it so others cannot access it).

Service Bus Topic: One-to-many messaging behavior, with Publish/Subscribe model. Can have multiple topics based on content type or other categorizations that can be separately subscribed to. Great for routing messages differently based on content, and having multiple subscribers receive them: business logic processing, push notifications, auditing, etc.

The differences are subtle, and it would be possible for any one of these to function in place of the others. The trick lies in choosing the best offering for your requirements, as an Event Hub or Service Bus Topic is not always the optimal solution. In the case of my example above, an Event Hub was chosen for a potentially high throughput of messages and desired output to Stream Analytics, which works best with Event Hub.

Great article

Great article. Kudos.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>