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

When you’re building a telemetry pipeline on Azure, you’ll encounter two services that sound interchangeable but solve fundamentally different problems: IoT Hub vs Event Hub. Both ingest data at scale, both route messages to downstream processors, and both integrate with Stream Analytics, Functions, and custom consumers. Yet they diverge sharply in identity model, protocol support, state management, and pricing. This guide cuts through the confusion by comparing them head-to-head across architecture, use cases, and failure modes—so you can choose with confidence.

Here’s the central tension: IoT Hub is device-centric; Event Hub is event-centric. IoT Hub manages per-device identity, enforces bidirectional communication, and handles secure provisioning. Event Hub treats all publishers equally, focuses on throughput, and lets any authenticated principal dump events into a shared stream. That one difference cascades through everything—protocols, state management, partition strategy, and cost model.

The Quick Answer

Choose IoT Hub if:
– You have discrete physical devices (sensors, gateways, edge boxes) that need persistent identity
– Devices must authenticate individually (X.509 certificates, SAS tokens, managed provisioning)
– You need cloud-to-device commands, device twins, or direct method invocation
– Protocols matter: MQTT 3.1.1, AMQP 1.0, or HTTPS
– Per-device state (desired vs. reported properties) is essential

Choose Event Hub if:
– Publishers are applications, services, or high-throughput event streams (not individual devices)
– You need to ingest terabytes per day with elastic throughput units
– Kafka compatibility is a hard requirement
– Shared SAS keys at namespace or entity level suffice for authentication
– Event ordering within a partition and horizontal scalability dominate

Choose both if:
– IoT ingestion (IoT Hub) feeds downstream event streaming (Event Hub or Kafka consumers)
– Legacy apps or services need a separate Kafka endpoint alongside device telemetry

Reference Architecture: Two Paths

The diagram above shows the canonical setup. Path A (left): devices connect to IoT Hub, which internally routes events through a built-in Event Hub endpoint. Downstream consumers (Stream Analytics, Azure Functions, Azure Data Explorer, or custom apps) read from that endpoint. Path B (right): applications or microservices bypass IoT Hub entirely and publish directly to Event Hub using shared credentials or Kafka protocol.

In production, many teams run both paths in parallel. IoT telemetry stays device-focused (identity, provisioning, twins); business events flow through Event Hub (app-to-app, Kafka fan-out). This separation keeps concerns clean and avoids the temptation to shoehorn non-device workloads into the IoT Hub identity model.

Per-Device Identity vs. Shared Producer: The Fundamental Difference

This is the mother of all IoT Hub vs Event Hub differences. Let’s be explicit:

IoT Hub per-device identity:
– Every device gets a unique identifier (device ID)
– Each device authenticates with its own credential: an X.509 certificate, a symmetric SAS token, or a Device Provisioning Service (DPS)–issued token
– The service validates that credential and binds the inbound message to that specific device
– You can query “what did device sensor-42 send in the last hour?” because identity is tracked at ingestion
– Twin state, direct methods, and cloud-to-device messages all route through that identity

Event Hub shared producer identity:
– All publishers authenticate with a shared SAS key at the namespace or entity level
– The service doesn’t know or care who the specific publisher is
– You get the event stream; you don’t get per-publisher attribution unless you embed it in the event payload
– Scale is simpler: add throughput units, not per-device provisioning

The diagram above contrasts the two. IoT Hub’s auth tree requires a per-device secret or certificate; Event Hub’s is a flat namespace or role-based grant. For a fleet of 10,000 sensors, IoT Hub means 10,000 identity bindings. Event Hub means one or two SAS keys, shared across all publishers.

This difference alone explains why you can’t simply “migrate from IoT Hub to Event Hub” without rearchitecting. If your downstream logic depends on device identity, Event Hub won’t give it to you.

Protocol Support: MQTT, AMQP, HTTPS, and Kafka

IoT Hub protocols:
– MQTT 3.1.1 (full support; WebSockets variant for NAT/proxy traversal)
– AMQP 1.0 (full support; WebSockets variant)
– HTTPS (pull and push; heavier overhead)
– MQTT 5.0 (partial, via preview; not yet production-grade for device-to-cloud)

MQTT is the dominant protocol for resource-constrained IoT devices. It’s lightweight (sub-10KB memory footprint), handles unstable networks with QoS levels and session resumption, and has a vast ecosystem of client libraries. If your sensors run on ARM Cortex-M with 32KB RAM, MQTT is the natural choice.

Event Hub protocols:
– AMQP 1.0 (full support; binary, lower latency)
– HTTPS (REST-style publishing; simpler but higher per-request overhead)
– Kafka 1.0+ (since 2018; full API support, except some admin operations)

