Azure Compute Blog articles

Announcing Preview of new Azure Lasv5 and Laosv5 VMs based on the AMD EPYC™ ‘Turin’ processor

sarah-zhou — Tue, 02 Jun 2026 19:16:22 GMT

We’re excited to announce the preview of the new Azure Lasv5 and Laosv5 Local Storage Optimized Virtual Machines (VMs) powered by the 5th Generation AMD EPYC™ (Turin) processors. Lasv5-series is designed for storage-intensive workloads requiring high disk capacity, throughput, and I/O, while Laosv5-series is well-suited for workloads requiring significantly higher local storage capacity and performance, such as large-scale caching clusters and big data processing.

Lasv5 and Laosv5 Key Improvements

The latest Azure AMD-based Lasv5 and Laosv5 VMs deliver significant enhancements over the previous generation Lasv4 and Laosv4 VMs.

Key Improvements include:

Increased maximum local storage capacity:
- Lasv5-series offers up to 30.7TB of local storage capacity (compared to 23TB on Lasv4-series)
- Laosv5-series offers up to 138TB of local storage capacity (compared to 23TB on Laosv4-series)
Increased maximum network bandwidth:
- Lasv5 and Laosv5 offer up to 200Gbps of network bandwidth (compared to 40Gbps and 50Gbps on Lasv4 and Laosv4 respectively)
Additional size offerings:
- Lasv5-series now offers new 128 and 160 vCPU sizes
- Laosv5-series now offers new 48, 64, 96, 128, and 160 vCPU sizes
Up to 35% CPU performance improvement compared to equivalent sized Lasv4 and Laosv4 VMs

Getting Started with Lasv5 and Laosv5 Preview

These VMs are in preview in the following Azure regions (subject to capacity):

Lasv5: North Europe, South Central US, West Europe, West US 2, and West US 3
Laosv5: East US and South Central US

To request access to the preview, please fill out the Preview Request Form. We look forward to hearing from you.

Announcing Preview of Guest RDMA for Azure Boost

MengxiWu — Wed, 03 Jun 2026 15:54:48 GMT

We’re excited to announce Guest RDMA (Preview) in Azure, beginning today in our UK South region, bringing high-throughput, ultra-low latency networking directly into guest virtual machines anywhere within the same region. By using Azure Boost to enable RDMA capabilities on our frontend network within the guest OS, applications can bypass the traditional networking stack and offload the transport protocol to the NIC - reducing CPU overhead and delivering consistent, high-performance communication for a variety of workloads including AI inference and training, storage, database, and HPC workloads.

RDMA

RDMA is a networking technology that enables direct memory access between machines without involving the CPU or operating system kernel. Instead of passing data through the traditional TCP/IP stack, RDMA offloads data movement to the network interface card (NIC), allowing applications to read or write remote memory directly.  Azure uses RDMA extensively today at the infrastructure layer for storage, and in backend networks for AI and HPC scenarios. Extending RDMA support to guest VMs on the frontend network allows VMs to take advantage of these offloads for a broad range of scenarios within a region, including across Availability Zones.

Key benefits of enabling RDMA for applications in your VMs include:

Kernel bypass and low latency: Data transfers avoid the OS networking stack, eliminating context switches and copies, reducing latency and jitter.
High throughput: a hardware-based transport delivers up to 100Gb/s single-connection throughput depending on VM SKU.
Low CPU usage: CPU overhead of the TCP/IP stack is eliminated since data movement is offloaded to hardware.

Guest RDMA Scenarios

Applications that typically use Guest RDMA involve frequent or large data transfers, such as:

AI/ML training and inference – Guest RDMA supports GPU Direct RDMA, enabling direct data movement between GPUs across VMs with minimal CPU involvement. This is useful for doing training across GPUs that don't share a single backend network, disaggregating GPUs for inference, loading stored KV Caches, and other parts of AI workloads, improving throughput and latency.
Distributed storage systems and databases – Azure Boost supports both kernel mode RDMA (e.g., NFS, SMB) and user mode RDMA (e.g., shared memory and database workloads), delivering high throughput and low CPU utilization for storage and data platforms. A key property of Guest RDMA in Azure is that it allows systems distributed across multiple Availability Zones (AZs) within a region to communicate over high speed RDMA.
High Performance Computing (HPC) – RDMA delivers low latency, high bandwidth VM to VM communication, which is critical for tightly coupled, communication intensive HPC applications and MPI workloads.

Enabling RDMA in Guest VMs

To enable Guest RDMA, create VMs using the following guidelines below:

Guest RDMA supports RDMA connections between VMs in a VNET talking directly to each other within the same region. The preview is currently available in the UK South region, with more regions to follow.
Recommended Linux Supported Distribution: Ubuntu 24.04 LTS
Required user-space packages: >= rdma-core (50.0-2ubuntu0.2)
Supported Kernel to use: >=6.8.0 - 1044-azure, recommend 6.17 if available

Supported VM sizes:

You can take advantage of Guest RDMA by utilizing the following virtual machine type

D-series: Dlsv6, Dldsv6, Dsv6, Ddsv6

Intel Dlsv6	Intel Dldsv6	Intel Dsv6	Intel Ddsv6
Standard_D64ls_v6	Standard_D64lds_v6	Standard_D64s_v6	Standard_D64ds_v6
Standard_D96ls_v6	Standard_D96lds_v6	Standard_D96s_v6	Standard_D96ds_v6
Standard_D128ls_v6	Standard_D128lds_v6	Standard_D128s_v6	Standard_D128ds_v6
—	—	Standard_D192s_v6	Standard_D192ds_v6

E-series and L-series: Esv6, Edsv6, Lsv4

Intel Esv6	Intel Edsv6	Intel L v4
Standard_E64s_v6	Standard_E64ds_v6	Standard_L64s_v4
Standard_E96s_v6	Standard_E96ds_v6	Standard_L80s_v4
Standard_E128s_v6	Standard_E128ds_v6	Standard_L96s_v4
Standard_E192is_v6	Standard_E192ids_v6	—

Network Optimized: Dnlsv6, Dnldsv6, Dsv6, Dndsv6, Esv6, Edsv6 (Public Preview)

Intel Dnlsv6	Intel Dnldsv6	Intel Dnsv6	Intel Dndsv6
Standard_D64nls_v6	Standard_D64nlds_v6	Standard_D64ns_v6	Standard_D64nds_v6
Standard_D96nls_v6	Standard_D96nlds_v6	Standard_D96ns_v6	Standard_D96nds_v6
Standard_D128nls_v6	Standard_D128nlds_v6	Standard_D128ns_v6	Standard_D128nds_v6

Intel Ensv6	Intel Endsv6
Standard_E64ns_v6	Standard_E64nds_v6
Standard_E96ns_v6	Standard_E96nds_v6
Standard_E128ns_v6	Standard_E128nds_v6

Remote Storage Optimized: Ebsv6, Ebdsv6 (Public Preview)

Intel Ensv6	Intel Endsv6
Standard_E64bs_v6	Standard_E64bds_v6
Standard_E96bs_v6	Standard_E96bds_v6
Standard_E128bs_v6	Standard_E128bds_v6
Standard_E192ibs_v6	Standard_E192ibds_v6

FX: FXmsv2, FXmdsv2

Intel FXmsv2	Intel FXmdsv2
Standard_FX64ms_v2	Standard_FX64mds_v2
Standard_FX96ms_v2	Standard_FX96mds_v2

Limitation

The preview is limited to enabling RDMA flows between VMs talking directly to each other in a VNET. Workloads that require RDMA to run across the following scenarios are not supported in preview:

Load balancers
Private Endpoints
VNET Encryption
Virtual Network Flow Logging
User Defined Routes (UDRs)
IP forwarding

These features and topologies are planned to be available with RDMA at General Availability.

Preview Sign Up & Contact

To participate in the preview program, please sign up aka.ms/guestRDMAPreviewSignUp
We'd love to hear your thoughts — please share any feedback by emailing us at guestrdmapreview@microsoft.com.

Public preview: Automatic OS Image Upgrades for VMSS Flex

BMahboob — Mon, 01 Jun 2026 18:38:35 GMT

Automatic OS Image Upgrades for Virtual Machine Scale Sets (VMSS) using Flexible Orchestration Mode are now in public preview, helping you keep scale set instances current with less manual effort.

This capability helps you apply operating system image updates more consistently across deployments while reducing operational overhead and supporting high availability.

With this release, Azure extends automatic OS image upgrades to Flexible orchestration mode, providing a more consistent upgrade experience across VMSS deployment models.

Why use Automatic OS Image Upgrades for VMSS Flex?

Keeping virtual machine fleets up to date is critical for maintaining security, performance, and compliance. However, managing upgrades manually across a distributed environment can be complex.

Without Automatic OS Image Upgrades	With Automatic OS Image Upgrades
Updates applied per VM (e.g., in-guest patching)	Consistent, fleet-wide orchestration
No built-in health-based safety	Health-based progression and safety

Prerequisites and Setup

To get started with Automatic OS Image Upgrades for VMSS Flexible Orchestration Mode:

Prerequisites

Register your subscription for the feature:
Microsoft.Compute/VmssFlexAutoOSUpgrade
EnableAutomaticOSUpgrade will fail if the health extension is not present
Ensure the Guest OS health extensions are installed for reporting health signals
Use a supported OS image*
Enable the AutomaticOSUpgradePolicy on your scale set

*Automatic OS image upgrades with Azure Virtual Machine Scale Sets - Azure Virtual Machine Scale Sets | Microsoft Learn

Once enabled, upgrades can be monitored through Azure Portal or logging tools.

What’s next

During public preview, we are focused on expanding adoption of Automatic OS Image Upgrades for VMSS Flexible Orchestration Mode:

Enabling onboarding across new and existing VMSS Flex deployments
Validating the experience across a broader set of customer workloads and configurations

Learn more

Automatic OS image upgrades with Azure Virtual Machine Scale Sets - Azure Virtual Machine Scale Sets | Microsoft Learn

Share feedback

We welcome your feedback as you explore this capability during public preview.

Questions or feedback? Contact AzGPSTeam@microsoft.com.

Announcing the general availability of Azure Integrated Hardware Security Module

simranparkhe — Wed, 13 May 2026 17:23:24 GMT

Today we are excited to release general availability for Azure Integrated HSM for AMD v7 Virtual Machines. Azure Integrated HSM is a hardware security module (HSM) cache and crypto offload designed to enhance the security and performance of cryptographic operations in virtual machines. For customers who heavily rely on cryptography and have performance-intensive workloads, Azure Integrated HSM provides a secure hardware-backed way to store cryptographic keys for fast and secure usage. This feature is available in select AMD D and E series v7 sizes for Trusted Launch VMs.

Azure Integrated HSM is designed to meet the Federal Information Processing Standards (FIPS) 140-3 Level 3 security requirements for cryptographic modules. Azure Integrated HSM eliminates network roundtrips for key operations and avoids the need to release keys into the workload environment. Instead of relying on remote access, the Azure Integrated HSM is securely bound to the local workload and provides oracle-style key usage to authorized services within the local environment.

We are now introducing support for Secure Key Release (SKR) with Azure Integrated HSM. Customers can take their keys in Azure Key Vault or Managed HSM and securely release them into Azure Integrated HSM after the platform is verified as trusted. The key material remains protected within the FIPS 140‑3 validated hardware boundary and is not exposed to guest VM memory. With this model customers no longer need to make remote calls to Azure Key Vault or Managed HSM for every cryptographic operation. This way keys are securely released and cached directly on the Azure Integrated HSM device for fast, local use while in a FIPS‑validated boundary.

Why should I use Azure Integrated HSM?

Customer Profile 1: I am a customer running a latency‑sensitive, cryptographic operation heavy workload

A customer running crypto‑intensive workloads uses Secure Key Release (SKR) to keep their primary keys stored in Azure Key Vault or Managed HSM, but releases a copy into Azure Integrated HSM at runtime. Once securely released, cryptographic operations are performed directly on the Azure Integrated HSM device thus eliminating repeated network calls to the Azure Key Vault and improving latency for high‑throughput signing and encryption workloads.

Example customers:

