Planning for an Azure Files deployment

Azure Files can be deployed in two main ways: by directly mounting the serverless Azure file shares or by caching Azure file shares on-premises using Azure File Sync. Deployment considerations will 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 does not require managing a file server or NAS device. This means you don't have to apply software patches or swap out physical disks.

  • Cache Azure file share on-premises with Azure File Sync: 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. To plan for an Azure File Sync deployment, see Planning for an Azure File Sync deployment.

Available protocols

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 do not 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. NFS 4.1 is currently only supported within new FileStorage storage account type (premium file shares only).

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
  • Windows 10, version 21H1+
  • Windows Server 2019+
  • Linux kernel version 5.3+
Linux kernel version 4.3+
Available tiers Premium, transaction optimized, hot, and cool Premium
Billing model Provisioned capacity
Redundancy LRS, ZRS, GRS, GZRS LRS, ZRS
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 Subset:
Mandatory lock/advisory byte range lock 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
Server service Not supported N/A
File system transactions (TxF) Not supported N/A

Management concepts

Azure file shares are deployed into storage accounts, which are top-level objects that represent a shared pool of storage. This pool of storage can be used to deploy multiple file shares, as well as other storage resources such as blob containers, queues, or tables. All storage resources that are deployed into a storage account share the limits that apply to that storage account. For current storage account limits, see Azure Files scalability and performance targets.

There are two main types of storage accounts you will use for Azure Files deployments:

  • General purpose version 2 (GPv2) storage accounts: GPv2 storage accounts allow you to deploy Azure file shares on standard/hard disk-based (HDD-based) hardware. In addition to storing Azure file shares, GPv2 storage accounts can store other storage resources such as blob containers, queues, or tables.
  • FileStorage storage accounts: FileStorage storage accounts allow you to deploy Azure file shares on premium/solid-state disk-based (SSD-based) hardware. FileStorage accounts can only be used to store Azure file shares; no other storage resources (blob containers, queues, tables, etc.) can be deployed in a FileStorage account. Only FileStorage accounts can deploy both SMB and NFS file shares.

There are several other storage account types you may come across in the Azure portal, PowerShell, or CLI. Two storage account types, BlockBlobStorage and BlobStorage storage accounts, cannot contain Azure file shares. The other two storage account types you may see are general purpose version 1 (GPv1) and classic storage accounts, both of which can contain Azure file shares. Although GPv1 and classic storage accounts may contain Azure file shares, most new features of Azure Files are available only in GPv2 and FileStorage storage accounts. We therefore recommend to only use GPv2 and FileStorage storage accounts for new deployments, and to upgrade GPv1 and classic storage accounts if they already exist in your environment.

When deploying Azure file shares into storage accounts, we recommend:

  • Only deploying Azure file shares into storage accounts with other Azure file shares. Although GPv2 storage accounts allow you to have mixed purpose storage accounts, because storage resources such as Azure file shares and blob containers share the storage account's limits, mixing resources together may make it more difficult to troubleshoot performance issues later on.

  • Paying attention to a storage account's IOPS limitations when deploying Azure file shares. Ideally, you would map file shares 1:1 with storage accounts. However, this may not always be possible due to various limits and restrictions, both from your organization and from Azure. When it is not possible to have only one file share deployed in one storage account, consider which shares will be highly active and which shares will be less active to ensure that the hottest file shares don't get put in the same storage account together.

  • Only deploying GPv2 and FileStorage accounts and upgrading GPv1 and classic storage accounts when you find them in your environment.

Identity

To access an Azure file share, the user of the file share must be authenticated and authorized to access the share. This is done based on the identity of the user accessing the file share. Azure Files integrates with four main identity providers:

  • On-premises Active Directory Domain Services (AD DS, or on-premises 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.
  • Azure Active Directory Domain Services (Azure AD DS): Azure AD DS provides a Microsoft-managed domain controller that can be used for Azure resources. Domain joining your storage account to Azure AD DS provides similar benefits to domain joining it to a customer-owned Active Directory. This deployment option is most useful for application lift-and-shift scenarios that require AD-based permissions. Since Azure AD DS provides AD-based authentication, this option also uses the Kerberos authentication protocol.
  • Azure Active Directory (Azure AD) Kerberos for hybrid identities (preview): Azure AD Kerberos allows you to use Azure AD to authenticate hybrid user identities, which are on-premises AD identities that are synced to the cloud. This configuration uses Azure AD 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 without requiring a line-of-sight to domain controllers from hybrid Azure AD-joined and Azure AD-joined VMs.
  • Azure storage account key: Azure file shares may also be mounted with an Azure storage account key. To mount a file share this way, 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 will have 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.

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, domain joining your storage account to Customer-owned Active Directory is the recommended option. To learn more about domain joining your storage account to a customer-owned Active Directory, see Azure Files Active Directory overview.

If you intend to use the storage account key to access your Azure file shares, we recommend using service endpoints as described in the Networking section.

Networking

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.

From a practical perspective, this means you will 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, 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.

To learn more about how to configure networking for Azure Files, 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.

Encryption

Azure Files supports two different types of encryption: encryption in transit, which relates to the encryption used when mounting/accessing the Azure file share, and encryption at rest, which relates to how the data is encrypted when it is stored on disk.

Encryption in transit

Important

This section covers encryption in transit details for SMB shares. For details regarding encryption in transit with NFS shares, see Security and networking.

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 will only allow the connection if it is made with SMB 3.x with encryption or HTTPS. Clients that do not support SMB 3.x or clients that support SMB 3.x but not SMB encryption will not 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 detailed 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 will also allow 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, will not 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.

Encryption at rest

All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. Because data is encrypted beneath the Azure file share's file system, as it's encoded to disk, you don't have to have access to the underlying key on the client to read or write to the Azure file share. Encryption at rest applies to both the SMB and NFS protocols.

By default, data stored in Azure Files is encrypted with Microsoft-managed keys. With Microsoft-managed keys, Microsoft holds the keys to encrypt/decrypt the data, and is responsible for rotating them on a regular basis. You can also choose to manage your own keys, which gives you control over the rotation process. If you choose to encrypt your file shares with customer-managed keys, Azure Files is authorized to access your keys to fulfill read and write requests from your clients. With customer-managed keys, you can revoke this authorization at any time, but this means that your Azure file share will no longer be accessible via SMB or the FileREST API.

Azure Files uses the same encryption scheme as the other Azure storage services such as Azure Blob storage. To learn more about Azure storage service encryption (SSE), see Azure storage encryption for data at rest.

Data protection

Azure Files has a multi-layered approach to ensuring your data is backed up, recoverable, and protected from security threats.

Soft delete

Soft delete is a storage-account level setting for SMB file shares 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 data is recoverable before it's permanently deleted, and undelete the share anytime during this retention period.

We recommend turning on soft delete for most SMB file shares. If you have a workflow where share deletion is common and expected, you may decide to have a short retention period or not have soft delete enabled at all. Soft delete doesn't work for NFS shares, even if it's enabled for the storage account.

For more information about soft delete, see Prevent accidental data deletion.

Backup

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 these snapshots in the Azure portal, via PowerShell, or command-line interface (CLI), or you can use Azure Backup. Snapshots are stored within your file share, meaning that if you delete your file share, your snapshots will also be deleted. To protect your snapshot backups from accidental deletion, ensure soft delete is enabled for your share.

Azure Backup for 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. Lastly, 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. All you need to do is 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.

For more information about backup, see About Azure file share backup.

Protect Azure Files with Microsoft Defender for Storage

Microsoft Defender for Storage provides an additional layer of security intelligence that generates alerts when it detects anomalous activity on your storage account, for example unusual access attempts. It also runs malware hash reputation analysis and will alert on known malware. You can configure Microsoft Defender for Storage at the subscription or storage account level via Microsoft Defender for Cloud.

For more information, see Introduction to Microsoft Defender for Storage.

Storage tiers

Azure Files offers four different tiers of storage, premium, transaction optimized, hot, and cool to allow you to tailor your shares to the performance and price requirements of your scenario:

  • Premium: Premium file shares are backed by solid-state drives (SSDs) and provide consistent high performance and low latency, within single-digit milliseconds for most IO operations, for IO-intensive workloads. Premium file shares are suitable for a wide variety of workloads like databases, web site hosting, and development environments. Premium file shares can be used with both Server Message Block (SMB) and Network File System (NFS) protocols.
  • Transaction optimized: Transaction optimized file shares enable transaction heavy workloads that don't need the latency offered by premium file shares. Transaction optimized file shares are offered on the standard storage hardware backed by hard disk drives (HDDs). Transaction optimized has historically been called "standard", however this refers to the storage media type rather than the tier itself (the hot and cool are also "standard" tiers, because they are on standard storage hardware).
  • Hot: Hot file shares offer storage optimized for general purpose file sharing scenarios such as team shares. Hot file shares are offered on the standard storage hardware backed by HDDs.
  • Cool: Cool file shares offer cost-efficient storage optimized for online archive storage scenarios. Cool file shares are offered on the standard storage hardware backed by HDDs.

Premium file shares are deployed in the FileStorage storage account kind and are only available in a provisioned billing model. For more information on the provisioned billing model for premium file shares, see Understanding provisioning for premium file shares. Standard file shares, including transaction optimized, hot, and cool file shares, are deployed in the general purpose version 2 (GPv2) storage account kind, and are available through pay as you go billing.

When selecting a storage tier for your workload, consider your performance and usage requirements. If your workload requires single-digit latency, or you are using SSD storage media on-premises, the premium tier is probably the best fit. If low latency isn't as much of a concern, for example with team shares mounted on-premises from Azure or cached on-premises using Azure File Sync, standard storage may be a better fit from a cost perspective.

Once you've created a file share in a storage account, you cannot move it to tiers exclusive to different storage account kinds. For example, to move a transaction optimized file share to the premium tier, you must create a new file share in a FileStorage storage account and copy the data from your original share to a new file share in the FileStorage account. We recommend using AzCopy to copy data between Azure file shares, but you may also use tools like robocopy on Windows or rsync for macOS and Linux.

See Understanding Azure Files billing for more information.

Limitations

Standard file shares with 100 TiB capacity have certain limitations.

  • Currently, only locally redundant storage (LRS) and zone redundant storage (ZRS) accounts are supported.
  • Once you enable large file shares, you cannot convert storage accounts to geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) accounts.
  • Once you enable large file shares, you can't disable it.

Redundancy

To protect the data in your Azure file shares against data loss or corruption, all Azure file shares store multiple copies of each file as they are written. Depending on the requirements of your workload, you can select additional degrees of redundancy. Azure Files currently supports the following data redundancy options:

  • Locally-redundant storage (LRS): With LRS, every file is stored three times within an Azure storage cluster. This protects against loss of data due to hardware faults, such as a bad disk drive. However, if a disaster such as fire or flooding occurs within the data center, all replicas of a storage account using LRS may be lost or unrecoverable.
  • Zone-redundant storage (ZRS): With ZRS, three copies of each file stored, however these copies are physically isolated in three distinct storage clusters in different Azure availability zones. Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking. A write to storage is not accepted until it is written to the storage clusters in all three availability zones.
  • Geo-redundant storage (GRS): With GRS, you have two regions, a primary and secondary region. Files are stored three times within an Azure storage cluster in the primary region. Writes are asynchronously replicated to a Microsoft-defined secondary region. GRS provides six copies of your data spread between two Azure regions. In the event of a major disaster such as the permanent loss of an Azure region due to a natural disaster or other similar event, Microsoft will perform a failover and the secondary becomes the primary, serving all operations. Since the replication between the primary and secondary regions are asynchronous, in the event of a major disaster, data not yet replicated to the secondary region will be lost. You can also perform a manual failover of a geo-redundant storage account.
  • Geo-zone-redundant storage (GZRS): You can think of GZRS as if it were like ZRS but with geo-redundancy. With GZRS, files are stored three times across three distinct storage clusters in the primary region. All writes are then asynchronously replicated to a Microsoft-defined secondary region. The failover process for GZRS works the same as GRS.

Standard Azure file shares up to 5-TiB support all four redundancy types. Standard file shares larger than 5-TiB only support LRS and ZRS. Premium Azure file shares only support LRS and ZRS.

General purpose version 2 (GPv2) storage accounts provide two additional redundancy options that are not supported by Azure Files: read accessible geo-redundant storage, often referred to as RA-GRS, and read accessible geo-zone-redundant storage, often referred to as RA-GZRS. You can provision Azure file shares in storage accounts with these options set, however Azure Files does not support reading from the secondary region. Azure file shares deployed into read-accessible geo- or geo-zone redundant storage accounts will be billed as geo-redundant or geo-zone-redundant storage, respectively.

Standard ZRS availability

ZRS for standard general-purpose v2 storage accounts is available for a subset of Azure regions:

  • (Africa) South Africa North
  • (Asia Pacific) Australia East
  • (Asia Pacific) Central India
  • (Asia Pacific) East Asia
  • (Asia Pacific) Japan East
  • (Asia Pacific) Korea Central
  • (Asia Pacific) Southeast Asia
  • (Europe) France Central
  • (Europe) Germany West Central
  • (Europe) North Europe
  • (Europe) Norway East
  • (Europe) Sweden Central
  • (Europe) Switzerland North
  • (Europe) UK South
  • (Europe) West Europe
  • (North America) Canada Central
  • (North America) Central US
  • (North America) East US
  • (North America) East US 2
  • (North America) South Central US
  • (North America) US Gov Virginia
  • (North America) West US 2
  • (North America) West US 3
  • (South America) Brazil South

Premium ZRS availability

ZRS for premium file shares is available for a subset of Azure regions:

  • (Asia Pacific) Australia East
  • (Asia Pacific) Japan East
  • (Asia Pacific) Southeast Asia
  • (Europe) France Central
  • (Europe) North Europe
  • (Europe) West Europe
  • (Europe) UK South
  • (North America) East US
  • (North America) East US 2
  • (North America) West US 2
  • (North America) South Central US
  • (South America) Brazil South

Standard GZRS availability

GZRS is available for a subset of Azure regions:

  • (Africa) South Africa North
  • (Asia Pacific) Australia East
  • (Asia Pacific) East Asia
  • (Asia Pacific) Japan East
  • (Asia Pacific) Korea Central
  • (Asia Pacific) Southeast Asia
  • (Asia Pacific) Central India
  • (Europe) France Central
  • (Europe) Germany West Central
  • (Europe) North Europe
  • (Europe) Norway East
  • (Europe) Sweden Central
  • (Europe) Switzerland North
  • (Europe) UK South
  • (Europe) West Europe
  • (North America) Canada Central
  • (North America) Central US
  • (North America) East US
  • (North America) East US 2
  • (North America) South Central US
  • (North America) West US 2
  • (North America) West US 3
  • (North America) US Gov Virginia
  • (South America) Brazil South

Migration

In many cases, you will not 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 for your scenario is important for the success of your migration.

The migration overview article briefly covers the basics and contains a table that leads you to migration guides that likely cover your scenario.

Next steps