Premium SSD v2 and Immediate Entry Snapshots: A Higher, Quicker, Cheaper Disk for Your Azure VMs

Hi there Of us!

In case you have been operating Premium SSD v1 as a result of that’s simply what you will have at all times performed, this session from the Microsoft Azure Infra Summit 2026 goes to be a get up name. Raymond Lui and Adam Li from the Azure Disk Storage workforce walked us by means of Premium SSD v2 (PV2 for brief) and the brand new Immediate Entry Snapshots, and the punchline is straightforward. PV2 is quicker, it’s cheaper, and the operational story round it simply retains getting higher.

📺 Watch the session:

In case you are an infrastructure individual, a SQL DBA, an SAP Foundation admin, or anybody who has ever needed to right-size a VM round its storage tier, this issues to you. In brief, Premium SSD v2 adjustments the foundations round the way you provision block storage in Azure. Here’s what stood out from the session:

• 4x extra IOPS and 2x extra throughput in comparison with Premium SSD v1, on a matched configuration that prices 42% much less.
• Sub-millisecond common latency, with a prime configuration of 800,000 IOPS and 20 GB/s of throughput on a single VM.
• Capability, IOPS, and throughput are decoupled. You dial every one independently, in 1 GB increments, as an alternative of shopping for a tiered SKU.
• 3,000 baseline IOPS and 125 MB/s throughput included on each disk, with no further price.
• Stay Resize. You’ll be able to develop disk dimension, IOPS, or throughput on a operating VM with no restart required.
• Immediate Entry Snapshots make restores really feel really prompt, with as much as 10x sooner hydration and 90% decrease learn latency throughout hydration.

That’s a number of wins on one slide. Let’s break it down.

Premium SSD v2 is Azure’s purpose-built block storage for I/O-intensive enterprise workloads. Microsoft Study describes it as designed for workloads that want sub-millisecond disk latency, excessive IOPS, and excessive throughput at a low price. The goal checklist is broad: SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, huge knowledge and analytics, gaming, and stateful containers operating on AKS.

The architectural shift that Raymond highlighted is impartial scaling. With Premium SSD v1, you purchased a hard and fast SKU. If you happen to needed extra IOPS, you had to purchase extra capability, even when you didn’t want it. With PV2, capability, IOPS, and throughput are three separate dials. You provision capability in 1 GB increments, then you definitely set IOPS and throughput to match what your workload really wants. If you happen to over-provisioned, you tune it down. If you happen to under-provisioned, you tune it up, and the VM retains operating.

Raymond highlighted three major use instances within the session:

1. SAP workloads, together with SAP utility VMs, SAP HANA databases, and non-HANA databases like Oracle, DB2, and SQL Server in SAP environments.
2. SQL Server. In accordance with a GigaOM benchmark cited within the session, SQL Server on PV2 delivered 51% extra transactions per second and 39% decrease price per transaction in comparison with AWS EC2, with a 9% decrease 3-year TCO.
3. Large knowledge and analytics changing native SSD. This one is a little bit of a shock. On D-series VMs, PV2 delivered over 1,400 MB/s of throughput in comparison with 720 MB/s from native SSD. Which means you’ll be able to run Spark or Databricks workloads on cheaper VM SKUs (with out native storage) and nonetheless get extra efficiency than you had earlier than.

Premium SSD v2 helps a 4k bodily sector dimension by default, with 512E accessible for legacy purposes. There are just a few sincere tradeoffs to find out about. PV2 disks can’t be used as an OS disk, and so they can’t be used with Azure Compute Gallery. PV2 additionally doesn’t help host caching. For areas with availability zones, PV2 disks can solely be hooked up to zonal VMs, so plan your VM placement accordingly.

Raymond coated the structure briefly, and it’s price understanding. PV2 makes use of direct VM-to-storage-node communication, with 3-replica sturdiness behind the scenes. That direct path is a part of the way it will get sub-millisecond latency persistently.

