# Amazon ECR Image

> ECR images bill through storage: every retained layer counts toward the repository's per-GB-month charge, so superseded and untagged image versions are pure storage waste. ZopNight discovers images through a dedicated per-image provider on the 6-hour cycle, attributes storage cost to the parent repository, and recommends cleanup of stale and untagged images.

Source: https://zop.dev/integrations/aws/ecr-image
Updated: 2026-08-19

---

An ECR image is an individual container image version stored inside a repository. Every retained image layer adds to per-GB storage charges, so old, untagged, or superseded images represent pure storage waste.

## Layers on the storage meter

An image in ECR is a manifest plus a set of layers, and storage bills per GB-month across everything retained. Layer deduplication softens the arithmetic (layers shared between image versions are stored once per repository), but every rebuild that touches early Dockerfile steps produces new layers, and CI pipelines rebuild constantly. Data transfer adds a second dimension: pulls to the internet or across regions bill per GB, which is how a frequently deployed public-facing repository can spend more on egress than on storage.

## Image-level accounting in ZopNight

A dedicated per-image provider discovers individual images, with storage cost attributed to the parent repository. That granularity is what makes cleanup findings concrete: instead of "this repository holds 400 GB", the recommendation names the stale and untagged images that make it up: versions superseded by months of newer builds, and untagged manifests orphaned when their tag moved to a newer push. Untagged images are the purest waste in the account: unreferenced by definition, undeployable without deliberate digest pinning, and billing monthly.

## How repositories fatten

CI is the engine: every commit pushes an image, tags like latest move forward, and yesterday's build becomes an untagged layer stack nobody will ever pull. Multi-architecture builds multiply storage per version. Base-image mirrors accumulate every upstream release since the mirror was set up. And rollback caution, the "keep everything, we might need to revert" instinct, defeats the lifecycle policy that would otherwise cap all of this, when anyone has configured one at all.

## Lifecycle policies and the console

The ECR console shows per-repository image lists with tags, digests, size, and push date; untagged images are filterable directly. The durable fix is a lifecycle policy per repository: expire untagged images after days, cap tagged history at a count. That turns a recurring manual cleanup into a rule the registry enforces itself.