Azure Storage Blog articles

More EDA Job Sets per Volume: Azure NetApp Files Raises the Performance Bar

GeertVanTeylingen — Tue, 29 Sep 2026 16:00:00 GMT

Introduction

New benchmark proof with large volume breakthrough mode

The same volume, nearly double the performance

The scaling paradigm has not changed. The scale unit has.

And your data does not have to move first

Already in the flow

Bringing it together

Learn more

Introduction

Chip design runs on concurrency. Thousands of simulation, synthesis and verification jobs hit the same project trees, tool libraries and scratch areas at once, and every one of them pays whatever the file system charges for a metadata lookup. As each new generation of silicon increases the scale, concurrency, and performance demands of EDA, Azure NetApp Files needs to keep pace by meeting the evolving storage requirements of these workloads in the cloud.

This article spotlights the next step in that story: Azure NetApp Files large volume breakthrough mode with a new SPECstorage® Solution 2020 EDA_BLENDED result for a single large volume - independently validated and published alongside every other submission in its category. It also covers what the newly generally available cache volumes add when the data your jobs need still lives on-premises.

For EDA teams the takeaway is practical. More concurrent work inside the same latency budget means shorter regression cycles, more design iterations per day, and compute grids and tool licenses that spend their time working rather than waiting on I/O - without sharding a dataset across volumes to get there.

Earlier this year we demonstrated that shared storage had stopped being the reason EDA stays on-premises. The evidence was a single Azure NetApp Files large volume in breakthrough mode, measured on SPECstorage® Solution 2020 EDA_BLENDED: 2,880 job sets, 1,296,040 ops/sec and 20,910 MB/s at a 0.51 ms overall response time.

Six of those volumes side by side scaled linearly to 17,280 job sets - the same architecture, simply multiplied. Both results are covered in Azure NetApp Files for EDA workloads: From revolution to breakthrough at scale and dissected in its technical companion, From Scale to Breakthrough: Azure NetApp Files Sets a New Cloud Benchmark for EDA Performance.

And the story continues.

Co-authors:

Jitesh Mani, MSFT , Sr. Product Manager Azure Storage
Ranga Sankar, Azure NetApp Files Product Manager
Andy Chan, Azure NetApp Files HPC/EDA Principal Product Manager
George Strother, Azure NetApp Files Product Manager

New benchmark proof with large volume breakthrough mode

Today, we are publishing a new result. This one is not simply about more linear scalability.

It is about further boosting the baseline; more single large volume breakthrough mode performance.

Our latest submission will tell you that:

A single Azure NetApp Files large volume breakthrough mode delivered 38,776 MB/s (36,980 MiB/s) of throughput and 2,403,131 operations per second at peak.

Throughout the iterations, sub-millisecond latency was observed, with latency only breaching 1 ms in the final two of fifteen load points.

SPECstorage® Solution 2020_eda_blended	5,340 Job_Sets
Overall response time	0.54 ms
Ops/sec at peak load	2,403,131
Throughput at peak load	38,776 MB/s
Maximum latency at peak load	2.043 ms

One 150 TiB Azure NetApp Files large volume, Flexible service level, breakthrough mode enabled, six storage endpoints, 48 RHEL 9.8 clients mounting over NFSv3, single region, single availability zone. Tested August 2026.

Explore the results here: https://www.spec.org/storage2020/results/res2026q3/storage2020-20260901-00150.html.

The same volume, nearly double the performance

Against that first single-volume result - 2,880 job sets, 1,296,040 ops/sec, 20,910 MB/s - the new number is 1.85x higher on every measure: job sets, operations and bytes. The overall response time moved up only by three hundredths of a millisecond.

That last part is the one worth pausing on. Performance boosts are easy to admire and hard to use if they come with massive latency increases. EDA is not merely a throughput game; it is a concurrency game played under a latency budget.

A regression farm does not care that storage can go fast. It cares whether the ten-thousandth job of the afternoon still gets its metadata lookup answered in the same number of microseconds as the first. This volume held average latency under a millisecond all the way through 4,628 job sets - and 4,628 is already well past where the previous single volume finished.

The scaling paradigm has not changed. The scale unit has.

Here is the part we will leave to you. The scaling approach remains the same. What has evolved is the amount of performance and concurrency each volume contributes. Consider the earlier scale-out result: six large volumes delivered 17,280 job sets, exactly six times the 2,880 job sets achieved by a single volume. The architecture remained unchanged, scaling linearly without overprovisioning or hot spots, while sustaining a 0.60 ms overall response time and 125,474 MB/s of throughput.

That horizontal paradigm is unchanged and remains available to every customer.

We’ve already proven volumes scale out linearly,
compute and storage scale independently,
and concurrency scales with them.

What has changed is the size of the unit you are multiplying. We are deliberately not publishing a projection. You know your regression profile, your license pool and your deadline better than any benchmark does. Take the new single-volume number, apply the scaling behavior we have already demonstrated, and draw your own conclusion.

And your data does not have to move first

The other capability that just became generally available is Azure NetApp Files cache volumes, and the combination is more interesting than either part alone. A cache volume is a cloud-based cache of an origin volume that stays on-premises: only the actively used blocks are pulled into Azure on demand, reads are served at LAN-like speed once cached, and writes are acknowledged locally and written back asynchronously, so the origin remains the authoritative copy. No lengthy pre-staging, no second source of truth, no application changes - standard NFS and SMB, with origin permissions preserved.

For EDA, that is what bursting to the cloud always needed to be: send the work to where the capacity is - including when you are relocating jobs to get around a regional CPU or GPU shortage - and let the dataset follow the demand. Put that with an in-Azure volume that now sustains 2.4 million operations per second at half a millisecond, and "bursting" stops meaning "a slower copy of your environment, somewhere else." It means the same design environment, at the latency profile your flows were tuned for.

Already in the flow

None of this is theoretical. Microsoft Discovery is bringing agentic AI to HPC-scale chip design workflows - see Microsoft Discovery: Where HPC meets agentic AI for the next era of EDA. And with that, Synopsys Advances Agentic AI Chip Design with AMD and Microsoft, powered by Azure NetApp Files. Production EDA on Azure has stopped being the experiment. It is the flow.

Bringing it together

Last year, revolution. This spring, breakthrough at scale. Today, the single volume underneath it is 1.85x faster than when we started. Measured, published, and independently comparable – all while breaking down the walls between cloud and on-premises.

Storage no longer decides where and how big your regression can be. That decision is yours again. Contact us at askanf@microsoft.com to get you started.

Learn more

SPEC® and SPECstorage® are registered trademarks of the Standard Performance Evaluation Corporation. Comparisons are between published SPECstorage® Solution 2020_eda_blended results for Azure NetApp Files large volume breakthrough mode. For the latest published results, see www.spec.org.

Dell Managed PowerScale for Microsoft Azure is now generally available

AzureAndrewChen — Thu, 10 Sep 2026 15:23:53 GMT

Organizations continue to look for practical ways to manage growing volumes of unstructured data while maintaining the performance, resiliency, and familiar filesystem capabilities their applications require. Customers with existing PowerScale environments also want options for extending those investments to Azure without taking on the work of deploying and operating the underlying infrastructure.

Today, we are pleased to announce the general availability of Dell Managed PowerScale for Microsoft Azure. Developed through collaboration between Microsoft and Dell Technologies, the service brings Dell PowerScale and OneFS to Azure as an Azure Native ISV Service. It expands the file storage options available to Azure customers with large-scale unstructured data environments and existing PowerScale investments.

A Dell-managed experience in Azure

Dell Managed PowerScale for Microsoft Azure combines the OneFS file system with an integrated Azure experience. Customers can create and manage a PowerScale resource through the Azure portal and use familiar interfaces including Azure CLI and PowerShell. The service is transactable through Azure Marketplace, providing consolidated billing through an existing Azure account.

Dell implements and operates the underlying infrastructure and is responsible for platform upgrades, maintenance, and support. This allows customers to consume PowerScale as a managed service while retaining access to the file services and data-management capabilities they use in their PowerScale environments. The service integrates with a customer's Azure virtual network to provide private access from connected workloads.

Customers continue to have a choice between customer-managed Dell PowerScale for Azure and this Dell-managed service. With the customer-managed option, infrastructure resources run in the customer's Azure tenant and the customer operates the software and infrastructure stack. With Dell Managed PowerScale for Microsoft Azure, Dell operates that stack in a Dell-managed environment while customers provision and manage the Azure resource through Azure interfaces.

Supporting unstructured data at scale

Dell Managed PowerScale for Microsoft Azure provides up to 8.4 PB in a single namespace and supports simultaneous access over NFS, SMB, and S3. PowerScale capabilities such as replication, compression, deduplication, and file tiering to Azure Blob Storage with Cloud Pools can help customers manage data across on-premises and Azure environments. With PowerScale deployed in Azure, customers can also more easily make their data available to Azure services for analytics and other data-intensive workflows.

These capabilities provide another option for organizations extending existing PowerScale environments to Azure, building hybrid data architectures, supporting cloud-based disaster recovery, or running data-intensive applications that depend on shared file access.

With general availability, we look forward to seeing how customers use Dell Managed PowerScale to extend their existing data environments and make more of their unstructured data available to applications and services on Azure.

Availability and next steps

Dell Managed PowerScale for Microsoft Azure is generally available today in the East US Azure region. In the Azure portal, search for Dell PowerScale for Azure - Dell managed to create a resource.

To learn more:

Generally Available: Restrict usage of user delegation SAS to an Entra ID identity

ellievail — Wed, 09 Sep 2026 19:44:54 GMT

Shared access signatures (SAS) grant time-bound, scoped access to Azure Storage resources without sharing account keys. Over time, Azure Storage has continued to strengthen SAS security, moving from account keys to user delegation (UD) SAS secured by Microsoft Entra ID.

Today, we’re taking the next step forward by announcing general availability for user-bound user delegation SAS, an extension of UD SAS that ensures a SAS token can only be used by a specific Entra ID identity. This new capability helps customers significantly reduce the risk of unintended access while preserving the flexibility of SAS.

UD SAS is an existing feature which utilizes Entra ID and Azure role-based access control (RBAC). Users retrieve a user delegation key tied to their Entra ID account and then use it to create SAS tokens granting a subset of their own access rights. The resulting token can be traced to the delegator and can only be valid for up to 7 days. User-bound UD SAS is an extension of user delegation (UD) SAS which allows users to create a more secure SAS token by restricting the usage of the SAS token to an end user identity. The delegator specifies the Entra identity (security principal) of the end user in the SAS token and the end user needs to authenticate to Entra ID to use the token. The end user can either be in the same tenant or a different tenant as the delegator.

Pricing and availability

There is no additional cost for user-bound user delegation SAS. Pricing is based on the standard read/write transaction costs for your storage account type. To learn more, please see Azure Storage Pricing.

User-bound user delegation SAS is available in all public regions. It is available via REST APIs, SDKs, PowerShell, CLI, and Portal.

Getting started

Getting started is simple:

User-bound user delegation SAS is available on all GPv2 storage accounts in public regions.

If the end user of the SAS token is in a different tenant, the allowCrossTenantDelegationSas setting must be enabled on the storage account. If you are not planning on using this feature cross-tenant, the account setting can remain disabled.

Perform the following steps in the create a user delegation SAS documentation to generate and use a user-bound UD SAS token:

Ensure you have the correct RBAC roles assigned to the delegator to create a user delegation key. These roles will include the Storage <Service> Data Contributor and Storage <Service> Delegator (replace Service with the respective service you are using). Here are all of the applicable roles for each service:

Azure Blob	Azure Files	Azure Tables	Azure Queues
Storage Blob Data Contributor	Storage Files Data Contributor	Storage Table Data Contributor	Storage Queue Data Contributor
Storage Blob Delegator	Storage Files Delegator	Storage Table Delegator	Storage Queue Delegator

Get a user delegation key (instructions here)
Get the OAuth object ID and tenant ID from your end user. They will have to get these IDs (instructions here) and provide them to you.
Create the user-bound user delegation SAS token (instructions here. Note that the steps are the same as for a normal UD SAS token; you will just have to specify the end user and tenant if applicable).
Share the SAS token to the application/user intended to access Azure Storage.
Tokens should be passed within applications automatically or shared via key vault for best practice.

Feedback

If you need help, create a support request.

Accelerated AI & Analytics workload on Azure Blob Storage: Up to 25x faster List Blobs operations

wolfgangdesalvador — Thu, 03 Sep 2026 18:46:37 GMT

Today Azure Storage introduces in preview a new List Blobs optimization that accelerates listing operations by up to 25x with up to 15x lower client-side CPU utilization allowing customers to return millions of objects per second in List Blobs results.

The list results are now returned in Apache Arrow format, a highly optimized and compact columnar response format that allows more efficient parsing and reduced client-side CPU utilization. Clients can now parallelize object list operations efficiently across multiple concurrent requests, while maintaining the same strong consistency of listing results that applications require. This increased performance and lower client CPU utilization is delivered within the existing List Blobs API via just a simple header change and is automatically invoked when using the updated Azure Blob Storage SDK’s.

Why we built this

Object storage was originally designed to provide low-cost, resilient data access through simple REST APIs. Early systems contained only a few million objects and were listed infrequently, so listing performance was not a priority.

Cloud, big data, mobile, and cloud-native computing steadily increased data volumes and access demands. Since 2020, foundation models, LLMs, and large GPU fleets have pushed object storage to trillions of objects, making it an active data layer for AI.

Modern AI and analytics workloads operates at the scale of trillions of objects. These workloads must repeatedly discover and inventory vast datasets for pre-training, analytics, fine-tuning, and inference, making frequent listing operations a significant source of storage-system pressure and client-side CPU consumption.

Downstream AI training and data analytics jobs are gated by the time required to enumerate immense datasets, while parsing the results consumes client-side CPU that could otherwise run the workload.

To meet these rapidly growing demands of AI workloads, we’ve built the next generation of Azure Blob Storage listing capabilities that deliver the performance required at this massive scale. Next, we will dive deeper into the details of how List Blobs performance and scalability have been accelerated and how simple it is for customers to take advantage of this new level of performance.

Faster, more efficient, listing results with lower client CPU utilization

The Apache Arrow format was selected as the most efficient new way to deliver the performance and scalability gains required for efficiently listing millions of objects per second. Apache Arrow is an open-source, compact columnar format that returns List Blobs results in an optimized response roughly one third the size of the XML format used by most cloud object-storage listing APIs, making parsing faster and easier.

The new format is enabled with a simple request-header change. The List Blobs API then packages and accelerates results automatically while preserving strong consistency, so newly written objects remain immediately visible. Because Apache Arrow is compact and efficient to parse, client-side CPU utilization per object listed decreased by up to 15x, freeing compute resources for the workload itself.

Submitting multiple List Blobs requests concurrently further improves performance, delivering up to a 25x increase in enumeration speed with a single request-header change, while preserving schema consistency and compatibility with existing XML responses.

This new List Blobs performance enhancement via Apache Arrow remains an additive, opt-in extension of the existing List Blobs API, not a replacement. The existing XML-based List Blobs API remains unchanged, and current clients not adopting the new header continue to work with no breaking changes, but without the performance and lower CPU-utilization benefits.

The next figure shows the comparison of a parallelized listing operation using Apache Arrow format compared with the XML baseline on 16 clients and 48 threads per client.

rclone accelerates listing of 100K objects from 24 seconds to 1.1 seconds

rclone is a popular command-line program to manage, copy, move and replicate files on and between cloud storage destinations. rclone is a widely used open-source tool for moving and syncing data across almost all types of cloud storage.

Listing is a critical part of rclone’s synchronization workflow. To perform these data management operations at scale for large numbers of objects, rclone must enumerate the objects that are intended to be copied, moved, or replicated. For example, before and after syncing Azure Blob Storage containers, rclone performs a large-scale listing to compare the source and target states.