Financial services signing and encryption
- Payment processing, trading, and secure messaging systems perform frequent cryptographic signing and encryption with strict latency and security requirements.
High‑frequency TLS termination / certificate operations
- Store private keys on the node and perform TLS signing operations directly in hardware, eliminating per request network calls to Azure Key Vault or Managed HSM this reducing tail latency.

Customer Profile 2: I am a customer that wants to store my key in my own private HSM but want to “Bring‑Your‑Own‑Key (BYOK)” to my Azure VM

A customer with strict key‑ownership requirements generates or holds their key outside Azure and uses Azure Integrated HSM to obtain an attested public wrapping key. They can wrap the key, then securely import it into the Azure Integrated HSM device where it is unwrapped and used only inside device’s FIPS 140-3 level 3 validated hardware boundary, ensuring the key is not exposed in the clear and remains under customer control throughout the process.‑

Example customers:

Compliance‑driven regulated workloads
- Government and regulated industry workloads require FIPS 140‑3 Level 3 key protection without compromising performance.

Benefits of AziHSM

Lower latency for cryptographic operations by reducing network round‑trips to Azure Key Vault or Managed HSM and performing crypto locally on the same node as the VM.
Keys stored in Azure Integrated HSM are not exposed in clear text and will remain in a FIPS 140‑3 Level 3 HSM boundary
Protection against memory and crash‑dump attacks
Built into Azure infrastructure with an Azure Integrated HSM attached to each supported node
No additional cost

Availability

Azure Integrated HSM is now available to use on the AMD v7 generally available platform in all the AMD v7 supported regions. This is supported for the general purpose Dasv7-series, Dalsv7-series, Dadsv7-series, Easv7-series, and Eadsv7-series for 8 vCores and above for Trusted Launch VMs. The Azure Integrated HSM general availability is for Windows support only, with Linux support coming soon. This feature will be offered at no additional cost.

Please see documentation on how to get started here: Azure Integrated HSM Overview | Microsoft Learn and How to deploy a Virtual Machine with Azure Integrated HSM enabled | Microsoft Learn. Customers can also check out our GitHub repository with customer samples and instructions on how to use Azure Integrated HSM.

Announcing the General Availability of the Next Generation of Azure Boost

Max_Uritsky — Wed, 13 May 2026 20:42:57 GMT

Starting May 7th, 2026, the new Esv7, Dsv7, and Dlsv7 virtual machines are generally available — and underneath them is a fundamentally new generation of Azure Boost. Not an incremental refresh. A platform that took over five years to build, with custom ASIC-hardened logic, a new network adapter, redesigned storage offload, and a security architecture that makes Azure Boost a Trusted Execution Environment in its own right.

You’ll notice the performance: up to 400 Gbps networking, up to 1M remote storage IOPS, up to 21 million local NVMe IOPS. What you won’t see yet is everything this platform can do. These VMs tap into the first wave of capabilities from the new Boost generation — and over the coming months, new VM families and features will unlock additional capabilities and performance.

What Makes This Generation Different

Azure Boost offloads virtualization, networking, and storage onto purpose-built hardware, so your workloads get more of the server you paid for. That fundamental model hasn’t changed. What has changed — substantially — is the platform underneath.

This generation of Azure Boost is built around a purpose-designed PCIe card that integrates three tightly coupled subsystems onto a single ASIC:

A custom ASIC/FPGA hybrid accelerator — handles storage acceleration, virtual network encryption, remote storage encryption, and high-throughput data-path processing. This generation hardens significantly more critical data path logic into dedicated logic — moving functions that previously ran in software or in FPGA into application-specific silicon. Most data for high-speed networking and storage is now transferred through the ASIC without going through the FPGA or software, which we use only where we need programmable packet processing. The result is higher throughput at lower latency, with better power efficiency per I/O operation – a 2x improvement in power per throughput over our prior 200Gbps Boost generation. The ASIC also contains the trusted subsystems that form the foundation of Azure Boost’s confidential computing capabilities.
The Microsoft Azure Network Adapter (MANA) — Microsoft’s custom-designed network interface, purpose-built for Azure. MANA delivers up to 400 Gbps of networking bandwidth with hardware-accelerated packet processing, high speed RDMA transport, dual top-of-rack active/active resiliency, and sub-second networking maintenance. It provides a consistent driver interface across hardware generations, so future platform upgrades won’t disrupt your networking stack.
A dedicated System-on-Chip (SoC) — running the Azure Boost control plane, agent management, servicing, and diagnostics on Arm cores — physically isolated from both the customer VM and the ASIC/FPGA data path. The SoC manages the operational lifecycle of the card while the ASIC and FPGA handle customer I/O at wire speed.

These three subsystems work as a single integrated platform. The ASIC and FPGA process your storage and networking data with hardware-enforced tenant isolation. MANA moves your packets. The SoC manages the device without ever touching your data. And all of it sits behind a hardware root of trust that attests the integrity of every component before the card is allowed to serve a single VM.

This architecture is also what makes confidential I/O possible. The ASIC contains dedicated confidential data-flow logic in hard-IP, designed to handle encrypted VM memory directly over IDE-encrypted PCIe links — without bounce buffers, without software intermediaries. This hardware foundation ships with every card today; the confidential computing features that build on it will be exposed in upcoming VM SKUs.

For customers, the practical impact is straightforward: faster I/O, more predictable performance, fewer host CPU cores consumed by platform overhead, and a security boundary that’s enforced in silicon — not just in software policy. Millions of additional sellable CPU cores have been released back to customer workloads as a result of the host core reductions this platform enables.

The physical Boost card itself — a PCIe card with the central ASIC/FPGA hybrid accelerator, surrounding memory, MANA network ports, and Microsoft branding — is visible in the image above. Every new generation of Azure Boost-enabled server in the fleet will carry this card, and every new Intel v7-series VM runs on it.

What the New VMs Deliver Today

The Esv7 (memory-optimized), Dsv7 (general-purpose), and Dlsv7(general purpose) families are the first SKUs to ship on this Azure Boost generation in general availability. Powered by custom Intel® Xeon® 6 processors with frequencies up to 4.2 GHz and up to 2x higher memory bandwidth than v6, they deliver substantial generational gains across the board:

Compute

Up to 20% better general compute performance compared to v6 VMs
Up to 25% better performance for compute-bound workloads like video transcoding, compression, and cryptography
Up to 30% better database workload performance on the largest sizes
Sizes up to 372 vCPUs and 2.8 TiB of memory — enabling larger in-memory databases, agentic AI workloads with larger context windows, and latency-sensitive applications that benefit from minimizing cross-node hops

Networking

Up to 400 Gbps of VM networking bandwidth on the largest Esv7/Edsv7 sizes
Dual top-of-rack (TOR) active/active fabric — continuing the proven architecture from prior generations for higher throughput and faster failover under network events

Storage

Up to 800K remote storage IOPS and 20 GBps remote storage throughput per VM on Premium v2 SSD and Ultra Disk with the largest Esv7/Edsv7 sizes
Up to 9.6 million local NVMe IOPS and 53 GBps local storage throughput with the largest Ddsv7/Edsv7 sizes — storage processing offloaded entirely to dedicated Azure Boost SSD hardware

Customers are strongly encouraged to use the latest Microsoft Azure Network Adapter (MANA) drivers to ensure optimal performance and reliability on Azure Boost-enabled hardware. The latest drivers are available at https://aka.ms/mana.

These are the capabilities the current VMs expose. The Azure Boost platform underneath has more in reserve — capabilities that will show up as new VM families ship throughout the year.

For the full SKU lineup, sizing, and benchmarks, see the companion announcement: Announcing General Availability of Azure Dl/D/Esv7-series VMs based on Intel® Xeon® 6 processors.

Azure Boost Confidential Device (ABCD): the Boost device joins the Confidential VM’s Trusted Compute Base through attested hardware and IDE-encrypted PCIe links.

Built on a Hardware Root of Trust

Performance is the visible part. Below the waterline, the bigger shift is what this generation enables for security: Azure Boost is now a full Trusted Execution Environment in its own right. That’s not a future promise — it’s the foundation shipping today, and it’s what powers the confidential computing capabilities already in production and the ones coming next.

Security isn’t layered on top of Azure Boost — it’s the foundation the platform boots from. Every Azure Boost device is anchored by Cerberus, Microsoft’s open-sourced hardware root of trust, certified to NIST SP 800-193 for platform firmware resiliency. Cerberus measures and attests every critical firmware component before Boost is allowed to initialize. If anything is off, Boost doesn’t come up.

You get a chain of trust that starts in hardware and extends all the way up to your workload:

Hardware root of trust identity — every Azure Boost device has a unique, cryptographically-bound identity established at manufacturing.
Measured and Secure Boot — every layer of Azure Boost firmware and software is measured and verified before execution.
Continuous attestation — the Azure Attestation Service periodically validates that each Boost device in the fleet is running known-good, trusted firmware and software. Devices that fail attestation are taken out of service automatically.

In practice, this means every Azure Boost device proves what it is before it’s allowed to touch your data — and keeps proving it continuously while your workloads run.

Strong Isolation Between Azure Boost and Your Workloads

By offloading virtualization, networking, and storage onto dedicated hardware, Azure Boost establishes a hard, physical isolation boundary between the platform infrastructure and your workloads:

Control plane and data plane separation — hypervisor management, networking, and storage policy execution all run on the Azure Boost hardware, completely off your CPU and memory. Your VM has no path to reach Boost’s control surfaces.
Reduced host attack surface — because Azure Boost owns the I/O path end-to-end, the host runs a minimal, hardened software stack with far fewer privileged components than a traditional hypervisor host.
Memory-safe implementation — critical Azure Boost components are written in memory-safe languages, eliminating entire classes of vulnerabilities by construction.
Per-tenant cryptographic isolation — networking and storage I/O are cryptographically segregated per tenant on the Azure Boost data path.

The net effect: the attack surface between your VM and the platform infrastructure is smaller than any mainstream cloud hypervisor — by design, not by patch.

Confidential Computing: What’s Shipped and What’s Coming

This Boost generation doesn’t just promise confidential computing — parts of it are already in production, and the hardware foundation for what comes next is shipping on every card today.

Shipped: Confidential VMs on Azure Boost

Confidential VMs running on Azure Boost infrastructure are generally available today on Intel platforms, deployed on dedicated clusters. This makes them the first CVM SKU running on Azure Boost. Learn more here: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dcesv6-series

Coming: Azure Boost Confidential Device and Confidential I/O

In traditional confidential computing, every I/O operation requires data to be copied from the VM’s private encrypted memory into a shared “bounce buffer” before it can be sent to devices like a NIC or storage controller. This exists because the VM’s memory is encrypted with a key that’s not accessible outside the CVM boundary — so devices can’t read it directly. The bounce buffer serves as an intermediary for DMA operations. The cost: every I/O operation requires an extra copy and an encrypt/decrypt cycle, increasing CPU usage and latency, and reducing networking and storage throughput.

Azure Boost Confidential Device (ABCD) eliminates this tax. ABCD extends the Confidential VM’s Trusted Compute Base (TCB) into the Azure Boost TDISP enabled ASIC through attested hardware integration. Rather than transferring data to a shared buffer, the Boost device can access encrypted VM memory directly through an IDE-encrypted PCIe connection, using TDISP — a PCI-SIG standard supported by all major CPU vendors that allows CVMs to attest the hardware and firmware of devices granted DMA access to their memory. By avoiding intermediate buffers, this attested secure link maintains both the confidentiality and integrity of data, allowing information to move safely and efficiently between the CVM and the attested Boost hardware.

The ASIC on the Boost card contains dedicated confidential data-flow logic in hard-IP, specifically designed to handle this encrypted traffic at wire speed. The Arm SoC and its agents remain outside the trust boundary — only the attested ASIC, FPGA and real-time firmware subsystems are included in the TCB.

We are implementing TDISP across both Intel (via TDX Connect) and AMD (via SEV-SNP) platforms — because confidential I/O should not be limited to a single CPU vendor.

The result: ABCD reduces CPU usage by eliminating bounce-buffer copies and redundant encryption cycles, freeing more vCPU resources for application workloads and enabling higher throughput through direct hardware offload of networking and storage. Benchmarks show attested confidential offloads performing at near parity with general-purpose VMs, with maintained security guarantees.

