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/boost
Public Preview of Azure Native Dell PowerScale
Dell and Microsoft are extending their partnership by bringing Dell's flagship unstructured data product, OneFS, to Azure as a new fully managed offering – now in Public Preview. Dell PowerScale for Microsoft Azure packs all the well-known benefits from OneFS in an Azure Native ISV service. This is a result of a co-development effort to create an easy-to-deploy and easy-to-manage filesystem-as-a-service. Power of choice Microsoft customers can now choose between two flavors of Dell PowerScale. One is the existing customer managed version, and the other is the newly released Dell managed PowerScale for Microsoft Azure. Both solutions allow customers to run OneFS in Azure, an enterprise-grade software-defined solution that integrates scale-out PowerScale and Microsoft's public cloud platform. PowerScale offers an end-to-end data solution for many AI, HPC and enterprise use cases with keeping simplicity top of mind. Both solutions offer efficiency, performance, resiliency, multi-petabyte scalability and feature set expected from an enterprise storage solution like PowerScale to Azure. You can replicate your data estate between on-premises and Azure-based deployments and optimize your hybrid data estate with data reduction through compression, deduplication and file tiering to scalable, cost-effective Azure Blob Storage with Cloud Pools. Rich Azure ecosystems for AI and Analytics services, cloud-based disaster recovery, or application bursting are now easily accessible for existing and new PowerScale customers. The only difference is the way you deploy and manage your storage solution. In a customer managed Dell PowerScale for Azure solution, customers deploy and manage the entire software and infrastructure stack. All the compute, networking and storage resources are in a customer’s tenant. If this is the preferred option, you can start with the deployment guide and provision a standalone PowerScale cluster now. However, if you are looking for a fully managed solution, Dell PowerScale for Microsoft Azure is the right choice. As a managed service, Dell implements and manages the underlying infrastructure stack, and is responsible for support activities, including platform upgrades and maintenance tasks. What is Dell PowerScale for Microsoft Azure, An Azure Native ISV Service Dell PowerScale for Microsoft Azure is a fully managed service, implemented as an Azure Native ISV service (LINK). It is deployed and managed through the Azure Portal and transactable through Azure Marketplace. This allows all Microsoft customers to use their existing Azure commitments and contracts to easily pay for and use this new offering. Unlike existing customer managed Dell PowerScale for Azure, this implementation runs in a Dell managed environment. The responsibility for service deployment and maintenance belongs to Dell while the customers consume the service in a cloud-native manner. The same ease-of-use typically tied to SaaS services, now applies to a traditional, enterprise grade storage system, like PowerScale. Customers can simply deploy the resource with the familiar Azure portal experience and start consuming a new petabyte scale OneFS cluster. As an Azure Native ISV service, Dell PowerScale for Microsoft Azure allows customers to manage their solution with a well-known Azure user interface. Customers can choose between Azure Portal, Azure CLI, or PowerShell. “Two industry leaders, one powerful solution raising the bar for enterprise cloud storage. Dell PowerScale for Microsoft Azure offers seamless scalability up to 8.4PB in a single namespace, versatile multi-protocol support, robust security, and is fully managed by Dell. This integration simplifies hybrid cloud operations while maintaining consistent high performance for data-intensive workloads like AI/ML, and EDA, helping you stay ahead to unlock your next breakthrough." Travis Vigil, SVP, Infrastructure Storage Group, Product Management at Dell Technologies. Dell PowerScale for Microsoft Azure provides up to 8.4PB in a single namespace and is available in 9 Azure regions. Supported regions: US East US South Central US West 2 West Europe North Europe UK South Germany West Central Australia East Southeast Asia How to take the next step Azure Marketplace Listing Request a Dell Reference Number for Public Preview Dell Documentation
📢 [Public Preview] Accelerating BlobNFS throughput & scale with FUSE for superior performance
Azure Blob Storage can be mounted and accessed like a local file system using BlobFuse, which is a FUSE-based driver for the Blob REST API. Customers choose BlobFuse for AI/ML, HPC, analytics and backup workloads. It provides exceptionally high throughput along with benefits like local caching and security integration via Azure Entra ID. For customers requiring NFS 3.0 protocol support or POSIX compliance, Azure Blob Storage also natively supports NFSv3 (aka BlobNFS). It enables Azure Blob storage access for customers’ legacy applications without requiring changes. BlobNFS is accessed via the Linux NFS client combined with our AZNFS mount helper package, which streamlines mounting and reliably connecting to Blob Storage’s NFS endpoints. Please note that BlobNFS only supports access over a virtual network since Azure Entra ID based auth isn’t yet available on NFS 3.0. Today, we’re excited to announce an update to AZNFS (3.0) for BlobNFS, which now uses the same libfuse3 library that powers BlobFuse bringing significant improvements in performance and scale. The updated AZNFS for BlobNFS delivers significantly higher throughput, larger file support, better metadata performance, and removes user group limits, enhancing performance for demanding workloads. Maximize Virtual Machine throughput: AZNFS now supports up to 256 TCP connections (up from16 in native NFS client) allowing throughput to reach VM NIC bandwidth (the maximum data transfer rate of virtual machine’s network interface card) or storage account limits. This benefits HPC workloads by ensuring high throughput for large dataset operations. Additionally, a small number (4 or fewer) of parallel file reads/writes can now fully saturate the VM NIC bandwidth even for larger VM sizes. Enhanced read/write speed: The updated AZNFS client outperforms native NFS client for read and write scenarios. For example, single file read/write performance is improved by a factor of 5x and 3x respectively, which can be useful for large database backup tasks requiring high single file throughput for writing and reading backup files. Refer to the link for a detailed performance comparison. Removal of the user's group limit: Linux NFS clients with a local Identity server can pass access permissions for up to 16 groups of a user, restricting resource access for users belonging to more than 16 groups. This update allows FUSE to handle permission checks, removing the 16-group limitation. Improved metadata query performance: READDIR can query more directory entries in one call. The Linux client has a limit of 1MB, whereas the updated AZNFS can now reach up to 3 MB. Customers with numerous files will experience quicker listing and metadata operations with reduced latency. This will be beneficial for workloads like EDA (Electronic Design Automation) and HPC (High Performance Computing) which often involve reading metadata for considerable number of files before selecting a subset for processing. Support for large file sizes (up to 5TB): The new release can support larger file sizes for sequential write patterns. Due to larger block sizes possible with AZNFS, users can create larger files up to the 5TB limit. With Linux clients, under best conditions, the max. file sizes were limited to ~3TB. CAD tools producing simulation and checkpoint data files over 3TB will benefit from this improvement. The following charts compare performance between updated AZNFS and the Native Linux client. Please refer the detailed benchmarks for more details. [Test parameters - VM: Standard D96ds v5, File size: 100GB, Linux NFS is with nconnect =16, Linux kernel 5.x.x ; Test used: DD test] Note: The VM supports higher read throughput than write throughput. For updated AZNFS, throughput starting from 4 parallel file read/write operations is constrained by VM NIC bandwidth, or it can scale higher. Getting Started Please register for the preview using this form. Please refer the link for instructions on how to install and use latest version of AZNFS. For any queries or feedback, please contact us at aznfs@microsoft.com. References: What is BlobFuse? - BlobFuse2 - Azure Storage | Microsoft Learn Network File System (NFS) 3.0 protocol support for Azure Blob Storage Mount Blob Storage by using the Network File System (NFS) 3.0 protocol on Linux Instructions to install and use latest version of AZNFS · Azure/AZNFS-mount WikiAzure September: Announced end of life
For those who missed the last announces of Azure end of life, please find a small recap: Azure AI Intelligence The Azure AI Document Intelligence API v2.0 will be retired on August 31, 2026. You are simply encouraged to migrate to the same API but in version 3.1 which obviously offers more features than the previous one. Azure AI Video Indexer Due to the withdrawal of Azure Media Services, announced during the month of July, Microsoft has decided to remove all dependencies related to Azure Media from Azure AI Video Indexer, starting January 15, 2024. Azure FarmBeats The Azure FarmBeats project will be retired on September 30, 2023. For those who are not familiar with Azure FarmBeats, it is a solution that allows you to aggregate agricultural datasets from different providers. Instead, Microsoft offers Azure Data Manager for Agriculture, which is actually an enhanced version of the Azure FarmBeats project. Azure HPC Azure FXT Edge Filer which is a caching appliance for HPC computing tasks will be retired on December 31, 2026. However, no information on a possible service which will replace it. Azure Kubernetes Service The AKS product team has decided to remove Azure Monitor for AKS-Engine on September 14, 2026. You are therefore encouraged to use Azure Monitor for Containers functionality instead. We continue with another decommission on AKS which concerns the HTTP application routing add-on module, which will be deleted on March 3, 2025. Please note that this module is no longer supported since version 1.22 of K8S. Instead, you are encouraged to use the Web Application routing add-on. Azure Sphere The Classic version of Azure Sphere CLI will be decommissioned on September 30, 2024. No worries here for its replacement which is none other than Azure Sphere CLI. Azure Database for MariaDB End of life of Azure Database for MariaDB which will be retired on September 19, 2025. Microsoft therefore suggests that you use Azure Database for MySQL instead which offers more features. Azure Monitor The removal of the Data Collector API that manages custom log ingestion into Azure Monitor logs will be done on September 14, 2026. Before this date, you will need to migrate to the rules-based log ingestion API which provides all the functionality of the Data Collector API, plus some new features. On September 30, 2026 the "Classic" URL Ping Tests configured on Application Insights will be deleted, in favor of the "Standard" tests. Azure Storage The product team announced for September 13, 2024 the removal of the old Azure Storage Python client libraries, but also the Azure Storage Ruby client libraries, as well as the old Azure Storage Go client libraries. Instead you will have to use the new libraries. Azure Maps The product team announces that the Azure Maps Data V1/V2 APIs will be retired on September 16, 2024. Instead, Azure Maps has deployed Data Registry APIs that provide enhanced data security. Azure Maps Render V1 APIs will be retired on September 17, 2026. You are therefore encouraged to migrate or deploy Azure Maps Render V2 APIs, which provide improved data quality and performance compared to the previous version. The Azure Maps Gen1 pricing tier will no longer exist from September 15, 2026. You will therefore need to upgrade to the Azure Maps Gen2 pricing tier which offers simplified pricing and better flexibility.Azure HPC Cache Updates: New Caching Option, Discounted Pricing, and More!
New Releases Azure HPC Cache Premium Read-Write We’re excited to announce the preview of Azure HPC Cache Premium Read-Write. This next generation of premium caching for high-performance computing workloads is designed to provide high-bandwidth and low-latency access to files. Azure compute clients are provided with read and write performance like what they would experience from a local NVMe drive. Premium HPC Cache provides lower latency than the Standard HPC Cache for your compute-intensive enterprise workloads. You can provision up to 84 TB of capacity in a single cache and point thousands of compute clients at the cache to get up to 20 GB/s of read throughput. Premium HPC Cache’s highlights include: Increased Read Throughput: up to 20 GB/sec against an 80+ TiB dataset Reduced Latency: 150 µsec for reads, 1 msec for writes Increased Write Throughput: 24.5% increase in write operations IOPS Scalability: 170,000 random 4 KiB writes; 450,000 random 4 KiB reads With our lowest-latency cache, Premium HPC Cache provides our best file-based performance to meet your time-sensitive workloads like media rendering, simulations for genomics and financial models, as well as chip design. Getting Started with Premium Read-Write Azure HPC Cache Premium Read-Write is currently available as a Public Preview in select regions. If you are interested in participating in the preview, you can create a new cache and choose the Premium (Preview) option. Overview of Current and New Offerings Attribute Read-Write Standard Caching Read-Only Caching Read-Write Premium Caching Throughput SKU 2, 4, or 8 GB/sec 4.5, 9, or 16 GB/sec 5, 10, or 20 GB/sec Write Throughput 1.1, 2.2, 4.4 GB/sec N/A GB/sec (write-through) 2.3, 4.6, 9.2 GB/sec Read IOPS 62.5K, 125K, 250K ops/sec 160K, 320K, 480K ops/sec 500K, 1M, 2M ops/sec Write IOPS 16.75K, 33.5K, 67K ops/sec N/A ops/sec (write-through) 135K, 270K, 540K ops/sec Cache sizes 3, 6, or 12 TB for 2 GB/sec 6, 12, or 24 TB for 4 GB/sec 12, 24, or 48 TB for 8 GB/sec 21 TB for 4.5 GB/sec 42 TB for 9 GB/sec 84 TB for 16 GB/sec 21 TB for 5 GB/sec 42 TB for 10 GB/sec 84 TB for 20 GB/sec Maximum number of storage targets 20 20 20 Compatible storage target types Azure Blob, NFS (on-premises), ADLS-NFS (NFSv3-enabled Azure Blob) NFS (on-premises), ADLS-NFS (NFSv3-enabled Azure Blob) Azure Blob, NFS (on-premises), ADLS-NFS (NFSv3-enabled Azure Blob) Caching styles Read caching or read-write caching Read caching only Read-write caching Cache can be stopped to save cost when not needed Yes No No *Results were without use of the priming feature. Additional details on priming will be included in our next blog post. Lower Pricing for Azure HPC Cache - Standard While it seems like the cost of everything is going up, we’re happy to report a price drop. As part of our commitment to provide the most cost-effective performance cache, we’re excited to share that we have dropped Azure HPC Cache – Standard prices by up to 33% percent in some regions. The new pricing is effective immediately. This enables cost-conscious verticals like media and entertainment to meet strict rendering deadlines while spending less on caching. Life sciences customers who rely on grants to fund their genomics research can now stretch their funds further. And chip designers can run their EDA workloads at a lower cost and still maintain the high performance for their tools repositories that they’ve come to expect. Terraform Terraform, an open-source software tool created by HashiCorp, provides an orchestration layer to deploy Azure resources. Using Terraform, you can deploy your own vdbench test system with all the required resources to run a performance benchmark. To try this yourself, the HPC Cache team has created a vdbench NFS-backed storage cache Terraform recipe to deploy a Premium 5G cluster and 30 clients. You can additionally run your own benchmarks against a 5G storage cache. Instructions and examples can be found on HPC Cache GitHub.Authenticating to an Azure CycleCloud Slurm cluster with Azure Active Directory
As enterprises increasingly move to using Azure Active Directory for their authentication needs this blog explores how Azure AD and OpenSSH certificate-based authentication may be used to provide authentication to a Slurm cluster. We also utilise the Azure Bastion recent native client support feature to provide remote access to the login node over the public internet.