After updating rclone to incorporate the simple header change for the enhanced Apache Arrow-based List Blobs API calls, rclone was able to reduce their List Blobs time-to-completion by 21.7x from 24 seconds to 1.1 seconds on 100K object datasets.

The chart below shows rclone's measured wall clock time for listing a single container with 100,000 entries (columns, left axis) alongside the resulting speedup versus the classic XML path (line, right axis).

Two things stand out in the results:

Apache Arrow is an immediate win on its own: With no parallelism at all, sequential Arrow listing is 3.5× faster than the current XML-based List Blobs results, reducing listing operation time to completion from 23.9 seconds to 6.9 seconds .
Parallel enumeration compounds the gains: Throughput climbs steadily with concurrency, reaching a 21.7× speedup at a parallelism of 30 and completing the same listing of 100,000 entries in just 1.1 seconds.

The accelerated List Blobs results are returned with the same consistency using the same List Blobs API but now returned much faster with no breaking changes for existing clients. That is exactly the outcome we set out to deliver with this new capability.

In rclone's own words about these results:

" rclone has to list containers before it can sync them; with Apache Arrow and parallelism enabled this will make a sync of a directory with millions of files get going 20x faster. The Azure Storage team has been very responsive to our feedback during the preview which made the integration straightforward. The new Go SDK works very well and required very few code changes. Our Azure Blob Storage users are going to love this!"
Nick Craig-Wood, rclone Lead Developer

To get started, you can download rclone from the official rclone website.

If you are running rclone v1.74.0 or later you can enable the Apache Arrow listing with the --azureblob-use-arrow-list flag and enable listing parallelism with --azureblob-list-parallelism. As described in the testing, if you set “--azureblob-list-parallelism 30” this will get you the most performance listing from Azure with Arrow listing also enabled.

A sincere thank you to the rclone community for adopting List Blobs with Apache Arrow early and sharing such clear, quantified results. Feedback like that is invaluable as we advance toward general availability. Happy listing rcloners!

How to get started

At the REST layer, the Arrow response is negotiated with the Accept: application/vnd.apache.arrow.stream header on a minimal x-ms-version of 2026-06-06 or later. This will return a response content that will be an Apache Arrow IPC stream that can be decoded and used to instantiate a RecordBatchStreamReader using Apache Arrow SDKs in any language.

An example of decoding from Rest API response is provided below using Apache Arrow Python SDK for decoding:

table = pa.ipc.open_stream(resp.content).read_all() print(table.schema) print("\nrows:", table.num_rows, " columns:", table.num_columns)

Name: string not null Creation-Time: timestamp[s] Last-Modified: timestamp[s] BlobType: string ResourceType: string not null Etag: string Content-Length: uint64 Content-Type: string Content-MD5: string AccessTier: string AccessTierInferred: bool LeaseState: string LeaseStatus: string ServerEncrypted: bool -- schema metadata -- NumberOfRecords: '100' NextMarker: '' rows: 100 columns: 14

import pandas as pd df = table.to_pandas() df[["Name", "BlobType", "Content-Length", "size_mb", "AccessTier"]].head(6)

	Name	BlobType	Content-Length	AccessTier
0	train_chunk10_shard1.jsonl.zst	BlockBlob	215	Hot
1	train_chunk10_shard10.jsonl.zst	BlockBlob	216	Hot
2	train_chunk10_shard2.jsonl.zst	BlockBlob	215	Hot
3	train_chunk10_shard3.jsonl.zst	BlockBlob	215	Hot
4	train_chunk10_shard4.jsonl.zst	BlockBlob	215	Hot
5	train_chunk10_shard5.jsonl.zst	BlockBlob	217	Hot

This new accelerated performance for List Blobs listing via Apache Arrow can be transparently enabled on Python, Java, .NET, C++ and Go SDKs with a simple option in the container listing function. Enabling via Azure Blob SDKs allows the performance benefits to be achieved without changing the listing interface and returned object formats in the Azure Storage SDK.

This new accelerated performance for List Blobs is available in public preview across the Azure Storage client libraries listed below. To evaluate the capability, use the corresponding minimum preview version for your preferred language.

SDK	Minimum version (preview)
.NET	12.30.0-beta.1
Python	12.31.0b1
Java	12.36.0-beta.1
Go	v1.8.1-beta.1
C++	12.19.0-beta.1
JavaScript	12.34.0-beta.1

To get started, update to a preview enabled SDK for your language and start testing the new feature with our samples, or add the new listing options to your existing REST calls

Parallelizing listing operations unlocks the double-digit performance gains described in this article. The optimal strategy depends on the namespace layout and distributes listing requests across multiple threads. The two most common approaches are:

Use delimiter parameter to recursively fan out additional threads for each BlobPrefix, walking the namespace.
Partition the namespace with startFrom and endBefore, then process the ranges across multiple threads. This is the approach used by rclone.

The best approach depends on the specific namespace layout and can be optimized by tuning both the algorithm and the level of parallelism.

Limitations

This new Apache Arrow-powered performance optimization for List Blobs is today supported on flat namespace (FNS) Azure Blob Storage accounts. In scenarios where the account is Hierarchical Namespace (HNS) enabled, if the List Blobs REST API is called with the new header, it will return a 409 (Conflict) error code. This error code can be used to fallback on the client application to standard XML listing.

Public preview is where your input shapes the product. Try it on your largest containers, tell us what you measure, and let us know what would make it even better through this form.

References

Accelerate Inference on AKS with Azure Blob Storage and NVIDIA Dynamo

Vishnu Charan TJ — Tue, 11 Aug 2026 15:00:00 GMT

As agents generate more tokens and use longer context windows, AI platforms must reduce cost per token and optimize inference performance across every layer of the stack. With new native integrations between Azure Blob Storage and the NVIDIA Dynamo stack, users can now combine the scalability, durability, and operational simplicity of Azure Blob Storage with Dynamo’s high-performance inference capabilities.

NVIDIA Dynamo is a suite of tools enabling accelerated AI inference systems on Kubernetes. Dynamo enables disaggregated inference, intelligent Key-value (KV) cache-aware routing, optimized model weight management, high-performance data movement, and more through a collection of fully modular components.

Our measurements demonstrate that vLLM enhanced with Dynamo ModelExpress and Azure Blob Storage loads weights up to 7.3x faster than the default loader, translating into up to 4.6× faster total cold start latency. When leveraging NIXL’s integration with Azure Blob Storage for KV cache offloading, vLLM provides up to 2.8x lower time-to-first-token (TTFT) latency when compared to recomputing KV cache.

Accelerate Model Cold Starts with Dynamo ModelExpress

Modern AI models continue to grow in size, with frontier models regularly exceeding one trillion parameters. Each time an inference cluster scales up and launches a new model instance, the model’s weights must be loaded into GPU memory before serving can begin. These weights often exceed one terabyte in size, making weight-loading the single largest contributor to cold start latency.

Reducing this bottleneck is critical for adaptable inference. Faster cold starts allow clusters to scale more quickly, responding to traffic spikes with less delay, and reduce idle GPU time.

Dynamo ModelExpress addresses this challenge by optimizing the end-to-end lifecycle of model weights across a Dynamo inference cluster, coordinating how weights are loaded, cached, distributed, and reused. A core part of this optimization is its native integration with Run:ai Model Streamer, which accelerates cold-start loading by streaming model weights from Azure Blob Storage into GPU memory using optimized parallel transfer and prefetching. Run:ai Model Streamer leverages the full network bandwidth provided by the Azure VM’s NIC, maximizing transfer speeds from Blob storage. Together, Dynamo ModelExpress and Run:ai Model Streamer reduce model startup latency by accelerating the initial load and enabling subsequent reuse of model weights across the cluster.

In our testing across multiple node types on Azure, vLLM with Dynamo ModelExpress loaded weights from Azure Blob Storage into GPU memory up to 7.3x faster and began serving up to 4.6x faster compared with the default vLLM loader.

Figure 1 shows the performance boosts observed with ModelExpress versus the vLLM model loader across multiple models:

The results show that these optimizations become more impactful as model size increases. As model weight files grow larger, faster Blob-backed streaming has a larger effect on the full startup path. For more details about the hardware, configuration, and procedure used in these measurements, see the ModelExpress deployment recipe.

For deployments on Azure Kubernetes Service (AKS), storing model weights in Azure Blob Storage and loading them with Dynamo ModelExpress provides three major benefits:

Faster Elastic Scaling: Model weights can be streamed from Azure Blob Storage into the Dynamo model loading path, reducing weight-loading time and cold-start latency.
Operational simplicity: Teams can centrally store model weights in Azure Blob Storage and use Microsoft Entra ID and Azure RBAC to control access from across clusters.
Enterprise-Grade Reliability: Azure Blob Storage provides lifecycle management and high durability for model artifacts, helping ensure that model weight files are securely stored and highly available for production inference workloads.

Extend KV Cache Offloading to Azure Blob

Cold start latency is only one challenge of the inference lifecycle. Once a model is deployed, a new challenge emerges: the KV data generated during inference is expensive to compute, so it must be efficiently cached and reused across requests to sustain high throughput and scalability.

When cached KV data is reused, inference clusters avoid recomputing the same data, helping requests achieve lower TTFT latency. While KV caching typically consumes GPU memory, offloading the KV cache to host memory or storage releases valuable GPU capacity while still enabling lower TTFT than recomputation.

KV cache management frameworks such as LMCache provide the platform that helps orchestrate this offloading. Many KV cache management tools leverage the NVIDIA Inference Xfer Library (NIXL) to facilitate the transfer of KV cache between GPU memory and host storage. NIXL is a core Dynamo component that provides high-bandwidth, low-latency point-to-point data transfers across various memory and storage tiers including HBM, DRAM, and local and remote storage. Through plugins, users can extend NIXL’s data transfers to specialized platforms such as Azure Blob Storage and GPUDirect Storage (GDS). Similar to when loading weights with ModelExpress, offloading KV cache to Blob storage is designed to efficiently use the network bandwidth available to the Azure VM.

NIXL’s plugin for Azure Blob Storage allows KV Cache management tools to offload KV cache directly to Azure Blob Storage. Offloading KV cache to Azure Blob Storage adds three concrete benefits for inference clusters on AKS:

Reduced GPU Load: On a cache hit, the serving engine can reuse KV data from Azure Blob instead of recomputing the KV data.
Scalable KV Caching Capacity: Blob’s scalability lets the cache layer keep more reusable KV blocks, preserving valuable GPU memory.
Better KV Offload Effectiveness: More cached blocks can be retained and retrieved across requests, increasing the chance that a stored block is reused.

As shown below in Figure 2, offloading KV cache to Azure Blob storage yields up to a 2.8x improvement in TTFT versus without offloading. This significantly reduces user-facing latency and provides a much smoother experience.

See the NIXL Azure Blob Storage offloading recipe for details about the hardware, configuration, procedure, and other models used in our measurements.

Accelerate Your Inference Workloads Today

Azure Blob Storage’s integrations with Dynamo ModelExpress and NIXL provide multi-layered optimizations for accelerated inference on Azure Kubernetes Service (AKS), resulting in a streamlined inference lifecycle, including faster model readiness, reduced Time-to-First-Token (TTFT) latency, and more efficient GPU memory utilization.

Start optimizing your AI inference workloads today by leveraging the native integrations between Azure Blob Storage and the NVIDIA Dynamo stack. To see how to deploy these capabilities, explore the step-by-step guidance for Dynamo ModelExpress and Azure Blob Storage and the recipe for NIXL KV cache offloading to Azure Blob. Continue to follow NVIDIA and Microsoft as we deepen our integration to build the future of accelerated inference.

Acknowledgements

This work was enabled by close collaboration between engineering teams from Microsoft and NVIDIA. Key contributors include Vishnu Charan TJ and Kyle Knapp from Microsoft; and Stephen McCullough, Akshatha Kamath, Adit Ranadive, Nikhar Maheshwari, Ganesh Kudleppanavar, Vishwanath Venkatesan, and Zheng Luo from NVIDIA.

Optimize Oracle workloads on Azure with Azure NetApp Files

GeertVanTeylingen — Thu, 09 Jul 2026 16:22:43 GMT

Introduction

Azure NetApp Files Advancements Overview

Azure NetApp Files Advancements in Detail

Flexible service level capacity pools

Oracle Direct NFS

Application volume group for Oracle

Availability zone volume placement

High availability

Standard network features

Simplified deployment

Optimal volume placement

Scalability and flexibility

Integrated data protection

Using application volume group for Oracle

VM IO throttling

Automatic Storage Management (ASM)

Migration assistant

Short-term clones

Storage with cool access

Sizing Your Volume Deployment for Oracle

Using Azure NetApp Files as backup target and test/dev for Oracle AI Database@Azure

Summary

Learn more

Introduction

Oracle workloads do not move to the cloud on storage promises alone. They only move when performance is predictable, operational needs are familiar, and the platform gives teams the flexibility they need to grow without disruption or the need to redesign or remigrate a database architecture as requirements evolve.

That was the foundation of the Azure Architecture Center Oracle Database with Azure NetApp Files reference architecture, which documents how Azure NetApp Files provides high-performance NFS storage for Oracle Database on Azure virtual machines. The article remains an important reference for customers who want low latency, high throughput, flexible scaling, data protection, and cloning for demanding Oracle environments.

Since then, Azure NetApp Files has grown and evolved. New capabilities now make Oracle environments easier to size, deploy, protect, replicate, migrate, and clone on Azure. This article builds on the original Azure Architecture Center guidance and highlights what has changed: flexible service level capacity pools, application volume group for Oracle, availability-zone-aware volume placement, migration assistant, short-term clones, cool access, and expanded data protection options.

This article explains how Oracle on Azure Virtual Machines can benefit from using Azure NetApp Files volumes for primary database storage and provides an additional look at how Azure NetApp Files can complement Oracle AI Database@Azure as a backup target and a source for rapid, space-efficient database clones.

Co-authors:

Arnt de Gier, Azure NetApp Files Product Manager
Jeffrey Steiner, Principal Architect, NetApp

Azure NetApp Files Advancements Overview

The most important advances are not just about faster storage. They are about making Oracle environments easier to size, deploy, protect, migrate, replicate, and reuse across the full database lifecycle.

Key advancements include:

Flexible service level capacity pools
Capacity and throughput can now be tuned independently. Some databases are heavy on IOPS, while others are bandwidth-hungry. ANF capacity pools now help you avoid overprovisioning and align storage performance more closely with actual Oracle workload demand.
Application volume group for Oracle
Deployment of Oracle data, redo, archive, and backup volumes can be automated through a workflow that applies Oracle-aware layout and placement guidance.
Availability-zone-aware volume placement
Oracle VMs and Azure NetApp Files volumes can be aligned in the same availability zone to reduce avoidable latency and support more predictable performance.
Enhanced data protection and replication
Snapshots, backup, cross-zone replication, and cross-region replication give customers more options to protect Oracle data and design for business continuity.
Migration assistant
ONTAP-based volumes can be migrated to Azure NetApp Files using efficient block-level replication, preserving file structure, permissions, and existing snapshots while enabling incremental cutover planning.
Short-term clones
Snapshots can be turned into writable, space-efficient clones for test, development, reporting, validation, or troubleshooting without creating full physical copies.
Storage with cool access
Inactive data can be tiered automatically to optimize storage cost while keeping data accessible through the same Azure NetApp Files namespace. This helps manage the cost of Azure NetApp Files volumes used as backup targets for Oracle databases.
Oracle Database@Azure backup and clone integration - Azure NetApp Files can be used as a high-performance backup target and a source for rapid, space-efficient test and development refreshes using snapshots and short-term clones.

