Messaging and Integration Services

Azure Service Bus is a fully managed enterprise message broker offering queues (point-to-point, one consumer processes each message) and topics with subscriptions (publish/subscribe, each subscription gets its own copy of every message it’s subscribed to, optionally filtered by a SQL-like or correlation filter). Both entity types support a dead-letter queue (DLQ) — a side channel every queue and subscription carries automatically, where messages land after exceeding MaxDeliveryCount, expiring past their time-to-live, or being explicitly dead-lettered by the receiver — and sessions, which group related messages (for example, all messages for one order) so a single receiver processes them in order and can hold session-scoped state between messages. The Standard tier is a fully multi-tenant, pay-per-operation service; the Premium tier runs on dedicated messaging units for predictable latency and throughput, and is required for larger message sizes and some geo-replication features.

Event Grid is a publish/subscribe eventing service for reacting to discrete state-change events — "a blob was created", "a resource was deleted", "an order was placed" — rather than carrying the payload of ongoing work the way Service Bus or Event Hubs do. A system topic is a built-in event source Azure itself manages for a resource type already in the subscription — most commonly a Storage account’s Blob Storage events (Microsoft.Storage.BlobCreated, BlobDeleted, and the rest), but also Resource Groups, Key Vault, Container Registry and others — and needs no publishing code: the resource emits events, Event Grid routes them. A custom topic is one an application creates and publishes its own domain events to explicitly (an HTTP POST of a CloudEvents- or Event Grid-schema payload), for events with no built-in Azure source. Either kind of topic gets one or more event subscriptions, each naming a handler (a webhook, an Azure Function, a Service Bus queue/topic, an Event Hubs namespace, or a Storage Queue) and, optionally, a filter narrowing which event types or subjects that handler receives.

Event Hubs is a high-throughput event streaming service — a managed, partitioned, append-only log conceptually close to Apache Kafka — built for ingesting large volumes of telemetry or activity events (clickstreams, IoT readings, application logs) that downstream consumers replay from an offset rather than receive one-shot the way Service Bus messages are consumed. Its distinguishing feature for teams already invested in Kafka tooling is the Kafka-compatible endpoint: an event hub is addressable as a Kafka topic over the Kafka wire protocol on port 9093, so an existing Kafka producer/consumer, kafkacat, Kafka Connect connector, or Kafka Streams application can often point at it by changing only bootstrap.servers and the SASL configuration, without touching application code, provided it targets a Standard, Premium, or Dedicated tier namespace (the Kafka endpoint isn’t available on Basic).

Azure Storage Queues (part of a general-purpose storage account, alongside Blob/Table/File) are a much simpler message queue: a message is up to 64 KB, addressed by a plain HTTP(S) URL under the storage account, with no sessions, no topics/subscriptions, and no dead-letter queue as a first-class construct (an application has to build its own poison-message handling by tracking a message’s DequeueCount and moving it to a separate queue itself). What Storage Queues trade for that simplicity is cost and scale: they’re billed as ordinary storage transactions rather than a dedicated messaging SKU, a single queue can hold millions of messages up to the storage account’s overall capacity, and there’s no namespace/tier to provision beyond the storage account already used for Blob Storage. Reach for a Storage Queue over a Service Bus queue for a plain work backlog (the Web-Queue-Worker pattern) that doesn’t need ordering guarantees, sessions, or a managed DLQ, especially when a storage account already exists for other reasons.

--auth-mode login authenticates the CLI call itself with the signed-in identity’s Entra credentials instead of an account key; an application does the same by pointing the Storage Queues SDK’s QueueServiceClient at DefaultAzureCredential rather than a connection string, with Storage Queue Data Contributor (or …​Message Processor/…​Message Sender for narrower access) granted on the storage account. See Introduction to Azure Queue Storage and az storage queue command reference.

Azure Logic Apps is a low-code workflow service: a designer-built (or JSON-defined) sequence of a trigger followed by actions drawn from 1,400+ prebuilt connectors, well suited to wiring together the other services on this page (poll a queue, call an API, branch on a condition, send an email) without writing an integration service from scratch. It comes in two hosting shapes that matter for cost and networking, not workflow authoring: the Consumption plan runs each logic app resource as a single workflow in multi-tenant, shared infrastructure and bills per action execution, which is the cheapest way to start and needs no capacity planning; the Standard plan runs on a dedicated App Service-based plan, hosts multiple workflows per logic app resource, supports direct VNet integration and private endpoints, and bills for the underlying plan’s compute rather than per execution, which suits higher-throughput or network-isolated workflows. Both plans deliver "at least once" — an application that can’t tolerate a duplicate action needs to make that action idempotent itself.

There’s no CLI command group for Standard logic apps (they’re deployed as a Function-app-shaped resource via Bicep/ARM or the Azure Functions Core Tools instead); the Consumption az logic workflow group above covers only the multi-tenant plan. See What is Azure Logic Apps? and az logic workflow command reference.

Both are managed services for pushing real-time updates to connected clients over WebSockets (falling back to other transports), so applications don’t have to operate their own long-lived-connection infrastructure or scale-out backplane. Azure SignalR Service is the managed backend for ASP.NET’s own SignalR programming model — hubs, Clients.All/Group/User, strongly-typed hubs — covered for ASP.NET Core in SignalR and for the OWIN-hosted SignalR 2 in SignalR 2; using it means changing the app’s SignalR configuration to point at the Azure service instead of running a self-hosted backplane, without changing hub code. Azure Web PubSub is the protocol-agnostic sibling: a lower-level connection/group/user model over plain WebSockets and a REST API, aimed at applications not already built on the SignalR hub abstraction (a non-.NET backend, a custom client protocol, or a Socket.IO/MQTT-based client) that still need the same broadcast/group/user delivery patterns and managed scale. Choosing between the two is really "does this application already speak SignalR’s hub protocol" — if it does (or is a new ASP.NET Core project), stay on SignalR Service and the pages linked above; otherwise Web PubSub is the more general fit.

See What is Azure Web PubSub service? and az webpubsub command reference.

The services above sit on a spectrum from commands (tell one specific consumer to do one specific thing, reliably and in order) through events (announce that something happened, let zero or more interested parties react) to streams (a durable, replayable log of many events, read at each consumer’s own pace) and push (shove data straight at connected clients rather than another backend service):

A Storage Queue created inside an existing storage account used for other purposes is removed on its own instead of deleting the whole account: az storage queue delete --name thumbnail-jobs --account-name stbookshelf --auth-mode login.