Azure Service Bus vs Event Hub: Specifications Comparison (2026)

Last Updated: April 2026

Architecture at a glance

Azure Service Bus vs Event Hub: Specifications Comparison (2026) — diagram — Azure Service Bus vs Event Hub: Specifications Comparison (2026)

When you’re building reliable, scalable distributed systems on Azure, the choice between Service Bus and Event Hubs feels deceptively simple—they’re both Microsoft’s enterprise messaging services. But they’re fundamentally different animals. Service Bus handles business logic with strict delivery guarantees; Event Hubs ingests high-volume telemetry with distributed consumer offsets. Pick wrong, and you’ll either overpay for the wrong throughput tier or lose guaranteed delivery when it matters most.

This guide compares them head-to-head with 2026 specifications, so you can route to the right service on day one.

Service Bus vs Event Hubs: The One-Paragraph Summary

Azure Service Bus is a broker-based messaging platform for point-to-point queues and publish/subscribe topics. It enforces per-message semantics—dead-letter queues, message session affinity, temporal filters—and guarantees exactly-once delivery (or at-least-once with duplicates detectable). It’s built for workflows: order processing, financial settlement, notification dispatch. You pay for messaging units (MU) that gate throughput and lock in high availability across zones.

Azure Event Hubs is a partitioned event log optimized for ingesting and replaying streams of telemetry from millions of devices. Consumers track their own offset in the log; multiple consumer groups can replay the same data independently. Event Hubs has no dead-letter or session semantics—it’s append-only. You pay for processing units (PU) that scale ingest, and retention is typically 1–7 days (though Kafka-enabled clusters can extend to 90+ days). It integrates with Apache Kafka brokers and ships logs to Azure Blob Storage (Event Hub Capture).

Rule of thumb: Service Bus = “did this message get processed?” vs. Event Hubs = “give me all events from timestamp T onwards.”

Architecture Differences

Service Bus: Broker-Based, Per-Message Guarantees

Service Bus implements a classical message broker architecture. Messages arrive at a queue or topic, where they sit in memory (or durable storage for Premium) until a receiver claims them.

Core building blocks:

Queues: Single-destination FIFO (or FIFO sessions). Receiver locks a message for 30 seconds (default) to process; if it doesn’t complete or acknowledge, the message returns to the queue or moves to the dead-letter queue.
Topics & Subscriptions: One-to-many. A publisher sends to a topic; multiple subscriptions filter and receive independently. Each subscription can have its own dead-letter queue and temporal filters.
Dead-Letter Queue (DLQ): Automatic or manual quarantine for poison messages. Includes disposition reason (“TTL exceeded”, “max delivery count”).
Message Sessions: Affinity grouping by sessionId. A receiver can lock a session; only that receiver can process messages in that session sequentially (prevents race conditions in stateful workflows).

Delivery semantics:
– Exactly-once detection (Premium tier): Service Bus stamps each message with a MessageId and DeduplicationId. If a receiver acknowledges but the acknowledgment is lost (network hiccup), the message won’t be redelivered because Service Bus remembers it processed.
– Temporal filtering: Subscriptions can ignore messages older than a certain timestamp or with specific properties.

Throughput and latency:
– Standard tier: ~1,000 msg/sec per queue, 50ms–100ms latency, shared infrastructure.
– Premium tier: 1MU = ~10,000 msg/sec, 1–2ms latency, dedicated capacity, active-active replication across zones.

Event Hubs: Partitioned Log, Offsets, Consumer Groups

Event Hubs is an event streaming platform inspired by Apache Kafka. Instead of broker-held message state, consumers own their read position (offset).

Core building blocks:

Partitions: Data is sharded across 2–256 partitions (configurable at creation; resizing requires re-creation). Ordering is per-partition, not global. A producer picks a partition key to deterministically land events in the same partition.
Consumer Groups: Multiple independent consumers (or apps) can read the same partition stream from different starting offsets. Consumer group A can be at offset 1000; consumer group B at offset 500. Each tracks its own progress.
Offsets: Consumers record their last read position (Kafka-style). If a consumer dies and restarts, it resumes from its last offset (not from the beginning).
Event Hub Capture: Automatically archives all events to Azure Blob Storage in Parquet or Avro format at configurable intervals (5 minutes–12 hours).

