Enforce tag usage on Azure resources using Tag policies

How do you find out for which project or environment a certain Azure resource was created?

How do you find out which team is responsible for the costs related to a resource or resource group?

These are just some of the questions that can be answered easily using the support of tags on Azure resources.

Azure supports adding tags to resources. These can be added when the resource is created. These can also be added or updated at a later moment:

Tags are just key-value pairs giving more context to your resources. You can describe eg. the project it is used for, the creation date, the owner, the customer, the environment.

You can just add any key-value pair you have in mind.

Once added, the tags are shown in the portal:

Tags can then be selected while filtering Azure costs, as seen in the portal:

Now, you have a better understanding of the context of this resource group.

Unfortunately, adding tags is optional by default. And in the portal, these must be added by hand at first. Therefore, these are not always added by users or entered wrong just because the purpose is not yet clear to them.

Luckily, Azure offers policies to enforce adding tags.

This way, it’s not optional anymore. And, tags can be inherited too.

Let’s see how this is done.

Doorgaan met het lezen van “Enforce tag usage on Azure resources using Tag policies”

Message enrichment for Azure IoT Edge modules

The Azure IoT Hub offers ingestion of D2C and D2C messages for thousands or more devices.

Incoming messages are routed to several endpoints (eg. Event Hub or Blob Storage) using internal IoT Hub routes:

Note: even messages sent to the Event Grid are also enriched.

The messages produced by devices look like these (image taken from the console output of the Microsoft temperature simulation):

Here, messages from the Microsoft temperature simulation module are sent to the cloud.

When these messages arrive in the IoT Hub, the fulll message format looks like this:

{
  "body": {
    "machine": {
      "temperature": 73.05171716227275,
      "pressure": 6.929942461524743
    },
    "ambient": {
      "temperature": 20.795734739068774,
      "humidity": 26
    },
    "timeCreated": "2021-05-10T11:51:42.1835163Z"
  },
  "enqueuedTime": "Mon May 10 2021 13:51:42 GMT+0200 (Central European Summer Time)",
  "properties": {
    "sequenceNumber": "101",
    "batchId": "7f3f847f-c20c-49aa-af17-a22db31f244f"
  },
  "systemProperties": {
    "iothub-connection-device-id": "simulation",
    "iothub-connection-module-id": "sim",
    "iothub-connection-auth-method": "{\"scope\":\"module\",\"type\":\"sas\",\"issuer\":\"iothub\",\"acceptingIpFilterRule\":null}",
    "iothub-connection-auth-generation-id": "637540164221770949",
    "iothub-enqueuedtime": 1620647502173,
    "iothub-message-source": "Telemetry",
    "x-opt-sequence-number": 13975,
    "x-opt-offset": "12885042704",
    "x-opt-enqueued-time": 1620647502314
  }
}

As you can see, the messages are build up in three parts:

  1. The actual message body, generated by (your) logic in the device. This part could be encoded so only the receiver knows how to handle this. Normally this is a JSON message format, though.
  2. (Application) properties, message enrichment on the device to provide context about the messages. This acts as a property bag, also added by the developer. The values are directly accessible for routing purposes.
  3. System properties, added by the IoT Hub. This gives technical context about the incoming message from the perspective of the IoT Hub

So users can choose to add values in the body or to add values in the application properties.

Still, every byte put in the message sent by the device results in a longer transmit duration and extra costs (number of bytes communicated, potentially more message chunks handled by the IoT Hub).

So, values already found in the system properties (eg. the device name or module id) can be left out in the body. This results in a smaller message.

Microsoft also provides message enrichment on the IoT Hub. This can take away some of the pain too.

It also makes it possible to route messages further down the road in other Azure resources which receive these enriched messages.

Let’s check this out.

Doorgaan met het lezen van “Message enrichment for Azure IoT Edge modules”

IoT Edge group enrollments using symmetric keys

In my previous blog about using a VM as IoT Edge device, it became clear that this could be used for testing IoT Edge at scale.

Testing IoT Edge at scale means testing device enrollments using the Device Provisioning Service (DPS) and IoT Hub deployments at scale.

We will look at both situations. But before we check out a group enrollment, first we look at an individual enrollment, just for comparison.

We will use the recently announced IoT Edge support for symmetric keys in DPS.

Doorgaan met het lezen van “IoT Edge group enrollments using symmetric keys”

How to tag your IoT Hub Devices

Until now, device twin tags were a bit lame.

Yes, desired and reported properties were much more fun to play with.

But those of you who administer thousands of Azure IoT devices, you really appreciate tags. It’s the only way to control that large amount of devices without losing your head.

Why? Because you first query your devices and then execute jobs on these subsets.

And Microsoft is making use of this feature a lot. You will have to use tags if you want to execute IoT Edge deployments (still in preview) or if you want to use the recently added Automatic Device Management (even newer):

But how do you actually add or alter tags of devices? What tooling is Microsoft providing?

Let’s check out a number of ways to tag and start querying your devices.

Doorgaan met het lezen van “How to tag your IoT Hub Devices”