Together, these advancements shift the conversation from simply “Can Oracle run well on Azure NetApp Files?” to “How can Oracle environments on Azure become easier to operate, easier to protect, and easier to scale?” For customers, that means more deployment confidence, better cost control, faster refresh cycles, and a more practical path to modernizing Oracle workloads on Azure.

Azure NetApp Files Advancements in Detail

Flexible service level capacity pools

To match Azure NetApp Files storage to the real needs of each Oracle workload use Flexible service level to enable sizing and scaling of capacity and throughput independently of each other instead of sizing capacity and performance together like you do with the traditional service levels (standard, premium and ultra). For an Oracle DBA, this means you can allocate the storage capacity your database requires and then tune throughput separately for the expected I/O profile. You start with a baseline throughput of 128 MiB/s and can increase performance in small increments, up to five times the Ultra service level per provisioned 1 TiB. This makes it easier to support demanding databases without over-provisioning storage, and it can reduce costs by 10–40% by paying only for the capacity and performance the workload actually needs. As database demand changes, you can adjust the balance between capacity and throughput to keep performance aligned with current requirements.

Oracle Direct NFS

Oracle Direct NFS (dNFS) with Azure NetApp Files gives Oracle workloads a faster, cleaner path to primary storage. Because dNFS is built into Oracle Database, it lets Oracle access Azure NetApp Files through a database-optimized NFS client rather than relying only on the host operating system. For customers, that means more predictable performance, simpler operations, and a practical way to modernize Oracle environments without changing proven NFS-based operating models.

This pairing is especially useful for performance-sensitive Oracle databases, where low latency, scalable throughput, and operational consistency matter. Azure NetApp Files provides enterprise-grade shared storage with flexible capacity and throughput, while dNFS helps Oracle use that storage efficiently for production, reporting, migration, consolidation, and test/dev scenarios.

The result is a storage architecture that is easy to understand, easy to scale, and easy to protect. Customers can keep familiar Oracle-on-NFS practices while gaining the elasticity, data protection, replication, backup, and cloning capabilities of Azure NetApp Files.

Predictable Oracle performance with a database-optimized NFS access path.
Greater migration confidence for customers moving from on-premises NAS to Azure.
Simpler storage operations with Azure NetApp Files snapshots, backup, replication, and cloning.
Flexible scaling of capacity and throughput as Oracle workload demand changes.

Oracle Direct NFS provides a database-optimized I/O path from Oracle Database on Azure VMs to Azure NetApp Files primary NFS storage, while Azure NetApp Files adds scalable throughput and enterprise data services such as snapshots, backup, replication, and cloning.

Application volume group for Oracle

Application volume group (AVG) for Oracle is a feature offered through Azure NetApp Files, designed to simplify the process of deploying all required volumes to install and run an Oracle database on Azure VMs (IaaS).

With just one workflow, you can provision volumes for data, redo, archive, and backup. This consolidation streamlines volume management, enforces best practices, and supports easy adjustments for size and throughput after deployment, all while keeping the flexibility of Azure NetApp Files volumes.

Application volume group for Oracle was recently enhanced with new functionality:

Availability zone volume placement: volumes should be placed in the same availability zone as the Oracle virtual machines, minimizing network latency by shortening the data path.
Data protection volume group creation: The same automated process allows you to create a data protection volume group with matching layout and naming for business continuity and disaster recovery in a secondary availability zone or region.
Standard network features: always utilize standard network features for best performance.
Enhanced performance: by deploying data and log volumes on separate storage endpoints, IOs are processed independently, preventing data read slowdowns during high-priority log writes. Application volume group will deploy multiple data volumes across different storage endpoints for large-scale workloads, using sizing inputs and affinity rules to optimize performance.

Availability zone volume placement

The efficiency of application volume group for Oracle is enhanced by aligning Azure NetApp Files volumes with the application VMs in the same availability zone. This alignment is crucial for meeting strict latency requirements, ensuring your Oracle applications run smoothly and efficiently.

Using compute in one zone and storage in another across a cross-zone data path (right side) introduces unnecessary latency and is easily avoided using availability zone aware volume placement and placing compute and storage in the same zone over a short data path (left side).

High availability

Azure availability zones are distinct locations within a region. By deploying Oracle volumes and application VMs in the same zone - and replicating data and redo logs to a secondary zone or region using cross-zone replication or cross-region replication you minimize the risk data loss during a disaster. Azure NetApp Files’ built-in replication can offload the replication of data files and volumes freeing up compute resources for transaction processing and deliver an RPO as low as 10 minutes. The replica can also be activated for a near-zero RTO. If an RPO and RTO all the way down to zero are required, you can use Oracle Data Guard to create a fully operational hot standby copy of your database.

Standard network features

The use of standard network features is recommended for all new implementations of Azure NetApp Files volumes. Basic network features is no longer supported for new deployments and will be phased out completely. Volumes using basic network features can be migrated to standard network features without interruption.

Simplified deployment

The automated application volume group deployment workflow accelerates and simplifies volume deployment, significantly reducing the risk of human error and resulting in a more reliable setup.

Optimal volume placement

Application volume group considers the underlying physical resources, applying affinity and anti-affinity rules to find the best locations for performance-critical volumes. This process ensures that your deployment achieves optimal performance; this is not possible with manual, one-by-one volume provisioning. Application volume group also splits data and log volumes across different storage endpoints to maximize performance and reduce contention.

Scalability and flexibility

Volume capacity and throughput can be easily resized before, during, or after deployment, allowing you to adapt your Oracle environment to changing needs without sacrificing availability or performance. Volume resizing and throughput adjustments can be done without interruption to the storage service and while the database is online.

Integrated data protection

Volumes deployed by application volume group are compatible with Azure NetApp Files data protection solutions, such as efficient, application-consistent snapshots and backup offloading. Data management tools like AzAcSnap, NetApp SnapCenter® software or other 3^rd-party data protection tools compatible with Azure NetApp Files are required to further ensure the consistency and safety of your Oracle data.

Using application volume group for Oracle

To use application volume groups, you need an Azure NetApp Files capacity pool that matches or exceeds the recommendations from the sizing exercise, and to be configured with Manual QoS. This setting allows application volume group to independently set volume throughput and capacity, making the most efficient use of the capacity pool since no overprovisioning will be required in this concept. The application volume group workflow calculates minimum required size and throughput based on your inputs and offers recommendations for optional backup volumes. After a successful pre-check it validates your inputs against the selected capacity pool, you simply click to deploy and after a few minutes your volumes are ready to mount onto your Oracle application VMs.

VM IO throttling

Not covered in this blog, but what may add to a more friendly TCO is the fact that network IO is not throttled by Azure VMs like managed disk is. This directly results in larger storage bandwidth when used with network connected storage like Azure NetApp Files. You may achieve the same or better performance with a smaller VM SKU, and this may have positive consequences for licensing as well.
Oracle on Azure specialists are available to help you with sizing Azure NetApp Files capacity pools, volumes and VM SKUs using your AWR reports.

Automatic Storage Management (ASM)

Oracle’s Automatic Storage Management is primarily designed to stripe data across multiple devices. This helps improve performance, plus devices can be added and removed nondisruptively, which makes capacity management easier.

Azure NetApp Files has the same capabilities, making ASM generally unnecessary. With Azure NetApp Files, IO is striped across multiple devices as the physical storage layer, and volumes can be resized on the fly and even throughput can be adjusted on the fly.

If you require ASM, for example, if you have existing procedures and scripts that depend on ASM, it is still fully supported with Azure NetApp Files and features like dynamic performance management still apply. You also get additional benefits. For example, you can create instant, space-efficient snapshots of your ASM diskgroups, and those snapshots can be offloaded to Azure NetApp Files backup for long term retention and protection against unlikely complete volume loss or corruption.

Migration assistant

Migration assistant allows for efficient migration of on-premises NetApp ONTAP® based storage volumes to Azure NetApp Files volumes.

This enables optimized volume migration to Azure NetApp Files volumes using NetApp SnapMirror® technology, providing:

Optimized volume migration with encryption and compression in transit to save network bandwidth
Complete database volumes are migrated, including the complete file structure with permissions and previously taken snapshots
Dry-run options are offered to perform intermediate testing of the migrated data volumes
Flexible cut-over planning with block-level incremental final transfer

Short-term clones

Azure NetApp Files short-term clones help reduce costs by allowing space-efficient provisioning of volume clones from snapshots for test/dev and other purposes.

The space efficiency stems from smart block manipulation in Azure NetApp Files, where the short-term clone uses the same blocks as the originating volume except for any changes made. Changed and new data blocks are written to a separate space in the short-term clone volume. Short-term clones are available almost immediately after creation and only take space in the capacity pool for any anticipated changes to be written to the clones. This saves capacity pool allocation space and cost. After 32 days short-term clones need to be either removed or converted to full independent clones.
Use short-term clones to rapidly create copies of production databases for analysis and test and development at minimal cost impact.

Storage with cool access

Leveraging Azure NetApp Files storage with cool access enables customers to optimize their storage strategies, reduce expenses, and efficiently manage their data lifecycle. Cool access automatically moves unused data to the Azure storage account without any changes required to user behavior or applications. This flexibility and efficiency make it a valuable option for a wide range of use cases, including backup and archival, data lakes, and compliance storage.

Sizing Your Volume Deployment for Oracle

Sizing tools are available to help determine the required volume configuration for Oracle. When migrating databases to Azure, generate Automatic Workload Repository (AWR) reports to analyze your current storage activity. AWR reports should be created at times when the database is at its highest load and run for a few hours. These reports allow the migration team to project suitable Azure NetApp Files volumes.
You can also upload multiple AWR reports to online sizing utilities such as the Atroposs and obtain recommendations for Azure NetApp Files capacity pool and volume layout using the Atroposs Azure NetApp Files Oracle Volumes TCO Estimator module which uses the measurements from the AWR reports provided. Since the database size is not included in the AWR reports, you need to enter the database size(s) manually. You can collect database sizes using this SQL script. Both volume capacity and throughput can be changed any time after deployment, providing flexibility and cost-efficiency. Please visit aka.ms/anftools for additional Azure NetApp Files estimator and sizing tools.

Using Azure NetApp Files as backup target and test/dev for Oracle AI Database@Azure

For Oracle AI Database@Azure deployments, Azure NetApp Files volumes can add value as high-performance backup targets that also become practical data sources for rapid test and development refreshes.

If all you need is a simple, easy-to-manage high-throughput RMAN backup target, Azure NetApp Files can be used as a simple, yet high-performance shared filesystem. You can also take snapshots of your RMAN backups for additional protection and replicate those backups to other regions.

If you really want to reduce your backup window and slash the capacity required for RMAN backups, you can combine RMAN image and incremental backups with Azure NetApp Files snapshots. The result is an incremental-forever backup strategy, but with a library of full-sized RMAN backups available within the snapshots. Backup windows shrink, and the only extra space required for each backup you retain is for the data that changed between backups.

You can also treat backups as more than just a recovery asset. Backup volumes can be used to capture recent, application-consistent copies of production data and make those copies available for temporary downstream use.

There are two options. First, you can set up a standby database (using Oracle Data Guard or as a traditional standby) to a right-sized VM and then create snapshot-based backups of that replica. That delivers backups as well as a low/zero RPO/RTO DR capability, but it can also be used for cloning. NetApp’s SnapCenter can automate the process from start-to-finish using those snapshots.

That is done through short-term clones. When a backup lands on an Azure NetApp Files volume, a snapshot of that backup set can be used to create a short-term clone. The short-term clone is writable, available quickly, and space-efficient because it references the existing snapshot data and only consumes additional capacity for changed blocks. This makes it well suited for feeding fresh production-like data to test, development, reporting, validation, or troubleshooting environments without creating full physical copies of large Oracle data sets.

Accelerates refresh cycles by making recent backup data available to non-production environments in minutes rather than through lengthy copy or restore processes.
Reduces storage consumption and cost by avoiding full-size duplicate database copies for short-lived test and development needs.
Limits production impact because clone creation is based on backup or snapshot data rather than direct activity against the active production database volumes.
Improves developer and QA productivity by providing realistic, current data sets for functional testing, upgrade validation, performance troubleshooting, and release rehearsal.

After the test/dev activity is complete, the short-term clone can be deleted before it ages out or converted to a regular volume if it needs to be retained longer. This approach turns the Oracle AI Database@Azure backup target into an active data lifecycle asset: protecting the database while also enabling faster, lower-cost access to fresh data for innovation and operational readiness.

That’s not the only route to leveraging short-term clones. If you’re using Azure NetApp Files with the incremental-forever backup strategy, each of those snapshots contains a fully consistent set of datafiles. You can also clone them and bring them up as an operational database using your own automation tools.

Summary

Consider the use of Azure NetApp Files volumes for your Oracle databases for flexibility, cost-efficiency, data protection and high-availability. You may achieve the same or better database performance even when using smaller VM SKUs in Azure. Snapshots provide extremely fast and efficient primary data protection from which complete databases can be restored very quickly. Use RMAN or other integrated backup applications to orchestrate the creation of snapshots for application consistency and easy operation.

Application volume group for Oracle provides a robust solution for deploying multiple Azure NetApp Files volumes for use with Oracle, optimizing performance, availability, and management of your Oracle databases. Leveraging availability zone placement ensures that your Oracle environment is resilient and ready for modern business challenges. Use application volume group for Oracle also for provisioning data protection volumes in an alternate zone or region and use cross-zone and cross-region replication to offload data and log volume replication from the application VMs for higher efficiency and better performance.

For efficient migration of on-premises ONTAP-based volumes to Azure NetApp Files, use migration assistant.

When using Oracle AI Database@Azure consider sending backup data to Azure NetApp Files volumes to allow space-efficient volume cloning and feeding test/dev operations with fresh data from production.

Consult Oracle on Azure specialists for sizing Azure NetApp Files volumes and VM SKUs for your Oracle deployment on IaaS in Azure.

Learn more

Announcing General Availability of Client-Side Data Integrity Protections in Azure Blob Storage

wmarkley — Mon, 29 Jun 2026 19:03:37 GMT

We are excited to announce the General Availability of client-side data integrity in Azure Blob Storage. Blob Storage has long supported integrity validation, starting with MD5 as part of the original HTTP standards and adding CRC64-NVME support in 2019. Today, CRC64-NVME is now integrated into the latest Azure Blob SDKs for .NET, C++, and JavaScript, extending Azure’s data integrity protections all the way into client applications.

Azure has had a longstanding commitment to provide the world’s most secure and reliable cloud storage platform. By extending data integrity protections into client applications, customers can end-to-end verify the data they read and write to Blob Storage is fully intact byte-for-byte from their application to Azure physical storage media using CRC64-NVME checksums – without the need to deploy and manage additional tools.

Azure’s Commitment to Data Integrity

Azure Blob Storage considers the durability and integrity of the data stored by customers as a fundamental promise of a cloud object storage provider. The Blob Storage platform was designed to prevent, detect, and repair any data integrity issues, along with making data durable and available at up to sixteen 9s with GRS. From the beginning, Blob Storage has stored checksums alongside every data fragment and continuously verifies them with background jobs, ensuring the bytes we durably store remain exactly the bytes we received —for every data replica (LRS/ZRS/GRS/GZRS).

Extending integrity to your client applications

Today, Azure Blob Storage is extending that protection into your client applications for end-to-end integrity. When enabled by customers, with CRC64-NVME transactional verification built into the latest Blob SDKs, every byte uploaded or downloaded has a CRC64-NVME checksum generated and that checksum is validated end-to-end. This protects against silent corruption that can occur within client-side code, on faulty client hardware, or in proxies and other services that sit between your application and Blob Storage. With CRC64-NVME validation enabled, the SDK computes and sends a checksum over the data and the service independently verifies it before acknowledging the write; the same happens in reverse on read. For multi-part reads/writes, individual checksums are reconciled against a whole-object checksum to catch any corruption within the client library itself. Every byte is now integrity-checked from the moment it enters the SDK, through the Blob Storage service and your storage account, and back again.