Event Hub’s Kafka surface is a game-changer for app-to-app streaming. If you have Kafka consumers already deployed (Kafka Streams, Spark Streaming, Flink), you can plug Event Hub in as a drop-in broker without recoding. One caveat: some Kafka admin APIs (broker reassignment, preferred leader election) are unsupported.

Pricing & Throughput Models: Per-Message vs. Per-Unit

IoT Hub pricing (tiered model):
– Basic tier (B1, B2, B3): priced per million messages per day, no twin or direct methods
– Standard tier (S1, S2, S3): priced per million messages per day, full features
– Message size cap: 4 KB (B1/S1), 64 KB (B2/S2), 256 KB (B3/S3)
– Example: S1 tier = ~$50–60/month for 400K messages/day; S3 = ~$10K+/month for billions/day

The per-message-day model is simple for small to medium IoT fleets (hundreds to low thousands of devices sending infrequently). It becomes expensive at massive scale.

Event Hub pricing (capacity model):
– Standard (throughput units, TUs): 1 TU = 1 MB/s ingress + 2 MB/s egress; priced hourly per TU
– Premium (processing units, PUs): more predictable latency; 1 PU ≈ 1 MB/s ingress; priced hourly per PU
– Dedicated cluster: reserved capacity, best for >5 MB/s sustained; fixed monthly cost

Event Hub’s unit-based pricing favors high-throughput, bursty workloads. 1 TU costs roughly $0.015/hour (~$110/month if always active), but can handle spikes flexibly. For a streaming app sending 100MB/day across 1,000 publishers, Event Hub’s per-unit model beats IoT Hub’s per-message model.

Rough guidance:
– <50K devices, <100 messages/day per device → IoT Hub Basic or Standard (cheaper than TUs)
– >500K messages/day aggregate, bursty or app-to-app → Event Hub (more elastic, cheaper at scale)
– Massive dedicated workload (>10 MB/s sustained) → Event Hub Dedicated cluster

Device Twins, Direct Methods, and Cloud-to-Device Messages: IoT Hub Exclusive

IoT Hub’s killer features for device management don’t exist in Event Hub:

Device Twin
– A persistent JSON document (max 8 KB) per device, stored in IoT Hub
– Two sections: desired state (cloud-to-device intent) and reported state (device-to-cloud reality)
– Example: cloud sets desired.powerState = "off"; device reads it, powers down, then reports reported.powerState = "off"
– Sync happens via the MQTT $iothub/twin/... topics or AMQP link properties
– Enables declarative device configuration, no polling loops

Direct Methods
– RPC-style invocation: cloud → device synchronously, waits for response
– Example: POST /directMethods/reboot with timeout; device executes and returns status
– Useful for firmware rollout, emergency shutdown, or ad-hoc diagnostics
– MQTT and AMQP both support it; HTTPS clients can invoke but not listen

Cloud-to-Device Messages
– Asynchronous messages from cloud to device
– Delivery guarantee, dead-letter handling, per-device queue
– Example: “download new firmware from URL X”
– Event Hub has no cloud-to-device; it’s unidirectional

For a smart-home or industrial monitoring scenario, these three features are non-negotiable. Event Hub cannot replace them.

Trade-offs & Failure Modes

No service is perfect. Here are the rough edges:

IoT Hub limitations:
– Partition count: up to 32 by default (higher tiers get more, but there’s still a ceiling). For massive device fleets, this becomes a bottleneck on a per-hub basis.
– Built-in Event Hub endpoint shares partitions with routing rules. If a routing rule starves a consumer, the built-in endpoint suffers.
– Per-device identity overhead. Provisioning 100K devices via DPS is handled, but adds latency.
– Throughput elasticity isn’t instant; scaling a tier change takes a few minutes.

Event Hub limitations:
– No per-publisher state. If you need to query “which app last published to partition 3?”, Event Hub won’t tell you.
– Kafka admin API gaps. Some operations (broker reassignment, controlled shutdown) aren’t supported. This matters if you’re migrating from Apache Kafka and have automation around those APIs.
– Retention is bounded (1–90 days by default for Standard; longer with Event Hubs Capture or Dedicated). If you need indefinite replay, stream to blob storage separately.
– Throughput unit elasticity: ~5 minutes to scale up or down. Sudden traffic spikes can cause client-side throttling.

Shared gotchas:
– Both services batch messages at the partition level. A single slow consumer can cause head-of-line blocking across all messages in that partition, not just for that consumer.
– Both are eventually consistent for metadata (partition count, consumer groups). DNS caching and connection pooling must account for this.

