Amazon ECR Repository

Amazon Elastic Container Registry (ECR) stores container images in private repositories. Storage is billed per GB-month, and repositories without lifecycle policies accumulate years of stale image versions that nobody pulls.

Layers bill by the GB-month

ECR’s meter is storage: per GB-month for the image layers a repository holds, with data transfer out billing on top when images are pulled across regions or to the internet. Layer deduplication softens the growth (identical base layers are stored once per repository), but every distinct build pushes new application layers, and CI pushes builds many times a day.

CI writes; nobody deletes

A repository wired to a build pipeline gains images continuously and loses them never. Deployments pull the newest handful; everything older is dead weight with a per-GB-month price. Multiply a few hundred MB per image by daily builds across dozens of services and years of history, and registry storage becomes a line item that grew one harmless push at a time.

Lifecycle policies are the fix that lasts

An ECR lifecycle policy expires images by count or by age, keeping the last 20 or deleting untagged images after 14 days, and runs automatically from then on. Manual cleanups decay; the policy does not. The repositories that need one most are exactly the busiest ones, where CI throughput makes hand-pruning hopeless.

What gets flagged

Repositories are discovered on the 6-hour cycle, with storage cost from Cost Explorer or CUR 2.0. Recommendations target unbounded image growth (no lifecycle policy on a growing repository), repositories never pulled at all (built, pushed, and abandoned), and images unpulled for months. Nothing stops or schedules; registry cost is entirely retention hygiene.

Repository sizes in the console

ECR console, then Repositories. Image count and size per repository are on each row; the Lifecycle policy tab on a repository is empty on precisely the repositories that have been growing longest.