Skip to main content
emnode
Cost

Store disk snapshots on standard storage

One small change Azure Advisor surfaces under Cost: keep managed-disk snapshots on standard storage instead of premium, where they sit by default if you copy a premium disk the obvious way, and pay roughly 60% less for the same protection.

12 min·10 sections·AZURE

Last reviewed

Snapshots on standard storage: the basics

Why is a backup of a premium disk being billed at premium rates?

A managed-disk snapshot is a point-in-time copy you keep so you can rebuild a disk after a bad change, a failed patch or an accidental delete. The thing most teams never notice is that a snapshot has its own storage SKU, separate from the disk it came from. When you snapshot a Premium SSD disk through the path of least resistance, the snapshot can land on premium (Premium_LRS) storage too, and you start paying a premium per-GB rate to hold a copy that almost never needs premium performance.

Azure Advisor flags exactly this under its Cost recommendations: 'Use Standard Storage to store Managed Disks snapshots'. Microsoft is blunt about the size of the saving: storing snapshots on standard storage rather than premium reduces the snapshot bill by around 60% for the same data. A snapshot is cold by definition. It is read only when you restore, so there is no workload reason to keep it on the fastest tier.

Most of this is drift, not a decision anyone made. A backup runbook that copied a premium disk and let the snapshot inherit a premium SKU, a one-off snapshot taken before a risky deployment and never cleaned up, a fleet of OS-disk snapshots created the quick way. The work is to find every snapshot sitting on premium storage, move it to standard, and make incremental the default so new snapshots are charged at standard rates and for changed data only.

In this lesson you will learn why a managed-disk snapshot can end up on premium storage, how to find every snapshot that is being overcharged, and how to move them to standard storage and make incremental the default, so the same protection costs roughly 60% less. It is grounded in the Azure Advisor recommendation 'Use Standard Storage to store Managed Disks snapshots' (recommendation ID 702b474d-698f-4029-9f9d-4782c626923e).

Fun fact

The default that quietly doubles a backup bill

Incremental snapshots in Azure are always stored on standard HDD storage, no matter what tier the parent disk is. Microsoft built the cheaper path straight into the product. The reason so many teams still pay premium rates is that the older, full-snapshot path lets a snapshot inherit a premium SKU, and a backup script written once and never revisited keeps taking the expensive route long after the incremental option became the better default. The fix is partly cleanup and partly changing one flag so the cheap path is the one your automation takes from now on.

Finding premium-priced snapshots across a subscription

Priya runs the platform team at a company tightening its Azure spend after a budget review. Advisor's Cost tab shows 'Use Standard Storage to store Managed Disks snapshots' against a resource group full of VM backups.

Rather than trust the recommendation count alone, Priya starts by listing every snapshot and its storage SKU, so the premium-priced ones can be separated from the standard ones already on the cheap tier before anything is changed.

Start by listing every snapshot with its SKU, size and whether it is incremental. The premium ones are the bill you are overpaying.

$ az snapshot list --query "[].{name:name, sku:sku.name, sizeGB:diskSizeGb, incremental:incremental}" -o table
Name Sku SizeGB Incremental
-------------------- ----------- -------- -----------
vm01-osdisk-snap Premium_LRS 128 False
vm02-datadisk-snap Premium_LRS 512 False
vm03-osdisk-snap Standard_LRS 128 True
# The two Premium_LRS snapshots cost ~60% more for nothing. Move them to standard.

A snapshot on Premium_LRS is paying the fast-tier rate to hold cold backup data. These are the snapshots Advisor is flagging, and the ones to move first.

How Azure decides what a snapshot costsdeep dive

A snapshot's cost is driven by two properties on the snapshot resource. The first is the SKU: 'sku.name' is one of Standard_LRS, Standard_ZRS or Premium_LRS, and the per-GB rate follows directly from it. A snapshot inherits no obligation to match its parent disk's SKU, so a Premium SSD disk can, and should, be backed by a Standard_LRS snapshot. The second is whether the snapshot is full or incremental: 'incremental' is a boolean, and an incremental snapshot is billed only for the data that changed since the previous one, not the full disk each time.

