Azure Container Registry Pricing: Tier Limits, Storage, and Geo-Replication
If you are evaluating Azure Container Registry for real production usage, the cleanest starting point is not the tier table by itself. The real budgeting decision is usually whether your registry problem is storage growth, pull pressure, or cross-region delivery.
Use this page when you need to show whether ACR spend is really coming from stored layers, pull churn during deploys, cross-region delivery, or the capability jump from Standard to Premium.
Quick tier snapshot: what most teams need first
If you searched for ACR pricing because you need a quick budget answer, start here. Price per day is the daily SKU charge, but the budget decision still depends on included storage, geo-replication, and throughput. Basic includes 10 GiB, Standard includes 100 GiB, and Premium includes 500 GiB. Geo-replication is only supported in Premium, and Premium offers the highest throughput headroom for concurrent pull bursts.
- Basic: includes 10 GiB of storage and usually fits low-volume, single-region registries.
- Standard: includes 100 GiB of storage and is often the practical production starting point.
- Premium: includes 500 GiB of storage, adds geo-replication, and carries the highest throughput ceilings.
- Beyond the included storage: additional retained storage can continue to grow the bill separately from the tier fee.
- Outside the registry fee: cross-region pulls and internet delivery should still be checked as network charges.
This page was updated on 2026-06-19 against the current Azure pricing page and the latest Microsoft Learn ACR SKU limits guidance.
What the ACR tier changes, and what it does not
Basic, Standard, and Premium are best understood as throughput and capability choices first. The tier changes service limits, concurrency headroom, and advanced features such as geo-replication or private-networking-related patterns. It does not remove the need to understand what your registry is storing, how often clients pull, or which regions those pulls cross.
- Basic fits small teams and low pull pressure, especially when usage stays single-region and operational spikes are rare.
- Standard is usually the production choice when pull throughput or CI reliability matters more than the lowest entry price.
- Premium makes sense when architecture, not just traffic, requires features such as geo-replication or stronger enterprise controls.
Tier selection affects features and throughput ceilings, but monthly spend still tracks stored GB-month, pull behavior, and billed transfer paths.
How to think about the ACR Basic monthly price
Many pricing searches are really asking a narrower question: what does ACR Basic cost per month? The safest answer is not a single hard-coded dollar amount, because Azure pricing varies by region, currency, and agreement. The reliable budgeting pattern is to treat Basic as the daily SKU charge converted into a monthly estimate, then add any storage above the included allowance and any separate networking charges that your topology creates.
- Use Basic when registry traffic is modest and you do not need Premium-only features such as geo-replication.
- Watch extra storage when retained layers, hotfix tags, and multi-architecture images outgrow the included 10 GiB.
- Watch networking when AKS, build agents, or downstream consumers pull across regions or over internet paths.
- Watch reliability when CI retries and node churn start turning a cheap SKU into an operational bottleneck.
Build the first estimate from registry behavior
A usable ACR estimate starts by defining the registry as an operating system component, not as a flat storage bucket. You need to know what is stored, who consumes it, where those consumers run, and which periods create the worst pull pressure.
- Registry scope: separate prod, staging, and dev behavior if they do not share the same repositories or pull patterns.
- Stored GB-month: measure retained image data over time, not just what was pushed this month.
- Pull volume: separate normal deploy activity from CI peaks, autoscaling events, and incident-driven node churn.
- Regional topology: keep same-region pulls, cross-region pulls, internet pulls, and replication in separate lines.
- Feature trigger: document whether the pressure is really about throughput, multi-region access, or Premium-only capabilities.
Two tools help anchor this first estimate: storage cost (GB-month) for retained data and data egress cost for billed outbound paths.
How storage, pull storms, and transfer shape the bill together
The biggest mistake on ACR pages is to explain storage, pulls, and egress as separate checkboxes. In practice, they reinforce each other. Retention policy decides your baseline. Pull activity decides whether the registry behaves like a quiet artifact store or a high-churn delivery surface. Regional topology decides whether those pulls stay local or turn into a second transfer bill.
- Storage baseline: retained image data usually grows because old tags, hotfix branches, and multi-architecture artifacts stay longer than teams expect.
- Layer sharing: storage is not a simple tags-times-size formula because common layers are reused across images.
- Pull storms: CI retries, fresh nodes, autoscaling, and incident recovery can create short windows where pull demand is far above the weekly average.
- Warm caches: node-local cache behavior matters, because assuming every deploy hits ACR will overstate some workloads and understate others.
- Transfer paths: same-region pulls, cross-region pulls, internet delivery, and replication should never be priced with one blended assumption.
- Base images vs app images: model them separately when retention and pull frequency are different.
- Compressed pull size: use actual pulled size when possible instead of repository uncompressed size.
- Cross-region clusters: treat them as transfer decisions, not as invisible internal traffic.
- Geo-replication: model replication as its own operational and transfer decision instead of assuming Premium is just a bigger version of Standard.
Read the official pricing table without underestimating the bill
The official Azure pricing table is the right source for current regional pricing, but it does not answer the budgeting question by itself. It tells you what the registry SKU and storage bands cost. It does not tell you whether your real bill shape is being driven by retention drift, pull concurrency, extra replicas, or transfer paths outside the registry fee.
- Included storage is not your final storage cost: the tier allowance is only the starting buffer for retained layers.
- Premium is not just a bigger Standard: geo-replication changes the geographic shape of the estimate, not only the feature list.
- Throughput limits still matter: API and pull pressure can become reliability constraints before they look like storage problems.
- Transfer remains a separate review: a cheap registry tier does not erase cross-region or internet distribution cost.
Tier snapshot for budgeting decisions
| Tier | Included storage | Best fit | Watch-outs | Upgrade trigger |
|---|---|---|---|---|
| Basic | 10 GiB | Small teams, low pull pressure, single-region usage | Can outgrow storage and throughput headroom quickly | CI churn, scale-outs, or repeated pull bottlenecks |
| Standard | 100 GiB | Many production registries without Premium-only features | Still does not solve multi-region design by itself | Need for geo-replication, private endpoints, or higher concurrency |
| Premium | 500 GiB | High-scale or multi-region registries with enterprise controls | Higher tier fee can hide topology inefficiency if you model it lazily | Stay only if the feature set and reliability boundary are genuinely needed |
When a tier upgrade is justified, and when it is hiding another problem
Tier upgrades usually pay off when the registry has become a reliability bottleneck, not when someone sees a bigger storage number and assumes the answer is to move upward. The registry tier is often the symptom review. The real question is whether throughput pressure, multi-region access, or feature requirements justify the change.
- Basic to Standard is usually justified when normal CI or deploy traffic is already hitting throughput or concurrency pain.
- Standard to Premium makes sense when multi-region workloads, geo-replication, or enterprise access patterns are operationally necessary.
- Do not upgrade blindly when the real issue is cross-region topology or pull inefficiency. In that case the architecture can keep the bill high even after the tier changes.
| Question | If yes | If no |
|---|---|---|
| Is pull throughput a normal reliability issue? | Review a tier move sooner | Focus on retention and topology first |
| Do workloads run across multiple regions? | Model geo-replication and cross-region pull paths explicitly | Keep single-region assumptions separate and simpler |
| Is egress dominating more than storage? | Review architecture and pull location before upgrading | Tier choice may matter more than transfer path |
What usually goes wrong, and how to validate the estimate
Most weak ACR estimates fail because teams count artifacts but do not measure behavior. They know how many repositories they have, but they do not know how retention, peak pull windows, and billed transfer interact.
- Counting tags instead of actual retained layer storage.
- Treating a quiet week of cached pulls as the normal baseline.
- Ignoring CI retries, node churn, or incident recovery when modeling pull volume.
- Using one transfer assumption across same-region, cross-region, and internet consumers.
- Assuming Premium is the answer when the bill is really being driven by topology.
Before you trust the model, validate it against real operating signals.
- Validate retention policy, cleanup behavior, and whether old layers remain billable longer than expected.
- Sample pull counts during peak CI windows, scale-outs, and recovery events instead of only during calm periods.
- Validate image size using compressed pull size where possible.
- Validate which transfer paths are actually billed: same-region, cross-region, internet, and replication.
- Validate whether the upgrade trigger is reliability, feature need, or a hidden architecture issue.
- Validate whether your current usage really requires Premium-only features or only cleaner topology and retention discipline.
A good sign-off rule is simple: every major number in the estimate should map back to registry stats, workload behavior, or billing data. If a large number only exists because it felt directionally right, the estimate is still too weak for budget or architecture decisions.
Next actions if you are evaluating ACR spend
If the registry estimate is being reviewed alongside cluster cost, pair this page with the AKS pricing guide so pull behavior and node churn are not analyzed in isolation.
Related Azure service guides
Teams reviewing registry cost usually end up validating adjacent delivery and event-ingestion paths in the same budgeting pass.
- Azure Load Balancer pricing: use this when image delivery or service exposure patterns make request and egress paths part of the same review.
- Azure Event Hubs pricing: use this when container workloads also depend on streaming or replay-heavy event pipelines.