My company is using Azure IoT services so my question is more specific to azure IoT cloud services.

My project is about Azure sphere that sends data to Azure IoT hub and an Azure Event hub reads real time data and publishes data to the hub instances(topic), a 3rd party technology that develops dashboards, consumes the data that is produced by the event hub.

Let's assume I have 5 customer, and they have a requirement of IoT projects(I mean use cases here). Each use case is different and my project can handle their requirements. From an architecture's perspective I have to create a plan that can handle multitenant environment so that those 5 customer will see the same dashboard view but the data it contains will be of respective tenant.

Couple of things, I have thought is: Create individual IoT hub for individual tenant, and adjust units in them depending on the requirement of messages. Create a single event hub and adjust throughput units/partitions and create each hub instance(topic) for each tenant and use message route feature from IoT hub to route the message to each tenant's hub instance.

Is this a good solution, what difficulties will I face if I take the above approach?

What other architecture would you suggest for this scenario?

Like with single S3 tier IoT hub for all the tenant and same size of event hub(ofcourse adjust unit on requirements), but how could I filter the tenant specific data, so that each tenant will only see their data and not other tenant's data.


To get a complete multi-tenancy you will have to create a specific IoT Hub instance per customer which will give you a full separation between tenants. The downsides of this approach are:

  • Pricing - the smallest instance of IoT Hub can consume 400K of messages per a day, so you will pay for this overhead if you have small tenants that sends less messages.
  • DevOps - You will have to configure each time you deploy a new IoT Hub for a tenant the alerts, failover and monitor settings.
  • Provisioning complexity - Your Azure sphere devices will need to know to connect to different IoT Hubs bases on their tenant.

Other option is to use one IoT Hub and to use it's routing capabilities to route based on some tenant Id to the tenant's event hub. In this approach you are using a shared resource for all tenants but you are losing the data separation and tenants can affect other tenent data streams (If some tenant sends to much data it can reach to the IoT Hub limit and block other tenants).


You can use the Azure IoT Hub message routing service. Message routing enables sending telemetry data from your IoT devices to built-in Event Hub-compatible endpoints or custom endpoints such as blob storage, Service Bus Queues, Service Bus Topics, and Event Hubs. Pls check for more info (https://docs.microsoft.com/en-us/azure/iot-hub/tutorial-routing), and for help of routing queries (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-routing-query-syntax).

Thanks, Vivek Bahl


I have been building IoT solutions on Azure since before IoT hub and have done it in various different ways over the last few years. So this comes from experience of doing it different ways and learning from mistakes.

You don't say how many devices/messages there are per tenant, but I'll assume that it is more than hundreds of devices. My recommendation is to have a completely separate pipeline per tenant, from IoT hub all the way to storage . Then multi-tenancy becomes a deployment issue and not an architectural issue. The pro's of complete separation are many and the primary con of wasted resources (that could be shared in a multi-tenant environment) is negated by the use of functions and similar approaches. So ask yourself... if the processing cost (compute, storage) per message is the same in a single or multi-tenanted environment then where are the cost savings by going multi-tenanted?

In a server-less cloud world, the only time that multi-tenant makes sense is when the tenants are really small (tens of dollars per month) so deployment costs per tenant are excessive for the value of the tenant, and the base (idle) costs too high. If you are targeting five high-value customers, you don't have that problem. If you think that you have thousands of low-value customers then prove it first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.