Benefits of CRC64-NVME

Microsoft has always considered 64 bit-checksums a requirement at cloud scale, with the CRC64-NVME polynomial protecting exabytes of customer data in Blob Storage from accidental data corruption. Microsoft has invested and shared high-performance implementations of our CRC64-NVME implementation that other cloud providers and industry participants have adopted as the default for data integrity use cases.

The Cyclic Redundancy Check (CRC) algorithm was originally designed for detecting bit corruption in data transit over network protocols like Ethernet, so it has relatively minimal CPU usage. The CRC64-NVME polynomial variant used for Blob Storage data integrity takes advantage of hardware acceleration present in modern x86 and ARM CPUs to further reduce CPU usage. Further performance gains are achieved by composing CRC checksums - meaning if you have the CRC of two chunks of data, you can combine them to get the CRC of the whole data, without needing to re-read the data. CRC64-NVME also provides strong reliability: a collision probability of a random bit error is 1 in 2^64, or 1 in 18 quintillion.

Performance

Performance is paramount in Azure Blob and great care was taken to implement the CRC64-NVME end to end integrity performantly. The latest version of the Blob SDK implements data integrity through the Structured Message Body REST API, which boosts our efficiency. Structured message bodies effectively allow the Blob client libraries to process the data, compute the CRC64-NVME checksum, and compose/unpack the HTTP request all in one flow, rather than processing the same data two or three times.

There are no restrictions on the size of your data for end-to-end data integrity to work. The latest version of the Blob SDKs using the structured message body implementation can handle any size of data to perform the end-to-end Data Integrity, unlike our previous MD5 version.

Throughput and CPU utilization can vary between using CRC64-NVME, MD5, and no validation. Customers can weigh the benefits of end-to-end integrity with the performance implications that might be right for their application.

Usage

Requires upgrading to the latest SDK versions.

Upload data to Blob with end-to-end data integrity (.NET):

BlobUploadOptions options = new BlobUploadOptions { TransferValidation = new UploadTransferValidationOptions { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 } }; Response<BlobContentInfo> response = blobClient.Upload(upStream, options);

Download data to Blob with end-to-end data integrity (.NET):

BlobDownloadToOptions options = new BlobDownloadToOptions { TransferValidation = new DownloadTransferValidationOptions { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 } }; Response response = blobClient.DownloadTo(downStream, options);

Upload and Download on all client operations to Blob with end-to-end data integrity (.NET):

BlobClientOptions options = new BlobClientOptions { TransferValidation = { Upload = { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 }, Download = { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 } }, }; BlobServiceClient blobServiceClient = new BlobServiceClient(serviceUri, new DefaultAzureCredential(), options);

Availability

SDK	Minimum Version
.NET	12.28.0
Java	Coming soon
Python	Coming soon
JavaScript	12.32.0
Go	Coming soon
C++	12.17.0

Comparison to MD5

MD5 is a cryptographic hashing algorithm that has historically been used for verifying integrity of data. Content-MD5 was one of the original HTTP headers for this purpose. While Blob Storage has supported HTTP headers for integrity including MD5, it’s less preferred than CRC64-NVME for data integrity due to its lower reliability in detection, high collision rate, inability for hardware acceleration, and higher computational cost. Recently, MD5 has even been disallowed by many security frameworks (e.g. FIPS) due to its lack of cryptographic security.

With MD5, Blob Storage has only been able to verify the data integrity of each partitioned HTTP request/response with MD5, not the entire blob. Additionally, for reading blobs with MD5 validation there is a 4MiB size limit on the data in HTTP responses, which can significantly increase the number of HTTP requests required to read data. In both reading and writing blobs, the SDKs require buffering or re-reading the data to compute MD5 in addition to assembling the HTTP request and unpacking the HTTP response.

With the latest implementation of CRC64-NVME, Azure Blob client libraries can verify data integrity on both the entire data and each HTTP request/response, can do so with any size of partitions on reading or writing data, and does so in only one pass over the data.

To migrate from MD5 to CRC64-NVME, simply change your ChecksumAlgorithm:

-ChecksumAlgorithm = StorageChecksumAlgorithm.MD5 +ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64

Next Steps

To begin using end-to-end Data Integrity with CRC64-NVME, upgrade to the latest SDK version of your preferred language and check out our developer guides and examples:

Boost performance with NFS nconnect on Azure NetApp Files datastores for Azure VMware Solution

GeertVanTeylingen — Wed, 24 Jun 2026 07:16:04 GMT

Reading the numbers: what the Azure VMware Solution datastore data shows

What this unlocks for Azure VMware Solution with Azure NetApp Files

Introduction

For the most demanding workloads, storage is rarely the limiting factor on Azure NetApp Files. More often, it is the path to storage. NFS has long used a single TCP connection per datastore per host, and while that one stream is dependable, it quietly caps how much I/O a host can drive to a datastore. The usual workaround was to spread the workload across more datastores, or more hosts, so additional connections could share the load. It worked but it meant running and managing more datastores than the workload itself ever needed.

The nconnect mount option removes that cap by letting a single NFS mount use multiple TCP connections. VMware introduced it in vSphere 8.0 Update 2, and on‑premises NetApp customers adopted it quickly to get more out of their high-speed networks and storage. Now that same option is supported on Azure VMware Solution with Azure NetApp Files. For details on the nconnect mount option, see the Azure NetApp Files Linux NFS mount options documentation.

This matters because it changes what you can expect from a single datastore with higher throughput, lower latency under concurrency, and a simpler design all without leaving the managed Azure VMware Solution platform.

Co-authors

Rich Crofford, Azure NetApp Files Product Manager
Pravinkumar Jeya Kumar, Senior Program Manager Azure Dedicated

What is nconnect

The nconnect option is a client-side NFS capability that allows a single NFS mount to use multiple TCP connections. Instead of sending all Azure VMware Solution datastore traffic through one stream, the client distributes it across several parallel connections driving more traffic at a lower overall latency.

Figure 1. With nconnect=4, each ESXi host opens four parallel TCP connections to a single Azure NetApp Files datastore.

ESXi introduced multiple TCP connections for a single NFSv3 datastore in vSphere 8.0 Update 2, where the capability became generally available. The number of connections is configurable per datastore and adjustable at runtime, and the default stays at a single connection, so turning it on is a deliberate choice the administrator makes.

On Azure VMware Solution, a setting of nconnect=4 is now supported with Azure NetApp Files. You can mount an Azure NetApp Files datastore with four parallel connections per host, bringing the same parallelism and performance that is proven on premises into the fully managed Azure VMware Solution. . The nconnect=4 capability is supported on both Azure VMware Solution Gen 1 and Gen 2 private clouds, so you get the same capability regardless of which generation you run.

Why it matters

The payoff shows up in the two dimensions workloads care about most.

Throughput. Four connections carry more data in parallel than one. By spreading I/O across multiple TCP streams, a single datastore connection attains more bandwidth from the same host and makes fuller use of the available network, and thus storage throughput. On the Azure NetApp Files side, those connections are serviced in parallel by the storage service, so the extra client streams translate into real aggregate throughput instead of queuing a single connection.

Latency under concurrency. This is the part that is easy to overlook. When an NFS mount is established, the storage service tracks a connection that supports a defined number of concurrent, in‑flight operations. When a busy workload exceeds that number on a single connection, the service applies flow control until operations complete and resources free up. Each pause is brief often only for microseconds but across millions of operations those pauses add up and surface as higher overall latency. Adding connections multiplies the number of operations that can be in flight at once, which reduces queuing and keeps response times consistent when the workload gets heavy. This is not just a theory. Azure NetApp Files testing with Linux NFS clients shows that adding parallel connections measurably lowers latency under concurrent load. The nconnect option brings that same mechanism to each Azure VMware Solution host.

For applications that generate sustained I/O, more throughput with higher concurrency and lower latency is exactly what is needed to run predictably.

How it works

With nconnect=4, each Azure VMware Solution ESXi host mounts an Azure NetApp Files datastore over four parallel TCP connections. Storage traffic is processed concurrently across those connections, raising aggregate throughput and supporting a higher level of I/O concurrency than a single connection model ever could.

Adoption is straightforward and non‑disruptive, for both new and existing datastores. New Azure NetApp Files datastores can be created with nconnect enabled from day one, and the option can also be applied to datastores you already run. Either way, no changes are required to your virtual machines or applications, they simply benefit from the added I/O parallelism. A single datastore can then support performance that previously took several, simplifying the environment while preserving the scalability demanding workloads rely on. Because nconnect is configured per datastore, each datastore’s connection count can be set independently to match its workload.

⚠️ Important

Four connections per datastore is a deliberate balance. It delivers a meaningful jump in parallelism while keeping the storage design clean and easy to operate. Azure VMware Solution supports up to 256 NFS connections per host, so with nconnect=4, each host can access up to 64 datastores per SDDC. Keep the connection count consistent across all hosts in a cluster so that performance and operations such as vMotion behave predictably.

Reading the numbers: what the Azure VMware Solution datastore data shows

Azure VMware Solution specific nconnect benchmarks are still being run, but we do not have to wait to understand the impact. The most useful context already exists in two places; the published Azure NetApp Files datastore guidance for Azure VMware Solution, and years of Azure NetApp Files nconnect experience on Azure virtual machines. The single‑host scaling data comparing one datastore to multiple datastores is especially telling, because it shows exactly what happens when a host can spread load across more network flows.

What the published Azure VMware Solution data already tells us. With a single datastore, each Azure VMware Solution host connects over a fixed number of network flows, which became a bottleneck for the most demanding workloads. Moving from one datastore to two, and then to four, scaled out performance by giving the host more parallel network flows, as the figure below shows. That gain came purely from adding datastore level connections not from any change inside the guest virtual machines.

Figure 2. Scaling from 1 to 16 datastores on a single host lifts 8K IOPS from roughly 156,000 to 389,000 driven entirely by more parallel datastore connections.

Why that matters for nconnect. In those published single host results, moving from one datastore to four improved throughput because the host had more parallel datastore connections available. nconnect=4 changes the equation it lets a single datastore mount use four parallel TCP connections from each ESXi host. In other words, the same performance principle that previously favored multiple datastores can now be applied within a single datastore mount. That is why nconnect=4 is so significant for Azure VMware Solution with Azure NetApp Files as it helps one datastore deliver much more of the performance that used to require several.

Figure 3. Averaged across read/write mixes, scaling datastores delivers up to 397% (8KB random) and 279% (64KB sequential) relative to a single datastore the same scaling nconnect=4 brings within one datastore.

Read together, the data makes the point plainly more parallel datastore connections increase performance, and nconnect=4 brings that same scaling model to a single Azure NetApp Files datastore. These figures illustrate the scaling pattern your real‑world results will vary with the specific workload running against the datastore.

What this unlocks for Azure VMware Solution with Azure NetApp Files

Azure NetApp Files has always been the storage service of choice for the most demanding enterprise workloads databases, and high‑performance computing with no application changes required. For some of those workloads on Azure VMware Solution, the limiting factor was never the storage itself. It was the single‑connection ceiling between the host and the datastore, and nconnect=4 removes that ceiling.

Customers already running Azure VMware Solution with Azure NetApp Files can easily make use of this new feature. Because nconnect is configured per datastore, you can apply it to the datastores that are already connected and see the benefit immediately with no migration and configuration changes to your virtual machines.

Two common situations where I/O previously funneled through a single TCP flow will benefit right away: maximizing throughput for single VM with VMDKs maps to one datastore and increasing throughput for many VMs on a single datastore. In both cases, nconnect=4 relieves the bottleneck and lets the existing datastore absorb far more load which also spares you from spinning up extra datastores just to chase performance.

That is what makes Azure VMware Solution and Azure NetApp Files so compelling together. You get the enterprise grade performance of Azure NetApp Files, the familiar VMware operating model of Azure VMware Solution, and now the parallel connection scaling that high-performance workloads depend on all on a managed cloud platform.

It is worth saying plainly: with Azure VMware Solution and Azure NetApp Files, you do not need dedicated infrastructure to get bare‑metal performance. That applies to virtualized Oracle and SQL Server, to large analytics estates, and to any storage heavy application that once justified a dedicated platform. The performance is right there in the Azure VMware Solution and Azure NetApp Files platform you already run.

Use cases

The nconnect=4 option is especially valuable for Azure VMware Solution workloads that need more throughput, steadier latency under concurrency, or a simpler storage design. These use cases show where parallel TCP connections to a single Azure NetApp Files datastore make the biggest difference.

Use case	How nconnect helps
Databases on Azure VMware Solution plus Azure NetApp Files	Databases live and die on throughput and latency, and they generate exactly the kind of sustained, concurrent I/O that benefits most from parallel connections. With nconnect=4, Oracle, SQL Server, and similar engines run consistently on a single high‑performing datastore without sharding data files across many datastores to chase performance.
Storage-heavy and high-performance workloads	Analytics platforms, file‑intensive applications, and large virtual desktop estates all gain from higher aggregate IOPS and steadier latency per datastore. Backup and bulk‑data windows, where I/O spikes hard for a defined period, are a natural fit for the extra parallelism.
Datacenter exits and migrations	Teams retiring physical datacenters want to move VMware estates to the cloud with minimal redesign. Azure VMware Solution lets you bring workloads over as they are, and Azure NetApp Files with nconnect=4 supplies the storage performance that once justified keeping high‑demand workloads on dedicated infrastructure. You retire the hardware and still clear the performance bar.

Across all of these, Azure VMware Solution backed by Azure NetApp Files delivers the performance that once required specialized or dedicated platforms while keeping the storage design simpler.

Conclusion

The nconnect option lets each Azure VMware Solution ESXi host open four parallel TCP connections to each Azure NetApp Files datastore, increasing throughput and lowering effective latency under load without adding datastores or hosts. The capability has been proven in VMware for some time, and the performance case is already backed by existing benchmark data, including Azure NetApp Files nconnect scaling on Azure virtual machines and the published one datastore versus four datastore scaling results for Azure VMware Solution.

For the workloads Azure NetApp Files is known to serve well; this was the missing piece. Databases, analytics, and other storage heavy applications now have the parallel connection scaling they need on a managed VMware platform. With Azure VMware Solution and Azure NetApp Files, you do not need specialized infrastructure to get bare‑metal performance; the performance is already there, and now it scales.

Next steps

Review your datastore design. Identify the workloads most likely to benefit from more parallelism, especially databases, analytics platforms, and other storage‑intensive applications that currently span multiple datastores mainly for performance.
Validate platform prerequisites. Confirm that your Azure VMware Solution environment and Azure NetApp Files datastore deployment follows the documented connectivity and performance best practices for attached datastores, including the guidance for your generation of private cloud.
Test nconnect on the right datastores first. Start with the datastores that show the clearest signs of throughput pressure or latency under concurrency, then compare performance and operational simplicity before expanding more broadly.
Standardize across the cluster. Apply a consistent configuration across hosts for any datastore that uses nconnect, so performance characteristics and mobility operations stay predictable.
Use the published guidance to plan rollout. Review the Azure VMware Solution attach guidance, performance considerations, and benchmark documentation to decide where nconnect can help you reduce datastore sprawl while preserving the performance your workloads require.

For Azure VMware Solution customers using Azure NetApp Files, nconnect is a practical way to simplify storage design while improving throughput and latency for demanding workloads. It helps you get more from the datastores you already use, with less need to spread workloads across additional datastores just to add parallelism.

