Azure Service Bus
Complete Guide

01What Is Azure Service Bus?

Azure Service Bus is a fully managed enterprise message broker that enables asynchronous, reliable, and decoupled communication between applications — both cloud and on-premises. Think of it as a post office for your applications: one system drops a message in a mailbox (queue), another picks it up later, regardless of whether both are running simultaneously.

02Core Concepts & Terminology

03Queues, Topics & Subscriptions

Queues — Point-to-Point

A queue is a FIFO channel with competitive consumers — only ONE consumer receives each message. Multiple producers can send, and multiple consumers can compete, but each message goes to exactly one worker.

Topics & Subscriptions — Publish/Subscribe

A topic allows ONE message to be delivered to multiple subscriptions independently. Each subscription gets its own copy of every message that matches its filter. Topics require Standard or Premium tier.

Subscription Filters

04Tiers — Basic / Standard / Premium

Azure Service Bus offers three tiers to match different workload requirements and budgets. Basic is ideal for dev/test with simple queues, Standard adds topics and transactions for most production apps, and Premium provides dedicated capacity, VNet isolation, and large message support for enterprise-critical workloads. Choose your tier based on feature needs, throughput requirements, and network security constraints.

05Sending & Receiving Messages

Understanding how to send and receive messages is the foundation of working with Service Bus. The .NET SDK provides a processor-based model for reliable consumption with automatic lock renewal, and supports batch sending for high-throughput scenarios. Always use PeekLock mode in production to ensure messages are not lost if processing fails.

Send a Message — .NET SDK

var client = new ServiceBusClient("your-connection-string");
var sender = client.CreateSender("your-queue-name");

var message = new ServiceBusMessage("{\"orderId\": 123, \"amount\": 99.99}")
{
    ContentType = "application/json",
    Subject = "OrderCreated",
    MessageId = Guid.NewGuid().ToString(),
    TimeToLive = TimeSpan.FromHours(24),
    ApplicationProperties =
    {
        ["Region"] = "EU",
        ["Priority"] = "High"
    }
};

await sender.SendMessageAsync(message);

Receive with Processor (Recommended)

var processor = client.CreateProcessor("your-queue-name", new ServiceBusProcessorOptions
{
    MaxConcurrentCalls = 5,
    AutoCompleteMessages = false
});

processor.ProcessMessageAsync += async args =>
{
    string body = args.Message.Body.ToString();
    Console.WriteLine($"Received: {body}");

    // Process the message...

    // Complete ONLY after successful processing
    await args.CompleteMessageAsync(args.Message);
};

processor.ProcessErrorAsync += args =>
{
    Console.WriteLine($"Error: {args.Exception}");
    return Task.CompletedTask;
};

await processor.StartProcessingAsync();

Message Settlement Actions

Receive Modes

Scheduled & Batch Messages

// Schedule for future delivery
var msg = new ServiceBusMessage("Reminder");
msg.ScheduledEnqueueTime = DateTimeOffset.UtcNow.AddHours(1);
long seqNo = await sender.ScheduleMessageAsync(msg, msg.ScheduledEnqueueTime);

// Cancel scheduled message
await sender.CancelScheduledMessageAsync(seqNo);

// Batch send
using ServiceBusMessageBatch batch = await sender.CreateMessageBatchAsync();
for (int i = 0; i < 100; i++)
{
    if (!batch.TryAddMessage(new ServiceBusMessage($"Message {i}")))
    {
        await sender.SendMessagesAsync(batch);
    }
}
await sender.SendMessagesAsync(batch);

06Dead-Letter Queue (DLQ)

The DLQ is a special sub-queue that receives messages that exceeded max delivery count, were explicitly dead-lettered, had their TTL expire, or failed filter evaluation.

Reading from DLQ

var dlqReceiver = client.CreateReceiver(
    "your-queue-name",
    new ServiceBusReceiverOptions { SubQueue = SubQueue.DeadLetter });

var dlqMsg = await dlqReceiver.ReceiveMessageAsync();
if (dlqMsg != null)
{
    Console.WriteLine($"Reason: {dlqMsg.DeadLetterReason}");
    Console.WriteLine($"Description: {dlqMsg.DeadLetterErrorDescription}");
    Console.WriteLine($"Delivery Count: {dlqMsg.DeliveryCount}");
    Console.WriteLine($"Body: {dlqMsg.Body}");

    // Fix and re-submit, or discard
    await dlqReceiver.CompleteMessageAsync(dlqMsg);
}

07Sessions

Sessions provide guaranteed FIFO ordering and exclusive processing for groups of related messages. They are essential when message sequence matters — such as multi-step order workflows or user-specific event streams. Enable sessions on the queue or subscription at creation time, and use session state to track progress across related messages.

Sessions enable ordered, FIFO processing of related messages. All messages with the same SessionId are delivered in order to the same consumer — critical for order management, user workflows, and financial processing.

