A virtual machine is a software-made computer that runs inside Microsoft’s data centres and behaves like a real one.

A physical computer has a processor, memory, a disk and a network connection. A virtual machine, often shortened to VM, has the same four things, but they are provided by software on a much larger physical server. A special program called a hypervisor divides one powerful server into many separate virtual computers. Each virtual computer believes it owns its own hardware, and each can run its own operating system, such as Windows or Linux.

In Azure, you create a virtual machine in a few minutes by choosing a size, an operating system, a disk and a network. Once it starts, you connect to it over the network, install your software and use it exactly as you would a computer in your own office. When you no longer need it, you delete it and the charges stop.

Azure Virtual Machines belong to a category called Infrastructure as a Service, or IaaS. This means that Microsoft provides the building blocks, such as hardware, power, cooling and the network, while you manage everything from the operating system upwards. That gives you great control and flexibility, and also means that patching, security settings and backups of the inside of the machine are your responsibility.

Words you will meet again and again

Because sometimes you need full control of a computer, without owning one.

Before the cloud, a company that needed a new server placed an order, waited weeks for delivery, paid a large sum in advance and found space in a data centre. If the server turned out to be too large or too small, there was little to do. If the project ended, the server sat idle. Virtual machines in Azure remove these problems. You get a computer in minutes, you pay by the hour, and you can resize or delete it as needs change.

Virtual machines are also the easiest way to move existing applications to the cloud. Many older programs expect a full operating system, specific software versions and settings that a platform service cannot offer. A virtual machine lets you move such an application with few changes. This approach is called lift and shift.

A VM is not one object. It is a small family of connected resources.

When you create a virtual machine in the Azure portal, Azure actually creates several resources and links them together. Understanding each part helps you manage, secure and price a machine correctly.

flowchart TD
  RG["Resource Group"] --> VM["Virtual Machine: size and OS"]
  VM --> OSD["OS Disk"]
  VM --> DD["Data Disks"]
  VM --> NIC["Network Interface"]
  NIC --> SN["Subnet in a Virtual Network"]
  NIC --> NSG["Network Security Group"]
  NIC --> PIP["Optional Public IP"]
        

Azure offers hundreds of sizes, grouped into families built for different jobs.

The size of a VM decides how many virtual processors and how much memory it has, how fast its disks and network can be, and how much it costs per hour. Sizes are grouped into families. Choosing the right family is more important than choosing the biggest size.

Reading a size name

A size name looks like a code, for example a letter followed by a number and some extra letters and a version. The first letter shows the family. The number shows how many virtual processors. Extra letters add features, such as support for premium storage, a different processor brand or local temporary storage. A trailing version number shows the hardware generation. Newer generations usually give better performance for the price.

Burstable VMs

The B-series is special. Its machines run at a modest baseline level of processor use and earn credits while they are idle. When a burst of work arrives, they spend those credits to run faster for a while. They are inexpensive and well suited to light, spiky workloads such as small websites, development machines and low-traffic services. They are a poor fit for steady heavy loads, because after the credits run out, performance drops back to the baseline.

Every VM starts from an image, which is like a photocopy of a prepared computer.

An image contains an operating system and sometimes pre-installed software. When you create a VM, Azure copies the image onto the new OS disk. You can choose from many sources.

Generation 1 and Generation 2

VMs come in two generations that describe the virtual hardware platform. Generation 2 uses a more modern design with support for larger disks, faster start-up and security features such as secure boot and trusted launch. New deployments should normally choose Generation 2 unless an old operating system demands the earlier type.

Customising at start-up

The speed and safety of a VM depend a great deal on its disks.

Azure VMs use managed disks. A managed disk is a virtual hard drive stored in highly durable Azure storage, with Azure handling the hard details of placement and copies. You choose the type and the size, and Azure takes care of the rest.

Three kinds of storage on a VM

A VM is only useful if the right people and systems can reach it, and nobody else can.

Every VM connects to a virtual network through a network interface. The interface lives in a subnet, which is a slice of the network, and receives a private IP address from that subnet. Other resources in the same network, or in connected networks, can reach the VM using this private address.

Peeking behind the curtain explains many behaviours that otherwise seem strange.

Azure data centres contain huge numbers of physical servers, called hosts. A control system inside Azure decides which host should run your new VM, based on the size you chose, the region and zone, the available capacity and rules such as keeping machines apart for resilience. The chosen host runs a hypervisor, based on Microsoft’s Hyper-V technology, which carves out the virtual processors and memory for your VM and keeps it isolated from the other VMs on the same host.

sequenceDiagram
  participant U as You
  participant M as Azure Management Layer
  participant A as Allocation System
  participant H as Physical Host with Hypervisor
  participant V as Your VM
  U->>M: Create VM request
  M->>M: Check permissions, quota and policy
  M->>A: Find a host
  A->>H: Reserve capacity
  H->>V: Create virtual hardware, attach disks and network
  V-->>M: Agent reports ready
  M-->>U: VM is running
        

Why this matters to you

A VM can be in several states, and the billing depends on the state.

