Cloud Native Identity with Azure Files: Entra-only Secure Access for the Modern Enterprise
Azure Files introduces Entra only identities authentication for SMB shares, enabling cloud-only identity management without reliance on on-premises Active Directory. This advancement supports secure, seamless access to file shares from anywhere, streamlining cloud migration and modernization, and reducing operational complexity and costs.Simplifying file share management and control for Azure Files
Azure Files makes it easy to run your file shares in the cloud without the overhead of on-premises file servers or NAS devices. Until now, managing file shares in Azure has also meant managing storage accounts, an extra layer of management that brings along capacity planning, shared settings, and scaling challenges. To simplify this experience, we're excited to announce the preview of a new file share-centric management model for Azure Files. This shift means you can focus on just the part you care about - creating and using file shares with your applications, without the overhead of storage account management. With the new management model, you can now: Deploy files shares using easy automation as a top-level resource. Configure granular secure access by share. Monitor and scale per share with added flexibility. Leverage simplified transparent pricing with provisioned v2. Let's look at how this works. A new way to manage file shares With the Microsoft.FileShares management model, file shares are now top-level Azure resources, just like virtual machines, disks, or virtual networks. This allows file shares to seamlessly integrate with Azure's ecosystem of tools, including templates, policies, tags, and cost management. By having file shares as top-level Azure resources, you no longer need to puzzle over which storage account settings actually apply. Each file share comes with only the settings that matter, so you can manage it directly without extra layers of complexity. The result is a simpler, more intuitive experience where you stay focused on your workload, not the infrastructure underneath. Per share settings unlock a new level of granular control: each file share can now have its own networking and security rules, tailored to the workload it supports. The result is isolation and flexibility: security without compromise. Provisioning and billing are also simplified in this mode, as you no longer need to capacity plan files against the storage, IOPS, and throughput limits of the storage accounts hosting them. Each file share now scales independently up to Azure Files' limits, so growth in one file share doesn't impact any others. And because Azure billing always works on a per resource basis, every file share stands on its own as a separate billable item. That makes costs easy to track, allocate, or charge back to the right project, department, or customer. Combined with the provisioned v2 billing model for Azure Files, the result is transparent pricing: you provision exactly what you need for each share and can attribute the cost with precision. In this first release, you'll be able to create and manage NFS file shares on SSD, with support for SMB file shares planned in the future. Built to scale Azure Files supports a diverse customer base, ranging from small businesses managing a few shares to large enterprises deploying thousands. It accommodates both traditional file share workloads with long-lived persistent data and dynamic container workloads that provision and decommission file shares frequently. No matter the scenario, our goal is the same: Azure Files should adapt to your workload, not the other way around. These principles are baked directly into the new model, ensuring that users do not need to create additional subscriptions due to management limitations, and that sufficient scalability and performance are provided to meet demanding workloads. In preview, you can create up to 1,000 file shares per subscription per region. But raw resource counts don't mean much if the management service can't keep pace - just as important, the new model significantly raises the management service limits compared to the storage account model. For most customers, this makes management throttling much less likely, even at scale (see Azure Files scale targets for information on both Microsoft.FileShares and Microsoft.Storage request limits). As we work toward general availability, we plan to further increase both resource and request limits to help customers operate at scale without running into throttling or needing to shard file shares across multiple subscriptions. Speed matters just as much as scale, and in preview, provisioning a file share has typically been faster than provisioning through a storage account. In our in-house testing, we observed file shares deployed using the new model were about ~2x faster than classic file shares, and we intend to continue to improve those numbers as we work towards general availability. Get started today You can start creating file share resources today in preview, which is open to everyone. Just go to the Azure portal, search for "file shares" and click "+ Create": A few important notes about what's not yet available in preview: The new management model is only supported on NFS and not SMB shares (on either SSD or HDD) for now. NFS file shares using customer managed keys (CMK), file share soft-delete, and AKS integration via the CSI driver are not yet available, but are planned for general availability. The initial preview is available in a limited set of regions, however we will expand this list as we work towards general availability. See regional availability for a complete list. To learn more, please see: Planning for an Azure Files deployment How to create a file share (Microsoft.FileShares) Azure Files scale targets
Reduce latency and enhance resilience with Azure Files zonal placement
We are pleased to announce the General Availability of zonal placement for Azure Files Premium LRS in select regions. Zonal placement enables you to pin Azure Files storage accounts to a specific Availability Zone within a region — giving you better control over data locality, resilience, and lower latency for your workloads. Benefits of zonal placement Azure Files provides both local-redundant storage (LRS) and zone-redundant storage (ZRS) options today. ZRS is leveraged for workloads that require storage-level replication across zones. For applications using Azure Files Premium LRS with application-level replication, customers can now pin storage resources to a specific Availability Zone to co-locate storage with compute resources like Virtual Machines (VMs). Zonal placement can be leveraged with both SMB and NFS shares, making it ideal for latency sensitive Windows and Linux workloads including databases, enterprise platforms, DevOps tools, and line-of-business applications. Leveraging zonal placement With zonal placement, you can Reduce latency: Choose the same availability zone for storage and compute resources, optimizing latency-sensitive workloads and reducing cross-zone network latency by 10-40%. Isolate failure domains: Limit exposure to potential zonal outages, by aligning the compute and storage resources of your application in a single zone. Design for zone-aware high availability: Build resiliency with application-level replication across compute and storage resources in each zone. To configure zonal placement for your workload: Select a specific Availability Zone when creating a new Azure Files Premium LRS storage account or update an existing Azure Files Premium LRS storage account to be Availability Zone aware. Allocate your compute resources in the same zone as your premium storage account zone. Get started today Start leveraging zonal placement for Azure Files Premium LRS today. Zonal placement is available in select Azure regions that support Premium LRS and Availability Zones; for the latest list of supported regions, please refer to the zonal placement for Azure File Shares | Microsoft Learn. Whether you’re provisioning new storage or enhancing existing deployments, Zonal placement empowers you to align your compute and storage resources within the same Availability Zone to minimize latency and control availability. Build more efficient, reliable, and zone-aware solutions with Azure Files—your data is ready for what’s next. For any questions, please reach out to the team at azurefiles@microsoft.com.Introducing Cross Resource Metrics and Alerts Support for Azure Storage
Aggregate and analyze storage metrics from multiple storage accounts in a single chart. We’re thrilled to announce a highly requested feature: Cross Resource Metrics and Alerts support for Azure Storage! With this new capability, you can now monitor and visualize metrics across multiple storage accounts in a single chart and configure alerts across multiple accounts — within the same subscription and region. This makes managing large fleets of storage accounts significantly easier and more powerful. What’s New Cross Resource Metrics Support Visualize aggregated metric data across multiple storage accounts. Break down metrics by individual resources in a sorted and ordered way. Cross Resource Alerting Support Create a single alert rule that monitors a metric across many storage accounts and triggers an action when thresholds are crossed on any resource. Full Metric Namespace Support Works across Blob, File, Table, and Queue metric namespaces. All existing storage metrics are supported for cross resource visualization and alerting. Why This Matters Centralized Monitoring for Large Environments Manage and monitor dozens (or hundreds) of storage accounts at once with a unified view. Fleet-wide Alerting Set up a single alert that covers your whole storage fleet, ensuring you are quickly notified if any account experiences performance degradation or other issues. Operational Efficiency Helps operations teams scale monitoring efforts without needing to configure and manage separate dashboards and alerts for each account individually. How To Get Started Step 1: Create a Cross Resource Metrics Chart Go to Azure Monitor -> Metrics. Scope Selection: Under Select a scope, select the same Metric Namespace (blob/file/queue/table) for multiple Storage Accounts from the same Subscription and Region. Click Apply. In the below example, two storage accounts have been selected for metrics in the blob metric namespace. Configure Metric Chart: Select a Metric (e.g., Blob Capacity, Transactions, Ingress) Aggregation: By default, a Split by clause on ResourceId is applied to view individual account breakdowns. Or view aggregated data across all selected accounts by removing the Split by clause. Example As another example, lets monitor total transactions across storage accounts on the Hot tier to view aggregate or per-account breakdown in a single graph. From the same view, select the Transactions metric instead. Select 5 storage accounts by using the Add Filter clause and filtering by the ResourceId property. Add another filter and select a specific tier, say Hot. This will show aggregated transactions on data in the Hot tier per minute across all selected storage accounts. Select Apply Splitting and select ResourceId to view an ordered breakdown of transactions per minute for all the Storage accounts in scope. In this specific example, only 4 storage accounts are shown since 1 storage account is excluded based on the Tier filter. Step 2: Set Up Cross Resource Alert Rules Click on New alert rule from the chart view shown above in order to create an alert that spans the 5 storage accounts above and get alerted when any account breaches a certain transactions limit over a 5 minute period. Configure required values for the Threshold, Unit and Value is fields. This defines when the alert should fire (e.g., Transactions > 5000) Under the Split by dimensions section, ensure that the Microsoft.ResourceId dimension is not included. Under Actions, attach an Action Group (Email, Webhook, Logic App, etc.). Review and Create. Final Thoughts Cross Resource Metrics and Alerts for Azure Storage makes monitoring and management at scale much more intuitive and efficient. Whether you're overseeing 5 storage accounts or 500, you can now visualize performance and respond to issues faster than ever. And you can do it for metrics across multiple storage services including blobs, queues, files and tables! We can't wait to hear how you use this feature! Let us know your feedback by commenting below or visiting Azure Feedback.
General Availability of Azure Backup vaulted support for Azure Files Premium (SSD) shares
Whether you're an enterprise IT administrator or a cloud-native developer, ensuring data protection and resiliency is non-negotiable, especially when running mission-critical workload on Azure Files Premium (SSD) shares. We’re thrilled to announce the General Availability of vaulted backup support with Azure Backup for Azure Files Premium (SSD) shares. This new capability brings enterprise-grade data protection to production scale workloads running on Azure Files SSD. IT professionals and decision-makers can now leverage Azure Backup to safeguard SSD premium file shares with the same ease and robustness previously available for standard (HDD) shares, closing a key gap in Azure’s data protection offerings. This release of Azure Backup introduces support for Premium SMB file shares, providing immutable and offsite backups designed to defend against ransomware, accidental deletion, and regional outages. This solution offers long-term retention, granular restores, and geo-redundant storage vault for cross region backup and restore, all of which can be centrally managed via Azure Backup. Some customers have utilized this capability since its preview. Below is a statement from Swisscom regarding this integration. Implementing Azure Backup for our premium file shares has significantly enhanced our data protection strategy. With nearly 7 TB of critical data securely backed up, we now have peace of mind knowing our information is resilient against accidental deletion and ransomware threats. The seamless integration and scalability of Azure Backup make it an essential part of our cloud infrastructure. --Swisscom Azure Backup capabilities enabled for Premium File share Cross-Region Recovery for Resilience Across Azure Regions One of the standout features of using Azure Backup with a Recovery Services vault is the ability to leverage Geo-Redundant Storage (GRS) for your backups. Cross-Region Recovery refers to the capability to restore your data in an alternate Azure region if the primary region becomes unavailable. This is an essential part of disaster recovery planning, especially for scenarios like region-wide outages or natural disasters Built-In Resiliency with 3-2-1 Backup Rule Azure Backup’s approach to protecting Premium Files inherently aligns with the industry-standard “3-2-1” backup rule, a best practice for ensuring data durability and recoverability. By configuring a Geo-Redundant Storage (GRS) vault, Azure Backup ensures, 3 copies of your data are maintained and stored across 2 different types of storage locations with at least 1 copy offsite, in a remote Azure region Security, Ransomware Protection, and Compliance Imagine an organization’s file share is hit with ransomware, with Azure Backup you have an untouched copy in the recovery services vault isolated from primary and snapshots in case malware dint delete them. In such a scenario, Azure Backup enables you to restore the last clean recovery point of the file share (either overriding the share or to a new location for analysis), and resume operations without paying any ransom. This has saved organizations millions of dollars and is a fundamental pillar of a good cyber recovery strategy Let’s now look at few scenarios where this integration may be applied. Profile data storage in VDI setups Azure Files SSD (Premium) is the recommended storage backend for FSLogix profiles in Azure Virtual Desktop (AVD), Citrix, and VMware Horizon environments. It enables persistent user profile storage and supports dynamic application delivery via App Attach. Vaulted backups ensure profile data is protected against accidental deletion and ransomware threats Application Storage Premium SMB shares are used to support Windows-based applications such as SQL Server, ERP systems, and custom line-of-business apps that rely on Win32 or .NET file system APIs. Azure Backup provides secure, off-site protection for these critical workload Cloud-Native Workloads Customers migrating from legacy NAS solutions to Azure Files benefit from cloud-native storage with built-in backup and DR capabilities. This is especially valuable for SMB workloads running in containerized environments like Azure Kubernetes Service (AKS) Hybrid Scenarios with Azure File Sync Azure File Sync enables caching and syncing between on-premises servers and cloud shares. Vaulted backups extend protection to such hybrid environments, ensuring data durability and compliance across distributed infrastructures Getting started Here are three simple steps to help you get started with configuring vaulted backup for Azure File shares: Create a Recovery services vault: A vault is a management entity that stores backups and allows you to access and manage them. Create a backup policy: Backup policy enables you to configure the frequency and retention of backups based on your business requirements. Select the storage account and File shares to backup: You can choose to back up all File shares or select specific File shares from the selected storage account depending on the criticality of the data they contain. Go ahead and select vault tier in your backup policy to improve the security posture of Azure Files data in these regions with a native, managed and secure offsite backup solution, strengthening business continuity and disaster recovery strategy for mission critical applications. Learn more about vaulted backup for Azure file share here. Resources for further reading Azure Files documentation | Microsoft Learn, secure, and serverless enterprise-grade cloud file shares. Azure Files Backup Overview: “About Azure Files backup – Azure Backup” – explains the architecture, benefits, and costs in detail Backup Support Matrix: Lists supported scenarios and limits for Azure Files backup. Azure Backup pricing– for the latest costs of protected instances and storage, and the Azure Pricing Calculator for scenario-based estimatesLower costs and boost flexibility with Azure Files provisioned v2
For enterprise IT professionals or startup developers alike, cost efficiency for file storage is top of mind. Whether you're running mission-critical databases, production scale applications like SAP, or cloud native applications using file storage on AKS, your storage infrastructure should adapt to your workload - not the other way around. To bring this flexibility to your hands, we introduced the provisioned v2 model for the HDD (standard) media tier in 2024. Today, we are excited to announce that we're extending the provisioned v2 model to the SSD (premium) media tier. Provisioned v2 is designed to give you more control, better performance alignment, and significant cost savings across a wide range of customer scenarios - by decoupling performance from capacity, lowering the minimum share size to 32 GiB, and increasing the maximum share size to 256 TiB. With provisioned v2 you can dynamically scale up or down your file share capacity or performance as needed without any downtime based on your workload pattern. Right-sized performance for every workload Whether you are running general purpose file shares, DevOps tooling, AI workflows or databases, you can benefit from leveraging the provisioned v2 model. Here are some examples: Database workloads such as SQL Server, Oracle®, MongoDB, and enterprise platforms like SAP and EPIC require high IOPS and throughput but minimal storage. With provisioned v2, you can secure needed performance without excess storage, resulting in substantial cost savings. Containerized workloads, like Azure Kubernetes Service (AKS), often use very small file shares to achieve shared storage between volumes. With provisioned v2, we've decreased the minimum share size from 100 GiB to 32 GiB and have enabled you to provision just the minimum IOPS and throughput that's included for free. This means that the minimum file share cost in Azure Files is going from $16 / month to just $3.20 / month - an 80% cost savings! Workloads that require fast fetch of infrequently used data, like media files, where the storage workload requires IOPS/throughput occasionally but requires the low latency upon retrieval that you can only get on SSD storage media. With provisioned v2, we've increased the maximum share size from 100 TiB to 256 TiB, enabling larger than ever file shares on Azure Files. And the flexible provisioning afforded by provisioned v2 enables you to dramatically decrease bundled IOPS/throughput to match the archive's requirements. Let's take a deeper look at these savings with some sample workloads: Workload scenario Provisioned v1 Provisioned v2 Cost savings Workload using defaults for IOPS and throughput 10 TiB storage, ~13K IOPS, ~1.1 GiB / sec throughput $1,638.40 / month $1,341.09 / month 18% Relational database workload 4 TiB storage, 20K IOPS, 1.5 GiB / sec throughput $2,720 / month $925.42 / month 66% Hot archive for multimedia 100 TiB storage, 15K IOPS, 2 GiB / sec throughput $16,384.00 / month $10,641.93 / month 35% To learn more about how to compare your costs between the provisioned v2 and provisioned v1 models, see understanding the costs of the provisioned v2 model. All pricing comparisons are shown using the West US 2 prices for locally redundant storage (LRS). Top reasons to give provisioned v2 a try If you haven't looked at Azure Files before, now is the best time to get started. Here's why you should look at making the move to Azure Files with provisioned v2 SSD: Affordable, with low entry costs starting at just $3.20/month. Flexible and customizable to fit a wide range of requirements. Easy to understand and predictable pricing. Support for high IOPS and low latency performance, ideal for performance-critical applications that require sustained throughput and rapid data access. Support for unpredictable or burst-heavy usage patterns, ensuring smooth performance under variable demand. Scalable sizing options, with SSD file shares ranging from 32 GiB to 256 TiB - well-suited for workloads with smaller footprints. How it works With the provisioned v2 model, IOPS and throughput are recommended to you based on the amount of provisioned storage you select, however this recommendation is completely overridable by you. If your workload needs more IOPS or throughput than the default recommendations, you can provision more without having to provision a bunch of extra storage. And if your workload needs less than the default recommendation, you can decrease the provisioned IOPS and throughput all the way down to the minimums for a file share. The best part of this is that you don't have to get this right on file share creation: if you don't know what your performance requirements are or your workload's patterns change over time, you can dynamically scale up or down your file share's provisioning as needed, without any downtime. The provisioned v2 file share also gives you all of the telemetry needed to monitor your workload's used IOPS and throughput usage, enabling you to continuously tune your file share to your workload. Getting started is easy Provisioned v2 for SSD is available right now, in all public cloud regions (see provisioned v2 availability for details). Simply select "Azure Files" for primary service, "Premium" for performance, and "Provisioned v2" for billing when creating your storage account in the Azure Portal. To learn more about how to get started, see: Azure Files pricing page Understanding the provisioned v2 model | Microsoft Learn How to create an Azure file share | Microsoft Learn
Secure Linux workloads using Azure Files with Encryption in Transit
Encryption in Transit (EiT) overview As organizations increasingly move to cloud environments, safeguarding data security both at rest and during transit is essential for protecting sensitive information from emerging threats and for maintaining regulatory compliance. Azure Files already offers encryption at rest using Microsoft-managed or customer-managed keys for NFS file shares. Today, we're excited to announce the General Availability of Encryption in Transit (EiT) for NFS file shares. By default, Azure encrypts data moving across regions. In addition, all clients accessing Azure Files NFS shares are required to be within the scope of a trusted virtual network (VNet) to ensure secure access to applications. However, data transferred within resources in a VNet remains unencrypted. Enabling EiT ensures that all read & writes to the NFS file shares within the VNET are encrypted providing an additional layer of security. With EiT, enterprises running production scale applications with Azure Files NFS shares can now meet their end-to-end compliance requirements. Feedback from the NFS community and Azure customers emphasized the need for an encryption approach that is easy to deploy, portable, and scalable. TLS enables a streamlined deployment model for NFS with EiT while minimizing configuration complexity, maintaining protocol transparency, and avoiding operational overhead. The result is a more secure, performant, and standards-compliant solution that integrates seamlessly into existing NFS workflows. With EiT, customers can now encrypt all NFS traffic using the latest and most secure version of TLS, TLS 1.3, achieving enterprise-grade security effortlessly. TLS provides three core security guarantees: Confidentiality: Data is encrypted, preventing eavesdropping. Authentication: Client verifies the server via certificates during handshake to establish trust. Integrity: TLS ensures that information arrives safely and unchanged, thus adding protection against data corruption or bitflips in transit. TLS encryption for Azure Files is delivered via stunnel, a trusted, open-source proxy designed to add TLS encryption to existing client-server communications without modifying the applications themselves. It has been widely used for its robust security and transparent, in-transit encryption for many use cases across industries for many years. AZNFS Mount Helper for Seamless Setup EiT client setup and mount for NFS volumes may seem like a daunting task, but we have made it easier using the AZNFS mount helper tool. Simplicity and Resiliency: AZNFS is a simple, open-source tool, maintained and supported by Microsoft, that automates stunnel setup and NFS volume mounting over a secure TLS tunnel. AZNFS’s in-built watchdog's auto-reconnect logic protects the TLS mounts, ensuring high availability during unexpected connectivity interruptions. Sample AZNFS mount commands, customized to your NFS volume, are available in the Azure portal (screenshot below). Fig 1. Azure portal view to configure AZNFS for Azure clients using EiT Standardized and flexible: Mounting with AZNFS incorporates the Microsoft recommended performance, security and reliability mount options by default while providing flexibility to adjust these settings to fit your workload. For example, while TLS is the default selection, you can override it to non-TLS connections for scenarios like testing or debugging. Broad Linux compatibility: AZNFS is available through Microsoft’s package repository for major Linux distributions, including Ubuntu, RedHat, SUSE, Alma Linux, Oracle Linux and more. Seamless upgrades: AZNFS package updates automatically in the background without affecting the active mount connections. You will not need any maintenance windows or downtime to perform upgrades. The illustration below shows how EiT helps transmit data securely between clients and NFS volumes over trusted networks. Fig 2. EiT set up flow and secure data transfer for NFS shares Enterprise Workloads and Platform Support EiT is compatible with applications running on a wide range of platforms, including Linux VMs in Azure, on-premises Linux servers, VM scale sets, and Azure Batch, ensuring compatibility with major Linux distributions for cloud, hybrid, and on-premises deployments. Azure Kubernetes Service (AKS): The preview of NFS EiT in AKS will be available shortly. In the meantime, the upstream Azure Files CSI Driver includes AZNFS integration, which can be manually configured to enable EiT for NFS volumes with stateful container workloads. SAP: SAP systems are central to many business operations and handle sensitive data like financial information, customer details, and proprietary data. Securing this confidential data within the SAP environment, including its central services, is a critical concern. NFS volumes, used in central services are single points of failure, making their security and availability crucial. This blog post on SAP deployments on Azure provides guidance on using EiT enabled NFS volumes for SAP deployment scenarios to make them even more secure. SAP tested EiT for their SAP RISE deployments and shared positive feedback: “The NFS Encryption in Transit preview has been a key enabler for running RISE customers mission critical workloads on Azure Files, helping us meet high data in transit encryption requirements without compromising performance or reliability. It has been critical in supporting alignment with strict security architectures and control frameworks—especially for regulated industries like financial services and healthcare. We’re excited to see this capability go GA and look forward to leveraging it at scale.” Ventsislav Ivanov, IT Architecture Chief Expert, SAP Compliance-centric verticals: As part of our preview, customers in industry verticals including financial services, insurance, retail leveraged EiT to address their data confidentiality and compliance needs. One such customer, Standard Chartered, a major global financial institution, highlighted its benefits. “The NFS Encryption in Transit preview has been a key enabler for migrating one of our on-premises applications to Azure. It allowed us to easily run tests in our development and staging environments while maintaining strict compliance and security for our web application assets. Installation of the required aznfs package was seamless, and integration into our bootstrap script for virtual machine scale set automation went smoothly. Additionally, once we no longer needed to disable the HTTPS requirement on our storage account, no further changes were necessary to our internal Terraform modules—making the experience nearly plug-and-play. We’re excited to see this capability reach general availability” Mohd Najib, Azure Cloud Engineer, Standard Chartered Regional availability and pricing Encryption in Transit GA with TLS 1.3 is rolling out globally and is now available in most regions. EiT can be enabled on both new and existing storage accounts and Azure Files NFS shares. There is no additional cost for enabling EiT. Next Steps to Secure Your Workloads Explore More: How to encrypt data in transit for NFS shares| Microsoft Learn Mandate Security: Enable “Secure Transfer Required” on all your Storage Accounts with NFS volumes to mandate EiT for additional layer of protection. Enforce at Scale: Enable Azure Policy for enforcing EiT across your subscription. Please reach out to the team at AzureFiles@microsoft.com for any questions and feedback.Azure Files NFS Encryption In Transit for SAP on Azure Systems
Azure Files NFS volumes now support encryption in-transit via TLS. With this enhancement, Azure Files NFS v4.1 offers the robust security that modern enterprises require, without compromising performance by ensuring all traffic between clients and servers is fully encrypted. Now Azure Files NFS data can be encrypted end-to-end: at rest, in transit, and across the network. Using Stunnel, an open-source TLS wrapper, Azure Files encrypts the TCP stream between the NFS client and Azure Files with strong encryption using AES-GCM, without needing Kerberos. This ensures data confidentiality while eliminating the need for complex setups or external authentication systems like Active Directory. The AZNFS utility package simplifies encrypted mounts by installing and setting up Stunnel on the client (Azure VMs). The AZNFS mount helper mounts the NFS shares with TLS support. The mount helper initializes dedicated stunnel client process for each storage account’s IP address. The stunnel client process listens on a local port for inbound traffic and then redirects encrypted nfs client traffic to the 2049 port where NFS server is listening on. The AZNFS package runs a background job called aznfswatchdog. It ensures that stunnel processes are running for each storage account and cleans up after all shares from the storage account are unmounted. If for some reason a stunnel process is terminated unexpectedly, the watchdog process restarts it. For more details, refer to the following document: How to encrypt data in transit for NFS shares Availability in Azure Regions All regions that support Azure Premium Files now support encryption in transit. Supported Linux releases For SAP on Azure environment, Azure Files NFS Encryption in Transit (EiT) is available for the following Operating System releases. SLES for SAP 15 SP4 onwards RHEL for SAP 8.6 onwards (EiT is currently not supported for file systems managed by Pacemaker clusters on RHEL.) Refer to SAP Note 1928533 for Operating system supportability for SAP on Azure systems. How to deploy Encryption in Transit (EiT) for Azure Files NFS Shares Refer to the SAP on Azure deployment planning guide about Using Azure Premium Files NFS and SMB for SAP workload As described in the planning guide, for SAP workloads, following are the supported uses of Azure Files NFS shares and EiT can be used for all the scenarios: sapmnt volume for a distributed SAP systems transport directory for SAP landscape /hana/shared for HANA scale-out. Review carefully the considerations for sizing /hana/shared, as appropriately sized /hana/shared volume contributes to system's stability file interface between your SAP landscape and other applications Deploy the Azure File NFS storage account. Refer to the standard documentation for creating the Azure Files storage account, file share and private endpoint. Create an NFS Azure file share Note : We can enforce EiT for all the file shares in the Azure Storage account by enabling ‘secure transfer required’ option. Deploy the mount helper (AZNFS) package on the Linux VM. Follow the instructions for your Linux distribution to install the package. Create the directories to mount the file shares. mkdir -p <full path of the directory> Mount the NFS File share. Refer to the section for mounting the Azure Files NFS EiT file share in Linux VMs. To mount the file share permanently by adding the mount commands in ‘/etc/fstab’. vi /etc/fstab sapnfs.file.core.windows.net:/sapnfsafs/sapnw1/sapmntNW1 /sapmnt/NW1 aznfs noresvport,vers=4,minorversion=1,sec=sys,_netdev 0 0 # Mount the file systems mount -a o File systems mentioned above are an example to explain the mount command syntax. o When adding nfs mount entry to /etc/fstab, the fstype is "nfs". However, to use AZNFS mount helper and EiT, we need to use the fstype as "aznfs" which is not known to the Operating System, so at boot time the server tries to mount these entries before the watchdog is active, and they may fail. Users should always add "_netdev" option to their /etc/fstab entries to make sure shares are mounted on reboot only after the required services (like network) are active. o We can add “notls” option in the mount command, if we don’t want to use the EiT but just want to use AZNFS mount helper to mount the file system. Also , we cannot mix EiT and no-EiT methods for different file systems using Azure Files NFS in the same Azure VM. Mount commands may fail to mount the file systems if EiT and no-EiT methods are used in the same VM o Mount helper supports private-endpoint based connections for Azure Files NFS EiT. o If SAP VM is custom domain joined, then we can use custom DNS FQDN OR short names for file share in the ‘/etc/fstab’ as its defined in the DNS. To verify the hostname resolution, check using ‘nslookup <hostname>’ and ‘getent host <hostname>’ commands. Mount the NFS File share as pacemaker cluster resource for SAP Central Services. In high availability setup of SAP Central Services, we may use file system as a resource in pacemaker cluster and it needs to be mounted using pacemaker cluster command. In the pacemaker commands to setup file system as cluster resource, we need to change the mount type to ‘aznfs’ from ‘nfs’. Also it’s recommended to use ‘_netdev’ in the options parameter. Following are the SAP Central Services setup scenarios in which Azure Files NFS is used as pacemaker resource agent, and we can use Azure Files NFS EiT. Azure VMs high availability for SAP NW on SLES with NFS on Azure Files Azure VMs high availability for SAP NW on RHEL with NFS on Azure Files For SUSE Linux: SUSE 15 SP4 (for SAP) and higher releases recognise the ‘aznfs’ as file system type in the pacemaker resource agent. SUSE recommends using simple mount approach for high availability setup of SAP Central services, in which all file systems are mounted using ‘/etc/fstab’ only. For RHEL Linux: RHEL 8.6 (for SAP) and higher releases will be recognising ‘aznfs’ as file system type in pacemaker resource agent. At the time of writing the blog, ‘aznfs’ as file system type is not yet recognised by the FileSystem resource agent(RS) on RHEL, hence this setup can’t be used at this moment. For SAP HANA scale-out with HSR setup We can use Azure Files NFS EiT for SAP HANA scale-out with HSR setup as described in the below docs. SAP HANA scale-out with HSR and Pacemaker on SLES SAP HANA scale-out with HSR and Pacemaker on RHEL We need to mount ‘/hana/shared’ File system with EiT by defining the filesystem type as ‘aznfs’ in ‘/etc/fstab’. Also it’s recommended to use ‘_netdev’ in the options parameter. For SUSE Linux: In the Create File system resource section with SAP HANA high availability “SAPHanaSR-ScaleOut” package, in which we create a dummy file system cluster resource, which will monitor and report failures for ‘/hana/shared’ file system, we can continue to follow the steps as it is in the above document with ‘fstype=nfs4’. ‘/hana/shared’ file system will still be using EiT as defined in ‘/etc/fstab’. For SAP HANA high availability “SAPHanaSR-angi”, there are no further actions needed to use Azure File NFS EiT. For RHEL Linux: In the Create File system resource section, we can replace the file system type to ‘aznfs’ from ‘nfs’ in the pacemaker resource configuration for ‘/hana/shared’ file systems. Validation of in-transit data Encryption for Azure Files NFS. Refer to Verify that the in-transit data encryption succeeded section to check and confirm if EiT is successfully working. Summary Go ahead with EiT!! Simplified deployment of Encryption in Transit of Azure Files Premium NFS (Locally redundant Storage / Zonal redundant Storage) will strengthen the security footprint of Production and non-Production SAP on Azure environments.From GlusterFS to Azure Files: A Real-World Migration Story
A few weeks ago, we received a call familiar to many cloud architects—a customer with a massive GlusterFS deployment impacted by Red Hat's end-of-support deadline (December 2024) wondering: "What now?". With hundreds of terabytes across their infrastructure serving both internal teams and external customers, moving away from GlusterFS became a business continuity imperative. Having worked with numerous storage migrations over the years, I could already see the late nights ahead for their team if they simply tried to recreate their existing architecture in the cloud. So, we rolled up our sleeves and dug into their environment to find a better way forward. The GlusterFS challenge GlusterFS emerged in 2005 as a groundbreaking open-source distributed file system that solved horizontal scaling problems when enterprise storage had to work around mechanical device limitations. Storage administrators traditionally created pools of drives limited to single systems and difficult to expand without major downtime. GlusterFS addressed this by allowing distributed storage across physical servers, each maintaining its own redundant storage. Red Hat's acquisition of GlusterFS (Red Hat to Acquire Gluster) in 2011 brought enterprise legitimacy, but its architecture reflected a pre-cloud world with significant limitations: Costly local/geo replication due to limited site/WAN bandwidth Upgrades requiring outages and extensive planning Overhead from OS patching and maintaining compliance standards Constant "backup babysitting" for offsite tape rotation 24/7 on-call staffing for potential "brick" failures Indeed, during our initial discussions, customer’s storage team lead half-jokingly mentioned having a special ringtone for middle-of-the-night "brick" failure alerts. We also noticed that they were running the share exports on SMB 3.0 and NFS 3.0, something which is considered “slightly” deprecated today. Note: In GlusterFS, a "brick" is the basic storage unit—a directory on a disk contributing to the overall volume that enables scalable, distributed storage. Why Azure Files made perfect sense With the challenges our customer faced with maintaining redundancies & administration efforts, they required a turnkey solution to manage their data. Azure Files provided them a fully managed file share service in the Cloud, offering SMB, NFS, and REST-based shares, with on-demand scaling, integrated backups & automated failover. GlusterFS was designed for large scale distributed storage systems. With Azure Files, GlusterFS customers can take advantage of up to 100TiB of Premium file or 256TiB of Provisioned V2 HDD, 10 GBPs of throughput and up to 10K IOPS for demanding workloads. The advantages of Azure Files don’t just end at performance. As customers migrate from GlusterFS to Azure files, these are the additional benefits out of the box: Azure Backup integration One-click redundancy configuration upgrades Built-in monitoring via Azure Monitor HIPAA, PCI DSS, and GDPR compliance Enterprise security through granular access control and encryption (in transit and at Rest) The financial reality At a high level, we found that migrating to Azure files was 3X cheaper than migrating to an equivalent VM based setup running GlusterFS. We compared a self-managed 3-node GlusterFS cluster (running SMB 3.0) on Azure VMs via Provisioned v2 disks with Azure Files - Premium tier (SMB 3.11). Note: All disks on VM are using Provisioned V2 for best cost saving. Region - East US2. Component GlusterFS on Azure VMs with Premium SSD v2 Disk Azure Files Premium Compute 3 x D16ads v5 VMs (16 vCPUs, 64 GiB RAM) $685.75 N/A VM OS Disks (P10) $15.42 N/A Storage 100TB Storage $11,398.18 $10,485.75 Provisioned Throughput (storage only) 2400MBps 10,340MBps Provisioned IOPS (storage only) 160000 102400 Additional Storage for Replication (~200%) $22,796.37 N/A Backup & DR Backup Solution (30 days, ZRS redundancy) $16,343.04 $4,608.00 Monthly Total $51,238.76 $15,094.75 As the table illustrates, even before we factor in the administration cost, Azure Files already has a compelling financial advantage. We also recently released “Provisioned v2” billing model for Azure files – HDD tier which provides fine grained cost management and can scale up to 256TiB!! With GlusterFS running on-premises, customers must take in account the various administrative overheads, which will be taken away with Azure Files. Factors Current (GlusterFS) Azure Files Management & Maintenance Significant None Storage Administration Personnel 15-20 hours/week Minimal Rebalancing Operations Required Automatic Failover effort Required Automatic Capacity Planning Required Automatic Scaling Complexity High None Implementation of Security Controls Required Included The migration journey We developed a phased approach tailored to the customer's risk tolerance, starting with lower-priority workloads as a pilot: Phase 1: Assessment (2-3 weeks) Inventory GlusterFS environments and analyse workloads Define requirements and select appropriate Azure Files tier Develop migration strategy Phase 2: Pilot Migration (1-2 weeks) Set up Azure Files and test connectivity Migrate test workloads and refine process Phase 3: Production Migration (variable) Execute transfers using appropriate tools (AzCopy, Robocopy, rsync // fpsync) Implement incremental sync and validate data integrity Phase 4: Optimization (1-2 weeks) Fine-tune performance and implement monitoring Decommission legacy infrastructure Results that matter Working with Tata Consultancy Services (TCS) as our migration partner, the customer did a POC migrating from a three-node RHEL 8 environment with a 1TB SMB (GlusterFS) share, to Azure Storage Account- Premium files. The source share was limited to ~1500 IOPS, and had 20+ subfolders, each being reserved for application access which made administrative tasks challenging. The application sub-folder structure was modified to individual Azure Files shares as part of the migration planning process. In addition, each share was secured using on-premises Active directory – Domain controller-based share authentication. Migration was done using Robocopy with SMB shares mounted on Windows clients and data copy being done in a mirror mode. The migration delivered significant benefits: Dramatically improved general-purpose performance due to migration of HDD based shares to SSD (1500 IOPS shared at source vs 3000 IOPS // 200MBPS base performance per share) Meeting and exceeding current RTO and RPO requirements (15 min) set by customer Customer mentioned noticeable performance gains for SQL Server workloads Flexibility to resize each share to Azure files maximum limit, independent of noise neighbours as previously configured Significant reduced TCO (at 33% of cost compared to equivalent VM based deployment) with higher base performance What this means for your GlusterFS environment If you're facing the GlusterFS support deadline, this is an opportunity to modernize your file storage approach. Azure Files offers a chance to eliminate infrastructure headaches through simplified management, robust security, seamless scalability, and compelling economics. Looking to begin your own migration? Reach out to us at azurefiles@microsoft.com, contact your Microsoft representatives, or explore our Azure Files documentation to learn more about capabilities and migration paths.
