ECR cost optimization: retention, smaller images, fewer pulls

Optimization starts only after you know whether retention drift, oversized images, duplicate tags, repeated pull paths, or unnecessary replication is the real ECR cost driver; otherwise teams delete tags blindly without reducing the real bill.

This page is for production intervention: retention enforcement, image slimming, pull-path discipline, replication control, and rollback safety.

Start by confirming the dominant cost driver

• Retention drift dominates: old tags, untagged artifacts, and over-deep rollback windows are filling the registry.
• Oversized images dominate: heavy layers are inflating both storage and pull cost.
• Repeated pull paths dominate: CI and autoscaling keep re-pulling the same bytes across expensive network paths.
• Unnecessary replication dominates: multi-region or multi-arch copies exist without enough workload value.

Do not optimize yet if these are still unclear

• You still cannot explain whether retention drift, image size, repeated pulls, or replication is the larger driver.
• You only have one blended ECR number with no split between stored GB-month and pull-path behavior.
• You are still using the pricing page to define scope or the estimate page to gather missing storage evidence.

1) Enforce retention on the real drift sources

• Keep only last N tags per repo (or last D days) for CI images.
• Delete untagged images and old build artifacts.
• Keep long retention only for pinned releases and rollback candidates.
• Separate prod vs non-prod repos/tags so non-prod can have aggressive retention safely.

If you are unsure, start with a conservative retention window and expand only for repos that need rollback depth.

2) Shrink images where bytes really matter

• Use multi-stage builds and slim base images.
• Remove build tools and caches from runtime images.
• Keep layers stable (small diffs) so rebuilds do not rewrite huge layers each time.
• Audit large artifacts (node_modules, debug symbols, logs) that accidentally end up in images.

3) Fix repeated pull paths

• Use node-level caching and avoid re-pulling identical tags unnecessarily.
• Prefer immutable tags/digests so caching is reliable.
• Keep CI runners and clusters in the same region when possible (avoid cross-region pulls).
• During cluster scale-out, confirm new nodes are not pulling multiple times per deployment.

4) Keep only replication that has operational value

• Multi-arch builds can store multiple variants; validate whether you need all architectures.
• Multi-region replication can reduce transfer but increases storage (multiple copies of the same images).
• Keep replication only for workloads that truly run cross-region.

Operational guardrails (prevent future cost creep)

• Set default retention rules for new repos (teams rarely come back later).
• Standardize tagging: release tags are limited; CI tags are short-lived.
• Track top repos by stored GB-month and review quarterly.
• During incidents and big deploys, watch for pull storms from fresh nodes.

Change-control loop for safe optimization

1. Measure the current dominant driver across retention drift, image size, repeated pull paths, and replication.
2. Make one production change at a time, such as tightening retention, slimming one image family, reducing re-pulls, or removing one replication path.
3. Re-measure the same storage and pull windows and confirm the bill moved for the reason you expected.
4. Verify rollback depth, deployment reliability, and cross-region availability still meet operational needs before keeping the change.

Validation checklist

• Measure stored GB-month by repo class and confirm retention is actually deleting.
• Measure pull traffic during autoscaling days and CI bursts (not just steady state).
• Confirm rollback behavior still works after reducing retention.
• After changes, compare a real month of storage and transfer to your estimate.

Sources

• ECR pricing: aws.amazon.com/ecr/pricing
• ECR lifecycle policies: docs.aws.amazon.com

Related guides

FAQ