Azure has two messaging services that get confused with each other constantly: Service Bus and Event Grid. They both move messages between systems. They both integrate deeply with the Azure ecosystem. They both show up in architecture diagrams with similar-looking icons. But they solve fundamentally different problems, and using the wrong one for your workload will cost you more money while delivering a worse result.
We see this regularly in client environments. Someone deploys Service Bus Premium to route simple event notifications between services, paying hundreds of pounds a month for something Event Grid would handle for pennies. Or someone pushes critical order processing messages through Event Grid, then wonders why occasionally a message gets processed twice or arrives out of sequence. Both services are excellent at what they are designed for. The trick is knowing which one to reach for.
Service Bus: The Enterprise Message Broker
Service Bus is a full-featured message broker. It provides queues (point-to-point) and topics (publish-subscribe) with a set of guarantees that matter when message processing is business-critical.
What you get:
- Guaranteed delivery and ordering. Messages arrive in the order they were sent, and they are delivered exactly once. For order processing, payment handling, or any workflow where duplicates or missed messages cause real problems, this is non-negotiable.
- Dead-letter queues. When a message fails processing after the maximum retry count, it moves to a dead-letter queue where you can inspect it, fix the issue, and resubmit. No message silently disappears.
- Sessions. You can group related messages together so they are always processed by the same consumer in sequence. Think of a multi-step order where the steps must execute in order on the same handler.
- Transactions. You can receive a message, do some processing, and send a new message as a single atomic operation. If any part fails, the whole thing rolls back.
- Complex routing. Topics with subscription filters let you route messages to different consumers based on message properties, without the publisher needing to know who the consumers are.
Pricing reality:
Service Bus Standard starts at roughly GBP 8 per month base cost, plus approximately GBP 0.80 per million operations. For most non-production workloads and moderate production volumes, Standard is perfectly adequate.
Service Bus Premium starts at roughly GBP 500 per month for a single messaging unit of dedicated capacity. That buys you private endpoints, predictable performance, and resource isolation. But it is a significant jump, and the main reason people end up on Premium is network isolation, since private endpoints are Premium only. If that is your sole driver for upgrading, read our Service Bus VNET isolation post for alternative approaches that might save you the upgrade.
Event Grid: The Event Router
Event Grid is not a message broker. It is an event routing service. The distinction matters.
Event Grid takes events, lightweight notifications that something happened, and delivers them to subscribers at massive scale with very low latency. It is the plumbing that connects Azure services together reactively.
What you get:
- Native Azure integration. When a blob lands in a storage account, when a resource is created or deleted, when an Azure Policy state changes. Event Grid fires an event automatically with no custom code.
- Fan-out to multiple subscribers. One event can be delivered to dozens of subscribers simultaneously. Every subscriber gets their own copy.
- Serverless scale. Event Grid handles millions of events per second without you provisioning or managing any infrastructure.
- At-least-once delivery. Events are delivered at least once, with retry logic built in. For most reactive patterns, this is perfectly fine.
What you do not get:
- Message ordering guarantees
- Exactly-once processing semantics
- Dead-letter queues with the same depth of tooling as Service Bus
- Sessions or transaction support
- Long-term message storage (events have a 24-hour retry window by default)
Pricing reality:
Event Grid charges approximately GBP 0.50 per million events published. The first 100,000 events per month are free. At most scales, Event Grid costs are so low they barely register on a cost report. We have seen environments routing millions of events a month for less than the price of a coffee.
When to Use Service Bus
Reach for Service Bus when the processing of the message is the critical part. If a message being lost, duplicated, or processed out of order would cause a business problem, Service Bus is the right choice.
Specific scenarios:
- Order processing and payment handling. An order must be processed exactly once. A duplicate charge is a support ticket and a refund. Service Bus guarantees this.
- Workflow orchestration. Multi-step processes where each step depends on the previous one completing. Sessions ensure related messages stay together.
- Reliable integration between services. When service A sends a command to service B, and service B must eventually process it even if it is temporarily down. The message waits in the queue.
- Dead-letter analysis. When you need to inspect failed messages, understand why they failed, and replay them after fixing the issue.
- Competing consumers. Multiple instances of a service pulling from the same queue for load balancing, with the guarantee that each message is processed by exactly one consumer.
When to Use Event Grid
Reach for Event Grid when you need to react to things that happened, and the event itself is a notification rather than a command.
Specific scenarios:
- Reacting to Azure resource events. A blob was uploaded to storage. A virtual machine was started. A deployment completed. Event Grid gives you these events natively without writing polling code.
- Fan-out notifications. A single event needs to trigger multiple downstream processes. Event Grid delivers to all subscribers in parallel.
- Lightweight event-driven architectures. A serverless function that fires whenever new data arrives. An automation that runs when a resource tag changes. A notification system that alerts when something happens.
- High-volume, low-latency routing. Event Grid can handle bursts of millions of events per second. If your workload is bursty and event-heavy, Event Grid absorbs it without breaking a sweat.
- Cross-service integration. Connecting Azure services together without custom intermediaries. Storage to Functions, Resource Manager to Logic Apps, custom applications to Event Hubs.
Common Mistakes We See
Using Service Bus Premium for simple event routing. This is the most expensive mistake. If all you need is to notify a Function when a blob lands in storage, you do not need a GBP 500 per month message broker. Event Grid does it for fractions of a penny.
Using Event Grid for critical business messages. Event Grid delivers at-least-once, not exactly-once. If your subscriber processes an event and then crashes before acknowledging it, the event will be redelivered. If your processing is not idempotent and processing the same event twice causes a problem, Event Grid is the wrong tool.
Running Service Bus Premium in every environment. We see this surprisingly often. Production, staging, development, and test all running Premium namespaces because the Terraform module was copied without adjusting the SKU. Standard is perfectly fine for non-production environments and saves you GBP 500 per month per environment.
Ignoring the combination pattern. The most powerful architectures use both services together, not one or the other.
The Combination Pattern
The smartest messaging architectures we see use Event Grid and Service Bus together. Event Grid handles the event notification: something happened. Service Bus handles the reliable processing: now do something about it.
Here is a concrete example. A customer uploads a file to Azure Blob Storage. Event Grid fires a "blob created" event to an Azure Function. The Function validates the file, enriches the message with metadata, and places a processing command onto a Service Bus queue. A backend service picks up the command from the queue and processes the file with full transactional guarantees, dead-letter handling, and retry logic.
Event Grid is doing what it does best: reacting to an Azure event instantly, at minimal cost. Service Bus is doing what it does best: ensuring the critical processing step happens reliably, exactly once, with full observability into failures.
This pattern gives you the responsiveness and cost efficiency of Event Grid for the notification layer, combined with the reliability and processing guarantees of Service Bus for the business logic layer. Each service handles the part of the problem it was designed for.
Making the Decision
The decision framework is straightforward once you strip away the confusion.
Ask yourself: is this a command (do this thing) or an event (this thing happened)? Commands that must be processed reliably belong on Service Bus. Events that notify subscribers of something that occurred belong on Event Grid.
If you are unsure, start with the consequence of failure. If a message being lost or duplicated would cause a business problem (a missed order, a double payment, a broken workflow), use Service Bus. If the worst case is a notification being delivered twice and your subscriber handling it gracefully, Event Grid is the simpler and cheaper choice.
And if your architecture needs both reactive event notification and reliable command processing, use both. That is not over-engineering. That is using each service for what it was built to do.
Reviewing your Azure messaging architecture or trying to reduce integration costs? Our free Azure cost assessment identifies over-provisioned services, including messaging infrastructure. No commitment, just clarity.