Azure IoT Hub vs Event Hub: Architecture Comparison (2026)

Last updated: May 2026

Every Azure IoT project eventually runs into the same question: should I be sending data through IoT Hub or Event Hub? Pick the wrong one and you will spend weeks retro-fitting security controls, fighting missing features, or paying for a service whose capabilities you never use. The stakes are higher in 2026 because the Azure messaging landscape now includes Event Hub’s Kafka-compatible surface, Fabric Event Streams, and an expanded IoT Hub built-in endpoint — all of which blur the lines further.

The short answer is that IoT Hub is a superset of Event Hub for device-to-cloud scenarios. It adds a full device-management layer — per-device identity, device twins, direct methods, cloud-to-device messaging, and Device Provisioning Service — on top of an Event Hub-style ingestion engine under the hood. Event Hub, in contrast, is a pure high-throughput, append-only streaming bus with no concept of an individual device and no channel back to producers.

What this post covers: the architecture of each service, a side-by-side capability comparison, when to use each (and when to use both), the cost model differences, real trade-offs practitioners encounter, and a decision flowchart you can use today.

Context: Why Azure Has Two Seemingly Overlapping Services

Azure IoT Hub vs Event Hub is not an accident of product history — it reflects two genuinely different problems. Event Hub was introduced as a telemetry ingestion bus for large-scale event streaming: web click-streams, application logs, financial tick data. It was explicitly modelled on the Apache Kafka log architecture: ordered partitions, consumer groups maintaining independent offsets, and retention-based replay. The Azure Event Hubs documentation describes it as a “distributed streaming platform and event ingestion service” — the emphasis is on throughput and fan-out, not on who is sending.

IoT Hub emerged from a different requirement. Connecting millions of constrained, heterogeneous field devices — sensors, controllers, gateways — demands more than a publish endpoint. You need to know which specific physical device is talking to you, revoke access when a device is compromised, push firmware updates, and query device state without waiting for the device to phone home. None of that is in scope for a generic streaming bus. The Azure IoT Hub documentation describes IoT Hub as a “managed service hosted in the cloud that acts as a central message hub for communication between an IoT application and its attached devices” — bidirectionality and identity are first-class concepts.

The two services intersect because IoT Hub internally uses an Event Hub-compatible endpoint to expose device-to-cloud telemetry. You can read from that endpoint using any Event Hub SDK. This overlap is intentional, not a design flaw: IoT Hub acts as the trusted gateway and management plane, while Event Hub (or IoT Hub’s built-in Event Hub endpoint) handles high-throughput downstream fan-out to analytics pipelines.

To understand the full breadth of Azure’s messaging options — including how Event Hub fits alongside Service Bus for queuing workloads — see our Azure Service Bus vs Event Hub specifications guide.

The Core Architectural Split: Superset vs Firehose

IoT Hub is not “Event Hub with extra features bolted on.” The two services have fundamentally different identities, and understanding that distinction is the most important thing you can take away from this comparison.

Figure 1: IoT Hub provides a bidirectional management plane on top of an Event Hub-style ingestion core. Event Hub provides the ingestion bus only, with no concept of individual device identity.

IoT Hub: Bidirectional, Identity-Aware, Management-Heavy

IoT Hub knows about individual devices. Every device that connects has an entry in the Identity Registry — a per-device record that stores credentials, current connection state, and twin metadata. This registry is what makes IoT Hub fundamentally different from any generic streaming endpoint.

Protocol support. IoT Hub speaks MQTT (3.1.1 and, in preview, MQTT 5), AMQP, and HTTPS. Each of these carries per-device authentication — either a Shared Access Signature derived from a device-specific key, or an X.509 client certificate. There is no shared connection string that any device can reuse. This matters enormously in production: a compromised device can be disabled in the Identity Registry and its SAS key rotated without affecting any other device on the fleet.

