| title | Plan for an Azure Files Deployment |
|---|---|
| description | Understand how to plan for an Azure Files deployment. You can either direct mount an SMB or NFS file share, or cache SMB file shares on-premises with Azure File Sync. |
| author | khdownie |
| ms.service | azure-file-storage |
| ms.topic | concept-article |
| ms.date | 09/18/2025 |
| ms.author | kendownie |
| ms.custom | references_regions |
You can deploy Azure Files in two ways: by directly mounting the serverless Azure file shares or by caching file shares on-premises using Azure File Sync. Deployment considerations differ based on which option you choose.
-
Direct mount of an Azure file share: Because Azure Files provides either Server Message Block (SMB) or Network File System (NFS) access, you can mount Azure file shares on-premises or in the cloud using the standard SMB or NFS clients available in your OS. Because Azure file shares are serverless, deploying for production scenarios doesn't require managing a file server or NAS device. This means you don't have to apply software patches or swap out physical disks. You can either choose to use Azure classic file shares or Microsoft.FileShares (preview) as your management model.
-
Cache Azure file shares on-premises with Azure File Sync (SMB only): Azure File Sync enables you to centralize your organization's file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server. Azure File Sync transforms an on-premises (or cloud) Windows Server into a quick cache of your SMB Azure file share.
This article primarily addresses deployment considerations for deploying an Azure file share to be directly mounted by an on-premises or cloud client. If you plan to use Azure File Sync, see Planning for an Azure File Sync deployment.
In Azure, a resource is a manageable item that you create and configure within your Azure subscriptions and resource groups. Resources are offered by resource providers, which are management services that deliver specific types of resources. While you may work with many resources to deploy a workload in Azure, Azure Files centers on two key resources:
-
Storage accounts, offered by the
Microsoft.Storageresource provider. Storage accounts are top-level resources that represent a shared pool of storage, IOPS, and throughput in which you can deploy classic file shares or other storage resources, depending on the storage account kind. All storage resources that are deployed into a storage account share the limits that apply to that storage account. Classic file shares support both the SMB and NFS file sharing protocols. -
File shares (preview), offered by the
Microsoft.FileSharesresource provider. File shares are a new top-level resource that simplify the deployment of Azure Files by eliminating the need for a storage account. Unlike classic file shares, which must be deployed into a storage account, file shares are deployed directly into the resource group like storage accounts themselves, or other Azure resources like virtual machines, disks, or virtual networks. Currently,Microsoft.FileSharesonly supports the NFS file sharing protocol. If you require SMB, choose classic file shares.
This video provides a comprehensive overview of the differences between the storage account and file share management models:
Classic file shares, or file shares deployed in storage accounts, are the traditional way to deploy file shares for Azure Files. They support all of the key features that Azure Files supports including SMB and NFS, SSD and HDD media tiers, every redundancy type, and in every region. While classic file shares support the entire breadth of Azure Files features, they have important key limitations:
-
Capacity planning: Classic file shares, as well as the child objects like blob containers that live within the same storage account, share a common pool of storage, IOPS, and throughput. This means placing multiple classic file shares in a storage account requires planning to avoid capacity bottlenecks. When planning for classic file shares, you need to consider both the current and future needs of each classic file share placed in a storage account, since the growth of one classic file share can crowd out other file shares.
-
Shared settings: Many important settings, such as network and security rules, are applied at the storage account level. As a result, placing classic file shares in the same storage account requires careful consideration. You should consider the storage account to be a trust boundary and only place classic file shares in the same storage account if you're ok with them having the same security settings.
-
Scaling complexity: Large scale Azure Files deployments can require managing many Azure subscriptions due the constraints on storage accounts from the
Microsoft.Storageresource provider. See storage account limits for more information.
[!INCLUDE storage-files-file-share-management-concepts]
To learn more, see Create a classic file share.
File shares (preview) are a new top-level Azure resource provided by the Microsoft.FileShares resource provider. These file shares offer the following advantages over classic file shares:
-
Simplified management: File shares are created directly as top-level resources in the Azure portal or through management APIs. This removes the requirement to manage a storage account and streamlines the deployment experience.
-
Independent capacity and performance: Each file share has its own dedicated storage, IOPS, and throughput. This avoids the need to do capacity planning against your storage account's limited resources and enables file shares to freely grow as workload demands grow.
-
Granular configuration: Networking and security settings are applied at the file share level, giving you precise control of access boundaries and isolation. This makes it easier to enforce security policies for specific apps, teams, or environments.
-
Predictable, flexible billing: File shares use the provisioned v2 billing model, which enables you to independently provision storage, IOPS, and throughput per share. Because billing in Azure is done per top-level Azure resource, this enables you to easily track the costs of each individual share for cost attribution back to the project, team, or customer that is using the file share.
-
Improved scale and performance: File shares support higher limits and lower deployment times than classic file shares. For more information, see Azure Files scalability and performance targets.
Currently, creating a file share with Microsoft.FileShares (preview) is available in the following regions. Private endpoint support for file share with Microsoft.FileShares (preview) is available in all Azure public cloud regions.
- Australia East
- Australia Central
- Australia Southeast
- East Asia
- East US
- Germany North
- Korea South
- Southeast Asia
- North Europe
- South Africa West
- South India
- UAE Central
| Feature | Classic file shares  |
File shares (Microsoft.FileShares)  |
|---|---|---|
| Support guarantee | Generally available | Public preview |
| Top level resource for the service | Storage account  |
File shares |
| SMB protocol |  |
 |
| NFS protocol | |
|
| File Sync support | |
|
| Require storage account | |
|
| Pay as you go billing model | |
|
| Provisioned v1 billing model | |
|
| Provisioned v2 billing model | |
|
| HDD supportability | |
|
| SSD supportability | |
|
| LRS | |
|
| ZRS | |
|
| GRS | |
|
| GZRS | |
|
| Per share level billing, networking, and security configurations | |
|
| Single vnet configurations for a file share | |
|
| Single vnet configuration for multiple file shares | |
|
| AKS CSI driver | |
|
| Data plane REST APIs | |
|
Azure Files offers two industry-standard file system protocols for mounting Azure file shares: the Server Message Block (SMB) protocol and the Network File System (NFS) protocol, allowing you to choose the protocol that is the best fit for your workload. Azure file shares don't support both the SMB and NFS protocols on the same file share, although you can create SMB and NFS Azure file shares within the same storage account.
With both SMB and NFS file shares, Azure Files offers enterprise-grade file shares that can scale up to meet your storage needs and can be accessed concurrently by thousands of clients.
| Feature | SMB | NFS |
|---|---|---|
| Supported protocol versions | SMB 3.1.1, SMB 3.0, SMB 2.1 | NFS 4.1 |
| Recommended OS |
|
Linux kernel version 4.3+ |
| Available media tiers | SSD and HDD | SSD only |
| Redundancy |
|
|
| File system semantics | Win32 | POSIX |
| Authentication | Identity-based authentication (Kerberos), shared key authentication (NTLMv2) | Host-based authentication |
| Authorization | Win32-style access control lists (ACLs) | UNIX-style permissions |
| Case sensitivity | Case insensitive, case preserving | Case sensitive |
| Deleting or modifying open files | With lock only | Yes |
| File sharing | Windows sharing mode | Byte-range advisory network lock manager |
| Hard link support | Not supported | Supported |
| Symbolic link support | Not supported | Supported |
| Optionally internet accessible | Yes (SMB 3.0+ only) | No |
| Supports FileREST | Yes | Yes (Microsoft.Storage only) |
| Mandatory byte range locks | Supported | Not supported |
| Advisory byte range locks | Not supported | Supported |
| Extended/named attributes | Not supported | Not supported |
| Alternate data streams | Not supported | N/A |
| Object identifiers | Not supported | N/A |
| Reparse points | Not supported | N/A |
| Sparse files | Not supported | N/A |
| Compression | Not supported | N/A |
| Named pipes | Not supported | N/A |
| SMB Direct | Not supported | N/A |
| SMB Directory Leasing | Not supported | N/A |
| Volume Shadow Copy | Not supported | N/A |
| Short file names (8.3 alias) | Not supported | N/A |
| File system transactions (TxF) | Not supported | N/A |
To access an Azure file share, the user must be authenticated and authorized to access the share. In nearly all cases, we recommend using identity-based authentication instead of the storage account key to access SMB Azure file shares.
Azure Files supports the following methods of authentication for SMB shares:
- On-premises Active Directory Domain Services (AD DS): Azure storage accounts can be domain joined to a customer-owned Active Directory Domain Services, just like a Windows Server file server or NAS device. You can deploy a domain controller on-premises, in an Azure VM, or even as a VM in another cloud provider; Azure Files is agnostic to where your domain controller is hosted. Once a storage account is domain-joined, the end user can mount a file share with the user account they signed into their PC with. AD-based authentication uses the Kerberos authentication protocol.
- Microsoft Entra Domain Services: Microsoft Entra Domain Services provides a Microsoft-managed domain controller that can be used for Azure resources. Domain joining your storage account to Microsoft Entra Domain Services provides similar benefits to domain joining it to a customer-owned AD DS. This deployment option is most useful for application lift-and-shift scenarios that require AD-based permissions. Because Microsoft Entra Domain Services provides AD-based authentication, this option also uses the Kerberos authentication protocol.
- Microsoft Entra Kerberos: Microsoft Entra Kerberos allows you to use Microsoft Entra ID to authenticate hybrid or cloud-only identities (preview). This configuration uses Microsoft Entra ID to issue Kerberos tickets to access the file share with the SMB protocol. This means your end users can access Azure file shares over the internet from Microsoft Entra hybrid joined and Microsoft Entra joined VMs.
- Active Directory authentication over SMB for Linux clients: Azure Files supports identity-based authentication over SMB for Linux clients using the Kerberos authentication protocol through either AD DS or Microsoft Entra Domain Services.
- Azure storage account key: Although it's not recommended for security reasons, you can also mount Azure file shares using an Azure storage account key instead of using an identity. To mount a file share using the storage account key, the storage account name is used as the username and the storage account key is used as a password. Using the storage account key to mount the Azure file share is effectively an administrator operation, because the mounted file share has full permissions to all of the files and folders on the share, even if they have ACLs. When using the storage account key to mount over SMB, the NTLMv2 authentication protocol is used. If you must use the storage account key, we recommend using private endpoints or service endpoints as described in the Networking section.
For customers migrating from on-premises file servers or creating new file shares in Azure Files intended to behave like Windows file servers or NAS appliances, we recommend domain joining your storage account to the customer-owned AD DS. To learn more, see Overview - on-premises AD DS authentication over SMB for Azure file shares.
Directly mounting your Azure file share often requires some thought about networking configuration because:
- The port that SMB file shares use for communication, port 445, is frequently blocked by many organizations and internet service providers (ISPs) for outbound (internet) traffic.
- NFS file shares rely on network-level authentication and are therefore only accessible via restricted networks. Using an NFS file share always requires some level of networking configuration.
To configure networking, Azure Files provides an internet accessible public endpoint and integration with Azure networking features like service endpoints, which help restrict the public endpoint to specified virtual networks, and private endpoints, which give your storage account a private IP address from within a virtual network IP address space. While there's no extra charge for using public endpoints or service endpoints, standard data processing rates apply for private endpoints.
This means you'll need to consider the following network configurations:
- If the required protocol is SMB and all access over SMB is from clients in Azure, no special networking configuration is required.
- If the required protocol is SMB and the access is from clients on-premises, then a VPN or ExpressRoute connection from on-premises to your Azure network is required, with Azure Files exposed on your internal network using private endpoints.
- If the required protocol is NFS, you can use either service endpoints or private endpoints to restrict the network to specified virtual networks. If you need a static IP address and/or your workload requires high availability, use a private endpoint. With service endpoints, a rare event such as a zone outage could cause the underlying IP address of the storage account to change. While the data is still available on the file share, the client would require a remount of the share.
For more information, see Azure Files networking considerations.
In addition to directly connecting to the file share using the public endpoint or using a VPN/ExpressRoute connection with a private endpoint, SMB provides an additional client access strategy: SMB over QUIC. SMB over QUIC offers zero-config "SMB VPN" for SMB access over the QUIC transport protocol. Although Azure Files does not directly support SMB over QUIC, you can create a lightweight cache of your Azure file shares on a Windows Server 2022 Azure Edition VM using Azure File Sync. To learn more about this option, see SMB over QUIC with Azure File Sync.
Azure Files supports two different types of encryption:
- Encryption in transit, which relates to the encryption used when mounting/accessing the Azure file share
- Encryption at rest, which relates to how the data is encrypted when it's stored on disk
By default, all Azure storage accounts have encryption in transit enabled. This means that when you mount a file share over SMB or access it via the FileREST protocol (such as through the Azure portal, PowerShell/CLI, or Azure SDKs), Azure Files only allows the connection if it is made with SMB 3.x with encryption or HTTPS. Clients that don't support SMB 3.x or clients that support SMB 3.x but not SMB encryption won't be able to mount the Azure file share if encryption in transit is enabled. For more information about which operating systems support SMB 3.x with encryption, see our documentation for Windows, macOS, and Linux. All current versions of the PowerShell, CLI, and SDKs support HTTPS.
You can disable encryption in transit for an Azure storage account. When encryption is disabled, Azure Files also allows SMB 2.1 and SMB 3.x without encryption, and unencrypted FileREST API calls over HTTP. The primary reason to disable encryption in transit is to support a legacy application that must be run on an older operating system, such as Windows Server 2008 R2 or an older Linux distribution. Azure Files only allows SMB 2.1 connections within the same Azure region as the Azure file share; an SMB 2.1 client outside of the Azure region of the Azure file share, such as on-premises or in a different Azure region, won't be able to access the file share.
We strongly recommend ensuring encryption of data in-transit is enabled.
For more information about encryption in transit, see requiring secure transfer in Azure storage and Encryption in transit for NFS Azure file shares.
[!INCLUDE storage-files-encryption-at-rest]
Azure Files has a multi-layered approach to ensuring your data is backed up, recoverable, and protected from security threats. See Azure Files data protection overview.
Soft delete is a storage-account level setting that allows you to recover your file share when it's accidentally deleted. When a file share is deleted, it transitions to a soft deleted state instead of being permanently erased. You can configure the amount of time soft deleted shares are recoverable before they're permanently deleted, and undelete the share anytime during this retention period.
Soft delete is enabled by default for new storage accounts. If you have a workflow where share deletion is common and expected, you might decide to have a short retention period or not have soft delete enabled at all.
For more information about soft delete, see Prevent accidental data deletion.
You can back up your Azure file share via share snapshots, which are read-only, point-in-time copies of your share. Snapshots are incremental, meaning they only contain as much data as has changed since the previous snapshot. You can have up to 200 snapshots per file share and retain them for up to 10 years. You can either manually take snapshots in the Azure portal, via PowerShell, or command-line interface (CLI), or you can use Azure Backup.
Azure Backup for SMB Azure file shares handles the scheduling and retention of snapshots. Its grandfather-father-son (GFS) capabilities mean that you can take daily, weekly, monthly, and yearly snapshots, each with their own distinct retention period. Azure Backup also orchestrates the enablement of soft delete and takes a delete lock on a storage account as soon as any file share within it is configured for backup. Azure Backup provides certain key monitoring and alerting capabilities that allow customers to have a consolidated view of their backup estate.
You can perform both item-level and share-level restores in the Azure portal using Azure Backup. Choose the restore point (a particular snapshot), the particular file or directory if relevant, and then the location (original or alternate) you wish you restore to. The backup service handles copying the snapshot data over and shows your restore progress in the portal.
Microsoft Defender for Storage is an Azure-native layer of security intelligence that detects potential threats to your storage accounts. It provides comprehensive security by analyzing the data plane and control plane telemetry generated by Azure Files. It uses advanced threat detection capabilities powered by Microsoft Threat Intelligence to provide contextual security alerts, including steps to mitigate the detected threats and prevent future attacks.
Defender for Storage continuously analyzes the telemetry stream generated by Azure Files. When potentially malicious activities are detected, security alerts are generated. These alerts are displayed in Microsoft Defender for Cloud, along with the details of the suspicious activity, investigation steps, remediation actions, and security recommendations.
Defender for Storage detects known malware, such as ransomware, viruses, spyware, and other malware uploaded to a storage account based on full file hash (only supported for REST API). This helps prevent malware from entering the organization and spreading to more users and resources. See Understanding the differences between Malware Scanning and hash reputation analysis.
Defender for Storage doesn't access the storage account data and doesn't impact its performance. You can enable Microsoft Defender for Storage at the subscription level (recommended) or the resource level.
[!INCLUDE storage-files-tiers-overview]
[!INCLUDE storage-files-redundancy-overview]
For more information about redundancy, see Azure Files data redundancy.
Zone redundant SSD file shares are available for a subset of Azure regions.
In the case of an unplanned regional service outage, you should have a disaster recovery (DR) plan in place for your Azure file shares. To understand the concepts and processes involved with DR and storage account failover, see Disaster recovery and failover for Azure Files.
In many cases, you won't be establishing a net new file share for your organization, but instead migrating an existing file share from an on-premises file server or NAS device to Azure Files. Picking the right migration strategy and tool is important for the success of your migration.
For SMB migrations, see SMB migration overview which contains a table that leads you to migration guides that likely cover your scenario.
For NFS migrations, see Migrate to NFS Azure file shares.