Estimate ECR storage (GB-month) from images and retention

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-01-27. Editorial policy and methodology.

This page is the storage-measurement workflow, not the bill-boundary page: the goal is to turn repo classes, image sizes, push frequency, retention windows, and multi-arch duplication into a defendable GB-month model.

If you are still deciding which costs belong inside the ECR bill versus beside it, go back to the pricing guide first.

Evidence pack before you estimate anything

Repo classes: CI artifact repos, release repos, and large shared base-image repos.
Image sizes: representative sizes by repo class instead of one blended average.
Push frequency: how many new tags are created per day or per release window.
Retention windows: days, tag counts, and whether untagged images are actually deleted.
Multi-arch duplication: whether one logical release becomes two or more retained variants.

Step 1: define repo classes (do not use one average)

CI artifacts: many tags/day, short retention (should be cheap if retention works).
Releases: fewer tags, longer retention (rollback needs).
Base images: few images but large and shared across many services.

Fast model (good for budgeting)

Stored GB-month ~= avg image size (GB) × retained images (count)
Retained images per repo ~= tags retained × (variants per tag)
If you store multi-arch variants separately, variants per tag can be 2 (amd64 + arm64) or more.

Better model (push frequency + retention days)

This model is useful for repos where CI pushes constantly.

Pushes/day = N
Retention days = D
Retained images ~= N × D (per repo or repo class)
Stored GB ~= retained images × avg image size

Worked example

Avg image size: 0.8 GB
CI pushes: 40 images/day
Retention: 14 days
Retained images ~= 40 × 14 = 560 images
Stored GB ~= 560 × 0.8 ~= 448 GB-month (order-of-magnitude)

Common multipliers (what makes storage explode)

No retention: “keep forever” means storage grows without bound.
Multi-arch: storing multiple variants can multiply retained GB.
Large base images: shared images can dominate storage even if app images are small.
Environment duplication: separate repos/tags for prod/staging/dev with independent retention.

Separate baseline storage from growth windows

Baseline storage: stable release repos, shared base images, and predictable retention windows.
CI growth windows: bursts from frequent builds, temporary branches, and test environments.
Release growth windows: rollout weeks where rollback depth and parallel versions both increase retained bytes.
Architecture growth windows: temporary multi-arch duplication or replicated rollout patterns that inflate stored GB-month for a limited period.

What to measure first (so your estimate converges)

Average image size by repo class (CI vs release vs base images).
Push frequency per repo (images/day) for the top 10 repos by activity.
Retention rules (days or tags) and whether untagged images are deleted.
Whether multi-arch variants are retained equally (amd64 + arm64 doubles storage if both are kept).

Turn storage into cost

Use AWS ECR Cost Calculator with your stored GB-month estimate and your effective $/GB-month.

When the GB-month model is ready to hand off

Go back to ECR pricing if you still are not sure which costs belong to the registry bill versus the surrounding network path.
Move to ECR cost optimization when you can defend the dominant driver and want to change retention, image size, pull behavior, or replication strategy.

Validation checklist

Pick 3 representative repos and measure average image size and retained tags.
Validate retention policies actually delete old tags (and untagged images).
Validate multi-arch behavior (are variants stored separately and retained equally?).
After changes, compare predicted GB-month to registry-reported storage and separate baseline months from burst months.