Azure IoT Hub and Telemetry Ingestion

Azure IoT Hub is a managed cloud service that acts as a central message hub for bidirectional communication between IoT applications and the devices they manage. It is designed to securely connect, monitor, and manage billions of IoT devices. Before IoT Hub, developers had to build their own messaging infrastructure, handle device authentication, manage scaling, and ensure reliable message delivery. IoT Hub abstracts all that complexity.

The DP-900 exam focuses on IoT Hub's role in telemetry ingestion—the process of collecting data from devices. Telemetry is typically small, frequent messages (e.g., temperature readings every 10 seconds) sent from devices to the cloud. IoT Hub can ingest millions of such messages per second, scale automatically, and ensure at-least-once delivery.

IoT Hub uses a publish-subscribe pattern with device-specific endpoints. Each device has a unique identity and security key stored in the IoT Hub identity registry. When a device sends a message, it connects to its device-specific endpoint (e.g., /devices/{deviceId}/messages/events). The hub authenticates the device using either symmetric keys, X.509 certificates, or Azure Active Directory tokens.

Once authenticated, the message is placed into a per-device queue. IoT Hub supports multiple message routes: the default event hub-compatible endpoint, custom endpoints (like Azure Storage, Service Bus, Event Hubs), and fallback routes. Message routing is based on properties and body content, allowing you to send temperature alerts to a separate queue or store all telemetry in Blob Storage.

You can create an IoT Hub using Azure CLI:

az iot hub create --resource-group MyResourceGroup --name MyIoTHub --sku S1 --unit-count 1

To send a simulated device message:

az iot device simulate --device-id MyDevice --hub-name MyIoTHub --data "{\"temperature\":25}"

To view device telemetry:

az iot hub monitor-events --hub-name MyIoTHub --device-id MyDevice

IoT Hub is often the entry point for telemetry that flows into Azure data analytics services: - Azure Stream Analytics: Directly consumes from IoT Hub's built-in endpoint to run real-time queries. - Azure Blob Storage: Custom endpoint to archive raw telemetry for batch processing. - Azure Functions: Triggered by IoT Hub events to process messages serverlessly. - Azure Time Series Insights: Connects to IoT Hub for real-time visualization of telemetry streams. - Azure Event Grid: Can publish device lifecycle events (registered, deleted) to trigger workflows.

For the DP-900 exam, you need to know that IoT Hub is the preferred ingestion service for device telemetry because it offers device management and bidirectional communication, unlike Event Hubs which is more generic.

IoT Hub supports up to 10 custom endpoints in the standard tier. Routes can filter messages based on message properties (system or application) and body content using a routing query language similar to SQL. For example:

temperature > 30 AND humidity < 20

Messages that do not match any route are sent to the fallback route, which is disabled by default. If enabled, unmatched messages go to the built-in endpoint.

IoT Hub supports three authentication mechanisms: - Symmetric key: Shared access signature (SAS) tokens generated from device keys. - X.509 certificates: Self-signed or CA-signed certificates for per-device or group enrollment. - Azure AD integration: For service-level operations (not device-level).

DPS is a helper service that automates device registration to IoT Hub. It is not covered heavily in DP-900 but is often mentioned in the context of zero-touch provisioning.

If a message cannot be delivered to a custom endpoint (e.g., storage account is full), IoT Hub will retry up to 10 times, then move the message to a dead-letter queue. The dead-letter queue stores the original message and error details.

IoT Hub units determine throughput. Each unit of S1 allows 1.1 million messages/day, S2 allows 11 million messages/day. You can add multiple units to increase capacity. The free tier (F1) allows 8,000 messages/day but is not recommended for production.

A large enterprise manages 50,000 sensors across office buildings globally. Each sensor sends temperature and humidity readings every 5 minutes. They deploy Azure IoT Hub (S2 tier with 5 units) to ingest the 10,000 messages per second peak. They configure message routing to send all telemetry to Azure Blob Storage for archival, and a second route for temperature readings above 35°C to Azure Service Bus for immediate alerting. They use device twins to update sensor sampling intervals remotely. A common misconfiguration is forgetting to enable the fallback route, causing messages that don't match any route to be dropped silently. They also set up Azure Stream Analytics to process the telemetry from the built-in endpoint for real-time dashboards.

A factory uses 10,000 IoT-enabled machines that send vibration, temperature, and pressure data every second. They need low-latency ingestion and reliable delivery. They choose IoT Hub over Event Hubs because they need bidirectional communication (to send firmware updates) and device management. They use DPS for zero-touch provisioning of new machines. They route telemetry to Azure Event Hubs for high-throughput stream processing with Azure Databricks. They also route failed messages to a dead-letter queue in Azure Storage for analysis. Performance consideration: they ensure the IoT Hub partition count matches the Event Hubs partition count to avoid throttling.

A logistics company tracks 100,000 vehicles with GPS devices sending location every 30 seconds. They need to store all telemetry for 7 days for compliance. They use IoT Hub with message routing to Azure Blob Storage, setting the retention policy to 7 days. They also route high-priority messages (e.g., 'engine fault') to Azure Service Bus Topics for dispatch. They monitor message delivery metrics and set alerts for high latency. A common issue is message size: GPS data with additional sensor readings can exceed 256 KB, so they implement file upload for large payloads. They also use device twins to update GPS reporting intervals based on vehicle status.