// Send with session
var msg1 = new ServiceBusMessage("Step 1: Order Created") { SessionId = "order-456" };
var msg2 = new ServiceBusMessage("Step 2: Payment Received") { SessionId = "order-456" };
await sender.SendMessageAsync(msg1);
await sender.SendMessageAsync(msg2);

// Receive sessions
var sessionProcessor = client.CreateSessionProcessor("session-queue");
sessionProcessor.ProcessMessageAsync += async args =>
{
    Console.WriteLine($"Session: {args.Message.SessionId}");

    // Store/retrieve session state
    byte[] state = await args.GetSessionStateAsync();
    await args.SetSessionStateAsync(BinaryData.FromString("step-2-complete"));

    await args.CompleteMessageAsync(args.Message);
};

08Filters & Actions

Filters control which messages reach each subscription, while actions can modify message properties in-flight. This enables intelligent routing — for example, sending only high-priority EU orders to a specific processor. Use correlation filters for best performance and SQL filters when you need complex expressions.

SQL Filter

-- Only receive Premium EU orders over $100
OrderType = 'Premium' AND Region = 'EU' AND OrderAmount > 100

Create Filter with Action via SDK

var filter = new SqlRuleFilter("Region = 'EU'");
var action = new SqlRuleAction("SET ProcessedBy = 'EUProcessor'");

await adminClient.CreateRuleAsync(topicName, subscriptionName,
    new CreateRuleOptions("EUFilter", filter) { Action = action });

09Security & Authentication

Service Bus supports multiple authentication methods, but Managed Identity with Entra ID RBAC is the recommended approach for production. This eliminates secrets from your code and provides fine-grained access control at the namespace, queue, or topic level. Always follow least-privilege principles by assigning only Sender or Receiver roles rather than the full Owner role.

Managed Identity — Zero Secrets

// No keys in code — uses DefaultAzureCredential
var credential = new DefaultAzureCredential();
var client = new ServiceBusClient(
    "<namespace>.servicebus.windows.net",
    credential);

RBAC Roles

# Assign Sender role via Azure CLI
az role assignment create \
  --assignee <principal-id> \
  --role "Azure Service Bus Data Sender" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/\
Microsoft.ServiceBus/namespaces/<namespace>

10Network Security

Network security controls restrict how clients connect to your Service Bus namespace. While IP filtering is available on all tiers, VNet integration and Private Endpoints require Premium tier. For enterprise deployments, use Private Endpoints to ensure traffic never traverses the public internet and disable public network access entirely.

11Logic Apps Integration

Logic Apps provides built-in connectors for Service Bus that enable no-code/low-code message processing workflows. You can trigger a Logic App when messages arrive in a queue or topic subscription, and use actions to send, complete, abandon, or dead-letter messages. Use Managed Identity authentication to avoid storing connection strings in your Logic App connections.

12Function Apps Integration

Azure Functions offers native Service Bus bindings for event-driven message processing with automatic scaling. The trigger binding processes messages as they arrive, while output bindings let you send messages from any function. Functions scale out automatically based on queue depth, making them ideal for variable-load message processing.

Service Bus Trigger

[FunctionName("ProcessOrder")]
public static async Task Run(
    [ServiceBusTrigger("orders", Connection = "ServiceBusConnection")]
    ServiceBusReceivedMessage message,
    ServiceBusMessageActions messageActions,
    ILogger log)
{
    string body = message.Body.ToString();
    var order = JsonSerializer.Deserialize<Order>(body);

    try
    {
        await ProcessOrderAsync(order);
        await messageActions.CompleteMessageAsync(message);
    }
    catch (Exception ex)
    {
        await messageActions.DeadLetterMessageAsync(message,
            "ProcessingFailed", ex.Message);
    }
}

Topic Subscription Trigger

[FunctionName("HandleBillingEvent")]
public static void Run(
    [ServiceBusTrigger("order-events", "billing",
        Connection = "ServiceBusConnection")]
    string messageBody,
    ILogger log)
{
    log.LogInformation($"Billing event: {messageBody}");
}

Output Binding — Send to Queue

[FunctionName("CreateOrder")]
[return: ServiceBus("orders", Connection = "ServiceBusConnection")]
public static ServiceBusMessage Run(
    [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
{
    string body = new StreamReader(req.Body).ReadToEnd();
    return new ServiceBusMessage(body)
    {
        ContentType = "application/json",
        Subject = "OrderCreated"
    };
}

DLQ Trigger

[FunctionName("ProcessDLQ")]
public static void Run(
    [ServiceBusTrigger("orders/$deadletterqueue",
        Connection = "ServiceBusConnection")]
    ServiceBusReceivedMessage dlqMessage,
    ILogger log)
{
    log.LogError($"DLQ Message: {dlqMessage.MessageId}");
    log.LogError($"Reason: {dlqMessage.DeadLetterReason}");
    // Alert on-call, store in blob, replay to queue...
}

host.json Configuration

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "prefetchCount": 100,
      "messageHandlerOptions": {
        "autoComplete": false,
        "maxConcurrentCalls": 16,
        "maxAutoRenewDuration": "00:05:00"
      }
    }
  }
}

13APIM Integration

Azure API Management can front Service Bus with a REST API, allowing HTTP clients to publish messages without direct Service Bus SDK dependencies. APIM handles authentication, rate limiting, and request transformation before forwarding to Service Bus via its REST API. This pattern is especially useful for exposing messaging capabilities to external partners or legacy systems.

APIM acts as an HTTP facade over Service Bus — clients POST to a REST endpoint, APIM transforms and publishes the message to a queue or topic using Managed Identity.

APIM Policy — Publish to Queue

<inbound>
  <base />
  <!-- Get Managed Identity token for Service Bus -->
  <authentication-managed-identity
      resource="https://servicebus.windows.net"
      output-token-variable-name="sbToken" />

  <!-- Forward to Service Bus REST API -->
  <send-request mode="new"
      response-variable-name="sbResult" timeout="30">
    <set-url>https://{{sb-namespace}}.servicebus.windows.net/{{queue}}/messages</set-url>
    <set-method>POST</set-method>
    <set-header name="Authorization" exists-action="override">
      <value>@("Bearer " + (string)context.Variables["sbToken"])</value>
    </set-header>
    <set-header name="Content-Type" exists-action="override">
      <value>application/json</value>
    </set-header>
    <set-body>@(context.Request.Body.As<string>())</set-body>
  </send-request>

  <!-- Return 202 Accepted immediately -->
  <return-response>
    <set-status code="202" reason="Accepted" />
    <set-body>{"requestId": "@(context.RequestId)"}</set-body>
  </return-response>
</inbound>

14Other Azure Services

Service Bus integrates with a broad ecosystem of Azure services to build complete event-driven architectures. From Event Grid for reactive notifications to KEDA for Kubernetes autoscaling, these integrations extend Service Bus beyond simple point-to-point messaging into a central nervous system for distributed applications.

15vs Storage Queue / Blob / Table

Azure offers both Storage Queues and Service Bus Queues, and choosing the right one depends on your requirements. Storage Queues are simpler and cheaper for basic fire-and-forget scenarios, while Service Bus provides enterprise features like ordering, dead-lettering, transactions, and pub/sub. Use this comparison to pick the right tool for your workload.

16Monitoring & Alerts

Proactive monitoring is critical for maintaining healthy messaging infrastructure. Azure Monitor provides built-in metrics for queue depth, DLQ count, throttling, and errors. Set up alerts on key thresholds — especially dead-lettered messages and throttled requests — to catch issues before they impact your application.

KQL — DLQ Messages in Last 24h

AzureDiagnostics
| where ResourceType == "NAMESPACES"
| where OperationName contains "deadletter"
| where TimeGenerated > ago(24h)
| project TimeGenerated, EntityName, CallerIpAddress, ResultType
| order by TimeGenerated desc

17Geo-DR & High Availability

High availability and disaster recovery ensure your messaging infrastructure survives regional outages. Service Bus Premium offers Availability Zones for intra-region resilience and Geo-DR for cross-region metadata failover. Plan your recovery strategy carefully — standard Geo-DR replicates only metadata, so implement message replay mechanisms for full data recovery.

Geo-Disaster Recovery (Premium only) replicates namespace metadata (queues, topics, subscriptions, policies) to a paired region. Message data is NOT replicated — plan for replay on failover.

18Architecture Patterns

Service Bus enables several proven distributed architecture patterns that solve common challenges in microservices and event-driven systems. These patterns address scalability, reliability, and data consistency across loosely coupled services. Choose the pattern that matches your specific integration challenge — most production systems combine multiple patterns.

19Pricing Overview

Service Bus pricing varies significantly across tiers — from pay-per-operation on Basic/Standard to fixed messaging-unit pricing on Premium. Understanding the cost model helps you optimize spend: batch operations to reduce per-op costs, use correlation filters over SQL filters for cheaper processing, and right-size your Premium messaging units based on actual throughput needs.

20Quick Reference Cheat Sheet

# Namespace endpoint
sb://<namespace>.servicebus.windows.net

# Queue DLQ
<queue-name>/$deadletterqueue

# Topic Subscription DLQ
<topic>/<subscriptions>/<sub-name>/$deadletterqueue

# Connection string format
Endpoint=sb://<ns>.servicebus.windows.net/;
SharedAccessKeyName=<policy>;SharedAccessKey=<key>

// Send
await sender.SendMessageAsync(new ServiceBusMessage("body"));

// Complete
await receiver.CompleteMessageAsync(message);

// Abandon (retry)
await receiver.AbandonMessageAsync(message);

// Dead-letter
await receiver.DeadLetterMessageAsync(message, "reason", "desc");

// Defer
await receiver.DeferMessageAsync(message);

// Receive deferred
await receiver.ReceiveDeferredMessageAsync(sequenceNumber);

// Peek (no lock)
await receiver.PeekMessageAsync();

// Schedule
await sender.ScheduleMessageAsync(message, DateTimeOffset.UtcNow.AddHours(1));