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

Hiya People!

When you have been operating Premium SSD v1 as a result of that’s simply what you could have at all times accomplished, 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 group walked us via Premium SSD v2 (PV2 for brief) and the brand new Prompt 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 particular person, 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 each 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 value.
• Dwell Resize. You’ll be able to develop disk measurement, IOPS, or throughput on a operating VM with no restart required.
• Prompt Entry Snapshots make restores really feel really instantaneous, with as much as 10x sooner hydration and 90% decrease learn latency throughout hydration.

That’s quite a lot 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 Be taught describes it as designed for workloads that want sub-millisecond disk latency, excessive IOPS, and excessive throughput at a low value. The goal record is broad: SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, massive information 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. In the event you 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, you then set IOPS and throughput to match what your workload really wants. In the event you over-provisioned, you tune it down. In the event you under-provisioned, you tune it up, and the VM retains operating.

Raymond highlighted three main use instances within the session:

1. SAP workloads, together with SAP software VMs, SAP HANA databases, and non-HANA databases like Oracle, DB2, and SQL Server in SAP environments.
2. SQL Server. Based on a GigaOM benchmark cited within the session, SQL Server on PV2 delivered 51% extra transactions per second and 39% decrease value per transaction in comparison with AWS EC2, with a 9% decrease 3-year TCO.
3. Massive information 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. Meaning you possibly can 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 measurement by default, with 512E out there for legacy functions. There are a number of 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 lined 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 constantly.

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

With Prompt Entry, the snapshot is usable the second it exists. The information stays in the identical high-performance storage because the supply disk for a configurable period (60 to 300 minutes, managed by the InstantAccessDurationMins parameter). On the similar time, Azure copies the snapshot information to Commonplace ZRS within the background for long-term retention. When the Prompt Entry window expires, the snapshot transitions to a daily 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 information hydrates within the background. There are some limits to remember. Prompt Entry counts towards the present restrict of three in-progress snapshots per disk, and you’ll create as much as 15 disks concurrently from all instantaneous 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 may be a significant enchancment to your Restoration Time Goal (RTO).

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

• Pre-deployment security nets. Take an instantaneous entry snapshot earlier than a giant 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 main occasion in seconds. You’ll be able to even place them throughout availability zones in the identical area.
• Dev/check surroundings refresh. Clone manufacturing into dev or check 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. Dwell Resize means you possibly can scale IOPS or throughput up on a operating database throughout a load spike, and not using a upkeep window.
• Proper-sizing to chop spend. When you have been paying for VM SKUs purely to get native SSD throughput, PV2 might allow you to drop to a smaller, cheaper VM and nonetheless hit increased numbers.

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

Concrete first steps so you can begin kicking the tires:

1. Verify 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. Decide a Premium-capable VM in a supported zone. Bear 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. Choice A: detach the disk from a operating VM and convert it (the VM retains operating on its different disks). Choice B: cease and deallocate the VM, then convert in place. Each protect information, and you’ll elevate IOPS and throughput as a part of the conversion.
5. Strive Prompt Entry Snapshots. Add –instant-access-duration-in-minutes (or the equal ARM/PowerShell parameter) to your present snapshot command. That’s all of the change it’s worthwhile 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 total Microsoft Azure Infra Summit 2026 session playlist right here

Cheers!

Pierre Roman