Azure Relay for Hybrid Connectivity

Azure Relay is a cloud service that facilitates secure communication between services running in different network environments, such as on-premises datacenters and Azure cloud, without requiring direct network connectivity or inbound firewall rules. It is part of the Azure Service Bus family and is designed specifically for hybrid connectivity scenarios where one party (typically the on-premises service) is behind a NAT or firewall that blocks inbound connections.

Azure Relay solves a fundamental problem: many enterprise environments have strict firewall policies that deny all inbound traffic from the internet. Traditional approaches like VPN gateways require opening ports or configuring complex routing. Azure Relay eliminates this need by allowing the on-premises service to initiate an outbound connection to the Relay in Azure, which then maintains a persistent bidirectional socket. Cloud clients connect to the Relay and are transparently connected to the on-premises service through this socket.

Azure Relay uses a relayed communication model. The process involves three actors: - Listener: The on-premises service that registers itself with the Relay. - Relay Service: The Azure-managed endpoint that mediates connections. - Sender: The cloud client that wants to communicate with the listener.

#### Step-by-Step Mechanism: 1. Listener Registration: The listener (on-premises service) opens an outbound WebSocket connection to the Azure Relay endpoint (e.g., wss://your-namespace.servicebus.windows.net/$hc/your-path?api-version=2016-07). This connection is authenticated using a Shared Access Signature (SAS) token. The listener sends a registration request, and the Relay acknowledges, creating a persistent bidirectional channel. 2. Connection Offer: When a sender wants to connect, it sends a request to the Relay with the listener's path. The Relay creates a new, temporary endpoint (a "connect" endpoint) and sends an "offer" to the listener over the persistent channel. The offer includes a unique connection ID. 3. Listener Acceptance: The listener receives the offer and can accept or reject it. If accepted, the listener opens a new WebSocket connection to the provided connect endpoint. This is a separate connection from the persistent channel. 4. Bidirectional Bridging: Once both the sender and listener are connected to the Relay's temporary endpoint, the Relay begins relaying data between them. Data flows through the Relay, which acts as a transparent proxy. The Relay does not inspect or modify the payload; it simply forwards bytes. 5. Connection Teardown: When either side closes the connection, the Relay cleans up the temporary endpoint and notifies the other side. The persistent listener channel remains open for future connections.

Azure Relay is typically configured using the Azure portal, Azure CLI, or ARM templates. Below are essential commands:

Create a Relay namespace:

az relay namespace create --resource-group myRG --name myRelayNS --location eastus

Create a Hybrid Connection:

az relay hybrid-connection create --resource-group myRG --namespace-name myRelayNS --name myHC

Generate a SAS key for the Hybrid Connection:

az relay hybrid-connection authorization-rule create --resource-group myRG --namespace-name myRelayNS --hybrid-connection-name myHC --name myPolicy --rights Listen Send
az relay hybrid-connection authorization-rule keys list --resource-group myRG --namespace-name myRelayNS --hybrid-connection-name myHC --name myPolicy

Verify connection using .NET SDK (listener side):

var listener = new HybridConnectionListener("sb://myRelayNS.servicebus.windows.net/myHC", "sas-key");
listener.Connecting += (o, e) => { Console.WriteLine("Connecting..."); };
listener.Online += (o, e) => { Console.WriteLine("Listener online"); };
await listener.OpenAsync(TimeSpan.FromSeconds(10));

Verify connection using .NET SDK (sender side):

var client = new HybridConnectionClient("sb://myRelayNS.servicebus.windows.net/myHC", "sas-key");
var connection = await client.CreateConnectionAsync();
// Use connection stream for bidirectional communication

A large financial institution has a legacy customer management system running on-premises behind a strict firewall. They are building a new mobile app that needs to retrieve customer data in real-time. The cloud development team wants to call the on-premises API directly, but the network team refuses to open inbound ports. Azure Relay is chosen to bridge the gap. The on-premises service is wrapped with a Hybrid Connection listener that registers with the Relay namespace. The mobile app's backend (running on Azure App Service) uses the Hybrid Connection client SDK to send requests through the Relay. In production, the system handles 500 requests per second during peak hours. The team monitors connection counts and latency using Azure Monitor. A common issue is idle timeout: if the listener does not send data for 60 seconds, the control channel drops. They implement a heartbeat message every 30 seconds to keep the channel alive. Misconfiguration occurs when the SAS token expires (default 1 hour) without renewal, causing all connections to fail. They now use tokens with 24-hour expiry and a background job to refresh tokens before expiry.

A manufacturing company collects sensor data from factory floor devices that cannot connect directly to the cloud. The sensors send data to an on-premises gateway (listener) over a local network. The gateway uses Azure Relay to forward the data to an Azure IoT Hub for processing. The gateway registers as a listener, and a cloud worker role acts as a sender, pulling data from the relay and pushing it to IoT Hub. The system ingests 10,000 messages per second across 50 Hybrid Connections. Scaling is achieved by distributing sensors across multiple gateways, each with its own Hybrid Connection. A common failure mode is when the gateway loses network connectivity; the listener disconnects, and the cloud sender receives errors. The team implements automatic reconnection with exponential backoff and alerts on connection loss. Another issue is that the relay adds a few milliseconds of latency, which is acceptable for sensor data but would not be suitable for real-time control systems.

A retail chain uses an on-premises SQL Server database for point-of-sale transactions and needs to synchronize inventory data with an Azure SQL Database. They use Azure Relay to create a secure tunnel for a custom sync service. The on-premises sync agent acts as a listener, and the cloud sync service acts as a sender. The relay ensures that no firewall ports are opened. The sync runs every 5 minutes, transferring about 10 MB of data each time. The team found that the default 64 KB WebSocket frame size limits throughput, so they switched to TCP Relay mode for larger payloads. They also encountered issues with multiple listeners: if two sync agents registered on the same Hybrid Connection, only one would receive offers, causing data loss. They now use a dedicated Hybrid Connection per agent.