Event Hub Geo-Disaster Recovery
A regional outage in Azure can make your Event Hub namespace unavailable. For systems that process critical data — financial transactions, IoT device telemetry, or order processing — even a few minutes of downtime causes significant impact. Azure Event Hub Geo-Disaster Recovery protects against this by replicating namespace metadata to a secondary region and enabling rapid failover.
What Geo-Disaster Recovery Covers
It is important to understand what Geo-DR replicates and what it does not.
What IS replicated: +-------------------------------------------+ | Namespace Configuration | | - Event Hub names | | - Consumer group names | | - SAS policies and authorization rules | | - Network firewall rules | | - Diagnostic settings | +-------------------------------------------+ What is NOT replicated: +-------------------------------------------+ | Event Data (actual messages) | | - Events in the retention window | | - Unread events in consumer offsets | +-------------------------------------------+
Geo-DR is a metadata failover solution, not a data replication solution. After failover, you get a working namespace in the secondary region, but the event data from the primary region is not available there.
For data-level replication, combine Geo-DR with Event Hub Capture (replicating captured data via Azure Storage geo-replication) or use the Active-Active pattern described later in this topic.
How Geo-DR Works
Before Failover (Normal Operation):
Primary Region (East US) Secondary Region (West US)
+---------------------+ +---------------------+
| Namespace A | | Namespace B |
| (Primary) | ---------> | (Secondary) |
| | Metadata | |
| Alias: myNS | sync | Alias: myNS |
| Event Hub: orders | | Event Hub: orders |
| Consumer Groups | | Consumer Groups |
+---------------------+ +---------------------+
^
|
Producers → connect via ALIAS (myNS)
Consumers → connect via ALIAS (myNS)
Producers and consumers always connect using the Alias name, not the primary or secondary namespace name directly. The alias always points to whichever namespace is currently primary.
After Failover (Primary Region Down):
Primary Region (East US) Secondary Region (West US)
+---------------------+ +---------------------+
| Namespace A | | Namespace B |
| (Unavailable) | | (Now Primary) |
| Alias: myNS -------|----------> | Alias: myNS |
| (alias re-pointed) | | Event Hub: orders |
+---------------------+ +---------------------+
^
|
Producers and Consumers
automatically connect here
(same alias, new target)
Setting Up Geo-DR Pairing
Requirements
| Requirement | Detail |
|---|---|
| Both namespaces must be Standard, Premium, or Dedicated | Basic tier does not support Geo-DR |
| Both namespaces must be in the same subscription | Cross-subscription pairing not supported |
| Secondary namespace must be empty | No existing Event Hubs before pairing |
| Namespaces must be in different regions | Paired Azure regions recommended |
Pairing via Azure Portal
Step 1: Create Primary Namespace
Region: East US
Name: myNamespace-primary
Step 2: Create Secondary Namespace (empty)
Region: West US
Name: myNamespace-secondary
Step 3: Configure Geo-DR on Primary
Primary Namespace → Geo-Recovery (Disaster Recovery)
→ Initiate Pairing
→ Select Secondary Namespace: myNamespace-secondary
→ Set Alias: myNamespace
→ Confirm Pairing
Step 4: Wait for Initial Sync
Status changes from "Pending" to "Succeeded"
Pairing via Azure CLI
az eventhubs georecovery-alias create \
--resource-group myResourceGroup \
--namespace-name myNamespace-primary \
--alias myNamespace \
--partner-namespace /subscriptions/<subId>/resourceGroups/myRG/
providers/Microsoft.EventHub/namespaces/myNamespace-secondary
Connecting Applications via Alias
Producers and consumers must use the alias connection string, not the primary namespace connection string.
# Get the alias connection string (works whether primary or secondary is active) az eventhubs georecovery-alias authorization-rule keys list \ --resource-group myResourceGroup \ --namespace-name myNamespace-primary \ --alias myNamespace \ --name RootManageSharedAccessKey
The returned connection string endpoint will look like:
Endpoint=sb://myNamespace.servicebus.windows.net/
This alias endpoint automatically redirects to whichever namespace is currently active.
Initiating Failover
Failover promotes the secondary namespace to primary. The alias re-points to the new primary.
Failover Process:
Time 0: East US region becomes unavailable
Time 1: Operations team detects outage
→ Monitors show Event Hub metrics stop reporting
Time 2: Trigger failover manually
az eventhubs georecovery-alias fail-over \
--resource-group myResourceGroup \
--namespace-name myNamespace-secondary \
--alias myNamespace
Time 3: Alias re-points to West US namespace
→ All new events flow to West US
→ Consumer connections resume via alias
Time 4: Producers reconnect (usually within minutes)
→ SDK clients detect connection failure
→ Reconnect using the same alias connection string
→ Now connected to West US namespace
Failover Is Manual by Default
Geo-DR failover does not trigger automatically. An operations team must decide when to fail over. This prevents accidental failover during short transient outages.
Recovery Time Objective and Recovery Point Objective
| Metric | Event Hub Geo-DR Value |
|---|---|
| RTO (Recovery Time Objective) | Typically minutes (time to trigger failover and reconnect) |
| RPO (Recovery Point Objective) | Minutes of metadata (event data in transit is lost) |
RPO for event data is not zero. Events in the primary namespace that were not yet consumed or captured are not available in the secondary after failover.
Handling Event Data Loss at Failover
Option 1 – Event Hub Capture + Storage Geo-Replication
Primary Event Hub → Capture enabled → Azure Blob Storage (Primary)
|
| GRS/GZRS replication
v
Azure Blob Storage (Secondary Region)
|
After failover, replay captured
events from secondary storage
Option 2 – Active-Active Pattern (Zero Data Loss)
+------------------+ +------------------+
| East US | | West US |
| Event Hub A | | Event Hub B |
+------------------+ +------------------+
^ ^
| |
+----------------+ +------------------+
| |
Producer Application
(sends each event to BOTH A and B)
Consumer reads from whichever is available.
On failover, consumer continues from Event Hub B.
No events lost — all events exist in both namespaces.
Active-Active doubles throughput capacity cost but achieves near-zero RPO.
After Failover: Re-Pairing
After failover, the old primary (East US) is now the secondary. The old secondary (West US) is now the primary. To restore Geo-DR protection, re-pair in the opposite direction once the old primary region recovers.
After Failover: Primary: West US (myNamespace-secondary) Secondary: (none — pairing broken after failover) Re-Pairing Steps: 1. Old primary (East US) comes back online 2. Clear its Event Hub configurations (it becomes empty) 3. Create new Geo-DR pairing with West US as primary 4. Set alias again 5. Geo-DR protection restored in reverse direction
Geo-DR Limitations
| Limitation | Detail |
|---|---|
| Event data not replicated | Only metadata (configuration) syncs |
| Failover is manual | No auto-failover trigger |
| One secondary only | Cannot pair with multiple secondaries |
| No cross-subscription pairing | Both namespaces must be in same subscription |
| Dedicated cluster required for Premium Geo-DR | Some Premium tier restrictions apply |
Summary
Event Hub Geo-Disaster Recovery replicates namespace configuration to a secondary region and provides an alias endpoint for transparent failover. Applications connect via the alias and reconnect automatically after failover without code changes. Event data itself is not replicated — only metadata. For zero data loss requirements, combine Geo-DR with Event Hub Capture and storage geo-replication, or implement an Active-Active producer pattern. Failover must be triggered manually by an operations team and re-pairing is required to restore Geo-DR protection after recovery.