Azure Container Registry SKU features and limits

Azure Container Registry is available in multiple SKUs. These SKUs, also known as pricing plans or tiers, support predictable pricing and align to different capacity and usage patterns of your private container registry in Azure.

When you create a registry, you select a Pricing Plan that determines the features and limits of your registry. Choose the plan that aligns with your expected usage patterns, such as the number of images, storage needs, and performance requirements.

Azure Container Registry offers three Pricing Plan options: Basic, Standard, and Premium. Each SKU offers a different set of features and limits to accommodate various scenarios, from development and testing to production workloads.

Each SKU includes a specific amount of free storage, with additional storage available at a per-GB rate. Each SKU also has a different maximum storage limit.

The Basic, Standard, and Premium SKUs all provide the same programmatic capabilities and data plane APIs. They also all benefit from image storage managed entirely by Azure, and all SKUs have zone redundancy enabled by default in supported regions. However, the Premium SKU enables a wider range of features and has higher limits.

SKU features and limits

The following table details the features and registry limits of the Basic, Standard, and Premium SKUs.

¹ Storage included in the daily rate for each tier. Additional storage may be used, up to the registry storage limit, at an additional daily rate per GiB. For rate information, see Azure Container Registry pricing. If you need storage beyond the registry storage limit, please contact Azure Support.

² Individual actions of content/delete, content/read, content/write, metadata/read, metadata/write correspond to the limit of repositories per non-Microsoft Entra token scope map.

ACR also has the following image pull and push performance limits.

API request rate limits

In addition to the storage and feature limits in the preceding table, Azure Container Registry enforces request rate limits on registry APIs. Rate limits are measured in requests per minute (r/m) and are determined by your registry's SKU. When your request rate exceeds a limit, the registry returns an HTTP 429 Too Many Requests error. The response includes a Retry-After header that indicates how long to wait before retrying.

Requests are throttled in the following operation categories. Each category is defined by the HTTP methods used by the registry's data plane APIs:

The following request rate limits are enforced for each SKU:

Per-registry and per-identity limits

• Per registry limits apply to the combined request rate from all clients and identities to a single registry.
• Per identity per registry limits apply to the request rate from a single identity to a single registry. Per identity limits prevent a single client, such as a vulnerability scanner or a misconfigured deployment, from consuming a registry's entire request capacity. Per identity per registry limits are tracked separately for each registry, so an identity that authenticates to multiple registries isn't throttled across those registries together.
• For a registry that has unauthenticated anonymous pull access enabled, all anonymous (unauthenticated) requests are throttled together as a single identity for that single registry.
• For a registry that has the admin user account enabled, all requests that authenticate with admin credentials are throttled together as a single identity for that single registry. The admin account has two passwords (password and password2), but both passwords share the same identity for throttling purposes. If multiple clients or automation workflows authenticate with admin credentials, they all consume the same per-identity rate limit bucket.
• OAuth authentication and authorization requests are throttled per registry only, without separate per identity per registry limits.

Requests that count against multiple limits

Some requests count against more than one operation category, and a request is throttled if any applicable limit is exceeded. For example, a request to list the referrers of a manifest is both a ListReferrers request and a DataplaneRead request, and it consumes capacity from both limits. If your registry has already exhausted its DataplaneRead limit, referrers requests are also throttled, even if the ListReferrers limit hasn't been reached. Likewise, a high rate of referrers requests reduces the DataplaneRead capacity that remains for other read operations, such as image pulls.

How rate limits are enforced

Rate limits are enforced by using a token bucket algorithm. Each operation category has a bucket of request capacity that refills continuously at the rate shown in the preceding table. This approach is designed to tolerate bursty workloads:

• Short bursts above the steady rate are allowed. A spike of requests, such as a large-scale deployment pulling images across many nodes at the same time, succeeds as long as capacity remains in the bucket.
• Sustained traffic must stay at or below the limit. If a burst empties the bucket, subsequent requests are rejected with 429 Too Many Requests until capacity refills, which can result in requests being throttled for up to a full minute after a large burst.

The Retry-After value in a 429 response indicates the number of seconds remaining until the current throttling period ends, so the value counts down across consecutive throttled requests rather than staying fixed. For example, the first throttled response might return Retry-After: 60. If you retry 10 seconds later and the request is still throttled, the response returns Retry-After: 50. Because the value is calculated dynamically for each request, don't take a dependency on a fixed Retry-After value.

