Create an Azure VM from an image or a snapshot
Two words that get used interchangeably and mean genuinely different things. Get the difference straight, and the "which button do I press" part answers itself.
New to cloud? CAMPUX is a free, build-first course. Start here →
An image is a reusable template for spinning up new, identical VMs; a snapshot is a point-in-time copy of a single disk for backup or cloning. You create a VM from an image when you want repeatable machines built to a known spec, and from a snapshot when you want to restore or duplicate one specific disk. Same end result — a running VM — but the two are built for opposite jobs, and mixing them up is a common early mistake.
I have watched more than one junior engineer take a snapshot of a golden VM, then wonder why they cannot "deploy ten servers from it." Snapshots do not scale out; that is not what they are. Let me lay out what each thing actually is, then give you the exact commands for both paths.
Image, snapshot, managed disk — three things, not one
All three live in the same neighborhood, so they blur together. Keep them separate:
- Managed disk. The live block storage attached to a running VM — the OS disk it boots from, plus any data disks. Azure manages the underlying storage account for you. Everything else here is derived from a disk.
- Snapshot. A read-only, point-in-time copy of one managed disk. It freezes exactly what that disk looked like at the moment you took it. It is disk data, nothing more — not bootable on its own, tied to a single disk, not a template.
- Image. A reusable template you deploy many VMs from. It can be built from a captured VM (OS disk, and optionally data disks) and it is designed to be stamped out repeatedly. The modern form lives in an Azure Compute Gallery (you may still see its old name, Shared Image Gallery), which adds versioning and replication across regions.
The one-line test: if you want one disk back the way it was, that is a snapshot job. If you want many machines built to the same spec, that is an image job.
A snapshot restores. An image reproduces.
Generalized vs specialized — the word that trips people up
Before the steps, one concept that shows up in the portal and in every interview on this topic: generalized vs specialized.
A running VM has machine-specific identity baked in — hostname, the local admin account, security identifiers, on Linux the SSH host keys and cached machine ID. If you cloned that disk straight into fifty VMs, they would all collide on that identity. That is fine for a one-off restore. It is not fine for a fleet.
Generalizing strips that identity out so each new VM gets its own. On Windows you run sysprep /generalize; on Linux you run waagent -deprovision+user. After that the VM is a clean stamp — you cannot boot the original again, which is exactly why you do it on a throwaway build machine, not your production box.
- Generalized image — identity stripped. The right choice for a golden template you deploy many VMs from. This is the classic "create an image, then
az vm create --image" path. - Specialized image or a snapshot — identity kept. The right choice when you want the machine back exactly as it was, same name and accounts. No sysprep, no deprovision.
Path A — build a reusable image, then deploy from it
This is the repeatable-machines path. You take a VM you have configured the way you want (patched, hardened, your agent installed), generalize it, capture it into an image, and deploy as many VMs as you like from that image.
Portal, in short
- Prepare the source VM, then generalize the OS from inside it (
sysprepon Windows,waagent -deprovision+useron Linux). - Back in Azure, Deallocate the VM, then open it and choose Capture. The wizard offers to create an image in a Compute Gallery (recommended) or a standalone managed image, and asks you to confirm you have generalized it.
- To deploy: Create a resource → Virtual machine, and under the image picker choose See all images → My Images / Shared Images, and pick your gallery image version. Fill in size, networking, admin credentials as normal.
The exact menu labels drift between portal refreshes — "Capture," the gallery naming, the image dropdown all get reworded. The shape stays the same: generalize, capture to a gallery, deploy from the gallery.
The az CLI version
# 1. Deprovision from INSIDE the Linux VM, then exit:
# sudo waagent -deprovision+user -force
# 2. Deallocate and mark the VM generalized
az vm deallocate -g rg-build -n vm-golden
az vm generalize -g rg-build -n vm-golden
# 3. Create a Compute Gallery + image definition (one-time setup)
az sig create -g rg-build --gallery-name galCampux
az sig image-definition create -g rg-build --gallery-name galCampux \
--gallery-image-definition img-web --publisher campux --offer web --sku ubuntu-2204 \
--os-type Linux --os-state Generalized --hyper-v-generation V2
# 4. Capture the VM into a versioned image
az sig image-version create -g rg-build --gallery-name galCampux \
--gallery-image-definition img-web --gallery-image-version 1.0.0 \
--managed-image $(az vm show -g rg-build -n vm-golden --query id -o tsv)
# 5. Deploy as many identical VMs as you want from that image
az vm create -g rg-prod -n vm-web-01 \
--image "/subscriptions/<sub-id>/resourceGroups/rg-build/providers/Microsoft.Compute/galleries/galCampux/images/img-web/versions/1.0.0" \
--admin-username azureuser --generate-ssh-keysThat last az vm create --image is the whole payoff. Run it with a different -n ten times and you get ten identical, cleanly-identified machines. That is what an image is for.
You do not always need to build your own image. az vm image list --output table shows Microsoft and marketplace images (Ubuntu, Windows Server, and hundreds of pre-baked appliances). Building your own is for when you want your config baked in — company agent, hardening, packages — so every VM starts identical instead of you scripting the setup each time.
Path B — restore or clone from a snapshot
This is the single-disk path. Something went wrong, or you want an exact copy of one machine's disk. A snapshot cannot boot on its own, so the move is always the same three beats: snapshot → managed disk → VM with that disk attached.
Portal, in short
- On the source VM's disk (or the VM's Disks blade), choose Create snapshot. Pick full or incremental.
- From the snapshot, choose Create disk — this turns the frozen data back into a live, attachable managed disk.
- From that disk, choose Create VM. Because the disk carries the original OS and identity, Azure treats it as the OS disk and boots the machine as it was.
The az CLI version
# 1. Snapshot the VM's OS disk (get the disk id first)
osdisk=$(az vm show -g rg-prod -n vm-web-01 --query storageProfile.osDisk.managedDisk.id -o tsv)
az snapshot create -g rg-prod -n snap-web-01 --source "$osdisk" --incremental true
# 2. Turn the snapshot back into a real managed disk
az disk create -g rg-prod -n disk-restored \
--source snap-web-01
# 3. Build a VM with that disk as its OS disk (no --image here)
az vm create -g rg-prod -n vm-restored \
--attach-os-disk disk-restored --os-type LinuxNotice what is missing in step 3: there is no --image. You do not build a fresh OS and layer settings on top — you attach a disk that already is the machine. That single difference, --image versus --attach-os-disk, is the cleanest way to see image-thinking versus snapshot-thinking in one line.
Full snapshots copy the whole used size every time. Incremental snapshots (--incremental true) store only what changed since the last one, which is cheaper and the sane default for a backup rhythm. For scheduled, policy-driven backups of real workloads, though, reach for Azure Backup rather than hand-rolling snapshots — snapshots are the primitive, not the backup product.
Image vs snapshot, side by side
| Image | Snapshot | |
|---|---|---|
| What it is | Reusable VM template (OS disk + optional data disks), ideally versioned in a Compute Gallery | Read-only point-in-time copy of one managed disk |
| Use case | Stamp out many identical VMs — golden image, scale sets, fleet rebuilds | Back up or clone one specific disk; restore a single machine |
| Generalized? | Usually yes (sysprep / waagent) so each VM gets fresh identity; specialized images exist too | No — keeps the original identity, name, and accounts |
| Scales to a fleet? | Yes — that is the point | No — it is one disk |
| Cost while idle | Stored per image version; gallery replication multiplies it per region | Billed as stored data for used size; incremental is cheaper |
| How you deploy from it | az vm create --image <image-id> | snapshot → az disk create --source → az vm create --attach-os-disk |
Pricing shifts and the gallery replication model has knobs — check the Azure pricing calculator for current per-GB figures before you size anything as of 2026. The relationships in that table, though, do not move.
Why this is worth knowing cold
Here is the honest angle. Plenty of people can click through "create a VM." Far fewer can answer, without hesitating, "you have a perfectly configured server and you need forty more like it — image or snapshot, and why." That question, or a near-cousin of it, lands in real Azure interviews because it separates someone who has only followed a tutorial from someone who understands what the platform primitives are for.
The tell is the word reusable. A snapshot is a copy of a moment; an image is a mould. If your answer reaches for generalize/sysprep and Compute Gallery when someone says "fleet," and reaches for snapshot when someone says "restore this one box," you are already ahead of most candidates. This is the kind of small, exact distinction the virtual machines class drills, and the reason we push you to build both paths by hand rather than read about them.
Common questions
What is the difference between an image and a snapshot in Azure?
An image is a reusable template you deploy many identical VMs from. A snapshot is a read-only point-in-time copy of a single managed disk, used to back up or clone that one disk. Use an image for repeatable machines; use a snapshot to restore or duplicate one specific disk.
Do I need to generalize a VM before creating an image?
For a generalized image, yes — you run sysprep on Windows or waagent -deprovision on Linux, then deallocate and mark the VM generalized before capturing. That strips machine-specific identity so every VM built from the image gets its own. A specialized image or a snapshot keeps the original identity and skips this step.
Can you create a VM directly from a snapshot?
Not in one step. A snapshot is disk data, not a bootable VM definition. You create a managed disk from the snapshot, then create the VM with that disk attached as the OS disk. In the CLI that is az disk create --source <snapshot>, then az vm create --attach-os-disk.
Does an Azure snapshot cost money while it sits there?
Yes. Snapshots are billed as stored data for the used size of the disk, so an idle snapshot keeps costing a little every month until you delete it. Incremental snapshots only store the change since the last one and are usually cheaper. Prices change — check the Azure pricing calculator for current per-GB figures.