What is Azure Service Bus? A plain-English explainer
Azure Service Bus is Azure’s enterprise message broker: a managed service that lets one part of an application send a message to another without either side needing to be online, reachable or even aware of the other at the same moment. It supports two patterns — simple point-to-point queues, and topics with subscriptions for publish/subscribe delivery — so the same service covers a straightforward “hand this task off” message and a “broadcast this event to several interested listeners” message. That combination makes it a common building block wherever an Azure application is split into independent, decoupled components. Because messaging underpins so much cloud architecture, Service Bus appears in Azure certification study once the syllabus moves past single-resource basics. Here is what a queue and a topic actually are, when each earns its place, and how Service Bus compares across clouds.
What a message broker is, and why applications use one
A message queue is a way for one part of a system to hand off a piece of work — a message — to another part, without both being available at the exact same instant. Our what-is-a-message-queue explainer covers the general idea in full: a producer sends a message, it waits safely, and a consumer picks it up when ready. The benefit is decoupling — if the receiving component is briefly slow or offline, the message simply waits rather than being lost.
A message broker is the managed service that stores and delivers those messages reliably. Azure Service Bus is Azure’s broker, and it is built specifically for enterprise messaging scenarios — ordered delivery, transactions and integration with line-of-business systems are what it is designed around, rather than raw throughput at any cost.
Queues versus topics and subscriptions
Service Bus offers two distinct entities, and the difference is the whole shape of the service:
- Queues — point-to-point messaging. A sender puts a message on a queue, and exactly one receiver processes it. This is the classic “hand off a task” pattern: a single message, a single worker.
- Topics and subscriptions — publish/subscribe messaging. A sender publishes a message to a topic, and every subscription attached to that topic receives its own copy. This is the “broadcast an event to whoever is interested” pattern: one message, many independent listeners.
- Because subscriptions can filter which messages they receive, a topic can serve several different consumers off the same stream of events without each needing to inspect every message itself.
When you would reach for Service Bus
Service Bus fits naturally wherever components of an application need to talk without being tightly coupled: an order-processing system handing work to a fulfilment service, several independent systems all needing to know when a customer record changes, or a workflow that must reliably retry a step if a downstream service is temporarily unavailable. Its enterprise focus — features like message sessions, transactions and dead-lettering for messages that repeatedly fail — makes it a common choice for integration work between established business systems, rather than the highest-volume streaming telemetry a big-data pipeline produces.
The Azure counterpart to SQS and SNS
On AWS, the same territory is split across two separate services: Amazon SQS for point-to-point queues, and Amazon SNS for publish/subscribe topics. Azure Service Bus is broadly the Azure counterpart to the two combined, since one service covers both queues and topics/subscriptions. The underlying concepts — decoupling, reliable delivery, publish/subscribe fan-out — transfer directly between the two clouds even though the service boundaries are drawn differently.
How you pay for it, without the numbers
Service Bus follows the pay-for-use model common across managed messaging services: cost is driven by the number of messaging operations and the tier of features you choose, rather than a flat fee regardless of use. Exact pricing, tier boundaries and included allowances change over time, so this article deliberately avoids listing them — check Microsoft’s official Service Bus pricing page for current detail. The concept worth keeping is that choosing queues versus topics, and the feature tier you need, is a design decision with a real cost consequence, not just a technical one.
Where Service Bus appears in certification study
Service Bus is relevant to Azure’s developer and administration paths, since building or operating a decoupled application is a named skill area. Azure Administrator Associate (AZ-104) covers configuring and managing messaging resources; developer-focused study goes further into designing message flows, sessions and filters. Azure Fundamentals (AZ-900) introduces the concept at a high level as part of Azure’s integration services.
This article covers what Service Bus is and why it exists — configuring queues, writing subscription filters and handling dead-lettered messages belong in the syllabus itself, which our /revision study library breaks down lesson by lesson for these certifications.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.