Throughput and latency:
– Standard tier: 1 throughput unit (TU) = 1MB/sec ingest, 1,000 events/sec, 2 partitions. Shared infrastructure.
– Premium tier: 1 processing unit (PU) = 1MB/sec ingest + Kafka protocol support + auto-scaling. Dedicated cluster with low-latency SSD.
– Dedicated tier (new in 2026): Per-cluster capacity reservation, no metering, fixed monthly cost; 1 cluster = 200MB/sec baseline.

Architecture diagram references:
– Diagram 1 (arch_01.mmd): Service Bus queues, topics, dead-letter routing.
– Diagram 2 (arch_02.mmd): Event Hubs partitions, consumer groups, offsets.

Specifications at a Glance (2026 Update)

Service Bus Specs (as of April 2026)

Aspect	Standard Tier	Premium Tier
Max message size	256 KB	1 MB
Throughput (per queue)	~1,000 msg/sec	~50,000 msg/sec (1MU)
Latency (p50)	50–100ms	1–2ms
Max queue/topic depth	Unlimited (up to storage limit)	Unlimited (up to storage limit)
Retention	14 days (configurable)	1–365 days
Dead-letter support	Yes	Yes
Session support	Yes	Yes
Exactly-once detection	Yes (deduplication window: 10 min)	Yes
Billing model	Per operation (send, receive)	Messaging units (MU), 730 hours/month
HA availability	No (single region)	Yes (multi-zone, across 3 AZs)
Estimated cost (1MU)	N/A	~$330/month per MU

Key notes:
– Premium tier is a “commitment”; you reserve 1+ MUs and pay whether you use them or not.
– Deduplication window is 10 minutes; messages with duplicate MessageId within that window are dropped.
– Max batch size for send: 100 messages, 1 MB payload.

Event Hubs Specs (as of April 2026)

Aspect	Standard TU	Premium PU	Dedicated Cluster
Max message/event size	1 MB	1 MB	1 MB
Throughput (ingest)	1 MB/sec per TU	1 MB/sec per PU	200 MB/sec baseline
Events/sec	~1,000 per TU	~1,000 per PU	200,000+/sec
Default partitions	2 (up to 256)	2 (up to 256)	4+ (configurable)
Retention	1–7 days	1–90 days	1–90 days
Kafka protocol support	No	Yes (Kafka 3.x)	Yes
Auto-scaling	Manual (TU provisioning)	Yes (min/max PU range)	Manual (cluster resize)
Billing model	Per TU, pay-as-you-go	Per PU, hourly	Fixed monthly (e.g., $4K–$10K)
HA availability	No (single region)	Yes (multi-zone)	Yes (multi-zone)
Event Capture to Blob	Yes (standard only)	Yes	Yes
Estimated cost (1 PU)	N/A	~$180/month per PU	~$4,000–$10,000/month

Key notes:
– Kafka protocol (Premium/Dedicated) uses the same offset store as native Event Hubs. You can swap Kafka and REST clients transparently.
– Event Capture is automatic; you choose the target Blob container and the flush interval.
– Partitions are permanent; resizing requires recreating the namespace.

When to Choose Which

Choose Service Bus if:

You need transactional guarantees. Order processing, payment settlement, or financial workflows where “at least once” with exactly-once detection is mandatory.
You have complex routing. Topic subscriptions with multiple filters, temporal conditions, or session affinity.
You use dead-letter queues. Poison message quarantine, manual retry logic, or dispute resolution.
Message retention is short-lived. Workflows where events are processed within seconds (no long-term log history needed).
You’re migrating from on-premises Service Bus. Parity with System Center Service Bus API.

Choose Event Hubs if:

You ingest high-volume telemetry. IoT sensors, application logs, clickstreams, stock tickers (thousands to millions of events/sec).
You need replay and temporal queries. “Give me all events from 3 hours ago” or “replay this partition from offset 5000”.
You’re running Kafka workloads. Existing Kafka producers/consumers (Spark Streaming, Flink, Kafka Streams) can plug in without rewriting.
You archive to data lake. Event Capture to Parquet/Avro, then query in Synapse or Databricks.
You have independent consumer groups. Multiple downstream systems reading the same stream at different speeds (real-time dashboards, batch processing, ML training).

