12.6 Azure Relay & Hybrid Connections

Azure Relay & Hybrid Connections

The technologies in sections 12.4 and 12.5 publish internal resources to users. Azure Relay solves the mirror-image problem: a cloud-native service — Azure App Service, Azure Functions, or Azure Logic Apps — needs to reach into the corporate network to query an on-premises SQL Server, Oracle database, or internal REST/SOAP API. Standing up a site-to-site VPN gateway or an ExpressRoute circuit for a single database connection is disproportionate, and both alter the network environment.

Azure Relay is deliberately narrower. As Microsoft frames it, "an Azure relay can be scoped to a single application endpoint on a single machine," whereas "the VPN technology is far more intrusive, as it relies on altering the network environment."

---

1. The Relayed Data Transfer Pattern

+-----------------------------------------------------------------------------------+
|                    AZURE RELAY & HYBRID CONNECTIONS DATA PATH                     |
|                                                                                   |
|   [AZURE PAAS ENVIRONMENT]          [AZURE CLOUD]            [INTERNAL NETWORK]   |
|   +-----------------------+         +---------------+        +------------------+ |
|   | Azure App Service     | ======> | Azure Relay   | <====> | Hybrid Connection| |
|   | (Web Front-End)       | Outbound| Service       | Out-   | Manager (HCM)    | |
|   +-----------------------+  HTTPS  | (WCF / Web-   | bound  | (Windows Server) | |
|                              Port   |  Sockets)     | HTTPS  +------------------+ |
|                              443    +---------------+  443            |           |
|                                                                (Local TCP 1433)   |
|                                                                       v           |
|                                                              +------------------+ |
|                                                              | On-Prem SQL Svr  | |
|                                                              +------------------+ |
+-----------------------------------------------------------------------------------+

The mechanism has four steps:

1. The on-premises listener connects out to the relay service through an outbound port.
2. It creates a bi-directional socket tied to a particular address in the relay namespace.
3. The cloud sender communicates with the on-premises service by sending traffic to the relay service targeting that address.
4. The relay service relays data to the on-premises service through the dedicated socket.

The sender never needs a direct connection to the on-premises service, never needs to know where it lives, and the on-premises service never needs an inbound firewall port.

---

2. The Two Relay Features

Both features coexist in the Azure Relay service and share a common gateway, but they are otherwise different implementations. Hybrid Connections is the modern, multi-platform choice; WCF Relay exists for customers with existing WCF programming models.

Naming trap: Azure Relay Hybrid Connections replaced the older BizTalk Services Hybrid Connections feature, which was itself built on WCF Relay. Exam items that mention BizTalk are describing the retired ancestor.

---

3. Namespaces and Shared Access Signature Authentication

Every hybrid connection lives inside a Relay namespace (a Service Bus namespace), and each namespace is pinned to one Azure region — always choose the region hosting the consuming app to avoid added latency. Authentication and authorization use shared access signature (SAS) keys, and the connection is protected with TLS 1.2.

SAS rules are role-split: a listener key authorises the on-premises agent to accept relayed traffic, while a sender key authorises the cloud application to initiate it. A gateway connection string looks like this:

Endpoint=sb://[NAMESPACE].servicebus.windows.net/;SharedAccessKeyName=defaultListener;SharedAccessKey=[KEY];EntityPath=[HYBRID-CONNECTION-NAME]

Each hybrid connection carries a primary and a secondary key so that keys can be rotated without an outage: repoint consumers at the secondary, regenerate the primary, then swap back.

---

4. The Hybrid Connection Manager (HCM)

The on-premises listener agent is the Hybrid Connection Manager, which runs as a service on Windows and Linux.

For high availability, run multiple Hybrid Connection Managers on separate machines for the same hybrid connection; the relay service distributes traffic across them by random assignment. Conversely, a single HCM can serve many hybrid connections.

Troubleshooting order: a status of Not Connected means no HCM with Azure access is configured for that connection — test with Test-NetConnection <relay-namespace> -P 443. A status of Connected while the app still fails points at the endpoint side: confirm the endpoint DNS name resolves from the HCM host and that Test-NetConnection <EndpointDNSname> -P <port> succeeds.

---

5. App Service Hybrid Connections: Limits and Hard Boundaries

Within App Service, each hybrid connection maps to exactly one host:port combination, and the feature is available only on Basic, Standard, Premium, and Isolated plans.

Things Hybrid Connections cannot do — a rich source of distractors:

• Mount a drive.
• Use UDP — TCP only.
• Reach TCP services that use dynamic ports, such as FTP Passive Mode.
• Support LDAP, because LDAP can require UDP.
• Support Active Directory, because an App Service worker cannot be domain-joined.

Exam trap: always configure a hybrid connection with a DNS name rather than an IP address. The redirection is triggered by the app's DNS lookup, so a client library that skips the lookup when given a literal IP will bypass the hybrid connection entirely and fail.