Learn more

Bringing Enterprise File Data to Users with Azure NetApp Files, Microsoft Foundry, and M365 Copilot

GeertVanTeylingen — Mon, 15 Jun 2026 07:37:24 GMT

Introduction

Why the user experience layer matters in enterprise AI

Microsoft Foundry: Orchestrating enterprise AI agents

The Copilot agent as the enterprise user experience

End‑to‑end user query flow

Why this pattern works for regulated and complex environments

Extending Copilot beyond SharePoint‑centric scenarios

From storage to knowledge to action

Key takeaway

Put the architecture into practice

Learn more

Introduction

In Part 1, From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake, we established a zero‑copy data foundation that makes enterprise file data AI‑addressable using Azure NetApp Files and Microsoft OneLake, without migration, duplication, or workflow disruption.

In Part 2, From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API, we showed how that foundation is activated through a knowledge pipeline using Azure AI Search and Azure OpenAI, transforming unstructured files into a living, queryable knowledge system grounded in Retrieval‑Augmented Generation (RAG).

In this final part, we focus on the user experience: how this architecture is safely and effectively surfaced to end users through enterprise AI agents, including Copilot, where employees already work.

Co-authors:

Thomas Willingham, Azure NetApp Files Product Manager
Sean Luce, Azure NetApp Files Product Manager

Why the user experience layer matters in enterprise AI

Enterprise AI adoption rarely fails because models are insufficient. It fails when users are asked to change how they work, learn new tools, or trust opaque answers.

For knowledge‑centric scenarios, success depends on three things:

Users interact with AI inside their existing workflows.
Answers are grounded in authorized enterprise data.
Responses are traceable, and auditable.

Microsoft 365 Copilot provides the ideal natural language experience for this layer. However, Copilot itself does not “understand files.” It relies on external knowledge sources and well‑defined grounding mechanisms to retrieve and synthesize information safely.

This is where the Copilot Agent completes the architecture, with Microsoft Foundry providing the orchestration layer behind it.

Microsoft Foundry: Orchestrating enterprise AI agents

Before enterprise knowledge is exposed to end users through enterprise AI agents such as Copilot, it must first be assembled, grounded, and governed as an AI capability. This is the role of Microsoft Foundry.

Microsoft Foundry is the control plane for building and governing enterprise AI agents. It provides the environment where enterprise AI agents are created and connected to authoritative knowledge sources. It orchestrates how Azure AI Search, Azure OpenAI models, and enterprise data sources, including Azure NetApp Files surfaced through OneLake, work together to deliver an accurate, grounded response.

Rather than embedding intelligence directly inside Copilot, Foundry acts as the control plane for enterprise AI. It defines:

Which knowledge sources an agent can access,
How retrieval and grounding are enforced,
How models are constrained to retrieved enterprise content, ensuring responses remain grounded, explainable, and auditable.

This separation ensures that Copilot remains the user experience, while Foundry governs how enterprise AI agents reason over data, securely and predictably.

Together, this user experience layer enables secure, seamless access to enterprise data for AI, unlocking real business value through governed, traceable Copilot experiences.

The Copilot agent as the enterprise user experience

The Copilot agent is built and governed within Microsoft Foundry, but users interact with it through Copilot.

At a high level, the agent performs three critical functions:

Receives natural language questions from users inside M365 experiences such as Teams or Copilot Chat,
Queries the Azure AI Search index built over enterprise file data referenced through OneLake,
Generates grounded responses using Azure OpenAI, restricted to retrieved content and enriched with source citations.

This separation of responsibilities is deliberate. Copilot does not read file storage directly, nor does it reason over raw documents. Instead, it queries a curated, indexed knowledge source designed specifically for enterprise RAG scenarios.

The result is a user experience that feels conversational but behaves predictably.

End‑to‑end user query flow

When a user asks a question in Copilot – such as:

“What is our incident escalation procedure for data breaches?”

The interaction follows a controlled, enterprise‑safe flow:

User submits a question in Copilot,
The Copilot Agent forwards the query to Azure AI Search,
Relevant document chunks are retrieved using semantic vector search,
Azure OpenAI synthesizes a response using only the retrieved content,
Source filenames are included in the response for transparency.

At no point does the model infer information from outside the enterprise dataset or hallucinate answers based on its general training.

This is not a chatbot layered on top of file storage. It is a governed retrieval and reasoning pipeline surfaced through a familiar, conversational experience.

Why this pattern works for regulated and complex environments

This user experience model is especially powerful for industries where trust, traceability, and compliance are non‑negotiable.

Because answers are always grounded in specific source files:

Legal teams can verify interpretations against contract language,
Security teams can audit responses back to official runbooks,
Compliance teams can validate that policies, not assumptions, are being cited.

Just as importantly, data never leaves its system of record:

Files remain governed and secured in Azure NetApp Files,
Access controls continue to be enforced at the storage layer,
OneLake provides virtualization, not duplication,
AI services operate on indexed representations, not copied datasets.

This preserves existing governance models while extending their reach into AI‑driven experiences.

Extending Copilot beyond SharePoint‑centric scenarios

Most Copilot examples focus on collaboration content stored in SharePoint or OneDrive. These are valid and important scenarios.

However, enterprise knowledge does not live exclusively in collaborative repositories.

Large organizations depend on:

Network file systems containing decades of operational knowledge,
Hybrid environments where SMB and NFS are the primary interfaces,
High‑performance storage platforms that cannot be re‑platformed.

By combining Azure NetApp Files, OneLake, a RAG‑based knowledge pipeline, and Copilot, this architecture extends Copilot’s reach to the realities of the enterprise data estate, without forcing that estate to change.

From storage to knowledge to action

Taken together, the three layers form a cohesive architecture:

Part 1: Data Foundation
Azure NetApp Files + OneLake make enterprise file data AI‑addressable without migration or duplication.
Part 2: Knowledge Pipeline
Azure AI Search + Azure OpenAI transform files into a living knowledge system using RAG.
Part 3: AI Orchestration & User Experience
Microsoft Foundry orchestrates enterprise AI agents, and Copilot provides a natural, trusted way for users to ask questions and receive grounded answers.

This is not a single-use solution. It is a repeatable architecture pattern for enabling secure, seamless access to enterprise data for AI, unlocking real business value safely, predictably, and at scale.

Key takeaway

The real promise of enterprise AI is not replacing systems of record but making them intelligible.

With this architecture, Azure NetApp Files becomes more than high performance storage.

It becomes the foundation of an AI‑ready data estate, delivering grounded insights inside Copilot, without compromising performance, security, or trust.

Together, these three parts form a complete architecture for extending AI to enterprise file data – bridging the gap between systems of record and AI-powered user experiences.

Put the architecture into practice

This three‑part series outlines a repeatable pattern for bringing AI to enterprise file data; without migration, duplication, workflow disruption, or governance compromise.

To go deeper:

Review the reference architecture described in this series and map it to your environment,
Identify candidate file‑based knowledge scenarios (security, compliance, operations),
Engage your data, storage, and AI teams, with us at askANF@microsoft.com to apply this pattern using Azure NetApp Files, Microsoft OneLake, and Copilot.

Enterprise AI succeeds when systems of record become systems of intelligence.

Learn more

From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake

GeertVanTeylingen — Mon, 15 Jun 2026 07:37:21 GMT

Introduction

Why the data foundation matters

Expanding beyond collaboration-centric data

The zero‑copy data foundation pattern

Why OneLake changes the model

What this enables

Key takeaway

Learn more

Introduction

Enterprise AI is advancing rapidly, but many organizations are discovering a common challenge: their most valuable data is not accessible to the systems they want to use.

While collaboration platforms and modern data services are designed for AI integration, the majority of enterprise knowledge still resides in file systems, powering critical applications, operational workflows, and long-standing systems of record. These environments were built for performance, reliability, and scale, not for AI-driven discovery or reasoning.

This creates a fundamental gap. Organizations have the data they need to power AI, but that data often remains outside the reach of modern AI platforms.

In this blog series, we explore how to close that gap without rewriting workflows, migrating data, or disrupting existing systems.

Co-authors:

Thomas Willingham, Azure NetApp Files Product Manager
Sean Luce, Azure NetApp Files Product Manager

Why the data foundation matters

As organizations accelerate their adoption of AI, a familiar challenge keeps emerging: AI is only as effective as the data it can access. While models and tools continue to advance rapidly, many enterprises are constrained by data foundations that were never designed for AI workloads.

The issue is not a lack of data. In fact, most organizations already store their most valuable institutional knowledge on enterprise file systems:

Engineering specifications and design documents
Legal contracts and compliance records
Policies and procedures
Technical runbooks
Historical reports and archives

For many enterprises, this content lives on high‑performance file storage such as Azure NetApp Files, accessed through long‑standing SMB and NFS workflows. The data is fast, reliable, and trusted, yet largely invisible to AI.

Files are rich in information, but they are fundamentally passive. Users must already know where to look, and AI systems cannot reason over data they cannot access. This disconnect between where enterprise content lives and where AI knowledge can operate is now one of the biggest blockers to scalable AI adoption.

Expanding beyond collaboration-centric data

Many AI scenarios today focus on collaboration-centric data that is:

Cloud‑native
Stored in SharePoint or OneDrive
Well suited for small to medium‑sized repositories

This is an important and valuable class of data. But it represents only part of the enterprise reality. Enterprise AI requires extending beyond collaboration data to include systems of record, where the majority of institutional knowledge resides.

Most large organizations also rely on:

Large NAS estates measured in tens or hundreds of terabytes, and often millions of files
Hybrid and on‑premises environments
Long‑standing SMB/NFS workflows that cannot be easily re‑platformed or migrated

These environments are not failures of SharePoint, they serve different needs. File systems remain the system of record for many regulated, performance‑sensitive, and document‑heavy workloads.

The challenge has been extending AI, and data platforms, to this class of enterprise file data without forcing migration, duplication, or workflow change.

This is the gap that Azure NetApp Files and Microsoft OneLake fill together.

The zero‑copy data foundation pattern

To unlock AI across enterprise file data, we need a different foundation, one that respects existing systems of record while making data accessible to modern AI services.

This solution introduces a zero‑copy, zero‑migration data foundation built on three key components:

Component	Role
Azure NetApp Files	System of record for unstructured enterprise files (SMB/NFS)
Object REST API	Provides object access (S3‑compatible) to file data
Microsoft OneLake	Unified data layer that exposes data without duplicating it

Files continue to be created, updated, and managed on Azure NetApp Files exactly as they are today.

The Azure NetApp Files object REST API provides object‑based access to that data, enabling modern analytics and AI platforms to work directly with existing file datasets without copying, moving, or restructuring them.

This same zero-copy pattern is already used to unlock advanced analytics and AI scenarios with services such as Azure Databricks and Microsoft Fabric, validating its suitability for large‑scale enterprise AI workloads.

Why OneLake changes the model

Microsoft OneLake is often described as a “single data lake for the entire organization,” but its most important capability in this architecture is what it does not do.

OneLake does not ingest Azure NetApp Files data.

Instead, it:

creates shortcuts as virtual pointers to external data,
preserves ownership, permissions, and access patterns,
avoids storage duplication and ETL pipelines,
keeps Azure NetApp Files as the authoritative system of record.

This shortcut‑based model allows OneLake to unify data across clouds, platforms, and on‑premises environments while maintaining a single logical namespace.

From an AI perspective, this is critical. It means enterprise file data can be discovered, indexed, and reasoned over by downstream AI services without breaking compliance boundaries, duplicating storage, or introducing synchronization risk.

What this enables

With Azure NetApp Files connected to OneLake through the object REST API:

enterprise file data becomes AI‑addressable,
existing SMB/NFS workflows remain unchanged,
data stays governed, secured, and owned by the original platform,
AI systems gain visibility into previously inaccessible knowledge.

This architecture does not replace SharePoint‑based scenarios. Instead, it expands AI and data analytics scenarios across a broader, more representative enterprise data estate.

Key takeaway

Azure NetApp Files is the high-performance, intelligent, and cyber-resilient foundation for enterprise file data, powering AI with enterprise application file data wherever it lives.

By combining Azure NetApp Files, the object REST API, and Microsoft OneLake, organizations establish a unified, zero‑copy foundation that brings enterprise file data into scope for modern AI systems.

With the data foundation in place, the next step is turning that data into usable knowledge.

This AI‑ready data foundation enables higher‑level AI capabilities and agents that are governed and surfaced to users in later layers of the architecture.

In Part 2, From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API we’ll explore how this foundation enables a knowledge pipeline using Azure AI Search and Azure OpenAI to support Retrieval-Augmented Generation (RAG).

Learn more

From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API

GeertVanTeylingen — Mon, 15 Jun 2026 07:37:13 GMT

Introduction

Why a knowledge pipeline is required

Retrieval‑augmented generation (RAG) at enterprise scale

Knowledge pipeline architecture overview

Step 1: Indexing enterprise file content without moving it

Step 2: Creating semantic meaning with embeddings

Step 3: Retrieval at query time

Step 4: Grounded answer generation

Why this architecture matters

Preparing for the Copilot experience

Key takeaway

Learn more

Introduction

In Part 1, From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake, we established the foundation: how Azure NetApp Files and Microsoft OneLake together transform enterprise file storage into an AI‑addressable data layer, without data migration, duplication, or workflow disruption.

But an AI‑ready foundation alone does not make data usable by AI.

⚠️Important

Industry research shows that many AI initiatives fail before they ever reach production. According to IDC, fewer than half (44%) of AI pilot projects advance out of experimentation, with the primary limiting factors not being model capability but the quality of business data and the timeliness of access to it.

IDC, *AI-Ready Data Storage Infrastructure: Definition, Taxonomy, Ontology, and Future Outlook*, IDC #US53709325, August 2025

To turn enterprise file data into something large language models can reason over, search, and cite, we need a knowledge pipeline, one that can understand unstructured content at scale, retrieve the right information at the right time, and ground AI responses in authoritative source data.

This is where Retrieval‑Augmented Generation (RAG) enters the architecture.

Co-authors:

Thomas Willingham, Azure NetApp Files Product Manager
Sean Luce, Azure NetApp Files Product Manager

Why a knowledge pipeline is required

Large language models are powerful, but they have a fundamental limitation in enterprise settings: they do not have inherent access to your organization’s internal data.

Even when data is accessible through a unified foundation like OneLake, these models cannot simply “read” files on demand. Enterprise AI systems require a mechanism to:

Discover relevant content across large document sets,
Understand the semantic meaning of unstructured files,
Retrieve only the most relevant excerpts for a given question,
Generate responses grounded in real documents, with traceability.

This is exactly what a knowledge pipeline provides.

Rather than pushing all enterprise data into a model, the pipeline keeps data in place, builds a continuously updated semantic index, and retrieves relevant information at query time. The AI model then generates answers based only on retrieved content, not on guesswork or generalized training data.

Retrieval‑augmented generation (RAG) at enterprise scale

At a high level, Retrieval‑Augmented Generation combines two functions:

Retrieval – finding the most relevant pieces of enterprise content
Generation – using a language model to synthesize an answer from those retrieved sources

For enterprise file data, this pattern is especially important:

File repositories are large, dynamic, and constantly changing
Content is unstructured and varies widely in format and quality
Accuracy, traceability, and compliance are mandatory, not optional

RAG ensures that AI responses are grounded in current, authorized enterprise content, not inferred, outdated, or hallucinated knowledge.

Knowledge pipeline architecture overview

In this solution, the knowledge pipeline sits on top of the OneLake data foundation and connects enterprise file data to downstream AI experiences through three core services:

Component	Role in the Knowledge Pipeline
Microsoft OneLake	Provides unified, zero‑copy access to enterprise file data
Azure AI Search	Indexes, chunks, and retrieves relevant content using keyword + vector search
Azure OpenAI	Generates semantic embeddings and synthesizes grounded responses

