Incoming Changes for Window Server 2022 Marketplace Image Users
New Azure Marketplace Windows Server 2022 media images offer is available in March 2026 excluding .NET 6 packages. Migrate to the new images before June 2026. After June 2026, there will be no patch to .NET 6 on the legacy images, and the legacy image will start deprecation at the same time.Announcing the General Availability of the Next Generation of Azure Boost
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/boostPublic Preview: Migrate your regional virtual machines to availability zones
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: Migrate a regional virtual machine to an availability zone Migrate from regional to a zonal Virtual Machine Scale Sets 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.Public Preview: Migrate Availability Sets to Virtual Machine Scale Sets
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.
Upcoming Compute API Change: Always return non-null securityType
Starting with Azure Compute API version 2025‑11‑01, Virtual Machines and Virtual Machine Scale Sets will always return a non‑null securityType value in API responses. This post explains the behavior change, which API versions are affected, and what teams need to update in automation, validation or post-deployment logic that relies on null checks.
Public Preview: Ephemeral OS Disk with full caching for VM/VMSS
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.Enhancing Resiliency in Azure Compute Gallery
In today's cloud-driven world, ensuring the resiliency and recoverability of critical resources is top of mind for organizations of all sizes. Azure Compute Gallery (ACG) continues to evolve, introducing robust features that safeguard your virtual machine (VM) images and application artifacts. In this blog post, we'll explore two key resiliency innovations: the new Soft Delete feature (currently in preview) and Zonal Redundant Storage (ZRS) as the default storage type for image versions. Together, these features significantly reduce the risk of data loss and improve business continuity for Azure users. The Soft Delete Feature in Preview: A safety net for your Images Many Azure customers have struggled with accidental deletion of VM images, which disrupts workflows and causes data loss without any way to recover, often requiring users to rebuild images from scratch. Previously, removing an image from the Azure Compute Gallery was permanent and resulted in customer dissatisfaction due to service disruption and lengthy process of recreating the image. Now, with Soft Delete (currently available in public preview), Azure introduces a safeguard that makes it easy to recover deleted images within a specified retention period. How Soft Delete Works When Soft Delete is enabled on a gallery, deleting an image doesn't immediately remove it from the system. Instead, the image enters a "soft-deleted" state, where it remains recoverable for up to 7 days. During this grace period, administrators can review and restore images that may have been deleted by mistake, preventing permanent loss. After the retention period expires, the platform automatically performs a hard (permanent) delete, at which point recovery is no longer possible. Key Capabilities and User Experience Recovery period: Images are retained for a default period of 7 days, giving users time to identify and restore any resources deleted in error. Seamless Recovery: Recover soft-deleted images directly from the Azure Portal or via REST API, making it easy to integrate with automation and CI/CD pipelines. Role-Based Access: Only owners or users with the Compute Gallery Sharing Admin role at the subscription or gallery level can manage soft-deleted images, ensuring tight control over recovery and deletion operations. No Additional Cost: The Soft Delete feature is provided at no extra charge. After deletion, only one replica per region is retained, and standard storage charges apply until the image is permanently deleted. Comprehensive Support: Soft Delete is available for Private, Direct Shared, and Community Galleries. New and existing galleries can be configured to support the feature. To enable Soft Delete, you can update your gallery settings via the Azure Portal or use the Azure CLI. Once enabled, the "delete" operation will soft-delete images, and you can view, list, restore, or permanently remove these images as needed. Learn more about Soft Delete feature at https://aka.ms/sigsoftdelete Zonal Redundant Storage (ZRS) by Default Another major resiliency enhancement in Azure Compute Gallery is the default use of Zonal Redundant Storage (ZRS) for image versions. ZRS replicates your images across multiple availability zones within a region, ensuring that your resources remain available even if a zone experiences an outage. By defaulting to ZRS, Azure raises the baseline for image durability and access, reducing the risk of disruptions due to zone-level failures. Automatic Redundancy: All new image versions are stored using ZRS by default, without requiring manual configuration. High Availability: Your VM images are protected against the failure of any single availability zone within the region. Simplified Management: Users benefit from resilient storage without the need to explicitly set up or manage storage account redundancy settings. Default ZRS capability starts with API version 2025-03-03; Portal/SDK support will be added later. Why These Features Matter 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. To evaluate the Soft Delete feature, you may register for the preview and activate it on your galleries through the Azure Portal or RestAPI. Please note that, during its preview phase, this capability is recommended for assessment and testing rather than for production environments. ZRS is already available out-of-the-box, delivering image availability starting with API version 2025-03-03. For comprehensive details and step-by-step guidance on enabling and utilizing Soft Delete, please review the public specification document at https://aka.ms/sigsoftdelete Conclusion Azure Compute Gallery continues to push the envelope on resource resiliency. With Soft Delete (preview) offering a reliable recovery mechanism for deleted images, and ZRS by default protecting your assets against zonal failures, Azure empowers you to build and manage VM deployments with peace of mind. Stay tuned for future updates as these features evolve toward general availability.Azure Automated Virtual Machine Recovery: Minimizing Downtime
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
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.Announcing preview of new Azure Dasv7, Easv7, Fasv7-series VMs based on AMD EPYC™ ‘Turin’ processor
Today, Microsoft is announcing preview of the new Azure AMD-based Virtual Machines (VMs), powered by 5th Generation AMD EPYC™ (Turin) processors. The preview includes general purpose (Dasv7 & Dalsv7 series), memory-optimized (Easv7 series) and compute-optimized (Fasv7, Falsv7, Famsv7 series) VMs, available with and without local disks. These VMs are in preview in the following Azure regions: East US 2, North Europe, and West US 3. To request access to the preview, please fill out the Preview-Signup. The latest Azure AMD-based VMs deliver significant enhancements over the previous generation (v6) AMD-based VMs: improved CPU performance, greater scalability, and expanded configuration options to meet the needs of a wide range of workloads. Key improvements include: Up to 35% CPU performance improvement compared to equivalent sized (v6) AMD-based VMs. Significant performance gains on other workloads: Up to 25% for Java-based workloads Up to 65% for in-memory cache applications Up to 80% for crypto workloads Up to 130% for web server applications Maximum boost CPU frequency of 4.5 GHz, enabling faster operations for compute-intensive workloads. Expanded VM sizes: Dasv7-series, Dalsv7-series and Easv7-series now scale up to 160 vCPUs. Fasv7-series supports up to 80 vCPUs, with a new 1-core size. Increased memory capacity: Dasv7-series now offers up to 640 GiB of memory. Easv7-series scales up to 1280 GiB and is ideal for memory-intensive applications. Enhanced remote storage performance: VMs offer up to 20% higher IOPS and up to 50% greater throughput compared to similar sized previous generation (v6) VMs. New VM families introduced: Fadsv7, Faldsv7, and Famdsv7 are now available with local disk support. Expanded constrained-core offerings: New constrained-core sizes for Easv7 and Famsv7, available with and without local disks, helping to optimize licensing costs for core-based software licensing. These enhancements make these latest VMs a compelling choice for customers seeking high performance, cost efficiency, and workload flexibility on Azure. Additionally, these VMs leverage the latest Azure Boost technology enhancements to performance and security of these new VMs. The new VMs utilize the Microsoft Azure Network Adapter (MANA), a next-generation network interface that provides stable, forward-compatible drivers for Windows and Linux operating systems. These VMs also 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 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 increased throughput and ability to scale for compute-intensive tasks like 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 support three memory (GiB)-to-vCPU ratios such as 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). The Dalsv7-series are ideal for workloads that require less RAM per vCPU that can reduce costs when running non-memory intensive applications, including web servers, video encoding, batch processing and more. The Dasv7-series VMs work well for many general computing workloads, such as e-commerce systems, web front ends, desktop virtualization solutions, customer relationship management applications, entry-level and mid-range databases, application servers, and more. The Easv7-series VMs are ideal for workloads such as memory-intensive enterprise applications, data warehousing, business intelligence, in-memory analytics, and financial transactions. The new Falsv7-series, Fasv7-series and Famsv7-series VM series do not have Simultaneous Multithreading (SMT), meaning a vCPU equals a full core, which makes these VMs well-suited for compute-intensive workloads needing the highest CPU performance, such as scientific simulations, financial modeling and risk analysis, gaming, and more. In addition to the standard sizes, the latest VM series are available in constrained-core sizes, with vCPU count constrained to one-half or one-quarter of the original VM size, giving you the flexibility to select the core and memory configuration that best fits your workloads. In addition to the new VM capabilities, the previously announced Azure Integrated HSM (Hardware Security Module), will be in Preview soon with the latest Azure AMD-based VMs. Azure Integrated HSM is an ephemeral HSM cache that enables secure key management within Azure virtual machines 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 provided below. These latest Azure AMD-based VMs will be charged during preview; pricing information will be shared with access to the VMs. Eligible new Azure customers can sign up for a free account and receive a $200 Azure credit. The new VMs support all remote disk types. To learn more about the disk types and their regional availability, please refer to Azure managed disk type. Disk storage is billed separately from virtual machines. 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 and Famdsv7-series. The latest Azure AMD-based VMs provide options for your wide range of computing needs. Explore the new VMs today and discover how these VMs can enhance your workload performance and lower your costs. To request access to the preview, please fill out the Preview-Signup form. Have questions? Please reach us at Azure Support and our experts will be there to help you with your Azure journey.