Device twins. A device twin is a JSON document in IoT Hub that mirrors the state of a physical device. It has two halves: the desired properties (set by the backend — target firmware version, sampling interval, alert threshold) and the reported properties (set by the device — current firmware, current temperature, last error code). The twin is the source of truth for device configuration. You can query the fleet — “give me all devices where reported firmware version is less than 3.2” — without waiting for a device to send a telemetry message. This is a powerful pattern for fleet operations that Event Hub simply cannot replicate.

Direct methods. These are synchronous RPC calls from the backend to a connected device. You invoke a named method (say, reboot or calibrate_sensor) and get a response within a configurable timeout. Direct methods are the recommended approach for immediate, interactive commands. They are not fire-and-forget — if the device is offline, the call fails fast (rather than silently accumulating in a queue).

Cloud-to-device (C2D) messaging. For asynchronous commands to potentially-offline devices, IoT Hub provides a C2D message queue per device. Messages are held until the device reconnects and acknowledges them. C2D messages support a feedback mechanism: the backend can learn whether a message was completed, rejected, or expired. This is qualitatively different from anything available in Event Hub, which has no concept of a downstream recipient.

Device Provisioning Service (DPS). IoT Hub integrates with DPS for zero-touch provisioning. A brand-new device arriving at a customer site can self-register, receive its IoT Hub assignment, and start sending data — all without a human configuring it. DPS supports X.509 certificate chains, TPM attestation, and symmetric key enrollment groups.

Event Hub: One-Way, Partition-First, Protocol-Agnostic

Event Hub’s design optimizes for one thing: ingesting very large volumes of events from many producers and making them available to many independent consumer groups simultaneously. It is append-only and has no concept of talking back to a producer.

Partitions and consumer groups. Events are written to a configurable number of partitions. Each partition is an ordered, immutable log. Consumer groups — up to the namespace limit, typically in the low hundreds — each maintain their own read offset per partition, so a Stream Analytics job, an Azure Function, and a Databricks cluster can all consume the same stream independently and at their own pace.

AMQP and the Kafka protocol surface. Event Hub’s native protocol is AMQP 1.0. More significantly, the Premium and Dedicated tiers expose a Kafka-compatible endpoint on port 9093. Any application that speaks Kafka’s producer or consumer protocol can connect to Event Hub without code changes beyond updating the bootstrap server and credentials. This makes Event Hub a viable managed Kafka alternative for teams that already have Kafka-based pipelines and want to reduce operational overhead.

Capture. Event Hub Capture automatically writes raw event data to Azure Blob Storage or Azure Data Lake Storage Gen2 in Avro format on a configurable time-or-size window. This is the simplest possible cold-path archival — no pipeline code required.

Schema Registry. Event Hub namespaces include an integrated Schema Registry (Apache Avro and JSON Schema). Producers register a schema; consumers validate incoming events against it. This is a governance feature that IoT Hub’s built-in endpoint does not replicate.

Device Management and Security: Where IoT Hub Has No Competition

The device management gap between IoT Hub and Event Hub is not a matter of degree — Event Hub provides none of these capabilities. This section explains why that matters at scale.

Figure 3: IoT Hub’s device-facing feature set. Every arrow represents a communication channel or state-management capability that Event Hub does not offer.

Per-Device Identity and X.509 Authentication

In Event Hub, every producer uses a namespace-level Shared Access Policy. All producers share the same credential. If any producer’s key leaks, you must rotate the key for the entire namespace — and every other producer stops working until it gets the new key. In a fleet of 10,000 sensors, this is a catastrophic operational risk.

IoT Hub’s identity registry assigns each device its own credential. Revoking a single device is an API call that takes effect in seconds, with zero impact on other devices. X.509 device certificates further allow you to anchor trust to a hardware root (TPM, secure element) rather than a software key — essential for regulated industries such as medical devices, industrial control, and automotive.

Device Twin Pattern: Fleet Configuration Without Polling

A common IoT anti-pattern is “configuration pull” — devices periodically polling a REST endpoint for their settings. This creates traffic proportional to fleet size and makes it difficult to know which devices are actually running the desired configuration.