The hardware foundation is shipping on every Azure Boost card today. The customer-facing SKUs that bring ABCD to virtual machines will enter preview on Intel later this year, with AMD following. Stay tuned.

Why this matters for regulated customers

For regulated industries and sovereign deployments, this answers a question that no amount of contractual language can resolve: how do you prove the infrastructure itself is trustworthy? Hardware root of trust and continuous attestation let you and your regulators verify — cryptographically, not contractually — that workloads run on known-good, policy-compliant hardware and firmware. That’s not a checkbox. It’s a fundamentally different assurance model.

More Platform Capabilities Coming This Year

The new Azure Boost generation powers more than today’s Esv7/Dsv7/Dlsv7 launch. Over the coming months, expect:

Network-optimized VM families — new SKUs designed to expose the full networking capabilities of the Boost platform for customers who need maximum connections-per-second and packet processing performance.
Guest RDMA — low-latency, lossless networking between VMs, extending RDMA beyond traditional HPC scenarios. This Boost generation is architected for region-wide RDMA, enabling distributed workloads to communicate across Availability Zones with minimal overhead.
Broader SKU coverage — additional VM families across AMD, Arm-based processors, and GPUs will ship on this Boost generation, including remote storage encryption enablement by default, extending the platform’s performance and security benefits across the Azure Compute portfolio.

We’ll share more details as each capability reaches preview and GA milestones.

Available Today

Deploy Esv7, Dsv7, or Dlsv7 today from the Azure portal, Azure CLI, or your preferred Infrastructure as a Code (IaC) tool. They’re the first to run on this generation of Azure Boost, and they won’t be the last. The platform underneath has more to give, and we’ll be showing what’s next throughout the year.

To learn more:

Azure Boost overview — https://learn.microsoft.com/azure/azure-boost/overview
Esv7, Dsv7, and Dlsv7 VM announcement — Announcing General Availability of Azure Dl/D/Esv7-series VMs based on Intel® Xeon® 6 processors
Azure Boost product page — https://azure.microsoft.com/products/virtual-machines/boost

Public Preview: Migrate your regional virtual machines to availability zones

micahmckittrick — Thu, 07 May 2026 21:33:43 GMT

This new capability enables you to move your existing regional (nonzonal) VMs and VMSS Flex deployments into specific availability zones while preserving the VM names, data disks, and other stateful properties.

We're excited to announce the public preview of regional to zonal migration for Azure Virtual Machines and for VMs in Virtual Machine Scale Sets with Flexible orchestration. With a small number of API calls, you can take a VM that was originally deployed without a zone and assign it to availability zone 1, 2, or 3—keeping the same VM resource ID, name, OS and data disks, NICs, IP addresses, and scale set membership.

For detailed instructions, see:

Why migrate from regional to zonal?

Availability zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. Placing your VMs into zones gives you a meaningfully higher availability profile and protects you from datacenter-level failures.

Capability	Regional VM / VMSS	Zonal VM / VMSS
Datacenter-level fault isolation	No	Yes
Single-VM SLA	99.9% (Premium SSD)	99.9% (Premium SSD)
Multi-VM SLA	99.95% (availability set or fault-domain spread)	99.99% (across two or more zones)
Protection from a zone outage	No	Yes
Required for many compliance and DR architectures	—	Yes

Until now, moving an existing regional VM into a zone meant rebuilding the VM: snapshot the disks, recreate the resource in the target zone, reattach NICs, update DNS, and so on. With this preview you can do it while preserving the resource IDs and all its dependencies.

How it works

The migration is a deliberate, in-place flow that you control end-to-end:

Register the preview feature Microsoft.Compute/RegionalToZonalVMMigrationForDeallocatedVM on your subscription.
Deallocate the VM. The VM must be in Stopped (deallocated) state—plan for downtime.
Assign the zone. Update the VM's zones property to ["1"], ["2"], or ["3"].
Start the VM. It boots in the new zone immediately, even while background data migration of the disks is still completing.
(Optional) Attach to a Flexible scale set for autoscaling, rolling upgrades, and instance protection.

A few important properties of the flow:

In place. The VM keeps its resource ID, name, NICs, private/public IPs, OS and data disks, tags, and extensions.
Background data movement. Disk data is migrated transparently after the zone is assigned. You don't have to wait for it before starting the VM.
One-way. A zonal VM can't be migrated back to a regional deployment.
Per-VM granularity. For scale sets, you migrate one VM at a time so you can stagger the change across instances and validate between batches.

Two migration paths

Path 1: Single regional VM → zonal VM

For standalone VMs (or VMs you want to leave standalone). Once the VM is zonal, you can optionally attach it to a Flexible scale set in the same region.

# 1. Deallocate az vm deallocate -g <rg> -n <vm> # 2. Assign zone az vm update -g <rg> -n <vm> --set zones='["1"]' # 3. Start az vm start -g <rg> -n <vm>

If the VM is in a Proximity Placement Group, remove the PPG association in the same update by adding --ppg "".

Path 2: Regional VMSS Flex → zonal VMSS Flex

For VMs running in a Flexible scale set, you first update the scale set model to include the target zones, then migrate each VM in place. VMs keep their names, disks, network configuration, and scale set membership.

# 1. Add zones to the scale set model (no impact on running VMs) az vmss update -g <rg> -n <vmss> --set zones='["1","2","3"]' # 2. For each VM in the scale set: az vm deallocate -g <rg> -n <vm-instance> az vm update -g <rg> -n <vm-instance> --set zones='["1"]' az vm start -g <rg> -n <vm-instance>

We recommend migrating in batches—for example, a third of the instances at a time—so the application stays healthy throughout the migration window. Spreading the instances across all three zones.

Supported configurations

Source	Target
Regional VM	Zonal VM
Regional VM	Zonal VM in a Flexible scale set
Regional VM in a Proximity Placement Group	Zonal VM (PPG removed)
Regional VM in a Flexible scale set	Zonal VM in the same Flexible scale set

Not supported in this preview

You'll need to address these before migrating:

Basic SKU public IP addresses — upgrade to Standard SKU.
Basic SKU Load Balancer — upgrade to Standard Load Balancer.
Unmanaged disks — convert to managed disks.

The target zone must also support the VM's current size. You can check with:

az vm list-skus --location <region> --zone --resource-type virtualMachines -o table

How to get started

Register the preview feature on your subscription: az feature register --namespace Microsoft.Compute \ --name RegionalToZonalVMMigrationForDeallocatedVM.
Pick a non-production VM or scale set first. Walk through deallocate → assign zone → start, and confirm the VM comes up healthy in the new zone.
Plan your zone strategy. For multi-VM workloads, distribute instances across zones 1, 2, and 3 so a single zone failure minimally impacts your workload.
Roll out in batches for production scale sets, validating application health between batches.

Announcing General Availability of Azure Dl/D/Esv7-series VMs based on Intel® Xeon® 6 processors

RishiGomatam — Thu, 07 May 2026 16:08:07 GMT

We’re excited to announce the general availability of the latest Azure Dlsv7, Dsv7, and Esv7 General Purpose and Memory Optimized Virtual Machines (VMs) powered by the latest Intel® Xeon® 6 processor. Whether you’re modernizing enterprise databases, scaling cloud‑native applications, or consolidating large memory‑intensive workloads, Dlsv7, Dsv7, and Esv7 VMs provide a powerful foundation to run your most demanding applications.

These new VM families are designed to help customers run business-critical, performance-sensitive workloads at scale by delivering up to 20% better general compute performance, larger VM sizes and memory capacities, and significant improvements in networking and storage performance compared to previous generation v6 VMs. With three memory-to-vCPU configurations and optional local NVMe temp disks, the new VMs enable customers to right-size their infrastructure for a wide range of workloads.

Dsv7 VMs deliver up to 25% better performance for compute-bound workloads such as video transcoding, compression/decompression, and cryptography, up to 30% better performance for database workloads, and up to 25% better performance for AI pre-processing workloads, compared to Dsv6 VMs.

The new VMs also enable greater scale on Azure, supporting sizes up to 372 vCPUs with up to 2.8 TiB of memory. This allows customers to scale up larger in‑memory databases, run agentic AI workloads with larger context windows, and improve latency‑sensitive applications by minimizing cross‑node network hops.

A new generation of performance and scale on Azure

Dlsv7, Dsv7, and Esv7 VMs utilize the latest generation of Azure infrastructure and platform innovations enabling these VMs to deliver performance improvements across compute, networking, and storage. Powered by custom Intel® Xeon® 6 processors, these VMs are optimized to deliver high performance at cloud-scale with frequencies up to 4.2GHz and up to 2x higher memory bandwidth compared to previous generation v6 VMs.

Dlsv7, Dsv7, and Esv7 VMs deliver the highest networking, remote storage, and local storage specs across comparable VMs from leading hyperscalers, driven by the latest capabilities of Azure Boost:

Higher Networking Bandwidth - Up to 400 Gbps networking bandwidth with the largest Esv7/Edsv7 size
Faster Remote Storage - Up to 800k IOPS and 20 GBps throughput to Premium v2 SSD and Ultra Disk remote storage with the largest Esv7/Edsv7 size
Improved Local Storage Performance - Up to 9.6M IOPS and 53 GBps throughput to local NVMe temp disk with the largest Ddsv7/Edsv7 size

Additionally, Microsoft and Intel have worked together to co-design adaptive infrastructure using Intel^® Xeon^® 6 processors which reduce power consumption by up to 11% for moderate workloads without impacting performance. By using power more effectively, Azure can deploy more servers within its existing datacenter footprint to quickly meet growing customer compute demands and improve efficiency.

Dlsv7, Dsv7, and Esv7 VMs include built-in AI acceleration with Intel® Advanced Matrix Extensions (Intel® AMX) which accelerates AI inference workloads and enable the latest hardware-based security capabilities such as Intel® Total Memory Encryption (Intel® TME) which is enabled by default and provides enhanced protection to system memory to further secure your workloads.

Optimized for both general‑purpose and memory‑intensive workloads

Dlsv7 VMs offer a lower ratio of memory to vCPU (2 GiB per vCPU) and can reduce costs when running non-memory capacity sensitive applications. These VMs are ideal for workloads such as web front ends, application servers, API tiers, stateless microservices, CI/CD, small databases, and scale-out processing.

Dsv7 VMs offer a balance of memory to CPU (4 GiB per vCPU) and are ideal for many general computing workloads such as e-commerce systems, web applications, desktop virtualization solutions, application servers, containerized workloads, batch processing, and more.

Esv7 VMs offer a higher ratio of memory to CPU (8 GiB per vCPU) and are ideal for memory-intensive workloads such as SQL and NoSQL database servers, data warehousing workloads, business intelligence applications, in-memory databases such as SAP and Redis, in-memory analytics, and agentic AI compute.

Each VM family has options with and without local NVMe temp disks. Whether you choose a VM with a local temp disk or not, you can attach remote persistent disks such as Premium Disk v1, Premium Disk v2, or Ultra Disks to the VMs.

Customers and partners are excited about the new Azure Dl/D/E v7 VMs

“Amadeus continuously aims to improve the performance of its compute layer to better serve the actors of the worldwide travel industry. With the new D/E Intel v7 series, we observe a gain of +35% and +44% in terms of transactional throughput, respectively for single-threaded and multi-threaded compute heavy OLTP workloads, compared to the D/E Intel v5 series we currently use at scale." - Didier Spezia, Director Expert, Cloud Design Authority, Amadeus

“SAS® Viya® is engineered for high‑performance data and AI, and our benchmarking on Azure E‑series v7 shows meaningful gains for customers running heavy workloads. Customers see 27–34% faster response times compared to prior generations, driven by improved CPU performance and higher disk throughput. These gains translate into faster time to value and higher productivity in machine learning, agentic AI and more.” - Craig Rubendall, Vice President, Applied Architecture and Technology, SAS

"Silk has tested the Azure Dv7/Esv7 VMs and observed performance gains of up to 45% over the previous generation. This breakthrough translates directly into faster query execution, lower latency, and more predictable uptime for customers’ most I/O-intensive workloads, whether that's transactional databases, analytics pipelines, or AI inference at scale." - Adik Sokolovski, Chief R&D Officer, Silk

