Scalability and performance targets for standard storage accounts

This reference details scalability and performance targets for Azure Storage. 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.

Make 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.

Scale targets for standard storage accounts

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.

Resource Default limit
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
Maximum number of virtual network rules per storage account 200
Maximum number of IP address rules per storage account 200

1Azure Storage standard 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 your storage account has read-access enabled with geo-redundant storage (RA-GRS) or geo-zone-redundant storage (RA-GZRS), then the egress targets for the secondary location are identical to those of the primary location. Azure Storage replication options include:


Microsoft recommends 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, see Upgrade to a general-purpose v2 storage account.

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.

See also