Device twins invert this model. The backend writes desired properties to the twin. IoT Hub delivers them to the device over the persistent MQTT or AMQP connection. The device applies the change and writes the result back as reported properties. The backend can then query: “how many devices have acknowledged firmware 4.1?” The answer is always current, without a single poll. For fleet sizes in the tens of thousands and beyond, this delta-sync model reduces both bandwidth and backend query load substantially.

Security Posture: Comparing the Attack Surface

Event Hub’s attack surface is namespace-scoped: compromise the connection string, and you can produce or consume any event in that namespace. IoT Hub’s attack surface is device-scoped by design. Additionally, IoT Hub enforces TLS 1.2+ on all connections, and the MQTT endpoint does not allow anonymous access. For deployments that must satisfy IEC 62443 (industrial cybersecurity), ISO 27001, or HIPAA, the per-device identity model is not optional — it is a compliance requirement.

Throughput, Partitioning, and the Cost Model

Event Hub Partitioning Model

Figure 2: Each partition in an Event Hub is an independent ordered log. Consumer groups read at their own pace, enabling multiple downstream services to consume the same stream without interfering.

Event Hub scales in two dimensions. The partition count — set at namespace creation and immutable in Standard tier, resizable in Premium and Dedicated — determines maximum parallelism. You cannot have more parallel consumers per consumer group than you have partitions. The throughput unit (Standard tier) or processing unit (Premium tier) governs aggregate ingress and egress bandwidth. Adding throughput units scales bandwidth linearly; it does not add partitions.

A common mistake is creating an Event Hub with too few partitions. Once data is flowing and you realize a Stream Analytics job is bottlenecked on a single partition, there is no way to add partitions in Standard tier without recreating the namespace — which means a migration. Size partitions generously at design time.

IoT Hub Tier and Unit Model

IoT Hub scales by tier (Free, Basic, Standard) and unit count. The Standard tier unlocks the full feature set — device twins, direct methods, device streams, message enrichment, IoT Edge support. The Basic tier is read-only from a cloud-to-device standpoint: it supports D2C telemetry but not C2D messages, device twins, or direct methods.

Each unit in a given tier provides a specific daily message quota and per-minute throttle. The per-minute throttle is what catches teams off guard: if a fleet of devices all attempt to reconnect simultaneously after a network outage, they can saturate the connection throttle even if the daily message quota is far from exhausted. Design device reconnect logic with exponential backoff and jitter to spread reconnect storms.

IoT Hub also exposes a built-in Event Hub-compatible endpoint (called messages/events). Messages that arrive at IoT Hub appear on this endpoint automatically — you do not pay Event Hub throughput units for this data path. If you need additional fan-out (multiple consumer groups beyond the built-in limit, Kafka protocol access, or Capture), you route messages from IoT Hub to a separate Event Hub namespace via message routing rules.

Cost Model Differences

The cost structures differ in ways that are not obvious at first glance.

Event Hub charges primarily for throughput units or processing units (hourly), ingress events (per million), and optionally Capture storage. The cost scales smoothly with ingress volume and retention period.

IoT Hub charges per unit per day, regardless of how many messages are sent (up to the quota). At low device counts this is efficient; at very high device counts with modest per-device message rates, you may find that IoT Hub’s per-unit pricing is more expensive per million messages than Event Hub would be for the same raw volume. However, this comparison omits the cost of the device-management infrastructure you would have to build yourself if you used Event Hub directly — and that engineering cost typically outweighs the per-message price delta.

The practical guidance: check current Azure pricing for both services, model your specific device count, message rate, and retention period, and then add a realistic estimate for the engineering work to replicate IoT Hub’s identity and management features. The total cost of ownership almost always favors IoT Hub for genuine IoT workloads.

The Combined Reference Architecture: Using Both Together

The most scalable Azure IoT architecture uses IoT Hub and Event Hub in complementary roles. IoT Hub owns the device-facing edge: authentication, provisioning, bidirectional communication, and fleet management. Event Hub owns the cloud-side fan-out: high-throughput streaming to multiple independent consumers.

Figure 4: Production-grade reference architecture. IoT Hub handles all device-facing concerns. Its built-in Event Hub endpoint feeds telemetry to stream analytics, serverless functions, and Fabric Event Streams for downstream processing.