flowchart LR
  C["Creating"] --> R["Running"]
  R -->|"shut down inside OS"| S["Stopped but allocated: still billed"]
  R -->|"stop from Azure"| D["Stopped and deallocated: compute not billed"]
  D -->|"start"| R
  S -->|"start"| R
  D -->|"delete"| X["Deleted"]
        

Other useful operations

Hardware fails and hosts need updates, so serious workloads need more than one VM and a smart layout.

A single VM on a single host can be affected by hardware problems or by planned maintenance. Azure offers ways of spreading VMs so that one event does not take down the whole application.

flowchart TD
  LB["Load Balancer"] --> Z1["VM in Zone 1"]
  LB --> Z2["VM in Zone 2"]
  LB --> Z3["VM in Zone 3"]
  Z1 --> D["Zone-redundant Database or Storage"]
  Z2 --> D
  Z3 --> D
        

When one machine is not enough, a group of identical machines can share the work.

A Virtual Machine Scale Set is a group of identical VMs created from the same image and configuration, managed as one unit. You can define rules that add machines when load rises and remove them when it falls. This is called autoscaling. A load balancer in front spreads the traffic over whichever machines are running.

Because you own the operating system, you also own its updates.

Azure maintains the physical hosts and the hypervisor. You maintain the operating system and the applications inside your VM. Unpatched operating systems are among the most common ways attackers break into servers, so a clear patching routine is essential.

Security for a VM works best in layers, from the network down to the data on its disks.

Redundancy keeps you running through hardware problems, but only backups protect you from mistakes and attacks.

If a user deletes important files or ransomware encrypts a disk, every zone and every copy will faithfully reflect the damage. To recover, you need separate backups and, for larger disasters, a recovery plan.

You cannot manage a machine you cannot see.

Azure provides basic metrics for VMs automatically, measured from outside the machine. These include processor use, disk operations, network traffic and availability. To see what happens inside the operating system, such as memory use, event logs and running processes, you install the Azure Monitor Agent and tell it what to collect.

The same VM can cost very different amounts depending on how you buy it and how you manage it.

A VM is one of several compute options, and the best choice depends on how much control you need.

flowchart TD
  Q["Do you need control of the operating system?"] -->|"Yes"| VM["Virtual Machines or Scale Sets"]
  Q -->|"No"| Q2{"Is it a web app or API?"}
  Q2 -->|"Yes"| AS["App Service"]
  Q2 -->|"Event-driven short tasks"| FN["Azure Functions"]
  Q2 -->|"Containerised microservices"| K["Containers or Kubernetes"]
        

These layouts appear again and again in successful VM-based systems.

Virtual machines quietly power a wide range of everyday systems.

These habits regularly lead to break-ins, outages and wasted money.

Walk through these steps whenever you plan a new virtual machine workload.

A VM behaves like a physical server, but it is created by software on shared hardware. It can be created, resized, copied and deleted in minutes, and you pay by usage, while a physical server needs purchase, delivery and installation.

Only if the VM is deallocated through Azure. A VM shut down from inside its operating system may still be billed for compute. Disks and other attached resources continue to cost money even when compute is off.

It is fast local storage on the host. Its contents can be lost when the VM is redeployed, resized or moved, so use it only for caches and temporary files. Keep important data on managed data disks.

An availability set spreads VMs across racks and update groups inside one data centre. Availability zones spread VMs across separate data centre buildings in a region, which protects against larger failures and generally offers a stronger availability promise.

Microsoft patches the physical hosts and hypervisor. You are responsible for the guest operating system and software inside the VM, which you can automate with update management tools or by rebuilding from fresh images.

Prefer Azure Bastion, a private VPN or other private connection, or just-in-time access, instead of exposing remote desktop or secure shell ports to the internet. Combine with multi-factor authentication and least-privilege access.

Use a scale set when you need many identical, stateless servers that should grow and shrink with demand and be updated or replaced automatically. Use individual VMs for unique, stateful or special-purpose servers.

Right-size using measurements, deallocate or schedule non-production machines, delete orphaned resources, use Hybrid Benefit where eligible, commit with reservations or savings plans for the steady base, and use spot capacity for interruptible work.

They solve different problems. Backup protects against deletion, corruption and ransomware by letting you restore earlier data. Disaster recovery protects against the loss of a data centre or region by keeping a replica ready to take over. Critical systems usually need both.

If you do not need operating system control, a platform service such as App Service, containers or functions usually means less operational work. Choose a VM when you need control, run legacy or licensed software, or need special drivers or hardware.

An Azure Virtual Machine is a software-made computer that you rent by the hour and control from the operating system upwards. A VM is a family of linked resources: the machine, its disks, its network interface, its security rules and its address. Success comes from choosing the right size family, using managed disks wisely, keeping machines private, spreading them across zones, patching and securing them in layers, protecting them with backups and monitoring them closely. By building servers from golden images and templates, right-sizing and deallocating idle machines, and choosing platform services where full control is not needed, you can run reliable, secure and economical workloads on Azure.