What you gain, and what you take on
The old till application needs an operating-system component that the managed web platform cannot provide. Ada chooses a VM and gets the control she needs. She also gets a calendar: patch Tuesday, backup verification, a restart window and someone responsible when it fails. An owned car can take a route the bus will not, but its servicing does not belong to the bus company. Here you learn both halves of that choice.
That control matters when software needs a particular operating system, a licensed component, or a configuration App Service cannot provide. For a straightforward web API, App Service may handle more of the operating work for you. The question is not whether VMs are good or bad. Ask which requirement needs that extra control, then budget for the work it creates.
Series, sizing and images — choosing the machine
A VM size sets the number of virtual CPUs, memory, and other capacity limits. Azure groups sizes into families: B can accumulate CPU credits when it runs below its baseline and spend them during bursts; D is general purpose; E offers more memory; and F favors compute. B-series is a candidate for occasional short spikes, but sustained CPU work can exhaust its credits. Measure the actual job before choosing it. For example, D4s_v5 is a D-family size with four virtual CPUs; the s signals Premium SSD compatibility and v5 is the version.1
An image is the starting copy of an operating system and any prepared software. You might choose a Marketplace image or an approved company image. Then observe CPU, memory, disk, and job duration before resizing. A resize may require a restart and a different size may be unavailable on the current host or in the chosen zone; plan a maintenance window rather than promising a two-minute change. A single VM does not automatically grow or shrink itself.
A VM does not right-size itself. That job stayed with you.
Staying up — availability sets versus zones
A single VM can stop serving when its host fails or restarts. For an application that must remain available, run at least two working copies and direct traffic to a healthy one. An availability set places VMs in different fault domains (groups of hardware that can fail together) and update domains (groups Azure can restart during planned platform maintenance). These VMs remain within one datacenter. Availability zones place copies in separate datacenters within a region. Neither feature makes an application highly available on its own: the copies, traffic routing, data design, and health checks must work together.2
Ask which outage the service must survive. An availability set reduces the chance that one host failure or platform update removes every copy; a datacenter-wide failure can still affect the set. Copies in separate zones can keep serving after one zone fails, provided the application and its dependencies are designed for that failure. Use the current Azure SLA for the chosen configuration when quoting a number. Multiple VMs and a load balancer add cost, so compare the extra protection with the service's recovery target.
| Approach | Spreads across | Survives | Does not survive |
|---|---|---|---|
| Single VM | No second copy | Restart and recovery are possible | No serving copy during a VM outage |
| Two or more VMs in a set | Fault + update domains in one datacenter | Can keep serving through one host or update-domain loss when traffic is routed to a healthy copy | A datacenter-wide disruption |
| VMs in separate zones | Separate datacenters in a region | Can keep serving through one zone loss when the whole application supports failover | Region-wide disruption or a shared dependency failure |
Managed disks and extensions — storage that outlives, code that configures
A managed disk is storage attached to a VM. The OS disk holds the operating system; a data disk can hold application files or job output. A data disk can survive VM deletion and be attached to a replacement, but only if its delete option is set to Detach. Check that setting before deleting the VM. Detached disks can keep billing, and a retained disk is not a backup: accidental deletion or corruption of its data still needs a recovery plan.3 Disk tiers trade price for performance; choose from measured throughput and latency needs.
VM extensions let Azure request management tasks inside the guest operating system. For example, a script extension can run a setup command, and Azure Monitor Agent can collect selected logs and metrics after you configure where to send them. Extensions help automate setup, but they can fail; inspect their result and keep the configuration in source control rather than assuming every VM was configured identically.
The POS batch job gets a right-sized VM — with the catch named
The nightly point-of-sale (POS) reconciliation job runs from 01:00 to 04:00. Start with a VM size that meets its measured CPU, memory, and disk needs; a B-series size is only suitable if the CPU-credit pattern supports the whole job. Store working data on a managed data disk, set its delete option to Detach, and back up data that cannot be recreated. Before a rebuild, verify the disk and backup; a separate disk is reusable, but it is not indestructible.
Set Azure auto-shutdown for after the job, and use a separate scheduler, such as an Automation runbook, to start the VM before the next run. Confirm the VM is deallocated when it should be off; compute billing stops then, but attached disks and other resources may still cost money. Add a check that alerts when the job fails to start. Schedule OS updates in a maintenance window that does not interrupt the reconciliation, and make sure the VM is running for that window.
Play it through
Three minutes. Plan a patch window, then pair shutdown with a separate start schedule so the nightly job can run. Check that the VM is running for updates and that the job succeeds afterward.
Do it for real. The lab for this class is on its own page: Patch, mount and schedule a VM. It is staged: first a small Linux VM and a patch run without SSH, which is the core result. Then a data disk mounted and the auto-shutdown schedule. The start schedule, which auto-shutdown does not come with, is a second level: it adds an Automation runbook and a role assignment, so it needs more permissions. About thirty minutes in all.
Carrying the chore list on purpose
The full VM cost includes more than the hourly compute rate. Plan for the disk, backup, monitoring, patching, networking, and the time your team spends operating it. App Service handles some of these operating-system tasks for a web app; a VM gives you control to do them yourself. Choose the VM when a requirement needs that control, then write down who owns each task.
Next, Part 11e looks at virtual machine scale sets: a way to manage multiple VMs together and change their count based on rules. A scale set helps with fleet management; it does not remove the guest OS, application, update, and recovery responsibilities you met here. Part 11f compares VMs with the lighter compute options.
The bill for a machine that works three hours a night
A VM runs a three-hour job each night but stays on all day. Check the job's measured resource use and its required availability first. Then schedule a start before the job and auto-shutdown afterward. Verify the VM reaches the deallocated state and alert if the job misses a run. This reduces billed compute hours, while managed disks, backups, and other attached resources may still incur charges. Add a separate powered-on maintenance window for OS updates.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. Place working copies in separate availability zones to reduce the impact of a datacenter-level failure. You also need traffic routing, health checks, and dependencies that can fail over; zones alone do not keep an application running. An availability set spreads VMs across hardware and update groups in one datacenter. A larger VM or extra disk does not provide a second serving copy.
B. Auto-shutdown does not supply a matching start schedule. Use a separate scheduler to start the VM before the job, confirm the job ran, and verify deallocation after shutdown. Compute billing can stop in the deallocated state; disks and other resources may still bill. A assumes a start feature that is not part of auto-shutdown. C changes capacity, and D changes storage configuration.
OS patching, sizing, and the app and runtime. Those all sit above the line Azure draws at the hardware — on a VM, everything from the guest OS up is yours. The two rejects are Azure's side: the physical host, the virtualisation layer, and the physical disks in the datacenter are the provider's to maintain and replace. This is the shared-responsibility line from Class One drawn at its lowest, most chore-heavy position — which is exactly why a VM is the rung you justify, not the one you default to. Everything you keep here, App Service kept for you in Part B.
POS VM — cost + run plan
1. Size: measured CPU and memory; B-series only if credits last.
2. Data disk delete option: Detach; data also backed up.
3. Auto-shutdown at 04:15; the VM auto-starts itself before 01:00.
4. Job window is 01:00-04:00 nightly.
Line three. Azure auto-shutdown has no matching auto-start. Use a separate scheduler to start the VM before the next job, and alert if either the start or the job fails. Line one is a candidate size to validate against actual CPU credits; line two is safe only if the data disk is configured to detach and the data is backed up. The job window in line four is the stated requirement.
Consider the consequence. The plan looks complete and even cost-aware, so it is approved; the first night runs fine because the VM happened to be on, then auto-shutdown fires and every subsequent night quietly does nothing. The books stop reconciling with no error to page on, and the gap is found weeks later at month-end. Encoding the false belief "shutdown implies start" into a plan is how a cost optimisation becomes an outage.
Separate the two questions being conflated. A backup answers "can I recover the data if it is lost or corrupted?" Availability answers "does the service stay up when a machine fails?" They are different axes, and the colleague has used an answer to the first as if it settled the second. Both matter; neither substitutes for the other.
Show where the single-VM-plus-backup plan breaks. After a host failure, restore takes time, and the service is offline until recovery finishes. If that outage is unacceptable, run another healthy serving copy and route traffic to it. An availability set or separate zones help place those copies, but do not create replication, health checks, or failover by themselves.
Give the calibrated rule. Backups are non-negotiable and orthogonal — keep them regardless. But for a workload that must stay up, add availability: a set for rack-level protection within a datacenter, zones for datacenter-level protection, chosen by the blast radius you must survive. "We have backups" is a true statement that answers the wrong question when the incident is "the host just failed." The mature design carries both, because they insure against different disasters.
Respect the reason before you question it. "We know how VMs work" is a genuine advantage — a team operating tools it understands makes fewer mistakes than one fighting an unfamiliar platform. Do not wave that away. The question is whether the familiarity is worth the chore list a VM hands them for a workload that, on your own description, needs none of the control that chore list buys.
Price the control against the requirement. A standard stateless HTTP API with no special OS needs is the exact shape App Service was built for. On a VM the team would own OS patching, availability sets or zones, disk management, the load balancer, TLS renewal, and start/stop scheduling — all the chores Parts A through C showed App Service absorbing. "Full control" here is control over things they have no special requirement to control, which means it is pure overhead: the all-IaaS instinct from Class Four, wearing the costume of prudence.
Offer a path that honours the real concern. Suggest App Service for this API, and name what would legitimately send it back to a VM — a licensed component that must see a real OS, a dependency App Service cannot host, a compliance rule. If none of those is present, the familiarity argument is answered by the platform doing the operating for them, which frees the very attention they think they are protecting. Choosing App Service is not giving up control that matters; it is declining chores that do not.
Five things worth carrying out of Part D
- A VM hands you everything above the hardware: OS, patching, runtime, app, availability, backup. Most control, longest chore list — chosen deliberately, never by default.
- Series encode the workload shape: B burstable, D general, E memory, F compute. Size from evidence and resize later; a VM does not autoscale itself.
- Availability sets separate VMs across hardware and update groups in one datacenter; zones separate VMs across datacenters in a region. Healthy copies and traffic routing are still required.
- A managed data disk can outlive a VM when its delete option is Detach; confirm the setting and keep a separate backup. Extensions can automate guest setup, but verify that each task succeeded.
- Auto-shutdown stops a VM but does not start it. Pair it with a scheduler, or you fix the bill and break the job.
- Microsoft documents VM size naming and the B-family CPU-credit model. Specific sizes, availability, and prices vary by region. ↩
- Microsoft's availability-set overview distinguishes fault and update domains from zones, and the VM reliability guide explains why placement alone does not guarantee application uptime. ↩
- Microsoft's VM deletion guide describes the Delete and Detach options for attached disks and their ongoing charges. ↩
Size, patch and schedule a virtual machine, and remember that auto-shutdown does not auto-start.
Play the lesson above to stamp this class.