In this pattern:

Devices connect to IoT Hub using MQTT with per-device X.509 certificates or SAS tokens.
IoT Hub validates device identity and routes inbound messages to the built-in Event Hub-compatible endpoint.
Stream Analytics, Azure Functions, or Fabric Event Streams consume from that endpoint via the Event Hub SDK or Kafka protocol.
IoT Hub message routing rules copy selected message types (alerts, high-priority telemetry) to a second Event Hub namespace, which in turn feeds a separate consumer group for near-real-time alerting.
Event Hub Capture writes raw telemetry to ADLS Gen2 for batch analytics in Synapse or Databricks.

The backend service retains full use of IoT Hub’s device-management features — querying twins, sending direct methods, pushing firmware — while the analytics pipeline never touches IoT Hub’s management plane directly. This separation of concerns is the key architectural principle: IoT Hub is the control plane for the device fleet; Event Hub is the data plane for event streaming.

For a deeper look at designing the cloud monitoring side of this architecture, see our cloud IoT device monitoring solutions architecture guide.

Decision Matrix: IoT Hub vs Event Hub

Use this matrix as a first-pass filter. Where both columns show support, the consideration is whether the added complexity and cost of IoT Hub is justified for your use case.

Capability	Azure IoT Hub	Azure Event Hub
Per-device identity and credential management	Yes (Identity Registry)	No — namespace-level only
MQTT protocol support	Yes (3.1.1, MQTT 5 preview)	No
AMQP 1.0	Yes	Yes
Kafka protocol compatibility	No (built-in endpoint is AMQP)	Yes (Premium/Dedicated)
HTTPS ingestion	Yes	Yes
Cloud-to-device messaging	Yes	No
Device twins	Yes	No
Direct methods (synchronous RPC)	Yes	No
Device Provisioning Service integration	Yes	No
X.509 / TPM attestation	Yes	No
Message routing and enrichment	Yes	Partial (Event Grid integration)
Consumer groups	Yes (built-in endpoint)	Yes
Event retention and replay	Yes (1–7 days built-in)	Yes (1 day to 90 days)
Capture to Blob/ADLS	Via routing	Yes (native)
Schema Registry	No	Yes
Kafka producer/consumer SDK compatible	No	Yes
Edge module management (IoT Edge)	Yes	No
OTA firmware updates	Yes (with Device Update for IoT Hub)	No
Message size limit	Up to 256 KB	Up to 1 MB (Standard), larger in Premium
Max devices / producers	Millions (with scaling)	Millions (with scaling)

Trade-offs, Gotchas, and What Goes Wrong

IoT Hub Throttling Is Quota-Plus-Rate

Most engineers read the daily message quota and stop there. IoT Hub also enforces per-minute and per-second rate limits on connection, authentication, twin reads, twin writes, and direct method calls — separately from the message quota. A fleet of 50,000 devices recovering from a 10-minute network outage will attempt to reconnect simultaneously. That reconnect storm can hit the connection-rate throttle and produce 429 ThrottlingException errors even though the daily quota has barely been touched. Always implement exponential backoff with jitter in device firmware. Always monitor ConnectedDeviceCount and the throttling metrics in Azure Monitor.

Event Hub Partition Count Is Immutable in Standard Tier

As noted above, Standard tier Event Hub partitions cannot be changed after namespace creation. If you start with 4 partitions and later need 16 for parallelism, you must migrate — create a new namespace, re-point producers, drain the old namespace. In Premium tier, partition scaling is supported. Size for 2–3x your expected peak parallelism at creation time.

IoT Hub Basic Tier Looks Attractive but Removes Half the Product

The Basic tier is meaningfully cheaper per unit. It supports D2C telemetry and is fine if all you need is a one-way telemetry pipe with per-device identity. But it removes C2D messages, device twins, direct methods, and IoT Edge support. Teams often start on Basic to save cost and then hit a wall six months later when a product requirement demands device twins. Upgrading from Basic to Standard requires recreating the hub — there is no in-place tier upgrade. Start on Standard unless you have a documented, hard budget constraint.

