Azure Container Registry Pricing & Cost (Basic, Standard, Premium)
Container registries are "storage + transfer". A clean estimate separates what you store from what you pull, and splits transfer by where it goes (same region, cross-region, internet). ACR pricing tiers (Basic/Standard/Premium) change limits and features, but the cost model still depends on storage, pulls, and egress. Most surprises come from retention drift and pull storms (CI peaks, autoscaling, node churn).
ACR pricing tiers (Basic, Standard, Premium)
- Basic: entry tier for low traffic and small teams.
- Standard: higher throughput and scale for production workloads.
- Premium: advanced features (geo-replication, private networking) with the highest limits.
Tier selection affects limits and features, but your monthly spend still comes from stored GB-month, pull volume, and billed data transfer paths.
0) Define your registry scope
- Environments: prod + staging + dev registries (or one shared registry with multiple repos).
- Regions: cross-region clusters and geo-replication change transfer patterns.
- Consumers: AKS nodes, VM scale sets, and external runners can each have different pull behavior.
1) Storage (GB-month)
Build a GB-month estimate from retention: average image size * tags retained * repos. Then adjust with reality: images share layers, so storage is often less than "tags * size" when tags reuse common layers.
Tool: Storage cost (GB-month).
- If you store many versions, keep a separate line for "base images" and "app images" (they behave differently).
- Model a growth rate if you keep long-lived tags (release tags, hotfix branches, multiple architectures).
2) Pull volume (the hidden spike)
Pulls scale with CI/CD, autoscaling, and node churn. A good first model is: deployments/day * pulls per deployment * image size. Add a multiplier for cache misses and fresh nodes.
- CI peaks: parallel builds and frequent pipeline retries can create pull storms.
- Cluster scale-outs: new nodes pull many images at once (worst during incidents).
- Warm caches: node-local caching can reduce pulls dramatically; do not assume every pod pull hits ACR.
3) Data transfer (egress)
Transfer is often the second bill: cross-region pulls, external runners, and any delivery outside your region. Split outbound transfer by destination and validate which paths are billed.
Tool: Data egress cost calculator.
4) Cross-region and geo-replication effects
- If clusters pull from a registry in another region, model that as cross-region transfer, not "free internal traffic".
- If you enable geo-replication, treat replication as its own line item (replicated data and any operational overhead).
Worked estimate template (copy/paste)
- Storage GB-month = avg stored GB over month (validate with registry stats if possible)
- Pull GB/month = pulls/month * avg image size (GB) (baseline + peak)
- Egress GB/month = pull GB to destinations that are billed as outbound (cross-region/internet)
Common pitfalls
- Retention drift: old tags and layers kept forever.
- Assuming tags * size equals storage (layer sharing changes the math).
- Ignoring CI and scale-out peaks (pull storms are the peak scenario).
- Cross-region pulls hidden inside "it's internal" assumptions.
- Missing that egress can dominate if you pull from outside the region.
How to validate
- Validate retention policy and garbage collection behavior (old layers keep storage high).
- Sample pull counts during peak CI windows and cluster scale-out events.
- Validate where transfer is billed (same-region vs cross-region vs internet).