AZ-305 Compute Design: Virtual Machines, Scale Sets, Containers, Functions and Azure Batch

Choose the compute service by asking what the workload needs control of, then picking the most managed option that still meets every stated requirement. The official skill is to specify the components of a compute solution from workload requirements, and Microsoft's compute decision tree follows the same logic: the more of the stack you must control, the further down you go towards virtual machines; the less you need, the more Azure can run for you.

Two habits decide most design questions. First, read every requirement: a phrase such as "no container images to build", "no Kubernetes experience", "must scale to zero" or "Windows-only modules" usually rules out one plausible service each. Second, when several options work, "minimize administrative effort" points to the platform service and "minimize cost" points to the option that bills least for the stated usage pattern, not to the cheapest-sounding product. A requirement for Windows, for example, doesn't by itself mean a VM: App Service on a Windows plan hosts ASP.NET sites with no operating system to patch, while Container Apps (Linux only) can't, and Windows node pools or Windows scale sets bring a cluster or operating systems to manage.

High availability across zones and regions, backup and disaster recovery, deployment pipelines and migration tooling are separate AZ-305 tasks; this lesson covers choosing and shaping the compute itself.

Pick the VM family that matches the workload's resource shape — memory per vCPU, CPU per GB, local storage, GPU or low-latency networking — and then the size within it. Azure names families by letter, and the letter tells you what the size is optimised for.

The distinctions that matter most in design scenarios are near twins. A workload with little CPU but a dataset that must stay in RAM needs memory optimised sizes, not compute optimised ones. A mostly idle machine with short spikes is the burstable B-series case: the VM earns credits while it runs below its baseline and spends them when it bursts. A simulation split across many nodes that exchange messages constantly is limited by node-to-node latency, and only the HPC sizes with InfiniBand fix that; faster CPUs (F-series), GPUs (N-series) or local NVMe (L-series) improve a resource that isn't the bottleneck.

Turning machines off is also a sizing decision. Auto-shutdown on a schedule deallocates a VM outside working hours: compute billing stops while the managed disks are kept (and still billed for storage), and the VM can be started again when needed.

Isolation options: Azure Dedicated Host and confidential VMs

When a requirement is about who shares the hardware, use Azure Dedicated Host; when it is about protecting data in memory from the host, the hypervisor and operators, use confidential computing. They answer different questions and are often confused.

Dedicated hosts also give you control of platform maintenance: assign a maintenance configuration with a recurring custom window to the hosts, and Azure applies platform updates during the hours you choose. Proximity placement groups (keep VMs physically close for low latency) and availability sets (spread VMs across fault domains) control placement, not tenancy, so neither meets a "no other customers on our servers" rule.

Azure has four main ways to lower VM cost, and they act on different parts of the price: reservations and savings plans discount compute in exchange for a commitment, Azure Hybrid Benefit removes the licence charge, and Dev/Test pricing applies only to non-production use.

Because Hybrid Benefit acts on the licence portion and a reservation (or savings plan) on the compute portion, they stack: a fixed fleet of Windows Server VMs running around the clock for years, owned by a customer with Software Assurance, gets the largest saving from a reservation plus Hybrid Benefit. Microsoft positions reservations for stable usage of a known size and region and savings plans for flexibility; a savings plan gives up some discount in exchange for following workloads as they move between families, regions and services, without exchanges.

Commitments bill every hour of the term whether or not you use them. A fleet that runs a few hours a week can't consume a reservation or savings plan; for interruptible work like that, Spot pricing (below) is the larger saving, and for steady work Spot is wrong because it can be evicted.

Azure Spot VMs and eviction policies

