Choosing a Compute Service

Microsoft’s Azure Architecture Center publishes a compute decision tree that starts from the same two questions every one of Bookshelf’s services answers before choosing a target: is this a migration of something that already runs somewhere else, or a new build; and, for a new build, how much control over the underlying OS and orchestration does it actually need. The flowchart below mirrors that tree’s shape, narrowed to the options this documentation section covers:

References: Choose an Azure compute service.

A Virtual Machine (VM) is the IaaS baseline: Azure provisions and patches the hypervisor and hardware, and everything above that — OS, runtime, patches, processes — is the operator’s responsibility. Reach for a VM when a workload needs full OS control, a specific kernel/driver combination, licensing tied to a particular OS image, or a lift-and-shift of an existing on-premises server with no appetite to re-platform it yet.

A VM is defined by four choices: an image (a marketplace, custom, or shared-gallery OS image), a size (the SKU that fixes vCPU/RAM/network/disk throughput, e.g. Standard_D2s_v5), one or more disks (an OS disk plus optional data disks, each with its own storage SKU — Standard HDD/SSD, Premium SSD, or Ultra Disk), and a network profile (a virtual network, subnet, and public/private IP).

A Virtual Machine Scale Set (VMSS) is a group of identical, load-balanced VMs managed as one resource, created from the same image/size/network profile and scaled in or out either manually or by an autoscale rule attached through Azure Monitor. It is the IaaS answer to "many interchangeable VM instances" the way an availability set or zone is the answer to "a handful of specific ones" — a scale set can itself span zones for the same datacenter-loss protection described above, at the group level rather than per instance.

Azure Virtual Desktop is a desktop- and app-virtualization service, not a general compute target for backend workloads: it streams full Windows 11/10 desktops or individual RemoteApp applications — including a multi-session Windows configuration that lets many users share one underlying VM’s OS overhead — to any device over the same Remote Desktop Protocol stack Windows admins already know, with Azure hosting the session hosts (themselves ordinary VMs, sized and imaged as above) plus the connection broker, gateway and load-balancing control plane so nothing outside those session-host VMs needs to be run or patched directly. It belongs on this page only because the decision tree’s "need full OS control" branch forks here: pick Azure Virtual Desktop over a plain VM specifically when the requirement is an interactive remote desktop or published app for end users, not a headless service.

References: What is Azure Virtual Desktop?.

Azure Container Instances (ACI) runs one or a handful of containers directly, with no VM to provision or patch and no orchestrator to run: az container create returns a running container group in seconds, billed per second for the CPU/memory actually requested. It fits a short-lived job, a burst of parallel work, a build agent, or any single/few-container task that doesn’t justify Container Apps' or AKS’s always-on control plane — compare with Container Apps and AKS Clusters once a workload grows past that.

Remove everything created on this page in one step once done experimenting:

If a VM created above was left running under a different resource group, deallocate it first so compute billing stops immediately rather than waiting on the group deletion to finish:

References: az group delete.

The table below covers control, scaling, scale-to-zero, networking, pricing model and the short version of "when to use it" for every compute option this documentation section touches. Each PaaS/container row links to the page that covers it hands-on.