Hybrid Worker on VM

Scenario Setup

An enterprise team needs to synchronize access changes from Entra into a legacy line-of-business system that lives on a private network and exposes only a host-bound connector. The worker must run near that system, use a vendor library that requires machine-level installation, and still participate in the cloud-side identity workflow.

That combination makes a VM-hosted worker the right fit even though the rest of the platform stays cloud-centric.

Why this pattern exists

This pattern exists because some identity workloads are shaped by network reachability and machine control, not just by application code.

When the worker must:

• reach private or on-premises systems,
• run OS-level agents or vendor software,
• live inside a tightly controlled network segment,
• satisfy host-level operational constraints,

the default Functions model stops being the cleanest answer.

Main architecture

flowchart LR
    subgraph cloud["Azure Cloud"]
        msGraph[Microsoft Graph]
        bus[Service Bus]
        state[Cosmos DB or Storage]
    end

    subgraph hybrid["Private or On-Premises Boundary"]
        vm[VM-hosted worker]
        target[Legacy target system]
    end

    msGraph --> bus
    bus --> vm
    vm --> target
    vm --> state
    vm --> msGraph

The important boundary is that the worker lives inside the network segment that can reach the target system, while still exchanging cloud-side messages and state with the rest of the architecture.

Read this pattern together with:

• VMs, Networking, and Boundaries
• Service Bus for Workflows
• Microsoft Graph Control Plane

Why this does not run in Functions

Functions is not the right default here because the workload is constrained by the host and the network boundary.

Typical reasons include:

• the target system is reachable only over private network paths,
• the connector depends on installed software or drivers,
• the team needs stronger control over the machine runtime than serverless compute provides,
• the workload must stay inside a managed network enclave for policy reasons.

This is a boundary-driven architecture decision, not a rejection of serverless in general.

Cloud-side integration surfaces

Even though the worker runs on a VM, it should still interact with cloud services through explicit boundaries:

• Microsoft Graph provides the identity inputs or target state checks.
• Service Bus carries commands or work items to the VM-hosted worker.
• Cosmos DB or Azure Storage stores state and artifacts that should remain outside the machine.

That keeps the VM from becoming an all-purpose silo for workflow coordination.

Where Entra product specifics belong

Hybrid identity scenarios often overlap with existing product surfaces. Use the local topics for those deeper mechanics:

• Entra Connect Sync
• Entra Cloud Sync
• Entra Application Provisioning

This quickstart stays focused on the surrounding platform pattern: how a VM-hosted component fits into the broader architecture.

Trade-offs

This pattern solves real reachability and host-control problems, but it increases operational cost.

• You now own machine lifecycle, patching, and network policy.
• Scaling is more deliberate than in serverless compute.
• Private connectivity and secret handling become first-order concerns.

Choose it because the boundary requires it, not because it feels familiar.

When not to use it

Do not use a VM-hosted worker when Functions or another managed compute service can already reach the target and satisfy the runtime requirements.

It is also the wrong fit when:

• the workload is short-lived and cloud-reachable,
• there is no machine-specific dependency,
• the team is adding VMs only to avoid learning the managed services.

If the network and host pressures are absent, return to the simpler cloud-native pattern.