Azure Files scalability and performance targets

Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard SMB protocol. This article discusses the scalability and performance targets for Azure Files and Azure File Sync.

The scalability and performance targets listed here are high-end targets, but may be affected by other variables in your deployment. For example, the throughput for a file may also be limited by your available network bandwidth, not just the servers hosting the Azure Files service. We strongly recommend testing your usage pattern to determine whether the scalability and performance of Azure Files meet your requirements. We are also committed to increasing these limits over time. Please don't hesitate to give us feedback, either in the comments below or on the Azure Files UserVoice, about which limits you would like to see us increase.

Azure storage account scale targets

The parent resource for an Azure file share is an Azure storage account. A storage account represents a pool of storage in Azure that can be used by multiple storage services, including Azure Files, to store data. Other services that store data in storage accounts are Azure Blob storage, Azure Queue storage, and Azure Table storage. The following targets apply all storage services storing data in a storage account:

Resource Default Limit
Number of storage accounts per region per subscription 2001
Max storage account capacity 500 TiB2
Max number of blob containers, blobs, file shares, tables, queues, entities, or messages per storage account No limit
Maximum request rate per storage account 20,000 requests per second2
Max ingress3 per storage account (US Regions) 10 Gbps if RA-GRS/GRS enabled, 20 Gbps for LRS/ZRS4
Max egress3 per storage account (US Regions) 20 Gbps if RA-GRS/GRS enabled, 30 Gbps for LRS/ZRS4
Max ingress3 per storage account (Non-US regions) 5 Gbps if RA-GRS/GRS enabled, 10 Gbps for LRS/ZRS4
Max egress3 per storage account (Non-US regions) 10 Gbps if RA-GRS/GRS enabled, 15 Gbps for LRS/ZRS4

1Includes both Standard and Premium storage accounts. If you require more than 200 storage accounts in a given region, make a request through Azure Support. The Azure Storage team will review your business case and may approve up to 250 storage accounts for a given region.

2 If you need expanded limits for your storage account, please contact Azure Support. The Azure Storage team will review the request and may approve higher limits on a case by case basis. Both general-purpose and Blob storage accounts support increased capacity, ingress/egress, and request rate by request. For the new maximums for Blob storage accounts, see Announcing larger, higher scale storage accounts.

3 Capped only by the account's ingress/egress limits. Ingress refers to all data (requests) being sent to a storage account. Egress refers to all data (responses) being received from a storage account.

4Azure Storage redundancy options include:

  • RA-GRS: Read-access geo-redundant storage. If RA-GRS is enabled, egress targets for the secondary location are identical to those for the primary location.
  • GRS: Geo-redundant storage.
  • ZRS: Zone-redundant storage.
  • LRS: Locally redundant storage.

The following limits apply when performing management operations using the Azure Resource Manager only.

Resource Default Limit
Storage account management operations (read) 800 per 5 minutes
Storage account management operations (write) 200 per hour
Storage account management operations (list) 100 per 5 minutes


Storage account utilization from other storage services affects your Azure file shares in your storage account. For example, if you reach the maximum storage account capacity with Azure Blob storage, you will not be able to create new files on your Azure file share, even if your Azure file share is below the maximum share size.

Azure Files scale targets

Resource Target
Max size of a file share 5 TiB
Max size of a file in a file share 1 TiB
Max number of files in a file share No limit
Max IOPS per share 1000 IOPS
Max number of stored access policies per file share 5
Maximum request rate per storage account 20,000 requests per second for files of any valid size3
Target throughput for single file share Up to 60 MiB per second
Maximum open handles per file 2000 open handles
Maximum number of share snapshots 200 share snapshots

Azure File Sync scale targets

With Azure File Sync, we have tried as much as possible to design for limitless usage, however this is not always possible. The below table indicates the boundaries of our testing and which targets are actually hard limits:

Resource Target Hard limit
Storage Sync Services per subscription 15 Storage Sync Services No
Sync groups per Storage Sync Service 30 sync groups Yes
Registered servers per Storage Sync Service 99 servers Yes
Cloud endpoints per Sync Group 1 cloud endpoint Yes
Server endpoints per Sync Group 50 server endpoints No
Server endpoints per server 33-99 server endpoints Yes, but varies based on configuration
Endpoint size 4 TiB No
File system objects (directories and files) per sync group 25 million objects No
Maximum number of file system objects (directories and files) in a directory 200,000 objects Yes
Maximum object (directories and files) name length 255 characters Yes
File size 100 GiB No
Minimum file size for a file to be tiered 64 KiB Yes

Azure File Sync performance metrics

Since the Azure File Sync agent runs on a Windows Server machine that connects to the Azure file shares, the effective sync performance depends upon a number of factors in your infrastructure: Windows Server and the underlying disk configuration, network bandwidth between the server and the Azure storage, file size, total dataset size, and the activity on the dataset. Since Azure File Sync works on the file level, the performance characteristics of an Azure File Sync-based solution is better measured in the number of objects (files and directories) processed per second.

For Azure File Sync, performance is critical in two stages:

  1. Initial one-time provisioning: To optimize performance on initial provisioning, refer to Onboarding with Azure File Sync for the optimal deployment details.
  2. Ongoing sync: After the data is initially seeded in the Azure file shares, Azure File Sync keeps multiple endpoints in sync.

To help you plan your deployment for each of the stages, below are the results observed during the internal testing on a system with a config

System configuration
CPU 64 Virtual Cores with 64 MiB L3 cache
Memory 128 GiB
Disk SAS disks with RAID 10 with battery backed cache
Network 1 Gbps Network
Workload General Purpose File Server
Initial one-time provisioning
Number of objects 10 million objects
Dataset Size ~4 TiB
Average File Size ~500 KiB (Largest File: 100 GiB)
Upload Throughput 15 objects per second
Namespace Download Throughput* 350 objects per second

*When a new server endpoint is created, the Azure File Sync agent does not download any of the file content. It first syncs the full namespace and then triggers background recall to download the files, either in their entirety or, if cloud tiering is enabled, to the cloud tiering policy set on the server endpoint.

Ongoing sync
Number of objects synced 125,000 objects (~1% churn)
Dataset Size 50 GiB
Average File Size ~500 KiB
Upload Throughput 20 objects per second
Full Download Throughput* 30 objects per second

*If cloud tiering is enabled, you are likely to observe better performance as only some of the file data is downloaded. Azure File Sync only downloads the data of cached files when they are changed on any of the endpoints. For any tiered or newly created files, the agent does not download the file data, and instead only syncs the namespace to all the server endpoints. The agent also supports partial downloads of tiered files as they are accessed by the user.


The numbers above are not an indication of the performance that you will experience. The actual performance will depend on multiple factors as outlined in the beginning of this section.

As a general guide for your deployment, you should keep a few things in mind:

  • The object throughput approximately scales in proportion to the number of sync groups on the server. Splitting data into multiple sync groups on a server yields better throughput, which is also limited by the server and network.
  • The object throughput is inversely proportional to the MiB per second throughput. For smaller files, you will experience higher throughput in terms of the number of objects processed per second, but lower MiB per second throughput. Conversely, for larger files, you will get fewer objects processed per second, but higher MiB per second throughput. The MiB per second throughput is limited by the Azure Files scale targets.

See also