Azure Storage scalability and performance targets for standard storage accounts
This article details the scalability and performance targets for standard 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 (requests) being sent to a storage account. The egress limit refers to all data (responses) being received from a storage account.
|Number of storage accounts per region per subscription, including both standard and premium accounts||250|
|Max storage account capacity||2 PB for US and Europe, 500 TB for all other regions including UK|
|Max 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|
|Max ingress1 per storage account (US Regions)||10 Gbps if RA-GRS/GRS enabled, 20 Gbps for LRS/ZRS2|
|Max ingress1 per storage account (Non-US regions)||5 Gbps if RA-GRS/GRS enabled, 10 Gbps for LRS/ZRS2|
|Max egress for general-purpose v2 and Blob storage accounts (all regions)||50 Gbps|
|Max egress for general-purpose v1 storage accounts (US regions)||20 Gbps if RA-GRS/GRS enabled, 30 Gbps for LRS/ZRS 2|
|Max egress for general-purpose v1 storage accounts (Non-US regions)||10 Gbps if RA-GRS/GRS enabled, 15 Gbps for LRS/ZRS 2|
1 Azure 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.
Microsoft recommends using a general-purpose v2 storage account for most scenarios. You can easily upgrade a general-purpose v1 or 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. See Azure Storage Pricing for information on volume 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.
Storage resource provider scale limits
The following limits apply only when performing management operations 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
|Max size of single blob container||Same as max storage account capacity|
|Max number of blocks in a block blob or append blob||50,000 blocks|
|Max size of a block in a block blob||100 MiB|
|Max size of a block blob||50,000 X 100 MiB (approx. 4.75 TiB)|
|Max size of a block in an append blob||4 MiB|
|Max size of an append blob||50,000 x 4 MiB (approx. 195 GiB)|
|Max size of a page blob||8 TiB|
|Max 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|
|Max size of a file share||5 TiB||5 TiB|
|Max size of a file in a file share||1 TiB||1 TiB|
|Max number of files in a file share||No limit||No limit|
|Max IOPS per share||1000 IOPS||5120 IOPS baseline
15,360 IOPS with burst
|Max number of stored access policies per file share||5||5|
|Target throughput for single file share||Up to 60 MiB/second||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|
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 subscription||15 Storage Sync Services per region||No|
|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||200,000 objects||Yes|
|Maximum object (directories and files) name length||255 characters||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: Limit varies based on available system resources.
V3 agent: 2 active sync sessions per processor or maximum of 8 active sync sessions per server
Azure Queue storage scale targets
|Max size of single queue||500 TiB|
|Max size of a message in a queue||64 KiB|
|Max number of stored access policies per queue||5|
|Maximum request rate per storage account||20,000 messages per second assuming 1 KiB message size|
|Target throughput for single queue (1 KiB messages)||Up to 2000 messages per second|
Azure Table storage scale targets
|Max size of single table||500 TiB|
|Max size of a table entity||1 MiB|
|Max number of properties in a table entity||255 (including 3 system properties: PartitionKey, RowKey and Timestamp)|
|Max number of stored access policies per table||5|
|Maximum request rate per storage account||20,000 transactions per second (assuming 1 KiB entity size)|
|Target throughput for single table partition (1 KiB entities)||Up to 2000 entities per second|