English | EN 
During the last few months I have completed a couple of posts about Azure IoT, and as the saying goes: ” no two without three “. So, here comes the third!
In this case, I’m going to talk about the benefits of using an Azure IoT Hub Device Provisioning Service (DPS).
As always, the first thing to do is create the service by assigning it to the resource group where we want to host it. We must also give it a name and define the Azure region where we want to locate it, which in our case is Western Europe.
Once provisioned, it is important to remember the end point and ID scope. They will be used later.
As a last screenshot, I will include the one in which we will link our newly created Azure IoT Hub DPS with the Azure IoT Hub previously created for the two previous entries. Why? Well, because, before continuing with configurations in Azure, I want to talk a little more in depth about the benefits of this service. To complete examples in future posts where through the creation of devices we will see how it works, and finally create our own subscription rules. With all this, we will have a complete image of the options that this way of working with IoT devices in Azure offers us.
So, let’s get down to business. What are the benefits of Azure IoT Hub DPS?
- Provisioning of IoT devices is done without manual intervention and at the same time.
- It is scalable, allowing the subscription of millions of devices.
- Allows linking with more than one Azure IoT Hub.
- It enables the possibility of customizing the hosting policy.
- It is not limited by the Azure region in which it is hosted, allowing devices to be provisioned between different Azure IoT Hubs located in different regions.
- You can also configure the permissions for reading, writing, …
- Regarding security, it encrypts data at rest using 256 bits AES and has multiple forms of authentication such as: symmetric keys, certificates (X.509), TPM
In short, by inserting the necessary code in your devices, you will be linking them with this service. Where through the accommodation policy, it will be decided automatically, which is the ideal Hub to connect to. Cool, right?
In future posts I will delve into visual examples to describe device hosting policies to finally complete an example.
