You closed module 1 with the foundations in place: the account, the billing hierarchy, the rg-contoso-reservas-dev and rg-contoso-reservas-pro resource groups, the mandatory tagging scheme and an Azure CLI script that deploys all of it idempotently. Now the real construction of the platform begins, and we start with the least glamorous and most unavoidable piece: a virtual machine.

Contoso Airlines has a problem that shows up in almost every migration. Their legacy availability engine — the process that works out how many seats are still free on each flight and at what price — is a monolithic Java application written eleven years ago, with operating system dependencies, absolute paths and a service that starts through a home-made script. Nobody on the team is willing to rewrite it before peak season. Diego Salas sums it up in one sentence: "it works, nobody fully understands it, and if we touch it now we don't sell tickets in July".

That application cannot go to a platform service yet. It needs a server with operating system access. In Azure, that means a virtual machine. In this lesson you will learn when a VM is the right answer and when it is expensive laziness, which resources it drags along with it, how to choose size and disk without ruining yourself, how to create and configure it from Azure CLI and — above all — how to shut it down so that it really stops billing, a subtlety that catches almost everyone out the first time.

Cost warning: this lesson creates resources billed by the hour. A Standard_B1s size with a Standard SSD disk costs very little per day, but it does not cost zero. At the end of the lesson you have the full cleanup; run it if you are not going to keep using the VM.

1. VM versus PaaS: when each one makes sense
2. Anatomy of a virtual machine in Azure
3. VM families and sizes: how to read the naming
4. Disks: types, performance and cost
5. Images: marketplace, custom images and galleries
6. Creating the availability engine VM with Azure CLI
7. Connecting over SSH and installing the service
8. Automatic initial configuration: cloud-init and extensions
9. VM states and what is billed in each one
10. Snapshots and images: copies and clones
11. Cleaning up when you finish
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

In lesson 01-02 you saw the shared responsibility model: with IaaS you manage the operating system upwards; with PaaS, only your application and its data. The practical question is not which one is "better", but what forces you to stay down at the bottom.

The real cost of a VM is not the monthly bill: it is the recurring work that comes with it. Operating system patches, backups, configuration hardening, agent monitoring, key rotation. With App Service, a good part of that disappears from your list.

That is why Contoso's decision is recorded like this, and it is worth internalizing because it shapes the whole module:

• The legacy availability engine goes to a VM, as an intermediate and explicitly temporary step.
• Contoso Bookings (the public website) and the new Availability API go to App Service (lesson 02-03).
• The VM is modernized later on, when the team can rewrite the engine; in module 6 you will see where it ends up.

This is exactly what the Cloud Adoption Framework calls rehost ("lift and shift"): move first, optimize afterwards. It is a legitimate strategy as long as the "afterwards" has a date. If it does not, the VM stays for ten years.

When you click "Create virtual machine" in the portal, Azure does not create one resource: it creates several, each with its own lifecycle and its own line on the bill. Understanding this avoids the classic surprise of deleting the VM and carrying on paying.

The resources a VM drags along:

• Operating system disk: a managed, persistent disk. It survives the VM unless you mark it for deletion.
• Temporary disk: local space on the physical host, usually mounted at /mnt (Linux) or D: (Windows). Its contents are lost if the VM is deallocated or moved to another host. It is for swap files and disposable working files. Never for data.
• Data disks: optional, persistent, attached and detached while the VM is running.
• NIC: the virtual network card. It lives inside a subnet of a virtual network.
• Public IP: optional. If it is static, it is billed even while the VM is powered off.
• NSG: the network-level firewall. It can be associated with the NIC or with the subnet (lesson 02-05).

The useful mental rule: the VM is the compute; everything else outlives the VM. That is why module 1 ended with that query for orphaned disks and unassociated public IPs.

Azure offers hundreds of sizes grouped into families, each optimized for a workload profile.

A name such as Standard_D4ds_v5 breaks down like this:

Other suffixes that show up often:

Concrete examples to orient yourself:

• Standard_B1s: 1 vCPU, 1 GB of RAM. Ideal for testing and for labs like the one in this lesson.
• Standard_B2ms: 2 vCPUs, 8 GB. A decent development environment.
• Standard_D4ds_v5: 4 vCPUs, 16 GB. A modest production application server.
• Standard_E8ds_v5: 8 vCPUs, 64 GB. A database on a VM.

To see what is available in your region and at what indicative price, the CLI helps:

az vm list-sizes returns the region's catalog; the --query with JMESPath that you learned in 01-06 filters by prefix and renames the columns. Careful: not every size is available in every region or in every subscription (there are quotas, as you saw in 01-05).

Sizing tip: start small. Resizing a VM in Azure is a matter of minutes (az vm resize), not a project. Oversizing "just in case" is the number one cost mistake in migrations, and Azure Advisor will remind you of it in module 8.

Azure disks are managed disks: you create a disk resource and Azure takes care of the storage accounts, the replication and the availability underneath. Unmanaged disks in your own accounts used to exist; today there is no reason to use them.

Details worth being clear about from the start:

• Performance depends on size in classic Standard and Premium SSD: a P10 disk (128 GB) gives fewer IOPS than a P30 (1 TB). If you need more IOPS, sometimes the answer is a bigger disk, not a more expensive one.
• Only VM sizes with an s in the name support Premium SSD.
• The 99.9% single-instance SLA requires Premium SSD (or better) on every disk of the VM. With Standard disks there is no single-instance SLA; for that you need zones or availability sets, and that is what lesson 02-02 is about.
• The temporary disk is not billed separately, but it is volatile: it is lost when the VM is deallocated or if Azure moves it to another physical host. Treat it as a large /tmp folder.
• Disks are billed by provisioned capacity, not by space used: a 1 TB disk with 10 GB written costs the same as 1 TB. And it keeps costing even while the VM is powered off.

Contoso Airlines' decision for the availability engine:

• Development: Standard_B1s + a 30 GB Standard SSD OS disk. Enough to validate the deployment.
• Production (when the time comes): Standard_D4ds_v5 + Premium SSD, to get the SLA and predictable latency.

An image is the operating system disk template the VM boots from.

• Marketplace images: published by Microsoft or by third parties. They range from clean operating systems (Ubuntu, Debian, RHEL, Windows Server) to appliances with preinstalled software. Some carry an extra hourly license cost on top of the compute: always check the price before deploying.
• Custom images: created from a VM you have already configured. They serve the golden image pattern: you install and harden once, you deploy a hundred identical machines.
• Azure Compute Gallery: the service for organizing custom images with versions, replicating them to several regions and sharing them across subscriptions. It is what you will use when your images stop being one and become a catalog.

Searching for images from the CLI:

An image's full identifier has the format Publisher:Offer:SKU:Version, for example Canonical:ubuntu-24_04-lts:server:latest. Using latest is convenient for testing; in production pin a specific version so that two runs of the same script produce the same thing.

Straight to the point. We create the development VM for the availability engine, with SSH key authentication only (never a password), an economical size and Contoso's mandatory tags.

This creates two files: ~/.ssh/contoso_motor (the private key, which never leaves your machine) and ~/.ssh/contoso_motor.pub (the public key, the one we upload to Azure). If the command asks for a passphrase, set one: it protects the key if your laptop is stolen.

What each option does, one by one:

If you do not specify a virtual network, az vm create creates one with a derived name (vm-motor-disponibilidad-devVNET) and a default subnet. That is fine for the lab; not in production. In lesson 02-05 we will design vnet-contoso-pro with its subnets and connect the VMs there with --vnet-name and --subnet.

Security warning: --nsg-rule SSH opens port 22 to the whole internet (0.0.0.0/0). That is acceptable for ten minutes in a lab; it is not in production. In 02-05 you will see how to restrict it by source IP and, better still, how to use Azure Bastion so that SSH is not exposed at all.

The output includes the assigned public IP. You can also retrieve it at any time:

--show-details (or -d) is what makes az vm show include networking data; without it, the query comes back empty. It is one of those CLI quirks worth memorizing.

Once inside the VM, we simulate deploying the availability engine. The real engine is Java, so we install the runtime and a minimal HTTP service that responds the way the engine would:

From your own machine, check that it responds over the internet. First you have to open port 80 in the NSG, because we only opened 22:

The priority (320) determines the evaluation order: the lower the number, the earlier it is evaluated. In 02-05 you will see the default rules and service tags in detail.

Installing by hand works once. To do it a hundred times identically there are two mechanisms.

cloud-init is the industry standard for configuring a Linux machine on its first boot. You pass a YAML file and Azure injects it.

Save it as init-motor.yaml and use it when creating the VM:

Block by block: package_update refreshes the package index; packages installs; write_files creates files with specific permissions; runcmd runs commands at the end. The first line, #cloud-config, is mandatory and must be exactly that: without it, cloud-init ignores the file. You can verify the result inside the VM with cloud-init status --wait and review /var/log/cloud-init-output.log when something goes wrong.

Extensions are small agents that Azure installs and runs inside the VM after boot, through the Azure agent. Unlike cloud-init, they can be applied to an existing VM and are managed from the control plane.

A practical rule: cloud-init for the immutable base configuration on first boot; extensions for platform agents and for acting on already deployed machines. If you end up writing long scripts in either of them, the real answer is a custom image or a container.

This section is the one that saves the most money in the whole lesson.

Read that again: shutting the VM down from inside the operating system does NOT stop compute billing. Azure keeps the host resources reserved for you. Only deallocation releases the hardware and stops the compute charge.

Consequences of deallocating that you need to know:

• The contents of the temporary disk (/mnt) are lost.
• If the public IP is dynamic, it is released and you will get a different one on start-up. With a static one you keep it, but you pay for it as long as it exists.
• The dynamic private IP can also change on reallocation.

Contoso applies this systematically: the VMs in rg-contoso-reservas-dev are deallocated every night and at weekends. In module 7 you will automate that shutdown with Azure Automation, and in module 8 you will see how much it represents on the bill (typically, more than half the spend of non-production environments).

Two mechanisms that are often confused:

First we get the disk's resource ID (that /subscriptions/.../disks/... string you saw in 01-05) and then we create the snapshot from it. A snapshot takes up space and is billed; delete it when you no longer need it.

For a generalized Linux image, the full process is: sudo waagent -deprovision+user inside the VM, then az vm deallocate, az vm generalize and az image create. A generalized VM can no longer be used: it only serves as an image source. Do not do it with the machine you need tomorrow.

For real backups (with policy, retention and granular recovery) you do not use manual snapshots but Azure Backup, which you will see in lesson 07-05.

az vm delete does not delete by default the OS disk, the NIC or the public IP. When creating the VM you can ask for them to be deleted with it:

Remember that the rg-contoso-reservas-pro group has the no-borrar-produccion (CanNotDelete) lock you applied in 01-05: any attempt to delete something there will fail until you remove it. That is exactly what we want.

• Believing that powering off the VM stops the billing. Only az vm deallocate stops the compute charge. Shutting down from the operating system does not.
• Deleting the VM and leaving orphaned disks and IPs. They are billed for existing. Always check after deleting, or use the --*-delete-option Delete options.
• Storing data on the temporary disk. /mnt is emptied on deallocation or on host migration. Only disposable things go there.
• Oversizing the VM "just in case". Resizing is a two-minute az vm resize with a restart. Start small.
• Opening SSH or RDP to the whole internet. An open port 22 receives automated access attempts within minutes. Restrict it by source IP or use Azure Bastion (02-05).
• Using passwords instead of SSH keys. With --ssh-key-values Azure disables password access. There is no reason to do otherwise.
• Using latest for the image version in production. Two identical deployments can produce different machines. Pin the version.
• Forgetting --show-details in az vm show. Without it you will not see the IPs and you will think the VM has no networking.
• Naming tip: name the disk, NIC and IP explicitly (disco-so-…, nic-…, ip-…). Automatic names with random suffixes turn cleanup into archaeology.
• Licensing tip: if you are migrating Windows Server or SQL Server with Software Assurance, look at Azure Hybrid Benefit (lesson 08-03) before deploying; the saving can exceed 40%.

For each Contoso Airlines case, propose a family, an approximate size and an OS disk type, and justify the choice:

1. A test VM where Diego Salas validates each version of the availability engine; it is used two hours a day.
2. The availability engine in production during peak season: an estimated 4 vCPUs and 16 GB, latency matters, a single-instance SLA is required.
3. An overnight process that recalculates fares: two hours of CPU at 100%, little memory, no meaningful persistence.
4. A legacy reporting server that loads a 48 GB cube into memory.

1. Write an init-motor.yaml that installs nginx, creates /var/www/html/salud.json with {"service":"availability-engine","status":"ok"} and starts the service.
2. Create vm-motor-disponibilidad-dev in rg-contoso-reservas-dev with Standard_B1s, a 30 GB Standard SSD disk, an SSH key and the four mandatory tags.
3. Open port 80 in the NSG and check the response from your own machine.
4. Deallocate the VM and prove with a command that its state is deallocated.

Write the Azure CLI commands that answer these questions in the development subscription:

1. Which VMs are there and what power state is each one in?
2. Are there disks not attached to any VM, and how many GB do they add up to?
3. Are there unassociated public IPs?
4. Which VMs do not have the propietario tag?

Solution 1:

Solution 2:

Solution 3:

Points 2 and 3 are the most common source of invisible spend: they are billed for existing, not for being used.

You now know how to deploy IaaS compute in Azure with judgment. You have seen when a VM is the right answer — Contoso's legacy availability engine, which cannot be rewritten yet — and when it is simply the comfortable, expensive path. You know the full anatomy of a VM and the resources it drags along: OS disk, volatile temporary disk, data disks, NIC, public IP and NSG, each with its own lifecycle. You can read the size naming (Standard_D4ds_v5) and choose a family according to the workload profile, and compare disk types understanding that the single-instance SLA requires Premium SSD. You have created a Linux VM with SSH keys, configured it with cloud-init and extensions, and — the most profitable part of the lesson — internalized the difference between stopped and stopped (deallocated), along with the cleanup that prevents orphaned disks and IPs.

But this VM has an underlying problem that no size fixes: it is a single machine. If the host fails, if there is platform maintenance, or if in April the summer season goes on sale and ten times the usual number of requests arrive, there is no safety net. A single instance has no SLA except with Premium disks, and even then it remains a single point of failure.

In the next lesson, Compute Scaling and High Availability, we solve exactly that: vertical versus horizontal scaling and why the cloud bets on the latter, virtual machine scale sets with automatic metric-based and scheduled rules for Contoso's sales peak, availability zones and availability sets with their fault and update domains, and Azure's four load balancing options compared. By the end you will have the Availability API serving behind a load balancer with two instances in different zones.