"Together, Intel and Microsoft have built a silicon-to-cloud foundation to deliver a new generation of Azure virtual machines powered by Intel Xeon 6, with the performance, security, and memory capacity customers need for the next generation of AI workloads.” - Srini Krishna, Intel Fellow, Data Center Products

Availability and getting started

Azure Dlsv7, Dsv7, and Esv7 virtual machines are now generally available in Central US, with additional regions coming online soon.

Customers utilizing previous generation VMs can seamlessly migrate to Dlsv7, Dsv7, and Esv7 VMs to take advantage of higher performance and scale.

To learn more about the specifications of these VMs, visit the specification pages below:

Right now, Dlsv7, Dsv7, and Esv7 VMs up to 192 vCPU are generally available. The 248 and 372 vCPU sizes for these VM series will be generally available soon.

For pricing details, visit the Azure Virtual Machines pricing page. You can learn more about regional availability on the product availability page.

Use Azure Container Registry as an Upstream Source for Artifact Cache

toddysm — Tue, 05 May 2026 23:29:10 GMT

In collaboration with:
Luis Dieguez, Principal Software Engineering Manager, Azure Container Registry
Akash Singhal, Senior Software Engineer, Azure Container Registry
Kiran Challa, Senior Software Engineer, Azure Container Registry
Nathan Anderson, Senior Software Engineer, Azure Container Registry
Tony Vargas, Senior Software Engineer, Azure Container Registry
Caroline Barker, Software Engineer II, Azure Container Registry
Mabel Egba, Software Engineer, Azure Container Registry

Introduction

ACR’s artifact cache feature has helped teams reduce upstream dependency on public registries like Docker Hub, GitHub Container Registry, and Microsoft Artifact Registry by serving cached copies of publicly available images from a local ACR instance. Until now, the main benefit of this feature has been to remove the dependency on a central public registry.

In the months after the feature release, we received a lot of requests from customers to enable ACR registries as an upstream source and we are glad to announce that this is now available.

In this post, we'll walk through:

The new scenarios this capability enables.
The supported authentication and networking matrix.
A step-by-step walkthrough using the Azure CLI to set up an ACR-to-ACR cache rule with a user-assigned managed identity.

A Quick Refresher on Artifact Cache

Artifact cache is a pull-through proxy built into ACR. You define a cache rule that maps an upstream repository to a local repository in your ACR. When a client requests an image that hasn't been cached yet:

A client pulls from your ACR (e.g., docker pull myregistry.azurecr.io/team-a/api:1.0).
ACR proxies the pull to the upstream registry and streams content back to the client.
In parallel, ACR kicks off an asynchronous copy to store the image in your ACR.
Once the async copy finishes, all subsequent pulls are served directly from your ACR.

New Scenarios ACR-to-ACR Enables

This new capability unlocks the following scenarios:

Quarantining and image promotion across environments. You can promote images between environments — for example, from a Dev registry to a Prod registry — by creating a cache rule on the target (Prod) registry that points at the source (Dev) registry as its upstream. The same pattern works for quarantining and scanning images pulled from public registries before they reach production. This increases security and reduces the risk of vulnerabilities in your environments.
Hub-and-spoke or hierarchy registry topologies. You can use the feature to implement a hierarchy of registries (up to three levels) to serve subset of images to targeted runtime clusters. This increases the performance and pull throughput for individual clusters and reduces the load on a single registry with golden images.
Eliminating credential sprawl. Existing cache rules require a credential set backed by Key Vault. With Managed Identity support, you can wire up ACR-to-ACR sync with zero secrets to rotate, store, or leak.

Authentication Model

A cache rule's authentication can now take one of these forms:

Credentials — username/password, service principal, or ACR token stored in Key Vault. This is the already existing behavior.
User-Assigned Managed Identity (UAMI) — a UAMI assigned to the target ACR is used to authenticate to the source ACR.

Design note: Managed identities are attached directly to the cache rule, not to a credential set. This is intentional and prevents a managed identity that's been granted pull permissions on a sensitive source registry from being silently reused by an unrelated cache rule pointing at a different upstream. Each cache rule gets its own explicit identity assignment.

Authentication & Networking Support Matrix

Networking on Source ACR	Same Tenant	Cross Tenant
Public - All networks	credentials, service principal, token, UAMI	credentials, service principal, token
Public - Selected networks	credentials, service principal, token, UAMI (requires Trusted Services enabled on source)	credentials, service principal, token (requires Trusted Services + CIDR allow-listing)
Private VNet (Private Link)	credentials, service principal, token, UAMI (requires Trusted Services enabled on source)	Not supported

Two important callouts:

Cross-tenant Managed Identity is not supported. Federated identity for cross-tenant scenarios is on the roadmap, and the cache-rule authentication model already includes the property shape (AuthenticationType: FederatedIdentity, TenantId, FederatedClientId) so the API is forward-compatible.
Trusted Services must be enabled on the source ACR any time the source is on a non-public network and the target ACR uses an MI. This is what allows the platform to bypass the network ACL using a trusted Microsoft control-plane path.

RBAC Required on the Source ACR

The identity (whether UAMI, or credentials) needs read access to the source registry's repositories:

RBAC and ABAC-enabled registries: assign the more granular roles Container Registry Repository Catalog Lister and Container Registry Repository Reader (optionally scoped to specific repositories).

On the target ACR, the user creating the rule needs Container Registry Cache Rule Administrator (and Container Registry Credential Set Administrator if creating a credential set).

Walkthrough: Promoting Images from Dev ACR to Prod ACR with a User-Assigned Managed Identity

Let's walk through the most common new scenario end-to-end: a Prod registry pulling images from a Dev registry, using a UAMI for authentication. Both registries are in the same tenant.

Setup

Source registry (Dev): devregistry.azurecr.io, repository team-a/api
Target registry (Prod): prodregistry.azurecr.io, repository promoted/team-a/api
A User-Assigned Managed Identity acr-promotion-uami already exists in a resource group you own.

Step 1: Attach the UAMI to the Target ACR

az acr identity assign \ 
  --name prodregistry \ 
  --identities /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/acr-promotion-uami

You can verify which identities are assigned to the registry with:

az acr identity show -n prodregistry

You'll need two values from the UAMI in the next steps:

The principal ID (object ID) — used in Step 2 for the role assignment on the source ACR.
The resource ID (the full /subscriptions/.../providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name> ARM ID) — used in Step 3 to attach the identity to the cache rule.

You can grab them with:

az identity show \ 
  --name acr-promotion-uami \ 
  --resource-group <rg> \ 
  --query '{principalId:principalId, resourceId:id}' -o tsv

Step 2: Grant the UAMI Read Access on the Source ACR

For an RBAC-only source registry:

az role assignment create \ 
  --assignee <uami-principal-id> \ 
  --role "Container Registry Repository Reader" \ 
  --scope /subscriptions/<sub-id>/resourceGroups/<dev-rg>/providers/Microsoft.ContainerRegistry/registries/devregistry 

az role assignment create \ 
  --assignee <uami-principal-id> \ 
  --role "Container Registry Repository Catalog Lister" \ 
  --scope /subscriptions/<sub-id>/resourceGroups/<dev-rg>/providers/Microsoft.ContainerRegistry/registries/devregistry

Note: We recommend enabling ABAC on your source registry and defining granular permissions for access to the upstream source registry and leveraging the —scope option for the above command to only limit the scope to the repositories the cache rule will read from.

Step 3: Create the Cache Rule with --identity

The new --identity (-i) parameter on az acr cache create accepts the resource ID (ARM ID) of the user-assigned managed identity you want the cache rule to use. It is mutually exclusive with --cred-set.

az acr cache create \ 
  --registry prodregistry \ 
  --name promote-team-a-api \ 
  --source-repo devregistry.azurecr.io/team-a/api \ 
  --target-repo promoted/team-a/api \ 
  --identity /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/acr-promotion-uami

If the identity you pass isn't actually assigned to the target ACR, you'll get a clear error indicating that the specified identity does not exist or is not associated with this registry.

Step 4: Pull Through the Cache

From any client that can authenticate to the target Prod registry:

az acr login --name prodregistry 
docker pull prodregistry.azurecr.io/promoted/team-a/api:1.4.0

Behind the scenes, the same artifact cache flow runs:

Prod ACR proxies the pull to Dev ACR, authenticating using the UAMI you attached to the rule.
The client receives the image immediately.
Prod ACR asynchronously copies the manifest(s) and layers into promoted/team-a/api.
When the async copy completes, ACR fires push webhook events on the target — exactly as it would for any other cache rule. (See the multi-arch webhook post for the event shape and timing.)

Step 5 (Optional): Update the Identity on an Existing Rule

You can swap the identity used by a cache rule at any time:

az acr cache update \ 
  --registry prodregistry \ 
  --name promote-team-a-api \ 
  --identity /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<new-uami-name>

This is useful when rotating identities or migrating a rule from a credential set to a managed identity.

Image Promotion as a First-Class Pattern

The most advanced use of this feature is image promotion — and it's worth calling out one nuance: a cache rule hydrates the target on demand, not on a schedule. The image lands in the target ACR the first time something pulls it through. Here are the steps for promoting an image:

A producer pushes a candidate image to the Dev registry (e.g., devregistry.azurecr.io/team-a/api:1.4.0).
A gating step (test pipeline, security scan, approval workflow) decides the image is fit for Prod.
The gating step does a docker pull prodregistry.azurecr.io/promoted/team-a/api:1.4.0 (or the equivalent in your CD system). That single pull triggers the cache rule and seeds Prod with the image.
On every subsequent pull, ACR performs a lightweight HEAD check against the upstream (Dev) registry to see whether the tag's manifest digest has changed. If the upstream tag was re-pushed (e.g., :1.4.0now points at a new digest), ACR re-pulls the updated content into Prod; otherwise, the pull is served directly from Prod without re-copying any layers.
From that point on, all Prod consumers serve the image from Prod — no further upstream traffic until the tag changes upstream again.

This collapses the typical "import job" into the first pull from Prod, which is both auditable (via webhooks and AAD logs on the source) and secured by a managed identity rather than a long-lived secret.

Limitations

A few things are explicitly out of scope for the initial private preview — file these under "coming soon" or "by design":

Cross-tenant Managed Identity is not supported. Use a credential set for cross-tenant scenarios.
Cross-tenant + Private VNet on the source ACR is not supported.
Anonymous pull from the source ACR is not supported. Authentication is always required for ACR-to-ACR rules.
Custom domains on the source ACR are not supported as an upstream value.
Delete propagation is not part of this feature. Deletes on the source do not propagate to the target. (This matches existing Artifact Cache behavior.)
The CLI does not provision identities or grant source-side RBAC for you. The identity must already exist, be attached to the target ACR, and have the right role on the source.
Portal experience is in development and will be available later this Summer.

Summary

Here are the key takeaways from this new capability:

ACR is now a supported upstream source for Artifact Cache. The data plane behavior — pull-through caching, async copy, webhook events, lifecycle — is identical to existing Artifact Cache behavior.
User Assigned Managed Identity is now a first-class auth option for cache rules. The identity is attached directly to the cache rule rather than to a credential set, which is an explicit security decision to prevent token reuse outside the ACR-to-ACR scope.
Same-tenant scenarios get the most flexibility: credentials, UAMI, public networking, selected networks, and Private Link are all supported. Cross-tenant scenarios are limited to credential-based auth on public networks.
Common use cases unlocked: secure image promotion (Dev → Test → Prod registries), org-wide "golden image" distribution to regional registries, and replacing brittle az acr import scripts with a managed, declarative cache rule.

Q&A

Question	Answer
Is the data plane different from regular Artifact Cache?	No — pull-through, async copy, and webhook semantics are identical.
What's actually new?	ACR is now a valid upstream, and Managed Identity is a first-class auth option.
How does auth attach to a rule?	Either a Key Vault credential set or a User-Assigned Managed Identity (UAMI). The UAMI attaches to the cache rule directly.
When can I use Managed Identity?	Same-tenant scenarios on public, selected, or private networks. Not yet for cross-tenant.
Does the source ACR need anything special?	The MI/SP needs read access (`AcrPull` or ABAC equivalents). For non-public source networking + MI, Trusted Services must be enabled on the source.
What replaces `--cred-set` for MI?	The new `--identity` (`-i`) parameter on `az acr cache create` / `az acr cache update`.
Do my existing cache rules change?	No — purely additive.

