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:
The following table describes default limits for Azure general-purpose v1, v2, and Blob storage accounts. The ingress limit refers to all data from requests that are sent to a storage account. The egress limit refers to all data from responses that are received from a storage account.
|Number of storage accounts per region per subscription, including both standard and premium accounts||250|
|Maximum storage account capacity||2 PB for US and Europe, 500 TB for all other regions, which includes the UK|
|Maximum number of blob containers, blobs, file shares, tables, queues, entities, or messages per storage account||No limit|
|Maximum request rate1 per storage account||20,000 requests per second|
|Maximum ingress1 per storage account (US regions)||10 Gbps if RA-GRS/GRS is enabled, 20 Gbps for LRS/ZRS2|
|Maximum ingress1 per storage account (non-US regions)||5 Gbps if RA-GRS/GRS is enabled, 10 Gbps for LRS/ZRS2|
|Maximum egress for general-purpose v2 and Blob storage accounts (all regions)||50 Gbps|
|Maximum egress for general-purpose v1 storage accounts (US regions)||20 Gbps if RA-GRS/GRS is enabled, 30 Gbps for LRS/ZRS2|
|Maximum egress for general-purpose v1 storage accounts (non-US regions)||10 Gbps if RA-GRS/GRS is enabled, 15 Gbps for LRS/ZRS2|
1Azure Standard Storage accounts support higher limits for ingress by request. To request an increase in account limits for ingress, contact Azure Support.
2 Azure Storage replication 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.
We recommend that you use a general-purpose v2 storage account for most scenarios. You can easily upgrade a general-purpose v1 or an Azure Blob storage account to a general-purpose v2 account with no downtime and without the need to copy data.
For more information on Azure Storage accounts, see Storage account overview.
If the needs of your application exceed the scalability targets of a single storage account, you can build your application to use multiple storage accounts. You can then partition your data objects across those storage accounts. For information on volume pricing, see Azure Storage pricing.
All storage accounts run on a flat network topology and support the scalability and performance targets outlined in this article, regardless of when they were created. For more information on the Azure Storage flat network architecture and on scalability, see Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency.
The following limits apply only when you perform management operations by using Azure Resource Manager with Azure Storage.
|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|
General purpose 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
Premium files scale targets
There are three categories of limitations to consider for premium files: storage accounts, shares, and files.
For example: A single share can achieve 100,000 IOPS and a single file can scale up to 5,000 IOPS. So, for example, if you have three files in one share, the maximum IOPS you can get from that share is 15,000.
Premium filestorage account limits
Premium files use a unique storage account called filestorage (preview), this account has slightly different scale targets than the storage account used by standard files. For the storage account scale targets, refer to the table in the Azure storage account scale targets section.
Storage account limits apply to all shares. Scaling up to the max for storage accounts is only achievable if there is only one share per storage account.
|Resource||Standard file shares||Premium file shares (preview)|
|Minimum size of a file share||No minimum; pay as you go||100 GiB; provisioned|
|Maximum size of a file share||5 TiB||5 TiB (public preview), 100 TiB (limited public preview)|
|Maximum size of a file in a file share||1 TiB||1 TiB|
|Maximum number of files in a file share||No limit||No limit|
|Maximum IOPS per share||1,000 IOPS||5,120 base IOPS with 15,360 burst limit (public preview), 100,000 IOPS (limited public preview)|
|Maximum number of stored access policies per file share||5||5|
|Target throughput for a single file share||Up to 60 MiB/sec||See premium file share ingress and egress values|
|Maximum egress for a single file share||See standard file share target throughput||Up to 368 MiB/s (public preview), Up to 6,204 MiB/s (limited public preview)|
|Maximum ingress for a single file share||See standard file share target throughput||Up to 245 MiB/s (public preview), Up to 4,136 MiB/s (limited public preview)|
|Maximum open handles per file||2,000 open handles||2,000 open handles|
|Maximum number of share snapshots||200 share snapshots||200 share snapshots|
|Maximum object (directories and files) name length||2,048 characters||2,048 characters|
|Maximum pathname component (in the path \A\B\C\D, each letter is a component)||255 characters||255 characters|
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:
|Storage Sync Services per region||15 Storage Sync Services||Yes|
|Sync groups per Storage Sync Service||100 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||30 server endpoints||Yes|
|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||1 million objects||Yes|
|Maximum object (directories and files) security descriptor size||64 KiB||Yes|
|File size||100 GiB||No|
|Minimum file size for a file to be tiered||64 KiB||Yes|
|Concurrent sync sessions||V4 agent and later: The limit varies based on available system resources.
V3 agent: Two active sync sessions per processor or a maximum of eight active sync sessions per server.
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:
- Initial one-time provisioning: To optimize performance on initial provisioning, refer to Onboarding with Azure File Sync for the optimal deployment details.
- 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
|CPU||64 Virtual Cores with 64 MiB L3 cache|
|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||25 million objects|
|Dataset Size||~4.7 TiB|
|Average File Size||~200 KiB (Largest File: 100 GiB)|
|Upload Throughput||20 objects per second|
|Namespace Download Throughput*||400 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.
|Number of objects synced||125,000 objects (~1% churn)|
|Dataset Size||50 GiB|
|Average File Size||~500 KiB|
|Upload Throughput||30 objects per second|
|Full Download Throughput*||60 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.
Send feedback about: