Azure Storage scalability and performance targets for standard 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.
Standard storage account scale limits
The following table describes default limits for Azure Storage. 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, which includes 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.
Premium storage account scale limits
Premium 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 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 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 60 MiB per second, or up to 500 requests per second|
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.
|Resource||Standard file shares||Premium file shares (preview)|
|Minimum size of a file share||No minimum; pay as you go||100 GiB|
|Maximum size of a file share||5 TiB||5 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||5,120 IOPS baseline
15,360 IOPS with burst
|Maximum number of stored access policies per file share||5||5|
|Target throughput for a single file share||Up to 60 MiB/sec||Up to 612 MiB/sec (provisioned)|
|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
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||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||4 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 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 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|
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.