For more details, check out the official Enable artifact cache to cache artifacts from another Azure Container Registry documentation.

If you have feedback, reach out to us on the Azure Container Registry GitHub repository or contact your Microsoft account team.

Public Preview: Migrate Availability Sets to Virtual Machine Scale Sets

micahmckittrick — Tue, 05 May 2026 22:30:00 GMT

We're excited to announce the public preview of availability set to Virtual Machine Scale Set migration for Azure Virtual Machines. This new capability enables you to move your existing VMs from availability sets to Virtual Machine Scale Sets with Flexible orchestration—unlocking higher availability, autoscaling, and zone-level resiliency without recreating your workloads from scratch.

For detailed instructions, see Migrate virtual machines from availability sets to Virtual Machine Scale Sets.

Why migrate from availability sets to Virtual Machine Scale Sets?

Virtual Machine Scale Sets with Flexible orchestration provide several advantages over availability sets:

Capability	Virtual Machine Scale Sets (Flexible)	Availability Sets
Maximum instances	Up to 1,000 VMs	Up to 200 VMs
Availability zone support	Yes	No
Autoscaling	Yes	No
Rolling upgrades	Yes	No
Instance protection	Yes	No
Availability SLA	99.95% (fault domains) or 99.99% (zones)	99.95%

How it works

The migration follows a structured, step-by-step process that gives you full control:

Create a target Virtual Machine Scale Set with Flexible orchestration mode (regional or zonal)
Validate that your availability set is eligible for migration
Start migration to put the availability set into migration mode
Migrate VMs individually to the target scale set
Start VMs after each migration completes
Clean up by deleting the empty availability set

VMs are migrated one at a time, giving you control over the pace and allowing you to verify each VM before proceeding. If something doesn't go as planned, you can cancel the migration at any point—VMs that haven't been migrated yet remain in the availability set.

Migrate directly from the Azure portal

You can also migrate entirely from the Azure portal with a guided experience that handles validation, scale set selection, zone assignment, and migration in a streamlined flow. Navigate to your availability set and select Migrate to VMSS Flex from the toolbar to get started. The Azure portal walks you through each step:

Select or create a target scale set — Choose an existing compatible scale set from a dropdown, or quick-create a new one directly from the migration experience.
Assign availability zones — If you selected a zonal scale set, assign each VM to a specific availability zone for maximum resiliency.
Review and migrate — Review the configuration, then select Migrate to move all VMs at once.
Start VMs and clean up — After migration completes, start your VMs and delete the empty availability set.

Note: The portal migrates all VMs in the availability set at the same time. If you need to migrate VMs one at a time to maintain application uptime during migration, use Azure CLI, PowerShell, or the REST API instead.

Regional and zonal migration paths

You can migrate to either a regional or zonal Virtual Machine Scale Set:

Regional migration distributes VMs across fault domains within a region, similar to availability sets but with all the scale set benefits.
Zonal migration places VMs into specific availability zones (1, 2, or 3), giving you the highest level of resiliency with a 99.99% SLA. You can also optionally change VM sizes during zonal migration.

We recommend zonal migration for workloads that need maximum resiliency. Distribute your VMs across multiple zones so that a single zone failure only impacts a fraction of your workload.

How to Get Started

To get started with availability set to Virtual Machine Scale Set migration:

Register for the preview: Enable the MigrateToVmssFlex feature flag in your subscription via Azure CLI or PowerShell.
Create a target scale set: Create a Virtual Machine Scale Set with Flexible orchestration mode in the same region as your availability set.
Validate and migrate: Run the validation API against your availability set, then migrate your VMs one at a time to the target scale set.

For detailed instructions, see Migrate virtual machines from availability sets to Virtual Machine Scale Sets.

Azure Reserved VM Instances for select VM series will no longer be available starting July 1, 2026

kyleikeda — Wed, 06 May 2026 20:11:47 GMT

Summary

Starting July 1, 2026, Azure will no longer offer new purchases or renewals of certain Azure Reserved Virtual Machine Instances (RIs) for select VM series. This change affects only the ability to buy or renew RIs for the VM series listed below—your existing reservations will continue to apply through the end of their current term.

What is changing on July 1, 2026?

One-year Azure Reserved VM Instances will no longer be available for purchase or renewal for these VM series: Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls, and Lsv2.
One-year and three-year Azure Reserved VM Instances will no longer be available for purchase or renewal for these VM series: Dv3, Dsv3, Ev3, and Esv3.

What this means for you:

To avoid unexpected billing changes or lapses in commitment savings, review your current RI orders for impacted VM series and note their expiration dates. If you take no action before July 1, 2026, any affected workloads will be billed at pay-as-you-go rates after their reservations expire—even if those reservations are set to auto-renew. Existing reservations remain valid through the end of their term.

Recommended next steps:

Identify impacted reservations: In the Azure portal, go to Reservations and filter for Virtual Machines to find RIs associated with the VM series listed above.
Plan before expiration: For each impacted RI, decide whether you want to transition your savings strategy or modernize the underlying VM family.
Choose an option: Consider moving eligible spend to Azure savings plan for compute for more flexibility, and/or migrate workloads to newer generation VM series.
Validate cost impact: Use the Azure Pricing Calculator to estimate costs and confirm your expected savings coverage before making changes

Plan your transition:

Transition guide for retired Azure Reserved VM Instances
- Step-by-step guidance to help you assess impact, evaluate options, and mitigate cost risk as your reservations approach expiration. Includes recommendations for moving to Azure savings plan for compute or migrating workloads.

Additional resources:

Retired VM Sizes Migration Guide
- Guidance to help you transition to the latest VM series, minimizing disruption while optimizing cost and performance.

AI-Powered Downtime Investigation for Azure VMs: Automating Root Cause Analysis

Jon_Andoni_Baranda — Fri, 24 Apr 2026 18:35:28 GMT

Co-authors: Jie Su, Abhinav Dua, Mukthar Ahmed, Dhruv Joshi, Dibyendu Mondal

In a previous post, we shared how Azure Automated VM Recovery works to minimize virtual machine downtime through a three-stage approach: Detection, Diagnosis, and Mitigation. This post goes one layer deeper into how our team is using AI to transform incident investigation, one of the most time-consuming parts of that process.

When an alert fires for a recovery event taking longer than expected, a DRI is notified and a ticket is opened. From there, the DRI must manually dig through logs across multiple sources, build Kusto queries from scratch, and correlate timestamps across systems to identify where time was lost. This has historically taken a long time. On top of that, an engineering manager or TPM had to review the incident, understand the failure, and route it to the right engineer, often resulting in multiple handoffs before the right owner was found. Across a platform the size of Microsoft Azure, that time adds up. That is the problem we set out to solve.

How do we use AI for long duration downtime investigation?

Model Context Protocol (MCP) is a standardized protocol that connects AI models to external tools; in our case, Kusto databases, log analyzers, and incident metadata extractors. Rather than generating text about what might be wrong, the AI actually runs real queries against live telemetry. Critically, this is not a chatbot. There is no interface for a DRI to interact with. When an incident fires, the system triggers automatically, runs the full investigation pipeline, and attaches a structured analysis report directly to the ticket. By the time a DRI opens the alert, the work is already done.

The real intelligence in this system goes beyond incident analysis. It comes from encoded domain knowledge about what "normal" looks like: expected recovery timelines for different error categories, log patterns that indicate specific failure modes, and the precise meaning of each phase in the healing workflow. The system knows, for example, how to distinguish a diagnostics bottleneck from a node isolation bottleneck, and what it signals when a particular isolation step runs longer than expected. This is knowledge that took our team years to accumulate, now automatically applied to every incident. Ultimately, the goal is not to replace the DRI but to eliminate the manual investigation work so they can focus on what matters most: making the right call. The system surfaces the analysis; a human always makes the final decision.

How the System Works

The investigation pipeline follows a six-step reasoning chain that mirrors how our best engineers approach manual triage.

Step 1 (Parse and Identify): The system extracts the key metadata from the ticket incident: the affected node identifier, container identifier, the timestamp when the VM went down, and the total duration of the outage. These parameters become the inputs for everything that follows.

Step 2 (Query VM Health Events): Using the extracted metadata, the AI invokes the AI assisted triage against VM availability tables, retrieving the sequence of state transitions the virtual machine experienced during the incident window.

Step 3 (Check Host Health): The AI then queries host-level health event tables, examining node state changes to understand what the underlying host was doing during the same period. This establishes whether the issue originated at the VM level or at the node level.

Step 4 (Correlate Repair Service Logs): With both the VM and host picture in hand, the AI cross-references repair service logs to trace when our repair orchestration service was triggered, what actions it took, and how long each step took.

Step 5 (Build the Timeline): The AI assembles all of the retrieved data into a chronological, end-to-end timeline of the recovery event. This timeline maps directly to the three phases we track: Time to Detect (TTD), Time to Diagnose (TTDiag), and Time to Mitigate (TTM), as well as Time to Isolate (TTI) when service healing is involved.

Step 6 (Root Cause and Report): Finally, the AI analyzes the timeline, identifies which phase contained the largest gap, determines what operation caused the bottleneck, and generates a structured investigation report that is automatically attached to the ticket incident.

Results and conclusion

The results are measurable across three dimensions. On speed, the investigation pipeline now completes in under 5 minutes, down from 30 to 60 minutes manually, a roughly 90% reduction that shaves 50% off total triage time. On consistency, 100% of qualifying incidents receive the same thorough analysis regardless of who is on call, with the full phase breakdown (TTD, TTDiag, TTMitigate, and TTIsolate) applied every time. On ownership, the generated report gives managers and TPMs immediate context to assign the incident to the right engineer from the start, eliminating the back-and-forth handoffs that previously delayed remediation. This solution has saved Engineering Manager and TPM 10-20 minutes of manual work per incident.

By encoding our team's best practices into an automated pipeline, we turned a slow, inconsistent manual process into something fast, thorough, and always available. MCP offers a practical path for any engineering team to make the knowledge of their most experienced engineers universally accessible, not as documentation, but as an automated system that applies it to every incident, every time. We will continue to share updates as this evolves and would love to hear from teams working on similar problems.

Public Preview: Ephemeral OS Disk with full caching for VM/VMSS

viveksingla — Mon, 30 Mar 2026 19:37:31 GMT

Today, we’re excited to announce the public preview of Ephemeral OS disk with full caching, a new feature designed to significantly enhance performance and reliability by utilizing local storage. This feature is ideal for IO-sensitive stateless workloads, as it eliminates dependency on remote storage by caching the entire OS image on local storage.

Key Advantages:

High Performance: Provides extremely high-performance OS disks with consistently fast response times.
Reliability: Ensures high availability, making it suitable for critical workloads.

Why Full OS Caching?

Currently, Ephemeral OS disks store OS writes locally but still rely on a remote base OS image for reads. With Ephemeral OS Disk with full caching, the entire OS disk image is cached on local storage, removing the dependency on remote storage for OS disk reads. Once caching is complete, all OS disk IO is served locally. This results in:

Consistently fast OS disk performance with low‑millisecond latency
Improved resilience during remote storage disruptions
No impact to VM create times, as caching happens asynchronously after boot

This capability is well suited for IO-sensitive stateless workloads that need fast OS disk access, including:

AI workloads
Quorum‑based databases
Data analytics and real‑time processing systems
Large‑scale stateless services on General Purpose VM families

These workloads benefit directly from lower OS disk latency and reduced exposure to remote storage outages.

How It Works?

When full OS caching is enabled:

VM’s Local storage (cache disk, resource disk, or NVMe disk) is used to host the full OS disk
Local storage capacity is reduced by 2× the OS disk size to accommodate OS caching
The OS disk is cached in the background after VM boot, ensuring fast provisioning
All OS disk IOs happen on the local storage, thus providing 10X better IO performance and resiliency to storage interruptions

Public Preview Availability

During public preview, Ephemeral OS disk with full caching is available for most general purpose VM SKUs (excluding 2‑vCPUs and 4‑vCPUs VMs) in 29 regions - AustraliaCentral, AustraliaCentral2, AustraliaSouthEast, BrazilSoutheast, CanadaCentral, CanadaEast, CentralIndia, CentralUSEUAP, EastAsia, GermanyWestCentral, JapanEast, JioIndiaCentral, JioIndiaWest, KoreaCentral, KoreaSouth, MalaysiaSouth, MexicoCentral, NorthEurope, NorwayWest, QatarCentral, SouthAfricaNorth, SwedenCentral, SwitzerlandWest, TaiwanNorth, UAECentral, UKSouth, UKWest, WestCentralUS, and WestIndia.

We’re continuing to expand support across regions, and tooling as we move toward general availability.

Getting Started

Customers can enable Ephemeral OS disk with full caching when creating new VMs or VMSS by updating their ARM templates or REST API definitions and setting the enableFullCaching flag for Ephemeral OS disks.

ARM template to create VMs with full caching:

"resources": [ "name": "[parameters('virtualMachineName')]", "type": "Microsoft.Compute/virtualMachines", "apiVersion": "2025-04-01", .. .. "osDisk": { "diffDiskSettings": { "option": "Local", "placement": "ResourceDisk", "enableFullCaching": true }, "caching": "ReadOnly", "createOption": "FromImage", "managedDisk": { "storageAccountType": "StandardSSD_LRS" } }

ARM template to create VMSS with full caching:

"resources": [ "name": "[parameters('vmssName')]", "type": "Microsoft.Compute/virtualMachineScaleSets", "apiVersion": "2025-04-01", .. .. "osDisk": { "diffDiskSettings": { "option": "Local", "placement": "ResourceDisk", "enableFullCaching": true }, "caching": "ReadOnly", "createOption": "FromImage", "managedDisk": { "storageAccountType": "StandardSSD_LRS" } }

Your feedback during public preview will help shape the final experience.

Upcoming Compute API Change: Always return non-null securityType

AjKundnani — Wed, 29 Apr 2026 09:02:08 GMT

Overview

Starting with Azure Compute API version 2025‑11‑01, responses for Azure Virtual Machines (VMs) and Virtual Machine Scale Sets (VMSS) will include a non‑null securityType value in all operations.

While this is a small behavioral change, it can impact deployments if they rely on null checks in automation, validation, or post‑deployment scripts. This post explains what is changing, why the change was made, and what—if anything—you need to do to prepare.

This update applies only to the 2025‑11‑01 API version. Older API versions are unaffected and will continue to behave as they do today.

What’s changing?

With Azure Compute API version 2025‑11‑01, all VM and VM Scale Set operations—including create, update, and GET—will always return a populated securityType field in the response.

Specifically:

The securityType field will always return one of the following values, based on the resource configuration:

Input Security Type

Returned Security Type with new API version

<null>

Standard

Standard

Standard

TrustedLaunch

TrustedLaunch

ConfidentialVM

ConfidentialVM
If a VM or scale set is created or updated without specifying a securityType (that is, the value is omitted or set to null), the API response will now return securityType: "Standard"
Existing VMs or scale sets that already have a defined securityType (TrustedLaunch or ConfidentialVM) will continue to return their configured value, unchanged.

Important: This behavior change applies only to API version 2025‑11‑01. API versions prior to this will continue returning null when no securityType is specified.

Why this change is made

The securityType field represents an explicit security posture for a VM or scale set. Returning a consistent, non‑null value improves response clarity and aligns the API contract with actual runtime behavior, where resources always operate under a defined security model—even when not explicitly specified during creation.

This change makes API responses more predictable and reduces ambiguity for consumers interpreting resource configuration.

Will this impact existing workloads?

No. This change does not affect the runtime behavior of your existing VMs or scale sets. There is no impact to deployed resources, workloads, or infrastructure behavior.

However, you may be impacted if:

You use API version 2025‑11‑01, AND
You have automation, validation logic, or post-deployment scripts that:
- Explicitly check for securityType == null
- Treat a missing or null securityType as a special case

Only requests made using API version 2025‑11‑01 will return the updated, always‑present securityType value. Requests using older API versions are unchanged.

Azure PowerShell and Azure CLI: Current released versions of Azure PowerShell (Az.Compute) and Azure CLI (az vm / az vmss) are not impacted by this change. These tools use API versions prior to 2025‑11‑01 and will continue to behave as they do today. When future releases of these tools adopt API version 2025‑11‑01, the change will be documented in the release notes for the respective tools.

Impact on Azure PowerShell and Azure CLI

Current released versions of Azure PowerShell (Az.Compute module) and Azure CLI (az CLI) are not affected by this change. They rely on Azure Compute API versions earlier than 2025‑11‑01, which continue to return null for securityType when none is specified — consistent with today's behavior.

When these tools are updated to use API version 2025‑11‑01 in a future release, release notes for Azure PowerShell and Azure CLI will call out any behavioral changes customers should be aware of. No action is needed from PowerShell or CLI users at this time.

What actions do customers need to take?

If you will be using Azure Compute API version 2025‑11‑01, review and update any code that assumes securityType may be null.

Recommended actions:

No action required for Azure PowerShell or Azure CLI users. The current versions of these tools are unaffected. Monitor the release notes for Az.Compute and Azure CLI for the version that adopts API version 2025‑11‑01 — that release will note any client-side impacts.

✅ Update validation logic to accept "Standard" as the default value

✅ Remove or adjust null checks that gate logic or fail deployments

✅ Ensure post‑deployment checks and compliance scripts handle all supported securityType values

For example, a VM created without specifying securityType will now return "Standard" instead of null.

No action is required if you are using API versions earlier than 2025‑11‑01.

Example: GET response behavior (API version 2025‑11‑01)

The following example shows a GET VM response where no securityType was specified at creation time. Note that the response still includes a non‑null value (Standard).

{ "id": "<vmResourceId>", "name": "<vmName>", "type": "Microsoft.Compute/virtualMachines", "properties": { "securityProfile": { "securityType": "Standard" } } }

Next steps

Review your automation, validation or/and post-deployemnt scripts now to ensure a smooth transition when adopting Azure Compute API version 2025‑11‑01.

Public Preview: Automatic zone balance for Virtual Machine Scale Sets

HilaryWang — Tue, 17 Feb 2026 17:30:00 GMT

We're excited to announce the public preview of automatic zone balance for Azure Virtual Machine Scale Sets. This new capability helps you maintain zone-resilient workloads with zero manual intervention. Automatic zone balance continuously monitors your scale set and redistributes VMs across availability zones, reducing the risk that a single zone failure disproportionately impacts your applications.

Maintain Optimal Resiliency Posture with Continuous Monitoring

When you deploy a Virtual Machine Scale Set across multiple availability zones, Azure spreads your VMs as evenly as possible for maximum resiliency. However, capacity constraints, scaling operations, and other factors can cause your scale set to become imbalanced over time, with some zones holding more VM instances than others. This imbalance often goes unnoticed, but it means a zone failure could take down a larger share of your workload than expected.

Figure 1: If an outage occurs in Zone 1, an imbalanced scale set would experience a 50% impact on its workload, while a balanced scale set would only experience 33% impact to an outage in any zone.

Automatic zone balance addresses these challenges by continuously monitoring your scale set for zonal imbalances and tracking capacity in under-provisioned zones. When capacity becomes available, VMs are automatically created in the under-provisioned zone, eliminating the need for manual trial-and-error.

When rebalancing occurs, Automatic zone balance uses a create-before-delete approach. New VMs are created in under-provisioned zones and verified healthy before VMs in over-provisioned zones are removed, ensuring your workload capacity is never reduced during the process. Health checks are performed through integration with Application Health Extension or Load Balancer Health Probes, so only healthy VMs are kept.

Built-in safety guardrails ensure rebalancing respects instance protection policies and pauses during active scale set operations. To minimize churn, rebalancing includes back-off periods between operations and moves only one VM at a time.

When you enable Automatic zone balance, automatic instance repairs is also activated by default, giving you both zone-level resiliency and instance-level health monitoring. Together, these capabilities help you maintain resilient, well-distributed workloads with minimal operational overhead, reducing the blast radius of zone failures while ensuring gradual, controlled changes to your scale set.

How to Get Started

To get started with Automatic zone balance:

Register for the preview: Enable the AutomaticZoneRebalancing feature flag in your subscription via Azure portal, CLI, or PowerShell.
Ensure prerequisites: Your scale set must span at least 2 availability zones, use best-effort zone balancing mode, and have application health monitoring configured.
Enable Automatic zone balance: Turn on the feature through Azure portal, CLI, PowerShell, or REST API.

For detailed instructions, visit the automatic zone balance documentation.

Azure Automated Virtual Machine Recovery: Minimizing Downtime

Jon_Andoni_Baranda — Wed, 04 Feb 2026 19:23:11 GMT

Co-authors: Mukhtar Ahmed, Shekhar Agrawal, Harish Luckshetty, Vinay Nagarajan, Jie Su, Sri Harsha Kanukuntla, David Maldonado, Shardul Dabholkar.

Keeping virtual machines running smoothly is essential for businesses across every industry. When a VM stays down for even a short period, the impact can cascade quickly; delayed financial transactions, stalled manufacturing lines, unavailable retail systems, or interruptions to healthcare services. This understanding led to the creation of this solution, with its primary goal of ensuring fast and reliable recovery times so customers can focus on their business priorities without worrying about manual recovery strategies. This feature helps ensure your business Service-Level Agreements are consistently met.

When a VM experiences an issue, our system springs into action within seconds, working to restore your service as quickly as possible. It automatically executes the optimal recovery strategy, all without customer intervention. The feature operates continuously in the background, monitoring the health of VMs through multiple detection mechanisms. Lastly, it automatically selects the fastest recovery path based on the specific failure type.

Getting Started

The best part? Azure Automated VM Recovery requires no setup or configuration. Running quietly in the background, this service helps guarantee the highest level of recoverability and a smooth experience for every Azure customer. Your VMs are already benefiting from faster detection, smarter diagnosis, and optimized recovery strategies.

The Importance of Automated VM Recovery

Automated VM recovery is essential to keeping cloud services resilient, reliable, and interruption-free. Automated recovery ensures that the moment a failure occurs, the platform responds instantly with fast detection, intelligent diagnostics, and the optimal repair action, all without requiring customer intervention.

Better experience for customers: By minimizing VM downtime, it helps customers keep their services online, avoiding disruptions and potential business losses.
Stronger trust in Azure: Fast, reliable recovery builds customer confidence in Azure’s platform, reinforcing our reputation for dependability.
Reduced financial impact for customers: The lower the downtime, the less time your customers will be impacted, reducing potential loss of revenue and minimizing business disruption during critical operations.
Empowering internal teams: Automated monitoring and clear visibility into recovery metrics help teams track health, onboard easily, and identify opportunities for improvement with minimal effort.

How Azure Automated VM Recovery Works: A Three-Stage Approach

Azure automatically handles VM issues through a three-stage recovery framework: Detection, Diagnosis, and Mitigation.

Detection

From the moment a failure occurs, multiple parallel mechanisms identify issues quickly. Azure hardware devices send regular health signals, which are monitored for interruptions or degradation. At the application level, operational health is tracked via response times, error rates, and successful operations to detect software-level problems rapidly.

Diagnosis

Once detected, lightweight diagnostics determine the best recovery action without unnecessary delays. Diagnostics operates at multiple levels; host level checks asses underlying infrastructure, VM level diagnostics evaluate the virtual machine state and system-on-chip (SoC) level analysis examines hardware components. This includes network checks, resource utilization assessments, and service responsiveness tests. Detailed data is also collected for post-incident analysis, continuously improving diagnostic algorithms while active recovery proceeds.

Mitigation

Based on diagnostics, the system automatically executes the optimal recovery strategy, starting with the least disruptive methods and escalating as needed. Hardware failures may trigger VM migration, while software issues might be resolved with targeted service restarts. If needed, a host reset is performed while preserving virtual machine state, ensuring minimal disruption to running workloads. Post-mitigation health checks ensure full VM functionality before recovery is considered complete.

Recovery Event Annotations

Recovery Event Annotations are specialized annotations that provide detailed visibility into every stage of VM recovery, going beyond simple uptime metrics. These indicators act as custom monitoring metrics, breaking down each incident into precise time segments. For example, TTD (Time to Detect) measures the time between a VM becoming unhealthy and the system recognizing the issue, while TTDiag (Time to Diagnose) tracks the duration of diagnostic checks. By analyzing these segments, Recovery Timing Indicators help identify bottlenecks, optimize recovery steps, and improve overall reliability. Key benefits include:

Understanding why some VMs recover faster than others.
Identifying which diagnostics add value versus those that don’t.
Highlighting opportunities that provide a faster path of recovery.
Enabling early detection of regressions through event annotation-driven alerts.
Establishing a common language across Azure teams for measuring and improving downtime.

Customer Impact and Results

Azure Automated VM Recovery demonstrates our commitment to not only high availability but also rapid recovery. By minimizing downtime, it helps customers build resilient applications and maintain business continuity during unexpected failures. Over the past 18 months, this solution has cut average VM downtime by more than half, significantly enhancing reliability and customer experience. Our ongoing goal is to provide a platform where customers can deploy workloads with confidence, knowing automated recovery will minimize disruptions.

Announcing General Availability of Azure Da/Ea/Fasv7-series VMs based on AMD ‘Turin’ processors

ArpitaChatterjee — Tue, 27 Jan 2026 21:54:30 GMT

Today, Microsoft is announcing the general availability of Azure’s new AMD based Virtual Machines (VMs) powered by 5th Gen AMD EPYC™ (Turin) processors. These VMs include general-purpose (Dasv7, Dalsv7), memory-optimized (Easv7), and compute-optimized (Fasv7, Falsv7, Famsv7) series, available with or without local disks.

Azure’s latest AMD based VMs offer faster CPU performance, greater scalability, and flexible configurations, making them the ideal choice for high performance, cost efficiency, and diverse workloads.

Key improvements include up to 35% better CPU performance and price-performance compared to equivalent v6 AMD-based VMs. Workload-specific gains are significant—up to 25% for Java applications, up to 65% for in-memory cache applications, up to 80% for crypto workloads, and up to 130% for web server applications just to name a few.

Dalsv7-series VMs are cost-efficient for low memory workloads like web servers, video encoding, and batch processing. Dasv7-series suit general computing tasks such as e-commerce, web front ends, virtualization, customer relationship management applications (CRM), and entry to mid-range databases. Easv7-series target memory-heavy workloads like enterprise applications, data warehousing, business intelligence, in-memory analytics and more. Falsv7-, Fasv7-, and Famsv7 series deliver full-core performance without Simultaneous Multithreading (SMT) for compute-intensive tasks like scientific simulations, financial modeling, gaming and more. You can now choose constrained-core VM sizes — reducing the vCPU total by 50% or 75% while maintaining the other resources.

Dasv7, Dalsv7, and Easv7 VMs now scale up to 160 vCPUs, an increase from 96 vCPUs in the previous generation. The Fasv7, Falsv7, and Famsv7 VMs, which do not include Simultaneous Multithreading (SMT), support up to 80 vCPUs—up from 64 vCPUs in the prior generation—and introduce a new 1-core option. These VMs offer a maximum boost CPU frequency of up to 4.5 GHz for faster compute-intensive operations.

The new VMs deliver increased memory capacity —up to 640 GiB for Dasv7 and 1280 GiB for Easv7—making them ideal for memory-intensive workloads. They also support three memory (GiB)-to-vCPU ratios: 2:1 (Dalsv7-series, Daldsv7-series, Falsv7-series and Faldsv7-series), 4:1 (Dasv7-series, Dadsv7-series, Fasv7-series and Fadsv7-series), and 8:1 (Easv7-series, Eadsv7-series, Famsv7-series and Famdsv7-series).

Remote storage performance is improved up to 20% higher IOPS, up to 50% greater throughput, while local storage performance offers up to 55% higher throughput. Network performance is also enhanced up to 75% compared to corresponding D-series and E-series v6 VMs. New VM series Fadsv7, Faldsv7, and Famdsv7, introduce local disk support.

The new VMs leverage Azure Boost technology to enhance performance and security, utilize the Microsoft Azure Network Adapter (MANA), and support the NVMe protocol for both local and remote disks.

The 5th Generation AMD EPYC™ processor family, based on the newest ‘Zen 5’ core, provides enhanced capabilities for these new Azure’s AMD based VM series such as AVX-512 with a full 512-bit data path for vector and floating-point operations, higher memory bandwidth, and improved instructions per clock compared to the previous generation. These updates provide the ability to handle compute-intensive tasks for AI and machine learning, scientific simulations, and financial analytics, among others. AMD Infinity Guard hardware-based security features, such as Transparent Secure Memory Encryption (TSME), continue in this generation to ensure sensitive information remains secure.

These VMs are available in the following Azure regions: Australia East, Central US, Germany West Central, Japan East, North Europe, South Central US, Southeast Asia, UK South, West Europe, West US 2, and West US 3. The large 160 vCPU Easv7-series and Eadsv7-series sizes are available in North Europe, South Central US, West Europe, and West US 2. More regions are coming in 2026. Refer to Product Availability by Region for the latest information.

Our customers have shared the benefits they’ve observed with these new VMs:

“Elastic enables customers to drive innovation and cost-efficiency with our observability, security, and search solutions on Azure. In our testing, Azure’s latest Daldsv7 VMs provided up to 13% better indexing throughput compared to previous generation Daldsv6 VMs, and we are looking forward to the improved performance for Elasticsearch users deploying on Azure.” — Yuvraj Gupta, Director, Product Management, Elastic

“The Easv7 series of Azure VMs offers a balanced mix of CPU, memory, storage, and network performance that suits the majority of Oracle Database configurations very well. The 80 Gbps network with the jumbo frame capability is especially helpful for efficient operation of FlashGrid Cluster with Oracle RAC on Azure VMs.” — Art Danielov, CEO, FlashGrid

"Our analysis indicates that Azure’s new AMD based v7 series Virtual Machines demonstrate significantly higher performance compared to the v6 series, particularly in single-thread ratings. This advancement is highly beneficial, as several of our critical applications, such as ArcGIS Enterprise, are single-threaded and CPU-bound. Consequently, these faster v7 series VMs have resulted in improved performance with the same number of users, evidenced by lower server utilization and faster client-side response times." — Thomas Buchmann, Senior Cloud Architect, VertiGIS

Here’s what our technology partners are saying:

“AMD and Microsoft have built one of the industry’s most successful cloud partnerships, bringing over 60 VM series to market through years of deep engineering collaboration. With the new v7 Azure VMs powered by 5th Gen AMD EPYC processors, we’re setting a new benchmark for performance, efficiency, and scalability—giving customers the proven, leadership compute they expect from AMD in the world’s most demanding cloud environments.” — Steve Berg, Corporate Vice President and General Manager of the Server CPU Cloud Business Group at AMD

“Our collaboration with Microsoft continues to empower developers and enterprises alike. The new AMD based v7-series VMs on Azure offer a powerful foundation for the full spectrum of modern workloads, from development to production AI/ML pipelines. We are excited to support this launch, ensuring every user gets a seamless experience on Ubuntu, with the enterprise security and long-term stability of Ubuntu Pro available for their most critical systems." — Jehudi Castro-Sierra, Public Cloud Alliances Director

"The new Azure Da/Ea/Fa v7-series AMD Turin-based instances running SUSE Linux Enterprise Server provide a significant performance uplift during initial tests. They show an impressive 20%-40% increase with typical Linux kernel compilation tasks compared to the same instance sizes of the v6 series. This demonstrates the enhanced capabilities the v7 series brings to our joint customers seeking maximum efficiency and performance for their critical applications.” — Peter Schinagl, Sr. Technical Architect, SUSE

You can learn more about these latest Azure AMD based VMs by visiting the specification pages at Dasv7-series, Dadsv7-series, Dalsv7-series, Daldsv7-series, Easv7-series, Eadsv7-series, Fasv7-series, Fadsv7-series, Falsv7-series, Faldsv7-series, Famsv7-series , Famdsv7-series, constrained-core sizes.

For pricing details, visit the Azure Virtual Machines pricing page. These VMs support all remote disk types. See Azure managed disk type for additional details. Disk storage is billed separately.

Azure Integrated HSM (Hardware Security Module) will continue to be in preview with these VMs. Azure Integrated HSM is an ephemeral HSM cache that enables secure key management within Azure VMs by ensuring that cryptographic keys remain protected inside a FIPS 140-3 Level 3-compliant boundary throughout their lifecycle. To explore this new feature, please sign up using the form.

Have questions? Please reach us at Azure Support and our experts will be there to help you with your Azure journey.

Improving Efficiency through Adaptive CPU Uncore Power Management

PulkitMisra — Wed, 21 Jan 2026 16:00:00 GMT

In a competitive landscape, Microsoft Azure, like other major cloud service providers, must continuously balance two competing objectives: maximizing performance and improving power efficiency. By using power more effectively, Azure can deploy more servers within its existing datacenter footprint to quickly meet growing customer compute demands and improve sustainability.

While power management encompasses a broad range of technologies, this article focuses on uncore power management, which targets components outside the CPU cores but within the processor package. The uncore domain includes the mesh interconnect, memory controllers, and I/O subsystem.

Figure 1: An illustration of a diurnal workload’s resource utilization

The Need for Uncore Power Management

Cloud servers often operate under low load due to diurnal resource utilization patterns (e.g., user-facing workloads such as Microsoft Teams), which exhibit reduced demand during weeknights and weekends, as shown in Figure 1. In addition, customers often provision VMs for peak demand, causing servers to run under reduced load during off-peak periods.

Even under reduced load, server CPUs continue to consume significant power. Although idle cores can enter deep low-power states (e.g., core C6), the uncore typically remains active and operates at its highest frequency, as the presence of even a single active core prevents it from entering an idle state. The few active cores may be running background Azure server agents for monitoring and maintenance, which generally have relaxed performance requirements. Moreover, workloads operating under reduced load can often tolerate slightly higher latency without degrading tail performance. Together, these characteristics make it feasible to leverage active low-power techniques, such as reducing uncore frequency, to improve power efficiency.

While modern CPUs support dynamic uncore frequency scaling, software-only approaches to reducing uncore frequency under low load are limited in effectiveness, as they struggle to respond quickly to sudden bursts of workload activity.

Hardware/Software Co-design For Improving CPU Power Efficiency

Intel and Microsoft Azure co-designed Efficiency Latency Control (ELC), a mechanism for managing uncore frequency that is now available on Intel Xeon 6 (Granite Rapids) processors. The implementation allows software to define CPU utilization thresholds and their corresponding uncore frequency targets, which are communicated to the CPU firmware for enforcement. This division of responsibility enables software to tailor power–performance behavior to workload characteristics, while the hardware ensures fast and reliable execution of the frequency control logic.

Figure 2: Managing uncore frequency and power using ELC

ELC mode allows software to specify three uncore frequency points—Low, Mid, and High—along with two CPU utilization thresholds -- Low and High. When utilization is at or below the Low threshold, firmware sets the uncore frequency to the defined minimum value, thereby maximizing power savings. As utilization rises above the Low threshold, the frequency is increased to the Mid-level, balancing performance and power efficiency. Finally, when utilization exceeds the High threshold, the uncore frequency is increased up to the defined maximum, subject to package power constraints, to meet performance demands under heavy load.

Figure 2 illustrates several ELC configuration strategies, each representing a different tradeoff between latency and power efficiency. Config #1 prioritizes latency by maintaining a consistently high uncore frequency across all CPU utilization levels, mirroring the default high-performance mode. This delivers optimal responsiveness but incurs higher power consumption, particularly under low-load conditions. Config #2 lowers the uncore frequency under very low utilization, improving power efficiency when background tasks (e.g., agents) are active and VMs are largely idle. Finally, Config #3 offers a balanced approach, allowing moderate frequency scaling at low load to conserve power while maintaining acceptable performance. This configuration is appropriate when a slight tradeoff in responsiveness is tolerable in exchange for improved power efficiency. The Perf/Watt Optimized curve represents the ideal dynamic scaling behavior, adjusting uncore frequency to maximize performance per watt across varying workload intensities.

Real-World Impact

ELC mode provides compelling benefits:

Figure 3: Power and performance impact for SPEC CPU Integer benchmark suite

ELC reduces power consumption by up to 11% under iso-performance for moderate loads. Figure 3 shows the performance and power impact of ELC Config #1 (latency-optimized) and Config #3 on the SPEC CPU Integer benchmark suite under moderate load, where only a subset of CPU cores are active while the rest remain idle. As the figure illustrates, Config #3 achieves comparable performance to Config #1 while reducing power consumption by up to 11% (9% on average). At higher loads (not shown), the power savings of Config #3 diminish, as the uncore must operate at higher frequencies to match the performance of Config #1.

Figure 4: Performance/watt improvement under lightly loaded storage operations

ELC provides up to 1.5× improvement in performance per watt under very low load. Figure 4 compares the performance-per-watt of ELC Config #1 and Config #3 under very low storage loads. Config #1 maintains a consistently high uncore frequency, which limits efficiency. In contrast, Config #3 can lower the uncore frequency to the Low setting under light load, slightly reducing absolute performance but achieving substantially higher performance per watt.

These results demonstrate that ELC’s configurability can deliver performance comparable to latency-optimized mode with significantly higher power efficiency, enabling Azure to increase server deployments within its existing datacenter power footprint to quickly meet customer compute demands while also improving sustainability.

Looking Forward

As cloud workloads continue to evolve, the importance of hardware–software co-design in enabling adaptive infrastructure will increase. The integration of hardware and software controls for CPU uncore frequency management marks a significant step towards improving server power and energy efficiency. Looking ahead, further collaboration between Microsoft Azure and hardware vendors will unlock new opportunities for efficiency, sustainability, and cost effectiveness.

Appendix

ELC mode details: Intel® Xeon® 6 Processors - Performance and Power Profiles - Default, Latency-Optimized Mode, and Other Options Technical Article

Scaling Azure Compute for Performance

DanaCozmei — Tue, 02 Dec 2025 21:20:46 GMT

Ignite 2025 highlighted a clear trend across customer and partner discussions: modern workloads—AI inference, data-intensive analytics, and globally distributed applications—require infrastructure that delivers consistent performance, rapid scale-out, and adaptive behavior under real-world pressure. The focus this year was on practical capabilities that remove bottlenecks, simplify operations, and provide the compute foundation needed to support the next wave of innovation.

Azure’s newest advancements reflect that direction. Breakthroughs like Direct Virtualization enable low-latency access to GPUs and NVMe; Large Container sizes push new limits for AI/ML and analytics; VM Applications streamline global deployments; Scheduled Actions bring automation to thousands of VMs; Azure Compute Gallery boosts resiliency with Soft Delete and ZRS; and VMSS Instance Mix improves capacity acquisition through flexible SKU selection.

This retrospective highlights the capabilities that shaped Ignite and how Azure is advancing a high-performance, adaptive compute platform built for the next generation of workloads.

Direct Virtualization – Breaking Barriers for Performance

Direct Virtualization generated a lot of excitement at Ignite, enabling performance-sensitive workloads like AI inference and gaming to launch faster and more affordably. Key highlights:

Direct access to devices like NvMe disks and GPUs with near Bare metal performance.
Isolation for child VMs hosting hostile workloads.
Lower latency and cost efficiency for demanding applications.
High throughput data access from child VMs for high performance workloads.

Available in limited preview, please sign up here: aka.ms/DirectVirtualizationPreview

Large Containers sizes: Supercharging Compute-Intensive Apps

Large containers were well received at Ignite. Why? Because they unlock massive performance gains for AI/ML training, big data analytics, and high-throughput services. With higher vCPU and memory configurations, customers can:

Accelerate AI workloads: Train models faster and scale inference seamlessly.
Simplify orchestration: Fewer containers, less complexity.
Reduce latency: Minimize inter-container chatter for blazing-fast execution.

Now Generally Available!

Learn more: aka.ms/bigcontainersblog

VM Applications: Global Reach, Zero Hassle

We were happy to announce General Availability for VM applications. Managing apps across thousands of VMs, at Ignite we showcased how VM Applications make this effortless. Customers loved the ability to:

Deploy up to 25 applications (2GB each) per VM together.
Deploy consistently across regions with automatic replication.
Automate updates without manual intervention.
Scale globally with confidence.

This simplifies operational overhead for enterprises running distributed workloads.

Learn more: https://aka.ms/VMApps/blogs/ignite2025

Scheduled Actions: Automation at Scale

Operational efficiency was a hot topic, and Scheduled Actions, now Generally Available solves this problem. Now you can schedule power operations for up to 5,000 VMs in one go. Scheduled actions enables:

Cost optimization during off-peak hours.
Reliability with built-in throttling safeguards.
Time savings through automation.
Actions available in GA: Start, Stop, Hibernate, with support for more actions coming soon!

Azure Compute Gallery – Enhance resiliency

Azure Compute Gallery (ACG) continues to evolve, introducing robust features that safeguard your virtual machine (VM) images and application artifacts. Two key resiliency innovations: the new Soft Delete feature (announced in preview) and Zonal Redundant Storage (ZRS) as the default storage type for image versions.

The combination of Soft Delete and ZRS by default provides Azure customers with enhanced operational reliability and data protection. Whether overseeing a suite of VM images for development and testing purposes or coordinating production deployments across multiple teams, these features offer the following benefits:

Mitigate operational risks associated with accidental deletions or regional outages.
Minimize downtime and reduce manual recovery processes.
Promote compliance and security through advanced access controls and transparent recovery procedures.

Acquiring capacity at Scale

We know that capacity acquisition can get complicated and can prohibit scale. With SKU fungibility in a single deployment where you can define up to 5 SKUs using VMSS Instance Mix with allocation policies simplifies capacity fungibility at scale. Customers can:

Mix up to five VM sizes in a single scale set.
Use allocation strategies like CapacityOptimized, LowestPrice, or Prioritized.
Secure capacity during peak demand while optimizing costs.

This approach ensures agility and resilience for unpredictable workloads.

Best Practices

We also shared best practices for Scale and performance. The session emphasized:

Using latest SKUs for best performance and price/performance.
Using Instance mix for acquiring capacity at scale using different SKUs.
Use VM Apps for delivering apps reliably and at scale.
For Virtual Desktop use cases, use Schedule actions for managing power states at scale.
Building resiliency and security from the get-go.

Session on-demand link: ignite.microsoft.com/en-US/sessions/BRK173?source=/speakers/80665103-5e69-4b8c-ad15-1d1f84c8dd6a

Conclusion: Customer Excitement on AI + Azure Infra

Ignite made it clear that scaling for performance is no longer about simply adding more compute; it’s about intelligent architecture, automation at scale, and flexible capacity models that adapt to real-world demands. Capabilities such as Direct Virtualization, Large Container sizes, VM Applications, Scheduled Actions, and SKU fungibility are not incremental enhancements; they represent foundational building blocks for AI-ready, resilient, and cost-efficient infrastructure.

Customers are approaching Azure with bold AI ambitions, and the momentum is unmistakable. Whether training large models or deploying inference globally, the innovations showcased at Ignite demonstrate that Azure Compute is engineered to support these next-generation workloads with precision, scale, and operational excellence.

As the industry accelerates toward more intelligent and distributed systems, Azure’s compute platform is evolving in lockstep—delivering the performance, automation, and adaptability required to turn ambitious ideas into production-ready breakthroughs.

Here’s to scaling smarter, operating more efficiently, and powering the next decade of cloud innovation—together.

Golazo: A Framework for Streamlined Engineering

Ben Martens — Thu, 20 Nov 2025 16:37:24 GMT

We’re excited to announce the public open-source release of Golazo!

Golazo is an open-source framework designed to help engineering teams work efficiently and transparently. It’s designed for real-world practicality by emphasizing design documentation before code, multiple peer reviews, visual workflow boards, shared ownership, and customer validation.

Every work item is scoped to less than two weeks and begins with a concise design document. Peer signoff is required before coding starts, helping eliminate architectural surprises during PR reviews. These documents not only provide immediate context but also serve as a lasting knowledge base for the team and a valuable resource for AI coding agents and LLMs.

There’s no assigned ownership of workstreams. Engineers are encouraged to pick up any ticket that interests them, supported by team conversations and the design doc knowledge base. Successes and learning opportunities are shared by all.

Golazo is built for asynchronous collaboration, making it ideal for both in-person teams and hybrid teams across time zones. Daily standups focus on lessons learned and moving work forward, not just status updates. Regular retrospectives celebrate wins and identify ways to improve efficiency. Planning is a group activity, ensuring everyone’s perspective is included.

Curious about the details? Explore the full documentation on GitHub or the rendered HTML version on GitHub pages to see how Golazo can help your team thrive.

Introducing Metadata Security Protocol (MSP): Elevating Platform Security for Azure VMs

Amjad_Shaik — Wed, 19 Nov 2025 19:36:55 GMT

We are excited to announce the General Availability (GA) of Metadata Security Protocol (MSP), an industry-first innovation designed to mitigate vulnerabilities at the platform layer. Azure becomes the first major cloud provider to integrate strong authentication and authorization (AuthN and AuthZ) for metadata service endpoints inside virtual machines. MSP introduces a default-closed security model for the Instance Metadata Service (IMDS) and WireServer, ensuring only trusted processes can access sensitive data over it, eliminating a subset of attack classes, reducing another subset of attack surfaces and aligning with zero-trust security principles.

What is MSP and Why Does It Matter?

The Instance Metadata Service (IMDS) provides critical information to virtual machines, including instance details, managed identity tokens, and platform configuration data. Historically, IMDS endpoints across the industry cloud providers including Azure, were accessible security boundary of protection being the Guest Virtual machine. With the advent of containerization and nested virtualization, the new MSP protocol invests in a strong authentication layer, which enables sub-VM security boundary protection for hosted cloud services infrastructure. And this additionally, helps eliminate several security anti-patterns and attack subclasses related to:

Server-Side Request Forgery (SSRF) over IMDS endpoints – curtailing exploitation of unauthenticated metadata APIs to gain access to sensitive tokens or configuration data.
Hosted-on-Behalf-of (HoBo) nested tenancy bypasses – eliminating attack scenarios bypasses for nested virtualization setup for multi-tenancy or misconfigured trust boundaries allowed indirect access to metadata.
Implicit trust within the VM – adding strong application layer defense in depth beyond network isolation for sub-VM boundaries.

MSP addresses this by introducing industry-first protections:

Authentication for IMDS calls – uses a trusted delegate and HMAC to ensure only verified processes can access metadata. Every IMDS and WireServer request is authenticated and validated using trusted delegates and HMAC signatures, ensuring only verified processes can access metadata.

Improved isolation – MSP offers enhanced protection against risks from container network misconfiguration.

Default-Closed Model – IMDS access is locked down by default, requiring strict allowlisting of approved in-guest software and users, aligning with zero-trust principles.

Guest Proxy Agent (GPA) – GPA leverages eBPF to verify the source of every metadata request and enforce Role-Based Access Control (RBAC) at the process level.

Fine-grained access control – allowing you to restrict IMDS access to specific users or processes with advanced configuration, reducing the attack surface significantly.

With MSP, you can limit IMDS access to approved applications, reducing your attack surface and improving your security posture.

Benefits of MSP

By adopting MSP, you gain:

Defense-in-depth against metadata-related attacks: MSP adds an extra security layer to protect sensitive metadata and identity tokens, reducing exposure from misconfigurations or compromised processes.

Granular control over IMDS access within your VMs: With fine-grained RBAC and allowlisting, you decide which applications and users can access metadata, ensuring only trusted components interact with critical services.

Peace of mind with industry-leading protections: MSP introduces a default-closed model and per-request authentication, aligning with zero-trust principles and making Azure the first major cloud to deliver this level of in-guest security.

How to Get Started?

The goal of onboarding is to configure your VMs so that only approved applications can access the WireServer/IMDS endpoints. Here’s the recommended approach:

Enable MSP in Audit Mode: Start by enabling MSP in audit mode to monitor which processes are accessing IMDS.
Create an Allowlist: Use audit logs to identify legitimate applications and build an allowlist.
Enable MSP Enforcement: Once the allowlist is finalized, switch MSP to enforcement mode to restrict access.

Start today by enabling MSP in audit mode and take the first step toward securing your Azure environment against evolving threats. For detailed instructions, visit the MSP Microsoft Learn page.

Input Security Type	Returned Security Type with new API version
<null>	Standard
Standard	Standard
TrustedLaunch	TrustedLaunch
ConfidentialVM	ConfidentialVM