For Immediate Entry Snapshots, Adam walked by means of the architectural distinction between the basic incremental snapshot path and the brand new Immediate Entry path. With basic incremental snapshots for PV2 and Extremely Disk, the snapshot is created, then the info has to repeat within the background to Normal HDD earlier than the snapshot is usable for restore. That replicate may take some time on a big disk, and restored disks would then hydrate slowly, which dragged down learn latency till hydration completed.

With Immediate Entry, the snapshot is usable the second it exists. The info stays in the identical high-performance storage because the supply disk for a configurable length (60 to 300 minutes, managed by the InstantAccessDurationMins parameter). On the similar time, Azure copies the snapshot knowledge to Normal ZRS within the background for long-term retention. When the Immediate Entry window expires, the snapshot transitions to an everyday incremental snapshot, sitting on low-cost sturdy storage. You get the velocity and the long-term sturdiness with out operating two separate workflows.

In brief, your VM can boot and run at near-full efficiency whereas the info hydrates within the background. There are some limits to bear in mind. Immediate Entry counts towards the prevailing restrict of three in-progress snapshots per disk, and you may create as much as 15 disks concurrently from all prompt entry snapshots of a single disk.

Adam closed his portion of the session with a BCDR demo. He cloned 12 disks of an M-series manufacturing database right into a restoration VM, hooked up them, and was instantly operating roughly 500,000 IOPS at single-digit-millisecond latency. No ready for hydration. No degraded efficiency window. That could be a significant enchancment to your Restoration Time Goal (RTO).

A couple of eventualities the place this mix actually pays off:

• Pre-deployment security nets. Take an prompt entry snapshot earlier than an enormous improve. If one thing goes sideways, roll again in seconds as an alternative of hours.
• Fast scale-out for stateful apps. Spin up a number of disk copies of a major occasion in seconds. You’ll be able to even place them throughout availability zones in the identical area.
• Dev/take a look at atmosphere refresh. Clone manufacturing into dev or take a look at on demand, with full efficiency from the primary I/O. No extra “we’ll refresh dev subsequent quarter” as a result of the restore takes too lengthy.
• SAP HANA always-on operations. Stay Resize means you’ll be able to scale IOPS or throughput up on a operating database throughout a load spike, with no upkeep window.
• Proper-sizing to chop spend. In case you have been paying for VM SKUs purely to get native SSD throughput, PV2 could allow you to drop to a smaller, cheaper VM and nonetheless hit larger numbers.

One nuance got here up within the dwell Q&A. Jens requested an ideal query about profiling: how are you aware when PV2 is the correct alternative versus Normal SSD? Raymond’s steering was direct. If the workload wants excessive IOPS or excessive throughput, PV2 is mostly the correct name. The VM SKU additionally must help “Premium Disk” functionality for PV2 to connect, so test that compatibility first.

Concrete first steps so you can begin kicking the tires:

1. Affirm area and zone help. Use az vm list-skus –resource-type disks –query “[?name==’PremiumV2_LRS’]” to see which areas and availability zones are supported in your subscription.
2. Choose a Premium-capable VM in a supported zone. Keep in mind, PV2 is zonal in AZ areas. Resolve on the zone earlier than you create the VM.
3. Provision a disk. Begin with default efficiency (3,000 IOPS, 125 MB/s) and a small capability. You might be paying for the dials you flip up; defaults are cheap for many beginning factors.
4. Plan your v1 to v2 migration. Raymond demoed two paths. Possibility A: detach the disk from a operating VM and convert it (the VM retains operating on its different disks). Possibility B: cease and deallocate the VM, then convert in place. Each protect knowledge, and you may elevate IOPS and throughput as a part of the conversion.
5. Strive Immediate Entry Snapshots. Add –instant-access-duration-in-minutes (or the equal ARM/PowerShell parameter) to your current snapshot command. That’s all of the change you want to allow it.
6. For AKS customers, outline a storage class with skuName: PremiumV2_LRS and let dynamic provisioning take it from there.

Catch the complete Microsoft Azure Infra Summit 2026 session playlist right here

Cheers!

Pierre Roman