ECR pricing: what to model (storage + transfer)

ECR costs are easiest to estimate with a two-part model: storage (GB-month) plus transfer. The right answer depends heavily on your retention policy and where your workloads run (same region vs cross-region vs internet).

1) Storage (GB-month): how many images you keep

Storage grows with tags retained and average image size, not with how often you deploy.
CI pipelines that push many tags/day create fast growth without retention policies.
Multi-arch images can duplicate stored bytes if you keep separate variants per architecture.

Guide: estimate ECR storage (GB-month).

2) Transfer: where pulls happen matters

Pulls in the same region are usually cheaper than cross-region pulls.
Cross-region replication can reduce pull transfer but increases storage (you store multiple copies).
Internet paths and NAT gateways can add additional cost layers in real architectures.

If you use private subnets, include NAT gateway processed GB as a separate line item.

A fast estimation workflow

Estimate storage: average image size × retained images (by repo class).
Estimate pull volume: pulls/day × average image size (and cache hit behavior).
Apply your effective $/GB-month and $/GB transfer for the actual traffic path.
Validate with a real week of pull patterns (CI + cluster autoscaling days).

ECR cost calculator ECR cost optimization

Common spike drivers

No retention: old tags accumulate forever.
Frequent rebuilds: pushing many images/day grows storage quickly.
Cluster scaling: new nodes pull images repeatedly (cold cache).
Cross-region pulls: replication and multi-region clusters change transfer costs.

How to estimate pull transfer (fast model)

Pull GB/day ~= (pulls/day) × (avg image size GB) × (1 - cache hit rate)
If nodes re-pull on every deploy, your effective cache hit rate can be near zero during busy windows.
Include CI separately: CI often pulls more frequently than production.

Transfer is a boundary problem. If your pulls go through NAT or cross-region, model those paths explicitly.

Retention policy vs rollback needs (practical)

CI tags: keep a short window (days) and rely on rebuildability.
Release tags: keep a longer window (weeks/months) for rollbacks.
Base images: pin carefully; a few large images can dominate storage.

Validation checklist

Validate storage with a few representative repos (image size and retention window).
Validate transfer boundary: same region vs cross-region vs internet makes a huge difference.
Validate pull behavior during autoscaling and CI bursts (not just steady state).