Azure Event Grid vs Service Bus: Event Routing vs Reliable Messaging
Azure Event Grid, Service Bus, and Event Hubs are three distinct messaging services in Azure that are frequently confused because they all move data between components. They solve different problems: Event Grid routes lightweight event notifications; Service Bus provides reliable, ordered message delivery; Event Hubs handles high-throughput event streaming. Using the wrong one creates delivery guarantees mismatches or architectural complexity that is hard to remove later.
What each service is for
Azure Event Grid is a managed event routing service. It receives events from Azure services (Blob Storage blob created, Resource Manager resource changed, IoT Hub device connected) or from custom publishers via HTTP, and routes them to subscribers — Azure Functions, Logic Apps, webhooks, Event Hubs, Service Bus queues. Event Grid is a fan-out router: one event can be delivered to multiple subscribers simultaneously. Events are small (up to 1 MB), and Event Grid guarantees at-least-once delivery with retry over 24 hours.
Azure Service Bus is a fully managed enterprise message broker. It provides queues (point-to-point delivery) and topics with subscriptions (publish-subscribe). Service Bus guarantees ordered delivery within a session, at-most-once or at-least-once delivery semantics, message locking during processing, dead-letter queues for failed messages, and message scheduling. It is designed for critical business processes where message loss is unacceptable.
Azure Event Hubs is a high-throughput event ingestion service. It accepts millions of events per second, stores them for up to 90 days, and allows multiple consumer groups to read from the same event stream independently. It is designed as the front door for real-time analytics pipelines — telemetry, logs, clickstream data — not for message processing with delivery guarantees.
Comparison across key dimensions
| Dimension | Event Grid | Service Bus | Event Hubs |
|---|---|---|---|
| Pattern | Event routing / pub-sub | Reliable message broker | Event streaming / ingestion |
| Delivery model | Push to subscriber (webhook, Function) | Pull by consumer (compete or session) | Pull by consumer group (offset-based) |
| Ordering guarantee | No guaranteed order | FIFO within a session | Ordered within a partition |
| At-least-once delivery | Yes (retry over 24 hours) | Yes (with message lock / peek-lock) | At-least-once with consumer offset management |
| Message size limit | 1 MB per event | 256 KB (Standard); 100 MB (Premium) | 1 MB per event |
| Max retention | 24 hours (retry window) | Up to 14 days | Up to 90 days (with Capture) |
| Fan-out (multiple consumers) | Yes — native, per event | Yes — via topics and subscriptions | Yes — via consumer groups |
| Dead-letter support | Yes — to Blob Storage | Yes — built-in DLQ per queue/subscription | No — unprocessed events expire |
| Throughput | 10M events/second (system topics) | Up to thousands of messages/second (Premium) | Millions of events/second |
| Pricing model | Per operation (first 100K/month free) | Per operation + namespace fee | Per throughput unit + storage |
Pricing summary
Event Grid: First 100,000 operations per month free. $0.60 per million operations after the free tier. A system with 10 million events per month costs approximately $5.94/month. Event Grid is inexpensive for typical event notification volumes.
Service Bus: Basic tier starts at $0.05 per million operations. Standard tier (queues + topics) has a base fee of approximately $10/month plus $0.05/million operations. Premium tier provides dedicated messaging units with predictable performance — starting at approximately $670/month per messaging unit. Use Premium for latency-sensitive production workloads requiring consistent performance.
Event Hubs: Basic tier: $0.028/throughput unit/hour + $0.028/million events. Standard tier adds consumer groups, message retention, and Capture: $0.030/throughput unit/hour. Premium tier is priced per Processing Unit ($0.134/PU/hour). For 10 million events per day (300M/month) at Standard tier with 1 throughput unit: approximately $21/month in compute + event costs.
Service Bus Premium tier provides predictable latency (under 5ms for most operations) and is required for large message support (up to 100 MB), Java Message Service (JMS) 2.0 support, and virtual network service endpoints. For financial systems, order processing, or any workload where message processing latency spikes cause business impact, Premium is the correct choice.
When to use Event Grid
- Reacting to Azure service events — triggering a Function when a blob is uploaded, starting a Logic App when a resource is created or deleted
- Fan-out notification — one event needs to be delivered to multiple subscribers simultaneously (audit logger, notification service, cache invalidator)
- Loosely coupled integrations where the publisher does not need to know which subscribers are listening
- Custom application events that need to be routed to multiple downstream consumers via a managed event router rather than direct HTTP calls
- Event volume is moderate and events are small (under 1 MB) with a short time window for delivery
When to use Service Bus
- Business-critical workflows where message loss is unacceptable — order processing, payment events, booking confirmations
- Ordered processing within a session — all messages for a specific customer or transaction must be processed in sequence
- Long-running processing where messages need to be locked during work and released (or dead-lettered) if processing fails
- Scheduled message delivery — send a message to be processed at a specific future time
- Large message payloads requiring up to 100 MB (Premium tier)
- Competing consumers pattern — multiple worker instances pulling from the same queue, each getting exclusive access to a message
When to use Event Hubs
- High-throughput telemetry ingestion — IoT sensors, application logs, clickstream data, metrics at millions of events per second
- Stream processing pipelines — data flows from producers through Event Hubs into Azure Stream Analytics, Azure Databricks, or Synapse for real-time analysis
- Event replay — consumers can re-read historical events from any offset within the retention window
- Apache Kafka compatibility — Event Hubs supports the Kafka protocol, allowing Kafka producer and consumer code to work without modification
Common mistakes
- Using Event Grid for critical business messages that must not be lost. Event Grid retries for 24 hours and then discards the event. There is no dead-letter queue in the same sense as Service Bus. For messages that represent financial transactions or must eventually be processed regardless of temporary consumer downtime, use Service Bus.
- Using Service Bus for high-throughput telemetry ingestion. Service Bus is not designed to ingest millions of events per second at low cost. For that volume, Event Hubs is the correct choice — it is purpose-built for high-throughput streaming ingestion.
- Assuming Event Hubs delivers each message to a single consumer. Event Hubs is a streaming log, not a queue. Multiple consumer groups can read the same events independently. If you need competing consumer semantics (only one worker processes each message), use Service Bus queues.
- Using Service Bus Standard tier for latency-sensitive production workloads. Standard tier shares messaging infrastructure across tenants and can exhibit occasional latency spikes. Production workloads with latency SLAs should use Premium tier for dedicated, predictable performance.
Summary
- Event Grid routes lightweight event notifications with at-least-once delivery over 24 hours — ideal for reacting to Azure service events and fan-out notification patterns.
- Service Bus is a reliable message broker with ordered delivery, message locking, dead-letter queues, and up to 14 days retention — required for critical business message processing where loss is unacceptable.
- Event Hubs is a high-throughput streaming ingestion service for millions of events per second with consumer group support and Kafka protocol compatibility — not a replacement for reliable message queuing.
- The key decision rule: events (notifications) → Event Grid; messages (directives that must be processed) → Service Bus; high-volume streaming data → Event Hubs.
Frequently asked questions
What is the difference between an event and a message?
An event is a lightweight notification that something happened — "a blob was uploaded", "a VM was deleted". Events are typically small and the publisher does not expect a specific reaction. A message is a directive with data that must be processed — "process this order", "send this email". Messages typically contain a complete payload and the sender expects the receiver to act on it. Event Grid is for events; Service Bus is for messages.
What is a dead-letter queue in Service Bus?
A dead-letter queue (DLQ) is a sub-queue that receives messages that could not be delivered or processed successfully after the maximum delivery count is exceeded. Instead of losing failed messages, they land in the DLQ where you can inspect them, diagnose the failure, and either reprocess or discard them. Service Bus has built-in DLQ support; Event Grid supports dead-lettering to a Blob Storage container.
When should I use Event Hubs instead of Event Grid or Service Bus?
Use Event Hubs for high-throughput event streaming — ingesting millions of events per second from telemetry, clickstreams, IoT devices, or log data. Event Hubs retains events for a configurable period (1–90 days) allowing multiple consumers to replay data. It is not a messaging system with delivery guarantees like Service Bus, and it does not route events like Event Grid. Use it as a high-volume event ingestion pipeline into analytics or stream processing.