How to privatize hybrid cloud, now possible!
Azure Local now supports private endpoints — finally enabling a truly private‑only connection to Azure PaaS services
One might say this is an oxymoron. It's either a private cloud or a hybrid cloud, Pieter — not both at the same time. That's true. But, with private endpoint now being supported on Azure Local, we now don't have to traverse the public internet any longer. For the first time, Azure Local can consume Azure Storage, Azure SQL, Azure Key Vault, and Azure Container Registry entirely over private IP space, using your own network as the transport.
This is the moment where "hybrid cloud" stops meaning "a private cloud that must rely on public egress exceptions" and starts meaning "a private cloud that satisfies strict network security and regulatory expectations through private‑only access to Azure."
Private endpoints fundamentally change the security and connectivity posture of Azure Local. Instead of relying on public outbound paths, firewall exceptions, or carefully curated FQDN allowlists, Azure Local can now reach Azure PaaS services the same way your datacenter does: privately, predictably, and without exposing anything to the internet.
This unlocks real hybrid patterns:
- Private image pulls from Azure Container Registry
- Private SQL connections
- Private blob ingestion
- Private secrets retrieval from Key Vault
And it does so without compromising the "private" part of your private cloud.
But how Azure Local routes that traffic depends on which of the four deployment methodologies you choose. Each one has a different personality — and a different set of trade‑offs.
Azure Local supports four ways to handle outbound connectivity. They all work with private endpoints, but they behave differently depending on whether you use an enterprise proxy, the Azure Arc gateway, both, or neither. Here's the high‑level view — the version architects actually need.
1. No Proxy, No Arc Gateway
The cleanest and most predictable model.
Azure Local sends traffic directly to Azure using your enterprise network. Public endpoints go out through your firewall; private endpoints go over ExpressRoute or VPN.
Best for: Organizations that want the simplest, most cloud‑native routing.
Pros:
- Minimal moving parts
- Private endpoints "just work"
- Easiest to troubleshoot
Cons:
- Azure Arc still requires public endpoints (Arc Private Link is not supported)
2. No Proxy, With Arc Gateway
Centralizes Arc traffic; everything else routes around it.
Even without an enterprise proxy, enabling the Arc gateway introduces a local HTTPS tunnel that Azure Local tries first. Anything the gateway doesn't support falls back to your firewall.
Best for: Environments that want Arc traffic to stay private but don't need a full proxy.
Pros:
- Arc traffic stays inside your network
- Still supports private endpoints
Cons:
- Some Azure services aren't supported by the Arc gateway
- Private endpoint traffic must bypass the gateway
- More moving parts than Scenario 1
3. Proxy Enabled, No Arc Gateway
Enterprise proxy controls outbound traffic; private endpoints must bypass it.
This is the classic "everything goes through the proxy unless told otherwise" model. Private endpoint traffic cannot use the proxy, so you must maintain bypass rules.
Best for: Enterprises with strict outbound proxy requirements.
Pros:
- Centralized egress control
- Predictable for security teams
Cons:
- Private endpoints require explicit bypass entries
- Misconfigured bypass = silent failures
- More operational overhead
4. Proxy Enabled, With Arc Gateway
The most locked‑down — and the most complex.
Both the enterprise proxy and the Arc gateway are in play. Private endpoint traffic must bypass both. Arc‑supported traffic goes through the gateway; everything else goes through the proxy.
Best for: Highly regulated environments with strict egress control and compliance requirements.
Pros:
- Maximum control
- Arc traffic stays private
- Proxy governs everything else
Cons:
- Highest operational complexity
- Requires two layers of bypass rules
- Hardest to troubleshoot
Across all four models, Azure Local supports:
- Private endpoints for Azure Storage, Azure SQL, Azure Key Vault, Azure Container Registry, and other Private Link–enabled services
- Routing private endpoint traffic over ExpressRoute or VPN
- Using any of the four patterns with Azure Local, AKS on Azure Local, and Azure Local VMs
But there are hard boundaries:
Not Supported
- Azure Arc Private Link for Azure Local (Arc must use public endpoints). Azure Local itself is still using public endpoints. This includes the Azure Local hosts, the Arc Resource Bridge and AKS (with its Arc Agents).
- Sending private endpoint traffic through a proxy
- Wildcard proxy bypass entries (e.g.,
*.azurecr.io) - Private endpoint IP ranges that overlap with AKS reserved ranges
These aren't soft recommendations — they're architectural constraints.
Private endpoints finally give Azure Local a clean, private‑only path to Azure PaaS services. It's the missing piece that makes a "private hybrid cloud" more than a marketing phrase.
But the routing model you choose matters. Each of the four deployment methodologies has a different operational footprint, a different security posture, and a different set of trade‑offs.
Pick the one that matches your environment — not the one that looks simplest on paper.
Further Reading
- Microsoft Learn: Azure Local Private Endpoints