These two combine. A full snapshot on Premium_LRS is the worst case: the fast-tier rate applied to the full disk size, every snapshot. An incremental snapshot is the best case, and Azure helps you here: incremental snapshots are always stored on standard storage regardless of the parent disk's tier, so choosing incremental moves you to the cheaper tier automatically and bills you for changed data only. The default SKU for a new snapshot in the CLI is already Standard_LRS; premium tends to creep in only when a script or template sets it explicitly or copies it from the source disk.

There is no functional downside to standard for this use. A snapshot is cold: it is read during a restore, not during normal operation, so the premium tier's IOPS and throughput never come into play. The restored disk is identical regardless of which tier the snapshot sat on. The only thing premium storage changes for a snapshot is the price.

What is the impact of leaving snapshots on premium storage?

The direct impact is a recurring overcharge. Every premium-priced snapshot is billed at the fast-tier per-GB rate, roughly 60% more than standard, every month it exists, for data that is only ever read during a restore. Because snapshots accumulate, a backup routine that takes the premium path quietly grows a line item that delivers no performance and no extra protection in return.

The second-order impact is compounding waste. Full snapshots on premium store the entire disk size each time, so a daily backup of a large disk multiplies the overcharge across every retained copy. Switching to incremental on standard collapses both problems at once: the cheaper tier and billing for changed data only, so the saving is larger than the headline 60% on any disk that does not change much between snapshots.

There is no offsetting benefit being lost. The premium tier buys IOPS and throughput that a cold backup never uses, and the restore produces an identical disk either way. Leaving snapshots on premium is paying for a capability that the workload, by definition, cannot consume.

How do you move snapshots to standard storage safely?

Work it as one loop: inventory by SKU, move the premium-priced snapshots to standard, then change the default so new snapshots are incremental on standard and the charge does not return. None of this touches a running workload.

1. Inventory every snapshot by SKU

List all snapshots with their 'sku.name', size and 'incremental' flag. Treat this inventory as the source of truth, not the Advisor estimate, because it shows exactly which snapshots are on Premium_LRS and how large they are, which is what drives the saving.

2. Move the premium-priced snapshots to standard

Change the SKU of each Premium_LRS snapshot to Standard_LRS. This is a metadata change on a cold backup: it does not touch any disk or VM, needs no maintenance window, and the restored disk is identical afterwards. Start with the largest snapshots, since the saving scales with size.

3. Make incremental the default for new snapshots

Change your backup automation to create incremental snapshots. Incremental snapshots are always stored on standard storage regardless of the parent disk's tier, and are billed for changed data only, so this both moves new snapshots to the cheaper tier and shrinks what they cost. This is the step that stops the premium charge from creeping back.

4. Prune what you do not need to keep

The cheapest snapshot is the one you no longer hold. Once the tier is right, review retention: delete the one-off snapshots taken before a deployment and never cleaned up, and set a retention window on the rest so the backup line does not grow unbounded even at the lower rate.

# Move every premium-priced snapshot to standard storage. Cold backups, no downtime.
RG="my-resource-group"
for snap in $(az snapshot list -g "$RG" \
    --query "[?sku.name=='Premium_LRS'].name" -o tsv); do
  az snapshot update -g "$RG" -n "$snap" --sku Standard_LRS
  echo "$snap: moved to Standard_LRS"
done

# Make new snapshots incremental on standard by default (billed for changed data only).
diskId=$(az disk show -g "$RG" -n my-os-disk --query id -o tsv)
az snapshot create -g "$RG" -n my-os-disk-snap-$(date +%Y%m%d) \
  --source "$diskId" \
  --incremental true \
  --sku Standard_LRS

Quick quiz

Question 1 of 5

Azure Advisor flags 'Use Standard Storage to store Managed Disks snapshots'. Why is this a safe saving to take?

You can now treat snapshot storage as a deliberate cost choice rather than a default nobody picked: inventory snapshots by SKU, move the premium-priced ones to standard with 'az snapshot update', make new snapshots incremental on standard so they are billed for changed data only, and prune what you do not need to keep. The Advisor recommendation 'Use Standard Storage to store Managed Disks snapshots' closes, and stays closed, at roughly 60% less for the same protection.

Back to the library