Learn

VMs, Networking, and Boundaries

Virtual machines are the option you choose when direct machine control becomes a requirement. In Entra-adjacent systems, that usually happens at the hybrid edge: agents, connectors, legacy dependencies, private targets, or software that cannot run comfortably inside the default serverless model.

This page is not a general Azure networking guide. It focuses only on the machine and network boundaries that directly affect Entra-backed architecture choices.

When VMs Still Matter

VMs are usually justified when one of these is true:

  • a connector or agent requires direct machine access,
  • a workload depends on OS-level software, drivers, or runtime control,
  • the target system is reachable only from a private or on-premises network,
  • the component has to live near legacy systems that do not expose cloud-friendly interfaces.

If none of those conditions apply, Functions or another managed compute option is usually a better default.

Why Network Boundaries Matter

Identity systems often cross trust boundaries. Even when the control plane is cloud-hosted, the systems it touches may sit behind private addressing, datacenter firewalls, or regulatory controls.

That is why networking shows up alongside VM decisions. The important concepts are:

  • VNets for defining private network boundaries in Azure.
  • NSGs for controlling which traffic is allowed in or out of subnets and interfaces.
  • Private endpoints for reaching supported Azure services over private IP paths instead of public exposure.
  • Hybrid connectivity such as VPN or ExpressRoute when Azure-hosted components must reach on-premises systems.

These are not optional details when the workload has to cross from Entra into private environments.

Typical Entra-Adjacent Cases

You are likely in this territory when:

  • a sync or provisioning companion service needs to reach on-premises directories or applications,
  • a VM-hosted worker runs near private line-of-business systems,
  • a locked-down target allows calls only from approved network paths,
  • security policy requires private access to storage, messaging, or data services that the worker depends on.

In each case, the architecture is shaped as much by reachability and trust boundaries as by the application code itself.

Why Boundaries Change Service Choices

Once network isolation and machine control become first-order requirements, some earlier defaults stop being obvious.

  • Functions may still fit, but VNet and dependency requirements can push hosting choices away from the lightest serverless option.
  • Private endpoints may become necessary for Storage, Cosmos DB, or messaging services that were originally planned with public access.
  • VMs may become the cleanest way to host agents or software that must stay inside a tightly controlled segment.

The mistake is to treat networking as an implementation detail after the service choices are already fixed. In hybrid identity systems, boundary design often drives the service selection.

Keep Scope Bounded

This topic stays focused on the architecture consequence of these boundaries, not on full network engineering. If you need deep product-specific sync or provisioning behavior at the hybrid edge, use:

Practical Guidance

Treat VMs as the exception you choose deliberately, not the starting point. When direct machine control, private reachability, or hybrid integration demands it, VMs and networking boundaries become central design elements. When those pressures are absent, prefer managed compute and simpler public service boundaries.