When to Choose Which: A Decision Tree

Start here:
1. Do you have discrete physical devices with persistent identity? Yes → IoT Hub. No → Event Hub.
2. Do you need device twins or direct methods? Yes → IoT Hub only. No → continue.
3. Is Kafka compatibility required? Yes → Event Hub. No → continue.
4. Is your primary pattern app-to-app or service-to-service? Yes → Event Hub. No → IoT Hub.
5. Do you expect >10 TUs sustained throughput? Yes → Event Hub (cheaper). No → either (depends on message rate).

Hybrid setup (both):
– IoT telemetry → IoT Hub → built-in Event Hub endpoint → Stream Analytics
– Business events → Event Hub directly ← microservices, SaaS webhooks, Kafka producers
– Both feed a common consumer (e.g., Azure Data Explorer, Data Lake)

This separation avoids forcing devices into an event-streaming model and avoids forcing services into a device-provisioning model.

Frequently Asked Questions

Q: Does IoT Hub use Event Hub under the hood?
A: Yes. IoT Hub’s built-in endpoint is an Event Hubs instance. Routing rules, telemetry, and events flow through it. However, you don’t manage the Event Hubs resource directly; it’s managed by IoT Hub. You can’t attach Kafka consumers to it.

Q: Can I switch from IoT Hub to Event Hub easily?
A: Not without rearchitecting. If your downstream logic (Stream Analytics, Azure Functions, custom apps) depends on device identity or twin state, losing that identity is a breaking change. You’d need to embed device ID in the event payload and rebuild the twin-state logic in your application.

Q: What about Azure Service Bus?
A: Service Bus is for message-oriented work: queues, topics, sessions, and durable subscriptions. It’s not a time-series or telemetry ingestion tool. IoT Hub and Event Hub are for high-throughput streaming; Service Bus is for transactional messaging and command orchestration.

Q: Is Event Hub’s Kafka surface the same as Apache Kafka?
A: 95% compatible. Consumer groups, offsets, and the Fetch API work identically. Admin APIs (broker metadata, controller operations) are partially unsupported. If your logic doesn’t use those APIs, it’s a true drop-in replacement.

Q: What if I need both per-device identity AND Kafka?
A: Use IoT Hub for device ingestion and route to a separate Event Hubs instance for Kafka consumers. Rewrite the message to include device metadata (ID, timestamp, twin state) before publishing to the secondary hub. This is a common fan-out pattern.

Architecture Patterns in Production

Pattern 1: Pure IoT
IoT Hub → Stream Analytics → SQL Database. Works for fleets of 10–100K devices sending telemetry once per minute. Simple, managed, no Kafka or custom consumers needed.

Pattern 2: IoT + Legacy Streaming
IoT Hub → (built-in Event Hub) → Event Hubs (Kafka surface) → Kafka Streams / Spark Streaming. Useful when you already have Kafka infrastructure and want to unify IoT and app data.

Pattern 3: App-to-App Event Streaming
Event Hubs → Kafka Streams / Flink / Azure Functions → CosmosDB / Data Lake. No IoT devices; pure event-driven architecture.

Pattern 4: Hybrid Device + App Events
– Devices → IoT Hub → built-in Event Hub
– Apps → Event Hub (Kafka surface)
– Both → Stream Analytics → Data Lake
This separates device identity from business events while keeping a unified ingestion layer.

Key Takeaways

1. Identity is destiny. Per-device identity (IoT Hub) vs. shared producer (Event Hub) drives every other difference.
2. MQTT is king for devices. If your devices speak MQTT, IoT Hub is the natural fit.
3. Kafka is king for apps. If your downstream consumers are Kafka-native, Event Hub’s Kafka surface is invaluable.
4. Twins and methods are IoT-only. If you need device state or cloud-to-device RPC, IoT Hub is mandatory.
5. Scale calculus shifts at high throughput. Event Hub’s TU model beats IoT Hub’s per-message model above ~1 MB/s.
6. Partition limits matter. Both services have partition ceilings; IoT Hub’s is tighter (32 default, higher in S3).

Further Reading

Internal:
– TimescaleDB Hypertables, Chunks & Continuous Aggregates — storing IoT time series
– Azure Category — all Azure cloud posts
– EMQX MQTT Cluster on Kubernetes: Production Tutorial — open-source MQTT for comparison

External:
– Azure IoT Hub Documentation — official reference
– Azure Event Hubs Documentation — official reference
– Azure IoT Device Provisioning Service — identity provisioning deep dive

---

Published: 2026-04-24
Updated: 2026-04-24
Author: IoT Digital Twin PLM
Category: Cloud & DevOps