AWS cost optimization

AWS ECR Cost: How to Control Registry Spend Safely

AWS ECR cost can grow through image storage, transfer, scanning, and cleanup drift. Learn how to find spend and set safer lifecycle policies for small teams.

Published 2026-05-26 Updated 2026-05-26 By Cloud Cost Clinic

Quick takeaway

AWS ECR cost usually comes from stored container images, data transfer, and adjacent services such as Amazon Inspector, NAT Gateway, or VPC endpoints. The main cleanup lever is not deleting random images. It is setting lifecycle rules that match how your team deploys, rolls back, scans, and restores containers.

Start with the bill, not the repository list. Cost Explorer tells you where to look. It does not know which image tag is the rollback path for Friday's deploy.

Cloud storage review visual for AWS ECR cost and image lifecycle cleanup

Why AWS ECR cost shows up

Amazon Elastic Container Registry is a managed registry for container images and artifacts. AWS pricing says there are no upfront fees for ECR, and that you pay for stored data plus data transferred to the internet. Storage is billed to the account that owns the repository.

In small AWS accounts, the usual cost pattern is simple:

  • CI/CD pushes an image on every commit.
  • Old tags and untagged images remain in the registry.
  • Production, staging, and test repositories drift apart.
  • Multi-Region replication copies images into more places.
  • Enhanced scanning or pull-path networking adds adjacent costs.

This is not always bad. A retained image can be a rollback point, an audit artifact, a release candidate, or the last known-good build. Possible waste is not safe cleanup.

"Temporary" images have an impressive memory. They can remember every build long after the team has forgotten the branch name.

What is inside the ECR bill

Use the AWS ECR pricing page as the current pricing source before estimating exact dollars. As of May 26, 2026, the important cost buckets to model are:

  • Private repository storage.
  • Public repository storage beyond the included free storage level.
  • Data transfer from private repositories to the internet.
  • Cross-Region transfer when copying images through ECR replication.
  • Managed signing if your account uses it.
  • Encryption choices if they create separate AWS KMS activity.

Do not stop at the ECR service total. The ECR line may be small while the container workflow is still driving cost somewhere else.

Costs that sit beside ECR

Some container registry costs do not appear as "ECR" in the bill. Treat them as related review candidates, not proof that ECR itself is expensive.

  • NAT Gateway processing: private subnet workloads may pull images through NAT if VPC endpoints are not configured.
  • VPC endpoints: interface endpoints have their own hourly and data processing pricing, so compare them against NAT usage before changing the network path.
  • Amazon Inspector: enhanced ECR scanning uses Amazon Inspector and should be reviewed with Inspector pricing and scanning settings.
  • CloudWatch Logs: build, deployment, or scanner logs can add cost if retention is not set.
  • Cross-Region architecture: replication can reduce repeated remote pulls but creates extra storage copies.

The bill is downstream of architecture. Cleanup helps, but it cannot fully fix a pull path nobody understands.

How to find ECR spend

Start in Cost Explorer:

  • Filter for Amazon Elastic Container Registry.
  • Group by usage type.
  • Split by linked account and Region.
  • Compare daily trends over the last full month and the current month.
  • Check whether the trend is steady storage growth, a one-time transfer event, or a new recurring baseline.

Then check related services:

  • Amazon VPC for NAT Gateway processing tied to image pulls.
  • Amazon Inspector for enhanced container scanning.
  • AWS KMS if customer managed keys are used for registry encryption.
  • CloudWatch Logs if build or deployment logging changed at the same time.

AWS also documents ECR usage reports through Cost Explorer and Cost and Usage Reports. Use those as the billing source of truth. The ECR console can show repositories and image metadata, but the bill explains which dimension is material.

Build a repository review queue

After you know the billing signal, create a review queue. Do not turn this into a delete script with a logo.

Useful fields:

  • Repository name.
  • Account and Region.
  • Owner.
  • Application or service.
  • Environment.
  • Recent push count.
  • Image size trend.
  • Number of tagged images.
  • Number of untagged images.
  • Last recorded pull signal where available.
  • Lifecycle policy status.
  • Replication status.
  • Scanning mode.
  • Proposed safe next action.

The owner column is more important than the savings estimate. If nobody can explain why a repository exists, that is already a finding.

How lifecycle policies reduce ECR cost

Lifecycle policies are the main ECR storage control. AWS documentation says lifecycle policies can expire or archive unused repository images, and AWS recommends creating a lifecycle policy preview to verify which images would be affected before applying the policy.