Azure Spot VMs run on Azure's surplus capacity at a deep discount, and Azure can evict them at any time when it needs the capacity back or when the price rises above your maximum, so they suit only interruptible work. Spot VMs have no SLA, and Spot isn't offered for every size (B-series burstable sizes, for example, aren't available as Spot).

Good Spot workloads are restartable and keep nothing important on the VM: render frames that a manager retries, load tests that a harness reruns, batch jobs that checkpoint to storage, dev/test environments. Production services that must stay up, or machines people need available during working hours, are not Spot workloads.

The maximum price setting is separate from the policy. Setting the maximum price to -1 means the VM is never evicted for price reasons and you pay up to the standard pay-as-you-go rate, but Azure can still evict it for capacity. It therefore doesn't protect data; only the Deallocate policy keeps the disks. With the Azure CLI, the choice appears as az vm create --priority Spot --eviction-policy Deallocate (or Delete), optionally with --max-price.

A Virtual Machine Scale Set manages a group of load-balanced VMs that scale in and out together, and its orchestration mode — Flexible or Uniform — decides what the group can contain. Flexible orchestration is Microsoft's recommended mode for new scale sets.

The orchestration mode is chosen when the scale set is created and can't be changed afterwards. If a Uniform set needs to mix sizes or priorities — for example because capacity shortages for its single size have blocked scale-out — the route is a new Flexible scale set placed in the same load balancer backend pool, then draining the old one. Mixing sizes is also a resilience tactic: if one size is short of capacity, the set can still grow with another. An availability set is not an alternative here; it has no autoscale.

Autoscale: metric rules and schedules

Scale set autoscale combines metric-based rules (for example, add instances when average CPU stays above a threshold) with schedule-based profiles (a recurring profile that changes the minimum, maximum and default instance counts at set times). A metric rule only reacts after load has arrived, so when a peak is known in advance and new instances take minutes to boot and warm up, a recurring profile that raises the minimum count before the peak is what gets warm capacity ready in time; keep a metric rule for unplanned spikes. Tuning the metric rule itself still leaves you reacting after the load has arrived.

Azure has four main places to run containers, and the choice depends on whether you need orchestration, the Kubernetes API, or simply a web host.

The decisive line between Container Apps and AKS is the Kubernetes API. Container Apps runs on Kubernetes but deliberately doesn't expose the API, so Helm releases, operators and CRDs can't target it; AKS can run Dapr or KEDA too, but then the team designs, upgrades and operates the cluster. Container Apps runs Linux container images only, so Windows containers (for example a .NET Framework app) need AKS Windows node pools or App Service on Windows instead. Container Instances is a building block: when you need scaling rules, ingress or service discovery, move up to Container Apps or AKS.

AKS node pools: system and user pools, GPU and Spot capacity

An AKS cluster's compute is a set of node pools: system node pools host critical system pods and must keep at least one node, while user node pools host your workloads and can scale down to zero. Designing node pools is how you put special or cheaper capacity in a cluster without paying for it all the time.

• Separate pools for special hardware. Add a user node pool of GPU sizes for training or inference rather than resizing the system pool; every node in the system pool would then be a GPU node, and that pool can't drop to zero.
• Cluster autoscaler. Enabled per pool with a minimum and maximum count, it adds nodes when pods are pending and removes idle ones. A user pool with a minimum of 0 costs nothing until pods need it.
• Taints and tolerations keep pods off nodes. A taint on a node pool repels every pod without a matching toleration, so only the pods you choose land on expensive nodes. A node selector or node affinity only attracts pods to nodes; on its own it doesn't stop other pods being scheduled there. Reserving a pool usually takes both: a taint to repel, and a selector or affinity plus a toleration on the intended pods.
• Spot node pools are user pools only. They run on discounted surplus capacity, can be evicted, and carry the taint kubernetes.azure.com/scalesetpriority=spot:NoSchedule, so workloads need the matching toleration. System components must stay on regular-priority nodes. Checkpointed, restartable batch pods are the intended Spot workload.

A separate cluster for one team's GPU work is rarely the answer: it adds a control plane and operations, and doesn't by itself remove idle GPU cost.

Azure Container Apps scales with KEDA-based rules, and it offers two compute types: apps, which run continuously, and jobs, which start, run to completion and stop.

Scale rules

An app can scale on HTTP traffic, TCP connections or custom KEDA scalers such as an Azure Service Bus queue or Storage queue length. Setting the minimum replica count to 0 lets an app scale to zero when idle, so an empty queue costs nothing; a minimum of 1 keeps a billed replica running. CPU and memory rules can't scale an app to zero, and CPU usage doesn't measure a queue backlog, so a queue-driven app should scale on the queue. A cron scale rule exists, but it only changes the replica count of a long-running app on a schedule.

Jobs

Each job execution is recorded with its status, and a replica retry limit retries failed runs, so jobs give per-run history and retries without VMs or clusters. Use a job when each unit of work needs its own container that ends with the work; use an app when replicas should share a continuous stream of events. Compared with alternatives: Container Instances runs an image but has no scheduler or event scaling of its own, and Functions on Flex Consumption has timer and queue triggers but can't run your own container image.

The Azure Functions hosting plan decides how a function app scales, whether it can reach a virtual network, whether it suffers cold starts, which operating systems it runs on and how it is billed. Microsoft now recommends Flex Consumption for new serverless function apps and treats the original Consumption plan as legacy.

Read the requirements as filters. An app that needs private network access and also scale to zero fits Flex Consumption. Windows-only modules rule out Flex Consumption. Private network access rules out Consumption. Staged releases through a slot swap rule out Flex Consumption and Container Apps hosting. Event-driven scale (for example on queue depth, with no rules to write) rules out Dedicated. When Windows or slots must combine with a VNet, no cold start and event scaling, the Premium plan is the one that meets all of them, at the price of always paying for at least one instance. The Dedicated plan is the right answer when existing App Service capacity is underused and predictable cost matters more than event scaling: functions share the plan already paid for, with Always On enabled so timer and queue triggers keep firing. Flex Consumption also doesn't run custom container images; a function that needs one goes to Premium, Dedicated or Container Apps hosting.

For stateful serverless workflows, Durable Functions is the code-first choice and Azure Logic Apps is the designer-first choice with ready-made connectors; within Logic Apps, Consumption is multitenant and billed per action, while Standard is single-tenant with virtual network support.

Durable Functions patterns

Durable Functions extends Azure Functions with orchestrator functions whose progress is checkpointed, so a workflow resumes after a host restart. The patterns to recognise:

• Function chaining — activities run one after another, each using the previous output.
• Fan-out/fan-in — the orchestrator starts many activities in parallel, waits for all of them, then runs an aggregation step. Plain triggered functions can also run in parallel, but nothing tells you when the whole batch is finished.
• Human interaction — the orchestration waits for an external event (such as an approval) with a timeout.
• Also async HTTP APIs, monitors and aggregators (durable entities).

Logic Apps hosting models

Choose by who maintains the workflow and what it must reach. Developers who want the workflow in code and source control pick Durable Functions. Analysts working in a visual designer with connectors (Office 365 Outlook, SharePoint, SAP, Service Bus) pick Logic Apps: Consumption when volume is low and no private network is needed, Standard when the workflows must reach private endpoints, run on single-tenant compute or deploy as a project. Power Automate targets business-user automation inside Microsoft 365 rather than Azure-hosted, network-integrated workflows.

App Service offers network isolation on the shared multitenant platform through private endpoints and virtual network integration, and full single-tenant isolation through an App Service Environment v3 (ASE v3) deployed in your own subnet.

On the multitenant platform, inbound and outbound networking are separate features:

• Private endpoint (inbound) — gives the app a private IP in your virtual network; with public network access disabled the app has no internet exposure. Available on Basic tiers and above. It carries no outbound traffic.
• Regional virtual network integration (outbound) — routes the app's outbound calls into a delegated subnet, so it can reach private endpoints of databases and other services, or on-premises networks through the hub.
• Access restrictions filter who may call the public endpoint, but the endpoint stays public. Hybrid Connections relay to one host and port through a connection manager you run; VNet integration is the native route into a network.

An internal ASE v3 meets almost any network requirement, but it adds single-tenant infrastructure cost; if the scenario accepts the multitenant platform, a Premium v3 plan with a private endpoint and VNet integration is the cheaper fit. If it demands the whole App Service stack in the organisation's subnet, only ASE v3 qualifies — VMs running IIS could meet the rule but give up the managed platform.

Azure Batch is the managed service for large-scale parallel and HPC batch jobs: it creates pools of compute nodes, queues tasks in jobs, schedules them across nodes, retries failures and scales the pool, so you don't build a scheduler. A scale set or AKS cluster gives you compute but leaves task queueing, scheduling and retries to you, and Functions isn't built for long, heavy tasks.

Dedicated and Spot nodes

A Batch pool has separate targets for dedicated nodes and Spot nodes. Spot nodes are discounted but have no availability guarantee: the pool may not reach its Spot target when surplus capacity is scarce, and allocated Spot nodes can be preempted, in which case Batch requeues the interrupted tasks automatically. Short, independent tasks suit Spot well. When results are due by a deadline, set a dedicated baseline that guarantees progress and a Spot target on top for savings; an autoscale formula can add dedicated nodes when variables such as $PreemptedNodeCount rise. Spot-only is cheapest but risks the deadline; dedicated-only meets it at full price.

Getting software onto nodes

When the install is long, the pool scales out often and jobs must start quickly, a custom image is the answer; when software changes constantly and installs are quick, start tasks or application packages are simpler.

Tightly coupled HPC: multi-instance tasks and Azure CycleCloud

Tightly coupled HPC jobs, such as MPI simulations whose processes exchange data across nodes, run on Azure either as Azure Batch multi-instance tasks or on a traditional scheduler cluster managed by Azure CycleCloud.

A Batch multi-instance task runs a primary task and subtasks across several nodes for MPI. The pool must have inter-node communication enabled and concurrent task execution disabled, which means task slots per node set to 1. If either condition is missing, the task is never scheduled and stays in the active state, even with enough idle nodes. Retry settings don't help, because retries apply only after a task fails. For performance, use RDMA-capable HPC sizes with InfiniBand; preemptible Spot nodes are a poor fit for long, tightly coupled jobs.