Together, these services transform passive file data into an actively queryable enterprise knowledge system.

Step 1: Indexing enterprise file content without moving it

The pipeline begins with Azure AI Search indexing content exposed through OneLake.

Because OneLake references Azure NetApp Files volumes via shortcuts, Azure AI Search can read files directly, without copying them into another storage system. Files remain:

Stored on Azure NetApp Files,
In-place available via existing SMB / NFS workflows,
Governed by their original security and ownership model.

Azure AI Search performs three key functions during indexing:

Content extraction – reading text from supported document formats,
Chunking – splitting large documents into semantically meaningful segments,
Metadata capture – preserving filenames and contextual information.

This process creates a searchable representation of enterprise file content while leaving the original data untouched. As files change, this index is refreshed through re-indexing processes that regenerate embeddings for updated content.

Step 2: Creating semantic meaning with embeddings

Keyword search alone is insufficient for natural language queries.

To understand meaning, not just matching words, the pipeline uses vector embeddings generated by Azure OpenAI.

During indexing:

Each document chunk is converted into a high‑dimensional vector that represents its semantic meaning,
These embeddings are stored in Azure AI Search alongside the textual index.

This enables semantic similarity search, allowing the system to retrieve relevant content even when a user’s question does not match document wording exactly.

For example:

A query about “incident response procedures” can retrieve documents titled “Security Escalation Playbook.”
Policy intent matters more than literal phrasing.

This is critical for natural language AI scenarios, where users ask questions conversationally rather than searching by filename or keyword.

Step 3: Retrieval at query time

When a user submits a question, for example through an AI agent, the knowledge pipeline activates in real time.

At query time:

The question is converted into an embedding,
Azure AI Search performs vector similarity search against the indexed content,
The most relevant document chunks are retrieved,
Source metadata (including filenames) is preserved.

Only the retrieved content is passed to the language model for response generation.

Example: How retrieval works in practice

A user asks: “What is our incident escalation procedure for data breaches?”

The system retrieves relevant sections from documents such as a “Security Escalation Playbook” stored on Azure NetApp Files, and passes only those excerpts to the language model to generate a grounded response with source citations included.

This design ensures:

AI responses are based on actual enterprise documents,
The scope of information is tightly controlled,
Results remain explainable and auditable.

Step 4: Grounded answer generation

Finally, Azure OpenAI synthesizes a natural language response using only the retrieved content.

The model does not infer beyond the supplied sources. Instead, it:

Summarizes relevant information,
Resolves ambiguities across multiple documents,
Produces an answer grounded in enterprise data.

Because filenames are preserved throughout the pipeline, downstream interfaces, such as an AI agent, require responses to include explicit source citations.

This is especially important in regulated and compliance‑driven environments, where users must be able to verify where an answer came from.

Why this architecture matters

The knowledge pipeline solves a problem that generic AI integrations cannot:

No data movement – files remain on Azure NetApp Files,
No re‑platforming – existing workflows continue unchanged,
No trust gap – every answer can be traced back to a real document.

Instead of forcing enterprises to restructure their data to fit AI tools, this architecture adapts AI to how enterprises store and manage knowledge.

The result is a living knowledge system:

Updated as content changes through re-indexing processes that refresh the semantic index,
Scalable across millions of documents,
Ready to support multiple AI experiences, not just a single user-facing scenario.

Preparing for the Copilot experience

At this point, the pipeline has done the hard work:

Enterprise file data is accessible through OneLake,
Semantically indexed and searchable,
Ready for controlled, grounded AI access.

What remains is exposing this capability to end users; safely, consistently, and within the tools they already use.

This knowledge pipeline provides the governed, retrieval‑ready foundation that enterprise AI agents can consume and orchestrate, before being surfaced to end users through downstream user experiences.

Key takeaway

Enterprise file data becomes a living, queryable knowledge system, without moving, copying, or restructuring a single file, eliminating the operational “copy-tax” associated with data duplication.

By combining Microsoft OneLake, Azure AI Search, and Azure OpenAI, the knowledge pipeline transforms the zero‑copy data foundation into an actively searchable enterprise resource. Every AI response is grounded in real documents, traceable to its source, and scoped to authorized content.

With the knowledge pipeline in place, the next step is surfacing this capability to end users in a secure and intuitive way.

In Part 3, Bringing Enterprise File Data to Users with Microsoft Foundry, M365 Copilot and Azure NetApp Files, we’ll explore how this pipeline is exposed through enterprise AI agents and user experiences, and governed by Microsoft Foundry, enabling natural language interaction with enterprise file data, complete with citations, governance, and enterprise controls.

Learn more

File share migrations simplified with Azure Copilot Migration Agent

madhurinrao — Wed, 03 Jun 2026 12:28:05 GMT

Building on our earlier announcement of discovery and assessment support for SMB and NFS file shares in Azure Migrate, we are extending the experience to support end-to-end file share migrations within the same workflow. With Azure Copilot Migration Agent, customers can move from discovery and assessment to migration through a single guided experience in Azure Migrate. By bringing planning and execution together, the agent helps organizations streamline migration activity, reduce handoffs, and maintain continuity across stages.

Overview

Since the release of file share discovery and assessment in Azure Migrate earlier this year, customers have indicated that while visibility into their file share estate improved, the transition to execution remained fragmented. In many cases, teams still had to work across separate workflows for inventory, readiness planning, and migration, increasing operational friction and the risk of losing context between stages.

Azure Copilot Migration Agent helps address this gap by bringing discovery, assessment, planning, and execution into a single guided journey. Azure Migrate provides visibility and recommendations, while Azure Storage Mover supports execution in a connected, agentic experience. The result is a more consistent migration path that reduces complexity, preserves context, and helps teams move file shares to Azure with greater operational confidence.

Invoking the Azure Migration Copilot Agent for on-premises data migration

Customer Value

This update streamlines the migration journey by connecting each stage of the process and reducing operational overhead. Natural language guidance helps teams start and manage migration activities much faster, often in hours or days instead of weeks.

The experience supports the following scenarios:

End-to-end discovery, assessment, and migration for on-premises Windows and Linux file shares (SMB) to Azure Files.
Discovery and assessment for on-premises Windows and Linux file shares (NFS).
Data transfers from one Azure Blob container to another container.

Design principles

The experience preserves continuity across inventory, readiness insights, and execution planning, enables direct movement of validated shares when heavyweight orchestration is unnecessary, maintains approval and sequencing controls, and supports the file and object movement patterns commonly required in production environments.

Getting Started with Storage Migration in Azure Copilot Migration Agent (ACMA)

Launch Azure Migrate: Sign-in to the Azure portal, open Azure Migrate.
From the Getting Started page, open Azure Copilot Migration Agent, then select or create an Azure Migrate project.
Describe the migration in natural language. The agent detects storage migration intent and assists with storage migration planning and routes execution requests seamlessly.

Examples scenarios and prompts

Migration of on-premises Windows Server data over SMB to Azure Files

setting up key vault after source is confirmed

create target if not already present

review configuration before creation of migration jobrun migration job and check status

2. Prompt: Help me transfer data from one Azure blob container to another blob container

Call to action

Storage integrated capability is launching in Limited Preview at Microsoft Build. Sign up for the Preview here.

For questions, contact storagemigrationcopilotagent@microsoft.com.

Learn More

Simpler, scalable file share management in Azure - now generally available

VincentLiu — Tue, 02 Jun 2026 19:07:28 GMT

Linux workloads in Azure are scaling faster than ever, powering everything from container platforms, analytics pipelines, SAP environments to line-of-business applications. As these workloads grow, infrastructure teams commonly run into challenges with scale, cost management, complexity and compliance. IT organizations need more granular control over management and isolation boundaries for file shares independent of storage accounts, to prevent multiple application teams sharing the same capacity pools, limits, and configuration surface across different storage services. Infrastructure administrators seek operational simplicity with managing access control, policy and networking isolation for file shares, so application teams can focus on business logic and development agility.

We are announcing the general availability of a new service management experience for premium SSD file shares (NFS) which allows each file share to be created, secured, scaled, and billed independently, without being tied to a storage account.

Key benefits include:

Familiar and intuitive file share management: Aligns user experience with on-premises NAS and file server paradigms, improving usability compared to the classic model.
Infrastructure-as-Code: Define naming, capacity, IOPS, networking, tags, and security in Bicep or ARM templates for simplified automation with your favorite DevOps tools.
Scale to match the workload: Support for up to 10,000 file shares per subscription per region, with 2.5x faster file share provisioning experience.
Share-level security and networking: Network restrictions, snapshots, and encryption scoped to the individual share, making isolation boundaries match workload boundaries.
Per-share cost visibility: Billing meters emit under the file share resource, teams can crossbill accurately, track per-workload costs, and improve chargeback without workarounds.

Independent performance, security, and billing per share

Combined with the provisioned v2 model, each file share is independently provisioned with its own storage, IOPS, and throughput. This allows organizations to align file shares directly to application or tenant boundaries, rather than grouping them under shared infrastructure constructs.

For multi-tenant SaaS platforms, this enables a natural one-to-one mapping between tenants and file shares. Each tenant operates within its own performance envelope, allowing steady workloads and bursty workloads to scale independently without contention. This reduces the need for capacity planning tradeoffs or overprovisioning to accommodate peak usage across tenants.

This isolation extends beyond performance; each file share carries its own encryption in transit settings, RBAC, policy, and network boundaries. For example, production tenants can be isolated with dedicated private endpoints, while development environments can operate under more flexible configurations. These boundaries align directly with application design, making systems easier to reason about and manage at scale.

Finally, treating each file share as its own resource simplifies cost management. Teams can tag and track usage at the workload or tenant level, enabling more accurate chargeback and better visibility into resource consumption. This makes it easier to understand how individual workloads contribute to overall spending without introducing additional tracking mechanisms.

Start easy, scale big

Cloud-native Linux applications often scale dynamically, so the underlying storage platform must provide resources quickly and support higher scale limits to keep pace with workload demand and enable teams to quickly provision infrastructure and keep pace of development. The new file share experience supports up to 10,000 file shares per subscription per region, making it practical to use a dedicated share for each application, environment, or tenant without running into platform limits. It also provides faster provisioning, with time to first share 2.5x times faster than classic file shares, so teams can spend less time waiting on infrastructure and more time building, testing, and shipping.

“Provisioning is fast and integrates seamlessly with Linux environments through NFS.” - Siam Commercial Bank

Data protection with snapshots

Linux workloads using shared file storage require robust data protection. With the new service management experience, customers can continue to leverage point-in-time incremental snapshots with up to 200 snapshots per share. You can also now edit metadata on individual snapshots, making it easier to organize and identify recovery points. Whether you need short term restore points or need to retain data for compliance requirements, snapshots provide an easy and cost-effective recovery mechanism.

Get started today

The new file share experience is available for NFS 4.1 file shares on SSD storage, using the provisioned v2 billing model with LRS and ZRS options. Whether the deployment model is ARM templates, Bicep, MCP server, or custom CI/CD pipelines, file shares are scriptable, repeatable, and automatable through the same tooling used for the rest of Azure infrastructure. Explore our documentation for step-by-step guidance.

We're continuously enhancing the new file share experience with the goal of achieving full feature parity while delivering improved scale and performance limits. We would love to hear your feedback, please fill out the survey to share your thoughts.

Learn more

For questions or feedback, contact us at azurefiles@microsoft.com.

Secure, Modern Access to Azure Files on macOS with MS Entra ID

grace_kim — Tue, 02 Jun 2026 18:55:03 GMT

Enterprises, large and small, rely on Azure Files for secure, scalable, and cost-efficient file storage. Modern workflows today span devices, platforms, and geographies; seamless, and secure access to shared data across every endpoint is critical to keeping teams productive and collaborative. With the growing demand for access across every device, Azure Files now extends secure access to macOS with Entra ID authentication, supporting design, creative, and AI teams where they work.

Today, we are announcing the Public Preview of MS Entra ID based authentication for Azure Files on macOS. Whether you are running creative production pipelines, design workflows, or AI workloads, macOS users can now access Azure file shares securely, meeting Microsoft Entra ID enterprise governance standards automatically and seamlessly, with no credential prompts, no storage account keys, and no complexity.

Key benefits

Enhanced Security posture: MacOS users can now sign in to their device and open shared files in Finder with no credential prompts and no storage account keys. Microsoft Entra ID governs access, conditional access policies, MFA requirements, and MS Entra ID governance applies automatically with AES-256 encryption.

Reduced operational overhead: IT admins no longer need to manage storage account key distribution/rotation. Provisioning and deprovisioning access is handled through standard Entra ID group membership.

No dependency on Active Directory: Organizations moving away from on-premises infrastructure, including Active Directory, can now give MacOS users full access to Azure file shares using cloud-based identities in MS Entra ID, with no domain controller required. MacOS users get full parity with the traditional Windows SMB share experience.

Identity Based Access model: User authentication is enforced with Kerberos and share-level access is enforced through Azure RBAC. File and folder permissions are controlled through NTFS ACLs, giving organizations precise, layered control.

Enabling AI-Driven Workloads: SMB shares on macOS enables AI teams to seamlessly access and share large datasets, fueling faster experimentation and streamlining developer and AI-generated workflows.

Partnership with Apple

Azure Files support for macOS is built in close collaboration with Apple macOS SMB engineering team. The integration works with Apple’s Platform SSO and the Microsoft Enterprise SSO plug-in, via MDM platforms such as Microsoft Intune. This allows macOS devices to authenticate through Microsoft Entra ID with single sign-in. We are committed to continuing this partnership to ensure Mac users in enterprise environments have a first-class experience accessing cloud services.

Powering Diverse Workloads across Design, Developer and Education Enterprises

Secure SMB access for creative workloads

Creative workflows on macOS have historically required workarounds to reach centralized cloud storage, often meaning local copies, consumer file sharing tools, or storage account keys distributed to individuals. Azure Files gives creative teams direct access to shared project libraries and production files from Finder, with no syncing or local copies needed. For IT, setup is simple: assign the right RBAC role on the share, add users to an Entra group, and access is ready. No keys to distribute and no deep storage expertise required.

"Secure access for our macOS users is a gamechanger for our creative teams. The ability to mount directly and access shared files securely — without keys, without workarounds — changes how we work. It’s how modern enterprise file access should feel." -Peter Day, Senior Engineer, The Marketing Store

SMB shares streamline developer and AI-generated build workflows

MacOS developers rely on local tools like Visual Studio Code, GitHub copilot, or fast iteration, but build artifacts, logs, and AI-generated outputs often end up fragmented across machines and pipelines.

With Azure Files, teams can use SMB shares as a centralized workspace for build outputs and shared assets. Mac build systems can write directly to a mounted share, making artifacts immediately accessible across developers, pipelines, and AI agents. DevOps teams gain a secure, identity-based storage layer using RBAC and Microsoft Entra, without managing keys or custom storage solutions.

Enable collaboration across mixed platform environments

Mac users should not be a special case. Azure Files gives MacOS users the same governed, identity-based access to shared storage that Windows users have always had. Access is provisioned through Entra ID, enforced through RBAC, and managed without a separate workflow, separate keys, or separate infrastructure. For large organizations running mixed-OS environments, this means a single, consistent access model tied to the user and not a device – the user can seamlessly access the SMB share across their Windows and Mac devices.

“By supporting Kerberos authentication for Azure Files on Mac devices, Microsoft delivers secure, consistent access for organizations operating mixed-OS environments. It addresses a long-standing enterprise gap by extending centrally governed identity controls to all users, regardless of device—helping organizations simplify access management and maintain trust at scale.” -Preetham G.K., CDL, Accenture

