AWS ECR Cost Calculator

Separate quiet image inventory from bursty pull behavior

ECR costs usually have one slow-moving line item and one bursty one. Stored GB-month grows with image retention and tag sprawl. Transfer or pull-driven cost changes when CI, release automation, or clusters pull far more often than teams expect.

• Measure average stored image size and retained tag count by repository to understand the steady baseline.
• Estimate pull behavior separately for CI pipelines, cluster nodes, and any public or cross-region consumers.
• Keep replication, scanning, and downstream compute-network spend outside this page unless you model them explicitly.

Where ECR estimates usually drift

• Retention sprawl: stale tags and repeated builds grow stored GB-month quietly over time.
• Release-day pull storms: node churn, rollouts, and CI rebuilds create transfer spikes that averages hide.
• Cache assumptions: local node cache or pull-through cache behavior changes real pull volume a lot.
• Boundary confusion: cluster egress, NAT, and runtime networking are adjacent costs, not registry cost.

How to reconcile the estimate with production evidence

1. Compare stored GB-month against actual repository inventory rather than raw image count alone.
2. Review CI and deployment windows to see whether pull bursts explain the transfer portion of the bill.
3. Separate in-region cached pulls from cross-region, internet, or public pull paths before changing prices.
4. Run a release-week or release-month scenario if the platform behaves very differently during rollouts.

What to do when storage or transfer dominates

If storage dominates, clean up retention policy and tag hygiene. If transfer dominates, investigate image size, rollout frequency, and cache efficiency. If neither explains the broader platform total, the next review belongs with cluster networking, NAT, or workload runtime rather than ECR alone.

Next steps