The Built-in Endpoint Has a Consumer Group Limit

IoT Hub’s built-in Event Hub endpoint supports a limited number of consumer groups (the current Azure documentation lists five consumer groups for most tiers, plus the default $Default group). If you have six independent consumers — Stream Analytics, Functions, a monitoring service, a data lake pipeline, a real-time dashboard, and a third-party integration — you will exceed the limit. The solution is to route telemetry from IoT Hub to a separate Event Hub namespace, which supports many more consumer groups. Plan for this at design time.

Event Hub Does Not Authenticate Devices — It Trusts the Network

If you point field devices directly at an Event Hub endpoint, you are relying on namespace-level SAS keys or managed identity for authentication. There is no way to say “only device serial number ABC-123 can publish on this connection.” If that key leaks from any device on the fleet, you have no way to know which device leaked it, and rotating the key disrupts all producers. For any deployment where devices leave a controlled environment — installed at customer sites, deployed in vehicles, embedded in consumer products — this is an unacceptable security model. Use IoT Hub.

Latency: Both Are Low, but IoT Hub Adds Management Overhead

For pure telemetry ingestion, Event Hub’s end-to-end latency from producer to consumer is very low — sub-second under normal conditions. IoT Hub adds per-message processing overhead for identity validation, twin synchronization, and routing evaluation. For most IoT telemetry workloads (sensor readings every few seconds) this is invisible. For high-frequency data streams (hundreds of messages per second per device), benchmark both and verify that IoT Hub’s processing overhead stays within your latency budget.

Practical Recommendations

Use IoT Hub when:
– You are connecting physical devices that leave your controlled environment.
– You need to send configuration or commands back to devices.
– Compliance requires per-device identity (IEC 62443, HIPAA, automotive/medical standards).
– You need device twins for fleet configuration management or zero-touch provisioning via DPS.
– You are deploying Azure IoT Edge modules to gateway devices.

Use Event Hub when:
– Producers are applications or services (not constrained IoT devices) running in your own infrastructure.
– You need Kafka protocol compatibility for an existing pipeline.
– Maximum throughput and lowest per-event cost are the primary requirements.
– You need the Schema Registry for Avro/JSON schema governance.
– Capture to ADLS with zero pipeline code is sufficient for your cold path.

Use both together when:
– IoT Hub handles the device-facing edge, and its built-in Event Hub endpoint feeds multiple downstream consumers.
– You need more than the built-in consumer group limit — route from IoT Hub to a dedicated Event Hub namespace.
– You want Kafka-protocol consumers to read IoT device telemetry — route to a Premium Event Hub namespace.

Quick checklist before committing to a service:
– [ ] Do any producers leave your network perimeter? → IoT Hub
– [ ] Do you need C2D, twins, or direct methods now or in the next 12 months? → Standard IoT Hub
– [ ] Is Kafka protocol compatibility required? → Event Hub (Premium/Dedicated)
– [ ] Are you over the built-in consumer group limit? → Route to a separate Event Hub namespace
– [ ] Did you model partition count at 2–3x expected peak parallelism? → Yes before creating
– [ ] Have you implemented device reconnect backoff? → Yes before fleet rollout

For guidance on protocol selection at the device level — MQTT vs AMQP vs HTTPS — see our IoT protocols comparison guide.

Decision Flowchart: Choosing IoT Hub vs Event Hub

Figure 5: Start at the top and follow the branches. Most IoT device workloads resolve to IoT Hub or the combined pattern. Pure application-to-application streaming resolves to Event Hub.

Integration With Stream Analytics, Functions, and Fabric

Both services integrate natively with Azure’s processing and analytics layer.

Azure Stream Analytics can use either an IoT Hub input (which reads from the built-in endpoint and exposes device metadata fields like IoTHub.ConnectionDeviceId in the query) or an Event Hub input. The IoT Hub input is preferred when you want to filter or enrich based on device identity or twin metadata in the query itself.

