An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
Azure IoT Hub integration is the way device data is collected by IoT Hub and then pushed to other Azure services through endpoints and message routing.
At a high level, the flow is:
- Devices send telemetry and other messages to IoT Hub.
- IoT Hub receives the data on its device endpoints and the built-in Event Hubs–compatible endpoint.
- Message routing rules evaluate each incoming message.
- Based on those rules, IoT Hub forwards the message to one or more service endpoints (Storage, Event Hubs, Service Bus, Cosmos DB, etc.).
Core concepts:
- IoT Hub as central hub
- Acts as a bi-directional message hub between devices and the cloud.
- Once data reaches IoT Hub, it can be processed or routed to other Azure services for analytics, ML, and automation.
- IoT Hub does not store or process customer data outside the geography where the hub is deployed.
- Built-in endpoint
- Every IoT hub has a built-in Event Hubs–compatible endpoint (
messages/events). - This endpoint collects device-to-cloud messages by default and retains them for up to seven days.
- Standard Event Hubs SDKs can be used to read from this endpoint.
- When any custom route is created, data stops flowing to the built-in endpoint unless a route explicitly targets it. A fallback route to the built-in endpoint is enabled by default when the hub is created via portal or CLI.
- Every IoT hub has a built-in Event Hubs–compatible endpoint (
- Custom endpoints
- IoT Hub can link existing Azure services in the subscription as custom endpoints for message routing. Supported custom endpoints are:
- Storage containers (Azure Blob Storage, Azure Data Lake Storage Gen2)
- Event Hubs
- Service Bus queues
- Service Bus topics
- Cosmos DB
- These are service endpoints (sinks) for routes; devices cannot write directly to them.
- IoT Hub can link existing Azure services in the subscription as custom endpoints for message routing. Supported custom endpoints are:
- Message routing
- Message routing is the primary integration mechanism for device-to-cloud messages.
- Each incoming message is evaluated against routing queries.
- A message is delivered to all endpoints whose routing queries it matches.
- If a message does not match any route, it goes to the default endpoint (built-in Event Hubs–compatible endpoint), provided the fallback route is enabled.
- Routing can send telemetry and non-telemetry events (for example, device lifecycle or twin change events) to downstream services.
- For Storage endpoints, IoT Hub can write data in Avro (default) or JSON. JSON requires
contentType=application/jsonandcontentEncoding=UTF-8in message system properties.
- Integration targets and patterns
- Event Hubs / built-in endpoint:
- Used for high-throughput streaming and real-time processing pipelines.
- Downstream services such as Azure Stream Analytics, Databricks, or custom consumers read from Event Hubs.
- Azure Storage (Blob / Data Lake Storage Gen2):
- Used for long-term storage, archival, and batch analytics.
- IoT Hub writes messages as blobs in Avro or JSON format.
- Service Bus queues/topics:
- Used when device data needs to drive workflows or application-level messaging patterns.
- Cosmos DB:
- Used when device data must be stored in a NoSQL store for low-latency queries and scalable operational workloads.
- Event Hubs / built-in endpoint:
- Real-time vs batch integration
- Real-time processing:
- Use IoT Hub message routing to Event Hubs (or the built-in endpoint) and then connect real-time analytics or event processing services.
- Message routing maintains message order, which is important for some real-time scenarios.
- Batch / historical processing:
- Use message routing to Storage (Blob or ADLS Gen2) for cost-effective retention and later batch processing.
- Real-time processing:
- Event Grid integration
- In addition to message routing, IoT Hub integrates with Azure Event Grid.
- Event Grid is a publish-subscribe event routing service that can fan out IoT Hub events (telemetry and device events) to many subscribers, including Functions, Logic Apps, Storage, Service Bus queues, and webhooks.
- Event Grid is typically used when many different endpoints must react to IoT Hub events, or when integration with non-Azure systems via webhooks is required.
- Choosing between message routing and Event Grid
- Use message routing when:
- The primary need is to route device telemetry to Storage, Event Hubs, Service Bus, or Cosmos DB.
- Ordering of messages must be preserved.
- Querying on message properties, body, or device twin is needed directly in IoT Hub routing.
- Use Event Grid when:
- Many different endpoints (up to hundreds) must receive events.
- Integration with a wide variety of Azure services and external systems via webhooks is required.
- Telemetry and device lifecycle events are used to trigger event-driven workflows.
- Use message routing when:
- Multiple downstream services
- A single message can be routed to multiple endpoints simultaneously if it matches multiple routing queries.
- This enables patterns such as:
- Real-time analytics via Event Hubs.
- Long-term archival via Storage.
- Operational workflows via Service Bus or Cosmos DB.
Details such as retry behavior and latency characteristics for each downstream service are not described in the provided context.
References: