Azure Storage scalability and performance targets for storage accounts
This article details the scalability and performance targets for Azure storage accounts. The scalability and performance targets listed here are high-end targets, but are achievable. In all cases, the request rate and bandwidth achieved by your storage account depends upon the size of objects stored, the access patterns utilized, and the type of workload your application performs.
Be sure to test your service to determine whether its performance meets your requirements. If possible, avoid sudden spikes in the rate of traffic and ensure that traffic is well-distributed across partitions.
When your application reaches the limit of what a partition can handle for your workload, Azure Storage begins to return error code 503 (Server Busy) or error code 500 (Operation Timeout) responses. If 503 errors are occurring, consider modifying your application to use an exponential backoff policy for retries. The exponential backoff allows the load on the partition to decrease, and to ease out spikes in traffic to that partition.
Storage account scale limits
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 PiB for US and Europe, and 500 TiB for all other regions (including the UK)1|
|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, Europe regions)||25 Gbps|
|Maximum ingress1 per storage account (regions other than US and Europe)||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 capacity limits and higher limits for ingress by request. To request an increase in account limits for ingress, contact Azure Support. For more information, see Announcing larger, higher scale storage accounts.
2 If you have Read-access enabled (RA-GRS/RA-GZRS), the egress targets for the secondary location are identical to those of the primary location. Azure Storage replication options include:
- Locally redundant storage (LRS)
- Zone-redundant storage (ZRS)
- Geo-redundant storage (GRS)
- Read-access geo-redundant storage (RA-GRS)
- Geo-zone-redundant storage (GZRS)
- Read-access geo-zone-redundant storage (RA-GZRS)
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.
Premium performance storage account scale limits
Premium performance block blob storage
A premium performance block blob storage account is optimized for applications that use smaller, kilobyte range, objects. It's ideal for applications that require high transaction rates or consistent low-latency storage. Premium performance block blob storage is designed to scale with your applications. If you plan to deploy application(s) that require hundreds of thousands of requests per second or petabytes of storage capacity, please contact us by submitting a support request in the Azure portal.
Premium performance FileStorage
Premium files use a unique storage account called FileStorage. This account type is designed for workloads with high IOPS, high throughput with consistent low-latency. Premium file storage scales with the provisioned share size.
|Max provisioned size||100 TiB|
For premium file share scale targets, see the Premium files scale targets section.
Premium performance page blob storage
Premium performance, general-purpose v1, or v2 storage accounts have the following scalability targets:
|Total account capacity||Total bandwidth for a locally redundant storage account|
|Disk capacity: 35 TB
Snapshot capacity: 10 TB
|Up to 50 gigabits per second for inbound1 + outbound2|
1 All data (requests) that are sent to a storage account
2 All data (responses) that are received from a storage account
If you are using premium performance storage accounts for unmanaged disks and your application exceeds the scalability targets of a single storage account, you might want to migrate to managed disks. If you don't want to migrate to managed disks, build your application to use multiple storage accounts. Then, partition your data across those storage accounts. For example, if you want to attach 51-TB disks across multiple VMs, spread them across two storage accounts. 35 TB is the limit for a single premium storage account. Make sure that a single premium performance storage account never has more than 35 TB of provisioned disks.
Storage resource provider scale limits
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|
Azure Blob storage scale targets
|Maximum size of single blob container||Same as maximum storage account capacity|
|Maximum number of blocks in a block blob or append blob||50,000 blocks|
|Maximum size of a block in a block blob||100 MiB|
|Maximum size of a block blob||50,000 X 100 MiB (approximately 4.75 TiB)|
|Maximum size of a block in an append blob||4 MiB|
|Maximum size of an append blob||50,000 x 4 MiB (approximately 195 GiB)|
|Maximum size of a page blob||8 TiB|
|Maximum number of stored access policies per blob container||5|
|Target throughput for single blob||Up to storage account ingress/egress limits1|
1 Single object throughput depends on several factors, including, but not limited to: concurrency, request size, performance tier, speed of source for uploads, and destination for downloads. To take advantage of high-throughput block blob performance enhancements, use a Put Blob or Put Block request size of > 4 MiB (> 256 KiB for premium-performance block blob storage or for Data Lake Storage Gen2).
Azure Files scale targets
For more information on the scale and performance targets for Azure Files and Azure File Sync, see Azure Files scalability and performance targets.
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.
Standard file shares larger than 5 TiB are in preview and have certain limitations. For a list of limitations and to onboard to the preview of these larger file share sizes, see the Standard file shares section of the Azure Files planning guide.
|Resource||Standard file shares||Premium file shares|
|Minimum size of a file share||No minimum; pay as you go||100 GiB; provisioned|
|Maximum size of a file share||5 TiB (GA), 100 TiB (preview)||100 TiB|
|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 (GA), 10,000 IOPS (preview)||100,000 IOPS|
|Maximum number of stored access policies per file share||5||5|
|Target throughput for a single file share||Up to 60 MiB/sec (GA), up to 300 MiB/sec (preview)||See premium file share ingress and egress values|
|Maximum egress for a single file share||See standard file share target throughput||Up to 6,204 MiB/s|
|Maximum ingress for a single file share||See standard file share target throughput||Up to 4,136 MiB/s|
|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|
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 max IOPs you can get from that share is 15,000.
Premium file share limits
Additional premium file share level limits
|Minimum size increase/decrease||1 GiB|
|Baseline IOPS||1 IOPS per GiB, up to 100,000|
|IOPS bursting||3x IOPS per GiB, up to 100,000|
|Egress rate||60 MiB/s + 0.06 * provisioned GiB|
|Ingress rate||40 MiB/s + 0.04 * provisioned GiB|
File level limits
|Area||Premium file||Standard file|
|Size||1 TiB||1 TiB|
|Max IOPS per file||5,000||1,000|
|Egress||300 MiB/sec||See standard file throughput values|
|Ingress||200 MiB/sec||See standard file throughput values|
|Throughput||See premium file ingress/egress values||Up to 60 MiB/sec|
Azure File Sync scale targets
Azure File Sync has been designed with the goal of limitless usage, but limitless usage is not always possible. The following table indicates the boundaries of Microsoft's testing and also indicates which targets are hard limits:
|Storage Sync Services per region||20 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|
|File system objects (directories and files) per sync group||50 million objects||No|
|Maximum number of file system objects (directories and files) in a directory||5 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.
An Azure File Sync endpoint can scale up to the size of an Azure file share. If the Azure file share size limit is reached, sync will not be able to operate.
Azure Queue storage scale targets
|Maximum size of a single queue||500 TiB|
|Maximum size of a message in a queue||64 KiB|
|Maximum number of stored access policies per queue||5|
|Maximum request rate per storage account||20,000 messages per second, which assumes a 1-KiB message size|
|Target throughput for a single queue (1-KiB messages)||Up to 2,000 messages per second|
Azure Table storage scale targets
|Maximum size of a single table||500 TiB|
|Maximum size of a table entity||1 MiB|
|Maximum number of properties in a table entity||255, which includes three system properties: PartitionKey, RowKey, and Timestamp|
|Maximum total size of property values in an entity||1 MiB|
|Maximum total size of an individual property in an entity||Varies by property type. For more information, see Property Types in Understanding the Table Service Data Model.|
|Maximum number of stored access policies per table||5|
|Maximum request rate per storage account||20,000 transactions per second, which assumes a 1-KiB entity size|
|Target throughput for a single table partition (1 KiB-entities)||Up to 2,000 entities per second|