Service Bus Auto Forwarding

Azure Service Bus Auto Forwarding automatically moves messages from one queue or subscription to another queue or topic when they arrive. This happens without any consumer code — Service Bus handles the forwarding internally. Auto Forwarding chains messaging entities together to build multi-hop message flows, aggregate messages from multiple sources, or relay messages across namespaces.

What Is Auto Forwarding?

When Auto Forwarding is configured on a queue or subscription, messages do not stay there. The moment a message arrives, Service Bus immediately moves it to the configured destination entity. The source entity acts as a relay or staging point rather than a final destination.

WITHOUT Auto Forwarding:

[Queue A] <-- message arrives
Consumer must read from Queue A and forward manually to Queue B
Consumer Code: read from A --> process --> send to B

WITH Auto Forwarding:

[Queue A] ----Auto Forward----> [Queue B]
Message arrives at Queue A --> Instantly moved to Queue B
No consumer code needed for the relay step

Auto Forwarding Use Cases

Use Case 1 — Topic Subscription to Queue (Fan-out)

A topic receives one message. Each subscription auto-forwards to a dedicated service-specific queue. Each service reads from its own queue independently.

[Publisher] --> [Topic: order-events]
                    |
                    |-- [Subscription: inventory-sub]
                    |       Auto Forwards To -->  [Queue: inventory-queue]
                    |                                   --> [Inventory Service]
                    |
                    |-- [Subscription: email-sub]
                    |       Auto Forwards To -->  [Queue: email-queue]
                    |                                   --> [Email Service]
                    |
                    '-- [Subscription: billing-sub]
                            Auto Forwards To -->  [Queue: billing-queue]
                                                        --> [Billing Service]

Use Case 2 — Message Aggregation

Multiple regional queues each forward to one global processing queue. The global processor handles all regions without connecting to each regional queue separately.

[Queue: orders-india] ----\
[Queue: orders-us]     ---- Auto Forward ----> [Queue: global-orders] --> [Processor]
[Queue: orders-uk]    ----/

Use Case 3 — Multi-Hop Pipeline

[Queue: raw-orders] --> Auto Forward --> [Queue: validated-orders]
                                              --> Auto Forward --> [Queue: enriched-orders]
                                                                        --> [Final Consumer]

Step 1: Validation service reads raw-orders, processes, sends to validated-orders
Step 2: Enrichment service reads validated-orders, enriches data, sends to enriched-orders
Step 3: Final service reads enriched-orders
(Each stage can be scaled independently)

Configure Auto Forwarding — Azure CLI

Queue to Queue Auto Forwarding

# Create the destination queue first
az servicebus queue create \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --name global-orders

# Create the source queue with auto-forwarding to the destination
az servicebus queue create \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --name orders-india \
  --forward-to global-orders

Subscription to Queue Auto Forwarding

az servicebus topic subscription create \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --topic-name order-events \
  --name inventory-sub \
  --forward-to inventory-queue

Dead Letter Queue Auto Forwarding

az servicebus queue create \
  --resource-group rg-messaging-prod \
  --namespace-name myshopns \
  --name orders \
  --forward-dead-lettered-messages-to dlq-monitor-queue

Configure Auto Forwarding — .NET SDK (Administration Client)

using Azure.Messaging.ServiceBus.Administration;

var adminClient = new ServiceBusAdministrationClient(connectionString);

// Create the source queue with auto-forwarding enabled
var queueOptions = new CreateQueueOptions("orders-india")
{
    ForwardTo = "global-orders"  // Auto-forward all messages here
};

await adminClient.CreateQueueAsync(queueOptions);
Console.WriteLine("Queue created with auto-forwarding.");

Subscription with Auto Forwarding — .NET

var subscriptionOptions = new CreateSubscriptionOptions("order-events", "inventory-sub")
{
    ForwardTo                       = "inventory-queue",    // forward normal messages
    ForwardDeadLetteredMessagesTo   = "dlq-monitor-queue"  // forward DLQ messages
};

await adminClient.CreateSubscriptionAsync(subscriptionOptions);
Console.WriteLine("Subscription with auto-forwarding created.");

Cross-Namespace Auto Forwarding

Auto Forwarding works only within the same namespace. To forward messages across namespaces, use one of these alternatives:

• Use an Azure Function triggered by Service Bus — read from Namespace A, send to Namespace B
• Use Azure Logic Apps with Service Bus connectors
• Use the Service Bus Bridge pattern with a relay consumer

Auto Forwarding Chain Limit

Azure Service Bus allows a forwarding chain of up to 4 hops. A message cannot pass through more than 4 queues or subscriptions in sequence via auto-forwarding.

Allowed (4 hops):
  Queue A --> Queue B --> Queue C --> Queue D --> Final Consumer

NOT Allowed (5 hops -- exceeds limit):
  Queue A --> Queue B --> Queue C --> Queue D --> Queue E --> Consumer

Auto Forwarding and Message Count

A source queue configured for auto-forwarding passes messages through immediately. The message count on the source queue stays at zero during normal operation. If the destination queue is full, messages accumulate in the source queue until space is available.

Source Queue: orders-india
  Message Count: 0 (messages pass through immediately)

Destination Queue: global-orders (Full!)
  Message Count: 10000 (at max size)

Effect:
  Source queue starts accumulating:
    orders-india message count = 500 (waiting for destination to drain)

Dead Letter Queue Auto Forwarding

Configuring ForwardDeadLetteredMessagesTo sends all dead-lettered messages from a queue or subscription to a dedicated monitoring queue. This centralizes DLQ messages from multiple sources into one place for investigation.

[Queue: orders]     DLQ --> Auto Forward --> [Queue: dlq-monitor]
[Queue: payments]   DLQ --> Auto Forward --> [Queue: dlq-monitor]
[Queue: shipping]   DLQ --> Auto Forward --> [Queue: dlq-monitor]

All DLQ messages from all queues go to one place.
Ops team reads only [dlq-monitor] to handle all failures.

Auto Forwarding Permissions

For auto-forwarding to work, the Service Bus namespace must have permission to write to the destination entity. This is handled automatically within the same namespace using the built-in system identity. No extra configuration is needed for same-namespace forwarding.

Summary

Auto Forwarding in Azure Service Bus automatically moves messages from a source queue or subscription to a target queue or topic without consumer code. It enables fan-out patterns from topics to dedicated service queues, message aggregation from regional queues to a central queue, multi-hop processing pipelines, and centralized DLQ monitoring. The forwarding chain supports up to 4 hops within the same namespace. Dead-lettered message forwarding consolidates failed messages from multiple sources into a single monitoring queue. Auto Forwarding is a powerful tool for building decoupled, scalable messaging architectures with minimal application code.