When you receive a 429 response, honor the Retry-After header and implement retry logic with exponential backoff. For more mitigation guidance, see Throttling and bandwidth constraints.

Occasionally, during a sudden, aggressive ramp-up from a low baseline (such as a thundering herd), you might temporarily observe lower throughput than the published limits while the registry's infrastructure scales out to meet demand.

For pricing information on each of the Azure Container Registry SKUs, see Container Registry pricing. For details about pricing for data transfers, see Bandwidth pricing.

Registry image pull and push performance limits

API concurrency, bandwidth throughput, and throttling during high-volume operations primarily affect image pull and push performance. Your registry SKU, network configuration, and client configuration determine these factors.

API concurrency and bandwidth throughput limits

Your SKU determines API concurrency and bandwidth throughput. Higher SKUs support more concurrent operations and greater bandwidth for data-plane operations like listing, deleting, pushing, and pulling images.

The following factors affect API concurrency and bandwidth throughput during image pulls and pushes:

• Number and size of image layers
• Reuse of layers across images in the registry
• Additional API calls required for each operation
• Scale of concurrent deployments, such as Kubernetes deployments pulling images across multiple nodes simultaneously

The following client environment factors affect performance:

• Docker daemon or Podman configuration for concurrent operations
• Container runtime configuration, such as containerd or CRI-O concurrency settings
• Cluster configuration or cluster data plane settings

The following network factors affect performance:

• Network bandwidth and latency for the network hops from clients to the registry
• Client-side network configuration, such as firewall rules and proxy settings
• Geographic distance to the registry or nearest replica if geo-replicated

For more information about API operations that happen during image push and pull, see the Docker HTTP API V2 documentation. For help troubleshooting, see Troubleshoot registry performance.

Throttling and bandwidth constraints

During periods of high request volume, you might encounter throttling with an HTTP 429 Too many requests error or slow bandwidth throughput. To mitigate these problems:

• Implement retry logic with exponential backoff and jitter.
• Reduce the rate of concurrent requests.
• Space out large-scale deployments to reduce simultaneous image pulls across multiple nodes.
• If you're experiencing throttling after a sudden increase in traffic from a previously low baseline, you might temporarily see lower throughput while the registry's infrastructure scales out to meet demand.

Show registry usage

Usage information helps you make decisions about changing the SKU when your registry nears a limit, and helps you manage consumption.

To get a snapshot of your registry's current consumption of storage and other resources, compared with the limits for that registry's SKU, check the Overview page of your registry in the Azure portal. You can also use APIs such as az acr show-usage (Azure CLI), Get-AzContainerRegistryUsage (Azure PowerShell), or Registries - List Usages (REST API).

Depending on your registry's SKU, usage information includes some or all of the following, along with the limit in that SKU:

• Storage consumed in bytes
• Number of webhooks
• Number of geo-replications (includes the home replica)
• Number of private endpoints
• Number of IP access rules
• Number of virtual network rules

In a geo-replicated registry, storage usage is shown for the home region. Multiply by the number of replicas for the total amount of storage.

Change registry SKU

You can change a registry's SKU in the Azure portal or by using Azure CLI or Azure PowerShell. You can move freely between SKUs as long as the SKU you're switching to has the required maximum storage capacity.

When you change a registry's SKU, there's no downtime or impact on registry operations. However, if you move from Premium to a lower SKU, features specific to premium are disabled. In some cases, you need to remove resources related to these features before you can switch SKUS. For example, you must delete any geo-replications or connected registries before you can switch from Premium to Standard or Basic.

To change SKUs in the Azure portal, go to your container registry. In the service menu, under Settings, select Properties. Change the option for Pricing plan, and then select Save.

To change SKUs by using the Azure CLI, use the az acr update command. For example, to switch to Premium:

az acr update --name myContainerRegistry --sku Premium

To change SKUs by using Azure PowerShell, use the Update-AzContainerRegistry cmdlet. For example, to switch to Premium:

Update-AzContainerRegistry -ResourceGroupName myResourceGroup -Name myContainerRegistry -Sku Premium

Related content

For information about upcoming Azure Container Registry features, see the Roadmap on GitHub.