Use lifecycle policy rules for decisions like:

  • Keep the most recent production release images.
  • Keep enough previous release images for rollback.
  • Expire untagged CI images after a short window.
  • Retain release tags longer than branch or pull request tags.
  • Treat dev, staging, and production repositories differently.
  • Apply policies in every replicated account or Region where needed.

The boring middle step is the important one: decide what the repository must support before choosing the rule.

For many teams, the first safe policy is not aggressive. It might keep a generous number of tagged release images, expire old untagged images, and leave production rollback images alone until the service owner signs off.

Verify before expiring images

Before expiring or archiving images, check:

  • Which ECS services, EKS workloads, Lambda container functions, batch jobs, or deployment tools use the repository.
  • Whether production deploys reference mutable tags such as latest or immutable image digests.
  • How many previous releases the team needs for rollback.
  • Whether old images are required for audit, incident review, or customer support.
  • Whether scanning, signing, or compliance workflows expect retained images.
  • Whether replicated repositories need matching lifecycle rules.
  • Whether a preview shows any production or release images being touched.

AWS cleanup is not a junk-drawer sprint. It is a change process with a bill attached.

Safer ways to lower AWS ECR cost

Start with changes that make the cost explainable and reduce drift:

  • Add missing repository owners.
  • Add lifecycle policies to repositories that have none.
  • Preview lifecycle policies before enabling them.
  • Expire old untagged CI images after owner review.
  • Keep production rollback images intentionally, not accidentally.
  • Reduce oversized images through Dockerfile review, multi-stage builds, and dependency cleanup.
  • Review replication rules so only active Regions receive copies.
  • Check whether private subnet image pulls are using NAT Gateway when VPC endpoints would be more appropriate.
  • Review enhanced scanning scope and frequency with the security owner before changing it.

The safest first action is often tagging and lifecycle policy preview. It is not glamorous. Neither is a production rollback that cannot pull the old image.

What not to do

Do not delete every untagged image without checking how your deploy tooling works. Some pipelines use digests, and some teams have odd but real rollback habits.

Do not keep every image forever because nobody wants to ask the owner. "Forever" is a brave retention policy.

Do not apply one lifecycle policy across every repository if production, staging, dev, and shared base images have different restore or rollback expectations.

Do not assume the ECR service total captures the whole container cost story. NAT Gateway, Inspector, KMS, VPC endpoints, and logging may be part of the same operational pattern.

Do not change scanning or signing settings just to reduce cost without security approval. Cost cleanup should not quietly become a weaker supply-chain control.

Checklist

  • Review Amazon ECR spend in Cost Explorer.
  • Group by usage type, linked account, and Region.
  • Check related NAT Gateway, Inspector, KMS, and CloudWatch Logs spend.
  • List repositories with owner, environment, image count, image size, and lifecycle policy status.
  • Identify repositories with no lifecycle policy.
  • Separate production release images from untagged CI images.
  • Preview lifecycle policy impact before applying rules.
  • Confirm rollback and restore expectations with the owner.
  • Apply changes during an appropriate change window.
  • Recheck spend after billing data refreshes.

FAQ

What drives AWS ECR cost?

The main AWS ECR cost drivers are stored image data and data transfer from repositories. Related costs can also appear in NAT Gateway, Amazon Inspector, AWS KMS, VPC endpoints, or CloudWatch Logs depending on how images are pulled, scanned, encrypted, and logged.

Does ECR charge for every image pull?

AWS ECR pricing depends on where data is transferred. Same-Region transfers from ECR to AWS compute services are commonly priced differently than internet or cross-Region paths, so check the live AWS ECR pricing page for your Region and architecture before estimating.

Are untagged ECR images safe to delete?

Not automatically. Untagged images are strong review candidates, especially from CI/CD pipelines, but verify deployment references, image digests, rollback needs, and owner approval before expiring them.

How do ECR lifecycle policies help with cost?

Lifecycle policies can expire or archive unused repository images based on rules such as tag status, age, pull time, or image count. Use the AWS lifecycle policy preview first so the rule does not remove images your team still needs.

Should every ECR repository have the same lifecycle policy?

Usually no. Dev and CI repositories can often use shorter retention, while production release repositories may need more retained images for rollback, audit, or incident review.

Can VPC endpoints reduce ECR-related NAT Gateway cost?

Sometimes. If private subnet workloads pull images through NAT, ECR and S3 endpoints may reduce NAT processing, but the endpoints have their own costs and networking requirements. Compare the actual NAT usage and validate the pull path before changing it.

Sources

Reader question

For ECR, is your bigger cleanup problem old untagged CI images, unclear rollback expectations, or not knowing which repository belongs to which service?

Back to top