Modernize Infrastructure and secure access for Educational Institutions

Institutions standardizing on macOS have faced a hard tradeoff: maintain costly on-premises infrastructure at every site or accept that MacOS users fall back on personal drives and consumer file sharing. Neither is acceptable at scale. Azure Files removes the tradeoff. Students, faculty, and staff access shared repositories and course materials directly from an SMB share over Finder using their Entra ID credentials. Access management can be controlled through group membership, with no per-site infrastructure and no manual credential management.

Get started with Azure Files Entra Kerberos authentication for macOS

Start leveraging secure, identity-based file access on macOS today at no added cost. Explore our documentation for step-by-step guidance. Whether you are onboarding new Mac users or modernizing an existing deployment, this feature gives your organization a simple path to identity management for Azure Files on macOS. Make your Mac workloads ready for the future!

For any questions, please reach out to the team at azurefiles@microsoft.com.

From Scale to Breakthrough: Azure NetApp Files Sets a New Cloud Benchmark for EDA Performance

GeertVanTeylingen — Fri, 22 May 2026 15:00:00 GMT

Introduction

New benchmark proof with large volume breakthrough mode

What is Azure NetApp Files large volume breakthrough mode?

Explore the latest Azure NetApp Files SPECstorage® 2020 publications

Results that Speak for Themselves

Single large volume breakthrough mode

Large volume breakthrough mode at scale

Performance that Scales with Your Design Cycles

From large volume scale… to breakthrough mode scale

What Storage Performance Means For EDA Velocity

Learn more

Introduction

In his latest Azure NetApp Files for EDA workloads: From revolution to breakthrough at scale post Aung Oo – Vice President, Azure Storage – explored a fundamental shift in Electronic Design Automation (EDA) infrastructure: cloud storage no longer needs to tradeoff between scale and predictable performance. It unpacked the historical compromises EDA teams made to balance amongst extreme concurrently, shared datasets and the strict latency requirements and how Azure NetApp Files was architected to solve these challenges with consistent, linear scaling behavior.

Just as importantly, that post presented independently validated SPECstorage® Solution 2020 benchmarks showing that Azure NetApp Files can support real-world EDA workloads at scale while sustaining sub-millisecond latency – shifting cloud storage from a bottleneck in modern chip design pipelines to an enabler.

This blog builds on that foundation.

With the introduction of Azure NetApp Files large volume breakthrough mode, the conversation shifts from proving scalable performance to redefining its upper limits. Where earlier results established predictable scaling, breakthrough mode pushes the concurrency envelope further – allowing thousands of parallel jobs to share storage while maintaining consistent latency under sustained load.

The result is a new level of cloud performance for EDA: not just solving scale challenges, but delivering a true performance breakthrough, now validated by the latest SPECstorage® Solution 2020 benchmark publications.

In this blog, we take a closer look at two new SPECstorage® Solution 2020 EDA_BLENDED benchmark submissions that validate the impact of large volume breakthrough mode, both for a single volume configuration and at scale, and place those results in real-world context.

Co-authors:

Ron Hogue, Sr. Program Manager
Ranga Sankar, Azure NetApp Files Product Manager
Andy Chan, Azure NetApp Files HPC/EDA Principal Product Manager
George Strother, Senior Cloud Solutions Architect, NetApp
Cass Morgenstern, Director of Engineering - Office the CTO, NetApp

New benchmark proof with large volume breakthrough mode

Following the same industry‑standard SPECstorage® Solution 2020 EDA_BLENDED workload methodology used in our prior large volume submissions, the newly published results evaluate:

Azure NetApp Files large volume breakthrough mode
Azure NetApp Files large volume breakthrough mode scale

Together, these independently audited benchmark publications validate how breakthrough mode enable Azure NetApp Files large volumes to sustain higher concurrency levels while maintaining the consistent, sub‑millisecond response times that modern chip design pipelines depend on.

What is Azure NetApp Files large volume breakthrough mode?

Azure NetApp Files large volume breakthrough mode unlocks a new level of scale and performance for the most demanding EDA workloads. By combining massive concurrency with consistent sub-millisecond latency, it helps modern chip design pipelines move faster, scale further, and operate without compromise.

For a quick overview, check out the Quick Byte video:

Explore the latest Azure NetApp Files SPECstorage® 2020 publications

These two newly released benchmark publications showcase the exceptional performance and scalability of Azure NetApp Files’ large volume breakthrough mode for EDA workloads.

Azure NetApp Files large volume breakthrough mode:
https://www.spec.org/storage2020/results/res2026q2/storage2020-20260227-00147.html

Azure NetApp Files large volume breakthrough mode scale:
https://www.spec.org/storage2020/results/res2026q2/storage2020-20260227-00148.html

Results that Speak for Themselves

This chapter presents the latest benchmark results for Azure NetApp Files in full detail, highlighting the significant performance advantages enabled by large volume breakthrough mode. Through both single and scaled large volume configurations, these results demonstrate the ability to support demanding EDA workloads with exceptional throughput and consistent low latency. The findings underscore Azure NetApp Files’ capability to meet the rigorous requirements of modern chip design pipelines, ensuring reliability and efficiency at every scale.

Single large volume breakthrough mode

The architecture shown in the diagram was specifically designed to generate the load necessary for producing the benchmark results discussed in this section.

The result:

The Azure NetApp Files large volume breakthrough mode configuration reached 2,880 SPECstorage® Solution 2020 EDA_BLENDED JOBS with an overall response time of 0.51 ms.

A single Azure NetApp Files large volume breakthrough mode delivered 20,910 MB/s (19,941 MiB/s) of throughput and 1,296,040 operations per second at peak.

Throughout the iterations, sub-millisecond latency was observed with latency only breaching 1 ms at the very peak.

This level of performance demonstrates how a single large volume deployment can sustain thousands of concurrent EDA workloads – while preserving the latency profile required for simulation, synthesis, and verification tasks.

Large volume breakthrough mode at scale

The architecture shown in the diagram was specifically designed to generate the load necessary for producing the benchmark results discussed in this section. For resource availability reasons, six volumes were distributed across multiple Azure regions and availability zones, though this is not a requirement. Deployments can use any number of volumes, and regional / zonal distribution is optional – only necessary when targeting specific availability or resilience goals.

The result:

The Azure NetApp Files large volume breakthrough mode scale configuration reached 17,280 SPECstorage® Solution 2020 EDA_BLENDED JOBS with an overall response time of 0.60 ms.

At this scale, the aggregate throughput was 125,474 MB/s (119,661 MiB/s), with 7,776,147 operations per second on the benchmark.

Again, throughout the iterations, sub-millisecond latency was observed with latency only breaching 1 ms at the peak.

Even at six times the workload scale, latency remains consistently sub‑millisecond – enabling highly parallel EDA workflows to scale without introducing storage‑induced bottlenecks.

The multi-region/zone configuration was selected for resource availability reasons. This configuration is not a requirement, and deployments can use any number of volumes – by no means limited to six. A configuration can scale to any number of volumes, provided sufficient large volume capacity is available.

Performance that Scales with Your Design Cycles

Across breakthrough mode and breakthrough mode scale configurations, latency remains tightly bounded as workload concurrency increases — indicating that Azure NetApp Files large volume breakthrough mode enables linear scalability characteristics without introducing latency instability under load.

EDA_BLENDED Metric	Large volume breakthrough mode	Large volume breakthrough mode scale	Factor
Job Sets	2,880	17,280	6.00x
Throughput (MB/s)	20,910	125,474	6.00x
Operations/second	1,296,040	7,776,147	6.00x
ORT (ms)	0.51	0.60	1.18x

This predictable performance and scale behavior is critical for distributed EDA environments, where design teams increasingly rely on massively parallel simulation and verification jobs to accelerate time‑to‑tape‑out.

From large volume scale… to breakthrough mode scale

Compared to previously published (non‑breakthrough mode) large volume results from October 2025,, large volume breakthrough mode expands the achievable throughput envelope while even lowering observed overall response times as workload levels increase.

This allows Azure NetApp Files to deliver:

Higher aggregate throughput ceilings
Greater concurrency tolerance
Consistent latency behavior under scaled-out EDA job submission

– all without architectural changes to application workflows.

More Throughput + Consistent Low Latency = More Jobs!

What Storage Performance Means For EDA Velocity

Modern EDA workflows are built around rapid, iterative design loops, where architects and physical designers continuously refine Register-Transfer Level (RTL), run regressions, analyze timing, fix violations, and repeat often thousands of times before tape‑out. At scale, these workflows depend on large compute grids with hundreds or thousands of cores accessing shared storage simultaneously. In this environment, storage latency is not just a performance metric; it directly determines engineering velocity and business outcomes. Azure NetApp Files large volume breakthrough mode delivers cloud‑native storage performance that keeps every core productive, enabling higher simulation throughput, faster iteration cycles, and predictable performance even under extreme parallel load. The benchmark results independently validate how Azure NetApp Files large volume breakthrough mode empowers the most demanding modern EDA workflows.

Ultimately, this improves engineering velocity. Shorter regression cycles enable more iterations per day, higher compute utilization eliminates idle cores, and predictable performance allows teams to confidently push scale without risk. More iterations before tape‑out translate directly into better Power, Performance, and Area (PPA) outcomes and faster time‑to‑market. For semiconductor design organizations, Azure NetApp Files large volume breakthrough mode elevates storage from supporting infrastructure to a strategic enabler – delivering independently validated, cloud‑scale performance purpose‑built for the most demanding EDA workloads.

Storage Performance Impact on Engineering Velocity:

Shorter regression cycles → more design iterations per day
Higher compute utilization → no idle cores or wasted licenses
Fewer job failures → engineers focus on design, not infrastructure
Faster data movement → smoother transitions across design stages

This is why companies investing in cloud‑scale EDA infrastructure such as AMD, Microsoft, and ASML, consistently report faster time‑to‑market and stronger design outcomes.

Learn more

Action required: Kerberos RC4 hardening may affect Azure Files Active Directory Domain Services

grace_kim — Fri, 05 Jun 2026 21:50:11 GMT

A Windows security hardening change beginning in April 2026 updates default Kerberos encryption behavior and may impact customers using Azure Files with Active Directory Domain Services (AD DS) authentication over SMB. If you created Azure Files shares prior to 2023, or chose RC4 encryption for your file shares, you will need to reconfigure to use AES-256 to avoid disruption to file share access. This is in accordance with the updated security posture and recommendation from Windows CVE-2026-20833.

Background

Azure Files uses Kerberos authentication for identity-based access when integrated with on-premises Active Directory Domain Services (AD DS). AES-256 Kerberos encryption has been supported since AzFilesHybrid module v0.2.2, and it has been the default since v0.2.5. Historically, RC4 was the only supported option until AES-256 support was added. This is a Windows platform security hardening change; Azure Files service behavior is not being modified.

You may be impacted if:

You use Kerberos-based SMB access to Azure Files with AD DS authentication, and
Kerberos encryption settings are RC4-only or unset (null) for relevant AD objects, service accounts, or computer accounts associated with Azure Files authentication.

When will this happen:

April 2026 – July 2026: Install the Windows security update and validate access. Domain controllers will default to issuing AES-256 tickets when msDS-SupportedEncryptionTypes is not explicitly set.
After July 2026: Manual rollback is removed. If you have not migrated to AES-256 by then, Kerberos-based SMB access to your Azure Files shares may fail.

What you should do now:

Find out if you are impacted, run the following PowerShell command on a domain-joined machine, with read access to AD. This identifies storage accounts that use Azure Files with AD DS authentication but have not been upgraded to AES-256 or follow the detection steps in aka.ms/rc4azurefiles:

