Learn

Private Connectivity and Hybrid Boundaries

Private connectivity changes architecture earlier than many teams expect. In Entra-adjacent systems, the identity control plane may stay cloud-hosted and public, but the systems around it often do not: target applications, companion services, connectors, data stores, and VM-hosted workers may need private network paths or hybrid reachability. Once that pressure appears, service selection and operating assumptions both change.

Read this after VMs, Networking, and Boundaries for the baseline mental model and Hybrid Worker on VM for one concrete pattern.

[!IMPORTANT] Scope guard: this page does not try to cover AKS, Azure SQL, API Management, or full observability-platform design for the initial release. It stays focused on private connectivity and hybrid boundaries that directly affect Entra-adjacent infrastructure choices.

Start With The Boundary, Not The Service

The first question is not “should this run on a VM or Functions?” It is “what can reach what, and over which network path?”

That framing usually exposes one of four situations:

  • the workload only needs outbound calls to public cloud services,
  • the workload needs outbound access to private Azure services,
  • the workload needs inbound access from a controlled network path,
  • the workload must cross into on-premises or otherwise hybrid networks.

Each case changes what a safe default looks like.

Private Endpoints Change Default Assumptions

Private endpoints matter when Azure services such as Storage, Cosmos DB, or messaging resources should be reached over private IP paths instead of public endpoints.

In this topic, that usually happens because:

  • a worker handling identity data must stay inside a private network boundary,
  • policy forbids public access to supporting data services,
  • the hybrid side of the system already depends on VNet-based routing and trust boundaries.

The design consequence is that compute hosting can no longer be chosen in isolation. A function app or worker that needs those services must have compatible network reachability, which can push the architecture away from the lightest default hosting choice.

VNet Isolation Is About Reachability And Trust

A VNet is not just an Azure checkbox. It is the boundary that determines which components can communicate privately and what traffic rules apply.

For Entra-adjacent systems, VNet isolation often exists to keep these surfaces controlled:

  • worker access to private data stores,
  • connectivity from Azure-hosted components into hybrid targets,
  • separation between operator-facing services and backend processing surfaces,
  • controlled egress toward downstream enterprise systems.

The useful design question is whether the workload’s security or reachability requirements depend on that isolation. If they do, the network boundary is part of the architecture, not a later deployment concern.

Outbound And Inbound Expectations Are Different

Teams often say a workload is “private” without separating outbound from inbound connectivity.

Outbound-focused workloads

Many Entra-adjacent workers mostly need to call outward:

  • call Microsoft Graph,
  • reach a private endpoint for Cosmos DB or Storage,
  • send or receive workflow messages,
  • connect to a private target system over hybrid networking.

These workloads are primarily shaped by what network paths they can originate.

Inbound-sensitive workloads

Some components also need controlled inbound access, such as:

  • an internal operator tool reachable only from a trusted network,
  • a VM-hosted connector listening inside a hybrid enclave,
  • a self-hosted integration component that other private systems contact directly.

These workloads usually narrow the hosting options further because inbound network policy and machine control start to matter alongside application code.

The distinction matters because many serverless-friendly workloads are outbound-only. Once inbound expectations appear, VM-hosted or more tightly networked designs become more likely.

Where VM-Hosted Or Hybrid Components Still Appear

VM-hosted components are still common when one of these pressures is real:

  • the target system is reachable only from on-premises or private network paths,
  • the integration depends on OS-level software, drivers, or vendor agents,
  • the team needs host-level control for connector operation or policy reasons,
  • the workload must sit beside legacy systems that cannot be cleanly exposed to cloud-native runtimes.

In that model, the VM is not the center of the platform. It is the boundary component that lets the rest of the cloud-side workflow reach the hybrid edge safely.

That is why the pattern in Hybrid Worker on VM keeps cloud messaging and state outside the machine where possible.

Private Connectivity Usually Pulls Other Services With It

Once a system needs private reachability, the surrounding service choices often move together.

Examples:

  • a worker that needs private Cosmos DB access may also need private Storage access,
  • a hybrid component receiving workflow steps may force messaging choices to account for private network reachability,
  • secret handling, egress rules, and DNS behavior become part of the runtime design, not just deployment details.

This is why “we can add private networking later” is often optimistic. The later you add it, the more likely you are to discover the current compute or service choice assumed public defaults that no longer hold.

Failure Modes At The Boundary

Private and hybrid designs fail differently from public-default designs.

Common failure modes include:

  • a component can reach Graph but not the private state store it also depends on,
  • DNS or routing assumptions break access to private endpoints,
  • a worker is deployed in Azure but cannot reach the on-premises target consistently,
  • teams move a service behind private access without updating every dependent runtime,
  • operators discover too late that the chosen hosting model cannot satisfy the network boundary cleanly.

Mitigation patterns:

  • design and test the network path as part of the architecture, not only at deployment time,
  • keep the private boundary narrow and explicit,
  • avoid storing workflow coordination only on the VM when cloud services can own it more safely,
  • use VM-hosted components only where machine control or boundary placement is genuinely required.

Keep The Topic Bounded

This page is intentionally narrower than Azure networking guidance in general. It explains how private connectivity and hybrid boundaries change the architecture around Entra-backed systems. It does not try to teach full network engineering, and it does not replace the deeper product-specific topics for hybrid identity behavior:

Practical Recommendation

Treat private connectivity as an early design constraint whenever an Entra-adjacent system must reach private Azure services, hybrid targets, or host-bound connectors. Prefer outbound-friendly managed compute when the network boundary allows it, and introduce VM-hosted or hybrid components only where machine control or placement at the boundary is the real requirement.

If the architecture depends on private paths, VNet isolation, or hybrid reachability, choose the compute and supporting services with those boundaries in mind from the start.