Networking and Private Access

Private connectivity changes architecture earlier than most teams expect. The application code may be straightforward, but once the question becomes “what can reach what, over which network path?” the compute, service, and deployment choices all shift.

This applies to any Azure-hosted platform with security or compliance constraints: regulated SaaS, healthcare backends, financial services, and infrastructure systems including Entra-adjacent identity services.

Start With the Boundary Question

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:

Each case changes what a safe default looks like.

graph TB
    subgraph Internet
        PublicClient[Public Clients]
    end

    subgraph Azure["Azure Subscription"]
        subgraph VNet["Virtual Network"]
            subgraph AppSubnet["App Subnet"]
                Worker[Worker / App Service]
            end
            subgraph PESubnet["Private Endpoint Subnet"]
                PE_Cosmos[PE: Cosmos DB]
                PE_Storage[PE: Storage]
                PE_SB[PE: Service Bus]
            end
            subgraph GWSubnet["Gateway Subnet"]
                VPN[VPN / ExpressRoute<br/>Gateway]
            end
        end

        CosmosDB[(Cosmos DB)]
        Storage[(Storage)]
        ServiceBus[Service Bus]
    end

    subgraph OnPrem["On-Premises"]
        LegacyDB[(Legacy Database)]
        Connector[Connector / Agent]
    end

    PublicClient -->|HTTPS| Worker
    Worker -->|Private IP| PE_Cosmos
    Worker -->|Private IP| PE_Storage
    Worker -->|Private IP| PE_SB
    PE_Cosmos -.->|Private Link| CosmosDB
    PE_Storage -.->|Private Link| Storage
    PE_SB -.->|Private Link| ServiceBus
    VPN <-->|Encrypted tunnel| Connector
    Connector --> LegacyDB
    Worker -->|Via VNet| VPN

    style VNet fill:#e8f4f8,stroke:#333
    style OnPrem fill:#f8e8e8,stroke:#333

Private Endpoints: Reaching PaaS Over Private IP

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

This usually happens because:

• A worker handling sensitive data must stay inside a private network boundary.
• Policy forbids public access to data services.
• The compliance posture requires all data-plane traffic to stay on private networks.

Design implications:

• Compute hosting can no longer be chosen in isolation. A function app or worker that needs private services must have compatible network reachability.
• DNS resolution changes. Private endpoints use private DNS zones; misconfigured DNS is the most common failure mode.
• Each private endpoint consumes a private IP in your subnet. Plan address space accordingly.

VNet Isolation: Reachability and Trust Boundaries

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

VNet isolation typically 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.
• 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 vs Inbound Connectivity

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

Outbound-focused workloads

Many platform workers mostly need to call outward:

• Call external APIs (Microsoft Graph, payment providers, partner services).
• Reach a private endpoint for Cosmos DB or Storage.
• Send or receive workflow messages via Service Bus.
• Connect to a private target system over hybrid networking.

These workloads are shaped by what network paths they can originate. Many serverless-friendly services handle outbound well through VNet integration.

Inbound-sensitive workloads

Some components also need controlled inbound access:

• An internal admin tool reachable only from a trusted network.
• A VM-hosted connector listening inside a hybrid enclave.
• A webhook receiver that only specific partners can reach.
• A self-hosted integration component that other private systems contact directly.

Once inbound expectations appear, hosting options narrow. VM-hosted or more tightly networked designs become more likely because inbound network policy and machine control start to matter alongside application code.

When VMs and Hybrid Components Are Still Needed

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 compliance reasons.
• The workload must sit beside legacy systems that cannot be 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. Keep cloud messaging and state outside the machine where possible.

Private Connectivity 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 will likely need private Storage access too.
• A hybrid component receiving workflow steps may force messaging choices to account for private network reachability.
• Secret handling (Key Vault), egress rules, and DNS behavior become part of the runtime design, not deployment details.
• Monitoring endpoints (Application Insights, Data Explorer ingestion) may also need private paths in strict environments.

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

Failure Modes at the Boundary

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

Practical Recommendation

Treat private connectivity as an early design constraint whenever a workload must reach private Azure services, hybrid targets, or host-bound connectors. Prefer outbound-friendly managed compute when the network boundary allows it. Introduce VM-hosted or hybrid components only where machine control or boundary placement 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. Retrofitting private networking onto a public-default architecture is significantly more expensive than designing for it upfront.

In Entra-adjacent systems, these patterns are common because identity infrastructure often bridges cloud and on-premises environments. Provisioning connectors, hybrid identity agents, and private data stores all create the same private networking pressures described here.