Get-ADObject ` -LDAPFilter "(&(servicePrincipalName=*.file.core.windows.net)(!(msDS-SupportedEncryptionTypes=*)))" -Properties servicePrincipalName, msDS-SupportedEncryptionTypes | Select-Object Name, ObjectClass, servicePrincipalName, msDS-SupportedEncryptionTypes

Update configurations to support and prefer AES256-based Kerberos ticket encryption.
Validate end-to-end SMB authentication and application access to Azure Files shares.
Run klist purge from an elevated command prompt to clear any cached Kerberos tickets that still use RC4.
Remount the Azure file share.

For any questions, please reach out to the team at azurefiles@microsoft.com

Resources:

Azure Files documentation on this change
Read the full Windows hardening guidance: How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.
Learn about RC4 usage in Windows and its risks: Detect and remediate RC4 usage in Kerberos.
Learn more about the related vulnerability: CVE-2026-20833.
Windows Server Blog: Beyond RC4 for Windows authentication

Modernizing Azure Virtual Desktop with Nerdio and Azure Files

Vybava_Ramadoss — Mon, 04 May 2026 16:05:17 GMT

Coauthored with Nerdio

Organizations adopting Azure Virtual Desktop (AVD) typically begin with small pilot deployments that perform well under limited load. As these environments scale to hundreds or thousands of users, a consistent set of challenges emerges. At the center of that shift is the user profile layer. FSLogix profile containers—stored on file shares—sit directly on the critical path of the user experience. During peak periods such as login storms, profile attach latency becomes a primary determinant of sign-in performance. At the same time, identity dependencies, storage configuration complexity, and cost management introduce variability across environments. What worked in a pilot often becomes more difficult to manage consistently at scale.

Common challenges include:

Performance variability during peak concurrency
Complex identity configurations for SMB access
Configuration drift across environments
Cost inefficiencies from peak-based provisioning

At enterprise scale, these issues converge at the storage and identity layers—making them central to both user experience and operational efficiency.

Nerdio: simplifying how AVD is deployed and operated

Nerdio Manager (available as Nerdio Manager for Enterprise and Nerdio Manager for MSP) is a deployment, management, and auto-scaling platform for Azure Virtual Desktop (AVD) with capabilities such as desktop image management, performance monitoring, and user session control to eliminate the need for complex scripting and speed up responses to end-users. Nerdio Manager helps organizations deploy and operate AVD environments in a more consistent, repeatable way. Rather than treating compute, storage, and identity as separate workflows, Nerdio integrates these components into a single operational model. Storage provisioning, permissions, and FSLogix configuration are handled as part of host pool deployment and scaling. This reduces coordination overhead, minimizes configuration drift, and keeps storage aligned with how environments grow.

This view shows how Nerdio brings users, host pools, and storage into a single control plane—ensuring storage is configured as part of deployment, not after.

Azure Files: enabling performance and identity at scale

Azure Files provides the foundational storage layer for FSLogix profile containers in many AVD environments. Because profiles attach at sign-in, storage performance directly impacts user experience.

Provisioned v2: performance without over-provisioning

Azure Files Provisioned v2 decouples performance (IOPS and throughput) from capacity. Previously, higher performance required over-provisioning storage. With Provisioned v2, organizations can align performance directly to workload needs. This is especially important for FSLogix, where login storms create short bursts of high IOPS demand even when data volumes are modest. The result: better cost efficiency and more predictable performance.

“We’ve been early adopters of Nerdio and consistently see meaningful Azure cost optimization… With Azure Files Provisioned v2, the decoupling of quota and IOPS… gives us precise control over performance and cost.” — David Wasserman, Chief Value Officer, FlexibleIT.com

Entra ID authentication: simplifying identity architecture

Azure Files supports Microsoft Entra ID authentication for SMB, enabling a cloud-native identity model.

This eliminates the need for domain infrastructure used only for storage access, resulting in:

Reduced infrastructure overhead
Simpler networking
Lower operational burden
Alignment with Zero Trust

These capabilities are already in use in Nerdio Manager for MSP environments managing multi-tenant deployments, and are being extended to Nerdio Manager for Enterprise in Q3 CY26 to enable the same cloud-native model within enterprise environments

This highlights how provisioning, monitoring, scaling, and identity are handled as part of a unified system instead of fragmented tasks.

Operationalizing storage at scale, why this matters for enterprises

Enterprise AVD environments operate under fundamentally different constraints. User populations are larger and more concentrated, compliance requirements are stricter, and tolerance for performance variability is significantly lower.

In practice, these pressures converge at the storage layer.

For enterprise customers, the goal is not automation itself—it is better user experience, lower cost, and predictable operations.

Faster, more consistent deployments. Storage is configured alongside compute, reducing dependency on separate teams and minimizing drift.
Lower cost without sacrificing peak performance. Capacity and performance align with actual demand instead of peak assumptions.
More predictable sign-ins during login storms. Standardized configuration reduces bottlenecks during high concurrency.
Audit-ready governance by default. RBAC, snapshots, backup, and data protection policies are applied consistently across environments.

Get started

At scale, Azure Virtual Desktop is as much about storage and identity as it is about compute. Azure Files plays a central role in determining sign-in performance, user experience, and cost efficiency. With Provisioned v2 and Entra ID authentication, organizations can move toward a more predictable and cloud-native model. Nerdio builds on this foundation by integrating storage and identity into a unified AVD deployment and operations workflow. Get started with Nerdio today.

AHEAD helps us launch the Strategic Azure Storage Services Partner Program

karautenMSFT — Fri, 01 May 2026 00:49:28 GMT

Authors:

Aung Oo, Vice President Azure Storage Product Management

Parker Leavitt, Partner Account Manager, AHEAD

Special thanks to:

Michael Johnson, Vice President, Cloud, AHEAD

AHEAD background

AHEAD was formed in 2007 and possesses deep expertise in Infrastructure, Cloud Platforms, AI, Analytics, Networking, Storage, Security and many more technical disciplines. 80% of AHEAD’s employees are engineers who help customers with the assessment of their needs to design optimal solutions and through implementation of complex application and infrastructure deployments. Headquartered in Chicago, IL, AHEAD has locations worldwide and is ready to assist with your most complex Azure projects. They hold over 1,000 Microsoft certifications and 4 Advanced Specializations.

Valued collaboration

AHEAD has been a key advisor to Azure Storage throughout the design and build of our Channel strategy. As a premier Microsoft Cloud and AI Partner, and with decades of Storage expertise, AHEAD helped us to create the Learning Path channel partners will need to complete to qualify as a Strategic Azure Storage Services Partner (SASS). SASS Partners have been validated by us to possess the skills to offer consulting, design, implementation, and migration services to Azure and ISV Storage services.

What can you expect?

AHEAD brings their history of infrastructure expertise to Azure Storage customers through a catalog of services that make it possible to select the optimal solution to ensure the ideal blend of price, performance, and resiliency.

Assessment

What are you doing to prepare for the industry wide memory shortage? How well do you understand your datasets? What are your performance requirements? Are there features you are paying for and not using? When was the last time that directory hosting the “Super Important Project” files was accessed? Is there mission critical data hiding that you should be leveraging to fuel Enterprise AI Agents? Is an Azure Storage Service the best fit for your data, or is it better to migrate it to one of our Storage ISV services?

AHEAD provides Microsoft-funded assessments that deliver data-driven guidance to help you align your application and data set needs with the ideal storage service(s) on Azure. We have long advocated that the best solution is the one that meets your requirements both today and in the future. AHEAD can help you get there.

Migration

After gaining insight into your data estate, AHEAD has the experience to help you migrate safely with best-of-breed solutions. Whether offline migration with Data Box or online over the network with Storage Mover or one of our validated ISVs like Komprise, Cirrus Data, or Cirata, AHEAD can help you move your data to an Azure Storage service like Blob Storage, Files, Elastic SAN, or NetApp Files – or one of our ISV Partners like Nasuni and Pure Storage. You can find our full list of validated partners on Microsoft Learn.

Azure Storage ISV Strength

An important reason we chose to onboard AHEAD as our first Strategic Channel Partner was the large crossover in mutual ISV relationships they possess, and their proven skills with each. You can view AHEAD’s full list of partners, including Nasuni, NetApp, Everpure, Commvault, Veeam, Rubrik, and Dell on their website. Our recent engagements with AHEAD and Nasuni are a great example of AHEAD’s depth. They were able to quickly determine Nasuni as the best fit for a customer who required a single centralized Azure-based repository for their data that could then be accessed within Azure and multiple remote locations simultaneously.

AHEAD has shown us that across their portfolio of ISVs, they can help you implement best-of-breed ISV services that include solutions in:

Air Gap Business Continuity
VMware Modernization
Storage Modernization
Cloud Scale Analytics
AI Dataset Curation

How can you move forward?

Do you need help understanding your data estate? Could you use expertise selecting the ideal service in Azure to host your data? Reach out to the AHEAD Azure team at info@ahead.com or via their Rapid Assess offer on Microsoft Marketplace and get started today!

Strategic Azure Storage Services Partner

In coming months, you will see our list of SASS Channel Partners expand, but we could not be more grateful to AHEAD for being a not only a pioneer, but a trusted advisor. Their commitment to Azure and Azure customers has made an impact that will benefit our customers worldwide.

Prefix-scoped access for User Delegation SAS is now generally available for Azure Blob Storage

despindola — Wed, 06 May 2026 20:01:06 GMT

We would like to share that prefix-scoped access for User Delegation SAS for Azure Blob Storage is generally available in all Azure regions.

SAS tokens for Blob Storage have historically supported two levels of scope: container and individual blob. With this release, you can now scope access to a prefix or virtual directory within a container, granting access to all blobs beneath the path.

This is especially valuable for applications that organize data by tenant, workspace, project, or department within a shared container. Instead of granting access to an entire container or generating many blob-level tokens, you can now issue a single SAS token scoped to a set of blobs through a prefix.

For example, if a container has these blobs:

contoso/sales/Q1-report.csv

contoso/sales/Q2-report.csv

contoso/invoice.pdf

A SAS token scoped to the prefix contoso/sales would grant access only to the two sales reports. This simplifies manageability by not having to generate multiple blob scoped tokens which significantly reduces overhead to manage permissions for large scale data storage estates. In addition, it helps customers provide more scoped permissions to a certain set of blobs rather than broader permissions at a container level.

Prefix-scoped access is supported for both Blob and Data Lake storage accounts.

As a best practice, we recommend using Entra ID with RBAC or ABAC for least privilege access. If you need to use SAS for your use cases, we recommend using user delegation SAS and prefix-based scoping is a good option to consider for more scoped permissions for a certain set of blobs.

Pricing and Availability

There is no additional cost for prefix-scoped access for user delegation SAS. Pricing is based on standard transaction costs for your storage account type. To learn more, see Azure Storage Pricing. 

Prefix-scoped access for user delegation SAS is available in all Azure regions.

How to generate a prefix-scoped SAS

To generate and use a prefix-scoped SAS:

Identify the prefix (or virtual directory) you want to authorize.
Follow the steps in the documentation to create a prefix-scoped SAS for user delegation SAS.
Use the SAS token with your application.

Notes

Support for prefix-scoped access parameters is available with authorization version 2020-02-10 or later via REST API and .NET Blob SDKs starting with version 12.29.0-beta.1 and newer.
The semantics for prefix scope (sr=d) are similar to container scope (sr=c), except that access is restricted to a prefix. When creating a prefix-scoped SAS, you must specify the signedDirectoryDepth (sdd) to indicate how many directory levels from the container root to the specified directory. For example, to grant access to dir2 on path container1/dir1/dir2, set the directory depth (sdd) = 2 to indicate the SAS is scoped to dir2 and everything beneath it.
Below are .NET SDK and REST API examples for reference.

.NET SDK Sample Definition

BlobSasBuilder blobSasBuilder = new BlobSasBuilder( permissions: BlobContainerSasPermissions.All, expiresOn: Recording.UtcNow.AddDays(1)) { BlobContainerName = test.Container.Name, BlobName = blobName, IsDirectory = true, }; // Test using same name as SAS BlobUriBuilder blobUriBuilder1 = new BlobUriBuilder(test.Container.Uri) { BlobName = blobName, Sas = blobSasBuilder.ToSasQueryParameters(Tenants.GetNewSharedKeyCredentials()) }; AppendBlobClient appendBlobClient1 = new AppendBlobClient(blobUriBuilder1.ToUri(), GetOptions()); await appendBlobClient1.CreateAsync(); // Test using SAS name + suffix BlobUriBuilder blobUriBuilder2 = new BlobUriBuilder(test.Container.Uri) { BlobName = blobName + "/test", Sas = blobSasBuilder.ToSasQueryParameters(Tenants.GetNewSharedKeyCredentials()) }; AppendBlobClient appendBlobClient2 = new AppendBlobClient(blobUriBuilder2.ToUri(), GetOptions()); await appendBlobClient2.CreateAsync();

REST API Sample Request

GET https://myaccount.blob.core.windows.net/mycontainer

?restype=container

&comp=list

&prefix=dir1/dir2/

&sr=d

&sdd=2

&sp=rl

&sv=2024-11-04

&se=2026-04-22T06:00:00Z

&skoid=<signed-oid>

&sktid=<signed-tid>

&skt=2026-04-22T00:00:00Z

&ske=2026-04-22T08:00:00Z

&sks=b

&skv=2024-11-04

&sig=<signature>

Next Steps

For a deeper dive, explore these resources:

Help and Support

If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, create a support request:  

For Issue type, select Technical.  
For Subscription, select your subscription.  
For Service, select My services.  
For Service type, select Blob Storage.  
For Resource, select the Azure resource you are creating a support request for.  
For Summary, type a description of your issue.  
For Problem type, select Authentication and Authorization .
For Problem subtype, select Issues using Shared Access Signature (SAS Token).

Secure, Keyless Application Access with Managed Identities - Now GA in Azure Files SMB

Priyanka-Gangal — Mon, 20 Apr 2026 17:57:56 GMT

As enterprises modernize applications and strengthen their security posture, identity is central to how applications access shared storage. Traditional identity models relying on account keys, stored credentials, or domain‑joined infrastructure add operational overhead and introduce security risks such as credential leakage, lack of identity attribution, and excessive privilege if shared keys are compromised. Today, we are excited to announce the General Availability (GA) of Managed Identity support for Azure Files over SMB, enabling applications and virtual machines to securely access Azure Files without secrets, passwords, or key distribution.

Managed Identity support enables customers to meet modern enterprise security standards without reliance on storage account keys, streamlining how organizations securely enable file‑based application access and reducing the operational overhead of filing internal exceptions. New storage accounts can support secure, identity‑based SMB access out of the box, while existing deployments can get secure by enabling Managed Identity authentication.

From web application workloads such as WordPress, to databases on Azure Kubernetes Service (AKS), to CI/CD pipelines, applications require secure access. In a world where security is foundational, continued reliance on key-based access conflicts with Zero Trust principles and least privilege access.

What’s New In GA

AKS Workload Identity Support

AKS Workload Identity (preview) extends the traditional managed identity model for Kubernetes by shifting the identity from the node to pods. Instead of inheriting the identity of the underlying cluster, each Kubernetes pod can use its own federated identity, mapped directly to a Microsoft Entra ID principal.

This feature enables:

Pod-level identity isolation, rather than cluster-level
Least-privilege access with secure RBAC
Seamless scaling and redeployment, without identity reconfiguration
No secrets, no key rotation, no credential injection

When combined with Azure Files over SMB, Workload Identity allows AKS workloads to access shared file storage securely and natively per pod, using the same identity-driven model as cluster level managed identities. Now available with AKS 1.35, for customers specifically in the financial services industries, AKS Workload Identity enables per‑application, least‑privilege access to Azure Files without credentials, improving isolation and auditability. This allows regulated, stateful workloads to run securely on AKS while meeting strict compliance and regulatory requirements.

Co-existence of Application Identities and end-user identity access

Azure Files now enables both Managed Identity and end‑user access on the same storage account, with users and applications independently authenticated via Entra ID and authorized through a shared permissions model.
This unified access model eliminates the need for duplicate storage or credentials, enabling secure collaboration, troubleshooting, and automation on shared data without compromising governance or compliance.

This supports scenarios such as:

Developers accessing the same file share as an application for debugging
Admins managing content used by automated workflows
Hybrid environments with user-driven and app-driven access

Simplified Storage Account enablement via the Azure portal

We have now added a dedicated Managed Identity property that makes enabling identity‑based SMB access simple and transparent via the Azure portal for new as well as existing storage accounts. With a single configuration at the storage account level, customers can allow applications to authenticate to Azure Files using Managed Identities. This portal experience supports incremental adoption, making it easy to modernize authentication while maintaining compatibility with existing user access and governance models.

Get Started with Managed Identities with SMB Azure Files

Start using Managed Identities with Azure Files today at no additional cost. This feature is supported on HDD and SSD SMB shares across all billing models. Refer to our documentation for complete set-up guidance.

Whether provisioning new storage or enhancing existing deployments, this capability provides secure, enterprise‑grade access with a streamlined configuration experience.

For any questions, reach out to the team at azurefiles@microsoft.com.

Azure Storage Blog articles

More EDA Job Sets per Volume: Azure NetApp Files Raises the Performance Bar

Table of Contents

Introduction

New benchmark proof with large volume breakthrough mode

The same volume, nearly double the performance

The scaling paradigm has not changed. The scale unit has.

And your data does not have to move first

Already in the flow

Bringing it together

Learn more

Dell Managed PowerScale for Microsoft Azure is now generally available

A Dell-managed experience in Azure

Supporting unstructured data at scale

Availability and next steps

Generally Available: Restrict usage of user delegation SAS to an Entra ID identity

Accelerated AI & Analytics workload on Azure Blob Storage: Up to 25x faster List Blobs operations

Why we built this

Faster, more efficient, listing results with lower client CPU utilization

rclone accelerates listing of 100K objects from 24 seconds to 1.1 seconds

How to get started

Limitations

References

Accelerate Inference on AKS with Azure Blob Storage and NVIDIA Dynamo

Accelerate Model Cold Starts with Dynamo ModelExpress

Extend KV Cache Offloading to Azure Blob

Accelerate Your Inference Workloads Today

Acknowledgements

Optimize Oracle workloads on Azure with Azure NetApp Files

Table of Contents

Introduction

Azure NetApp Files Advancements Overview

Azure NetApp Files Advancements in Detail

Flexible service level capacity pools

Oracle Direct NFS

Application volume group for Oracle

Availability zone volume placement

High availability

Standard network features

Simplified deployment

Optimal volume placement

Scalability and flexibility

Integrated data protection

Using application volume group for Oracle

VM IO throttling

Automatic Storage Management (ASM)

Migration assistant

Short-term clones

Storage with cool access

Sizing Your Volume Deployment for Oracle

Using Azure NetApp Files as backup target and test/dev for Oracle AI Database@Azure

Summary

Learn more

Announcing General Availability of Client-Side Data Integrity Protections in Azure Blob Storage

Azure’s Commitment to Data Integrity

Extending integrity to your client applications

Benefits of CRC64-NVME

Performance

Usage

Availability

Comparison to MD5

Next Steps

Boost performance with NFS nconnect on Azure NetApp Files datastores for Azure VMware Solution

Table of contents

Introduction

What is nconnect

Why it matters

How it works

Reading the numbers: what the Azure VMware Solution datastore data shows

What this unlocks for Azure VMware Solution with Azure NetApp Files

Use cases

Conclusion

Next steps

Learn more

Bringing Enterprise File Data to Users with Azure NetApp Files, Microsoft Foundry, and M365 Copilot

Table of Contents

Introduction

Why the user experience layer matters in enterprise AI

Microsoft Foundry: Orchestrating enterprise AI agents

The Copilot agent as the enterprise user experience