Azure Functions can be triggered by either service using the respective SDK bindings. The Event Hub trigger is partition-aware and handles checkpointing automatically. The IoT Hub trigger is an alias over the same Event Hub SDK, so it behaves identically for function triggers.

Microsoft Fabric Event Streams (formerly part of the Synapse Real-Time Analytics offering) supports both IoT Hub and Event Hub as native sources. For Fabric-first architectures, you can stream device telemetry from IoT Hub directly into a Fabric Eventstream, apply transformations, and land data in a KQL database or Lakehouse without managing intermediate infrastructure.

Apache Kafka workloads. Teams migrating from self-managed Kafka can use Event Hub’s Kafka-compatible endpoint as a drop-in replacement for the broker. IoT Hub’s built-in endpoint does not support Kafka protocol; you must route to an Event Hub namespace first if Kafka-speaking consumers need to read IoT Hub telemetry.

Frequently Asked Questions

Is Azure IoT Hub built on top of Event Hub?

IoT Hub uses an Event Hub-compatible storage and ingestion mechanism internally, which is why you can read device-to-cloud messages using the Event Hub SDK pointed at IoT Hub’s built-in endpoint. However, IoT Hub is not simply “Event Hub with a UI on top.” The identity registry, device twin store, direct method broker, C2D message queue, and DPS integration are entirely separate services that do not exist in Event Hub. Think of Event Hub as the ingestion substrate, and IoT Hub as a full device-communication and management platform built on top of it.

Can I connect IoT devices directly to Event Hub without using IoT Hub?

Technically yes — any device that can speak AMQP 1.0 or HTTPS can publish to an Event Hub. However, you lose per-device identity, X.509 authentication, C2D messaging, device twins, and DPS. You also share a namespace-level credential across all devices. For production deployments where devices leave a controlled environment, this is a significant security and operational risk. The only scenario where direct Event Hub connection makes sense for “devices” is when those devices are actually well-governed services running in your own cloud or on-premises infrastructure.

What is the difference between IoT Hub’s built-in endpoint and a custom Event Hub route?

IoT Hub’s built-in endpoint (messages/events) is an Event Hub-compatible endpoint that automatically receives all device-to-cloud messages. It has a fixed, small number of consumer groups and does not support Kafka protocol or native Capture. A custom route sends messages that match a filter (based on message properties or body) to an external Event Hub namespace that you own — giving you full Event Hub feature access, including Kafka, Capture, Schema Registry, and a larger consumer group limit. Use the built-in endpoint for simple pipelines; add a custom route when you need Event Hub’s full capabilities.

When does it make sense to use both IoT Hub and Event Hub in the same architecture?

The combined pattern is the right choice when you have genuine IoT devices (requiring per-device identity and bidirectional communication) and you also need to fan out telemetry to many independent consumers, use Kafka-protocol pipelines, or archive data with Event Hub Capture. IoT Hub handles the device edge; Event Hub handles the high-throughput analytics bus. The boundary between them is the message routing rule that copies telemetry from IoT Hub’s built-in endpoint to the Event Hub namespace.

Does Event Hub support MQTT?

No. Event Hub supports AMQP 1.0 natively and exposes a Kafka-compatible endpoint in Premium and Dedicated tiers. It does not support MQTT. If any of your producers use MQTT — which is the dominant protocol for constrained IoT devices due to its low overhead and QoS semantics — you must use IoT Hub as the MQTT broker. Event Hub cannot accept MQTT connections.

How does pricing compare between IoT Hub and Event Hub for the same message volume?

A direct per-message price comparison favors Event Hub at high volumes, because IoT Hub charges by unit-per-day regardless of utilization up to the quota, while Event Hub charges per ingress event. However, IoT Hub provides device management capabilities that would cost significant engineering effort to build on top of Event Hub. When total cost of ownership includes the development and maintenance of a per-device identity system, reconnect management, command dispatch, and twin-style state synchronization, IoT Hub is almost always cheaper for genuine IoT workloads. Always check current Azure pricing pages for both services before committing to either, as tier pricing and included quotas change regularly.

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories