What Is an Azure VM Actually Made Of?

Disks, NICs, fault domains, and the metadata service — the inside view nobody shows you

When you create a VM on Azure and the portal shows you one item called “vm-web”, it looks like you made one thing. You did not. You made six. And the reason this matters is that each of those six things has its own lifecycle and its own billing. Miss this and you will end up with orphaned disks quietly charging you for months after you thought you cleaned everything up.

The VM itself is just a config record

People picture a VM as a computer. On Azure, the VM resource is closer to a specification. It says: this many vCPUs, this much RAM, boot from this disk, connect through this network card. The actual CPU and RAM come from a physical host in the datacenter running a hypervisor. When you create a VM, Azure finds a host with free capacity and carves a slice out for you:

Physical host (one server in the datacenter)
  96 physical cores, 384 GB RAM, running Hyper-V

  your vm-web        (2 vCPUs, 8 GB RAM)
  another tenant     (4 vCPUs, 16 GB RAM)
  another tenant     (8 vCPUs, 32 GB RAM)

The VM resource provides compute — the CPU and RAM slice — and ties the other pieces together. The disk, NIC, and public IP are all independent resources. This is why the disk survives when you delete the VM. The compute allocation disappears, but the storage object stays.

The disk: network-attached, not a physical drive

The OS disk is an Azure Managed Disk. Physically it is block storage sitting on Azure’s storage infrastructure, connected over the network — not a drive physically inside the host. From the OS perspective it behaves like a local SSD. But it is completely decoupled from compute.

Two important billing facts:

Standard SSD and Premium SSD are billed for the full provisioned size. A 30 GB disk bills you for 30 GB whether you used 2 GB or 29 GB. Standard HDD is different — it bills based on actual used space. Worth knowing before you provision large disks and leave them empty.

The disk is billed by the hour, always, as long as it exists. Even when the VM is off.

The behaviour that gets everyone:

Delete VM, keep disk   -> disk survives, data survives, storage billing continues
Delete VM + disk       -> everything gone, billing stops
Delete VM (default)    -> DISK SURVIVES AND KEEPS BILLING YOU

Azure does not delete the OS disk when you delete the VM by default. It stays as an orphaned resource. Always check after cleanup.

Because the disk is independent, you can also detach it from a dead VM and attach it to a healthy one. This is how you recover data from a crashed machine — detach the disk, mount it on a clean VM, read what you need.

OS disk vs data disk

The OS disk holds Ubuntu. Data disks are separate disks you attach for application data — database files, uploads, logs. In production you always keep them on separate disks because you can resize, snapshot, detach, and reattach a data disk without touching the OS. If the OS disk ever gets corrupted, your data disk is unaffected.

A database VM in production has the OS on one disk and the database files on a separate always-backed-up data disk. Those are two separate managed disk resources.

Managed disk vs ephemeral disk

There are two ways to back an OS disk.

Managed disk (default) — persistent, stored on Azure’s remote storage, survives VM deletion, billed until you delete it explicitly.

Ephemeral disk — stored on the physical host’s local SSD, not remote storage. Created when the VM starts, gone when it stops. Near-zero added cost. Much faster read/write.

Two things to know about ephemeral before you use it:

First, not every VM size supports it. Only Premium Storage VM sizes support ephemeral — DS, ES, FS, GS, M series. B-series (burstable) support is limited. You need a size that has enough local cache storage to hold the full OS image.

Second, and this is the big one: a VM with an ephemeral disk cannot be deallocated. Only restarted, reimaged, or deleted. There is no “off but keep the VM” option. For a learning setup this is painful. For a Kubernetes node pool or a stateless web server it is completely fine — those VMs are disposable by design.

The right way to choose:

Ephemeral   your pipeline can rebuild the OS from scratch in minutes
            the VM is disposable and stateless
            used by AKS node pools and scale sets

Managed     the VM has config or data that would be painful to rebuild
            you are still learning and want to keep state between sessions
            any database or file server

Fault domain and update domain

In the VM metadata you see platformFaultDomain: 0 and platformUpdateDomain: 0. These only matter when you run multiple VMs for the same workload.

Fault domain is about hardware failure. VMs in the same fault domain share a physical rack — same power supply, same switch. If that rack goes down, all of them go down together. Azure spreads VMs across fault domains so one rack failure does not kill your whole service.

Update domain is about planned maintenance. Azure patches and reboots VMs in one update domain at a time. VMs in the same domain get rebooted together. Spread across domains, at least one VM is always running during maintenance.

A single VM like ours gets 0 for both. It has no redundancy. Azure can reboot it for maintenance whenever it needs to. Availability Sets and Availability Zones are how you spread VMs properly — this will be disscussed in later article.

The metadata service

Inside the VM, there is an HTTP endpoint at 169.254.169.254:

curl -s -H "Metadata:true" \
  "http://169.254.169.254/metadata/instance?api-version=2021-02-01" \
  | python3 -m json.tool

It only works from inside the VM. No credentials needed. It tells the VM everything about itself — region, size, subscription, resource group, the public key that was injected at boot. In production, applications use this to self-configure without hardcoding anything. A deployment script can ask “which region am I in?” and adjust its behaviour. It is small, but it is the bridge between your code and the cloud it runs on.

Follow for more intresting stuff !!