Trade-Offs and Gotchas

Event Hub Capture and Blob Costs

Event Hub Capture sends all events to Azure Blob Storage automatically. If you have 10 TB/day ingest, you’ll pay ~$450/month for Blob storage on top of Event Hub throughput. Batch agents and retention tiers can mitigate, but it’s easy to miss in cost forecasts.

Kafka Protocol Caveats

Event Hubs Premium and Dedicated tiers support Kafka 3.x wire protocol, but there are gaps:

Consumer group rebalancing works, but Zookeeper integration doesn’t (Event Hubs doesn’t expose a Zookeeper port).
Transactions (atomicity across partitions) aren’t supported; Kafka’s transactional.id is ignored.
Schema Registry integration requires workarounds (Azure Schema Registry or Confluent Platform).

Premium vs. Standard Cost Delta

Service Bus Premium (1MU ≈ $330/month) handles 50× the throughput of Standard, but costs only 10× more. If you’re spending >$100/month on Standard operations, Premium becomes economical. For Event Hubs, the crossover is similar: 1 Premium PU (~$180/month) = 10 Standard TUs (~$900/month).

Partitioning Immutability

Event Hubs partition count is set at creation and cannot be changed. If you launch with 2 partitions and later discover you need 32, you must recreate the namespace and rehydrate consumers. Plan your partition count upfront.

Service Bus Session Affinity Overhead

Using sessions locks a receiver to a single session at a time. If you have 1000 sessions and only 10 receivers, you’ll have long tail latency as receivers rotate through sessions. Sessions are powerful but introduce scheduling complexity.

Practical Recommendations

For microservices orchestration: Use Service Bus. It’s built for point-to-point messaging with dead-letter and retry logic baked in. Pair it with Azure Logic Apps or Durable Functions for workflow state management.

For real-time analytics: Use Event Hubs. Pair it with Azure Stream Analytics for CEP (complex event processing), or Synapse for batch SQL over captured events.

For hybrid Kafka workloads: Use Event Hubs Premium or Dedicated with Kafka protocol. If you’re running Kafka on-premises and migrating, Event Hubs lets you run your existing Kafka clients without rewriting.

For compliance and audit logging: Use both. Service Bus topics for workflow events + Event Hubs for audit trails. Event Hub Capture archives all logs to Blob Storage for long-term compliance queries.

For cost optimization: Right-size your tier. Run a 2-week pilot on Standard; measure peak throughput and message size. If you exceed 1,000 msg/sec or 50KB average message, escalate to Premium. Use Event Hubs auto-scaling (Premium PU) to handle burst traffic without over-provisioning.

FAQ

What’s the difference between Azure Service Bus and Event Hubs?

Service Bus is a message broker for orchestration and reliable delivery; Event Hubs is an event stream for ingestion and replay. Service Bus guarantees exactly-once semantics and dead-lettering; Event Hubs scales to millions of events/sec and lets multiple consumers read the same partition independently.

Does Event Hubs support Kafka?

Yes, in Premium and Dedicated tiers (2026). Standard tier does not. Kafka protocol support means you can plug in Kafka producers and consumers (Spark Streaming, Flink, Kafka Streams, Logstash) without rewriting. Offsets are compatible between Kafka and native Event Hubs clients.

What replaced Azure Event Grid’s messaging role?

Event Grid is for serverless event routing (CloudEvents, SaaS integrations, fan-out). Service Bus and Event Hubs are for persistent, high-volume messaging. They’re complementary: Event Grid can publish to Service Bus or Event Hubs for durability.

Is Service Bus Premium worth the cost?

If you’re handling >500 msg/sec or have sub-100ms latency requirements, yes. If you’re at the edge (100–200 msg/sec Standard), run a cost-benefit: Premium ≈ $330/month vs. Standard ≈ $100–150/month in operations. The break-even is around 1,500–2,000 msg/sec.

How much do Event Hubs Premium processing units cost?

Approximately $180/month per PU (1 PU = 1 MB/sec ingest). Auto-scaling is included. Dedicated clusters start at ~$4,000/month for a baseline 200 MB/sec cluster. For high-volume telemetry (>10 MB/sec), Dedicated becomes cheaper per GB than Premium.

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories