Amazon ECR Pricing: When $0.10/GB Becomes the Most Expensive Storage in Your Account

Amazon ECR is the container registry that runs quietly in the background until you look at its line on the bill and realize it costs more than the EKS cluster pulling from it. The per-GB rate looks innocuous — $0.10/GB-month, less than a tenth of the cost of the underlying Fargate or EKS compute — yet across a real microservices estate, ECR storage compounds in ways that are uniquely invisible. There is no “your bucket has 14,000 unused objects” warning. Every CI/CD pipeline silently writes new image versions; every new region gets its own replicated catalog; every Inspector-enabled repository bills $0.09 per push.

This post is the bill story. For deploying containers to EKS with cost-optimized autoscaling that pulls efficiently from this registry, see our Karpenter vs Cluster Autoscaler guide. For the broader Fargate compute math, run scenarios through our Fargate pricing calculator.

The Six ECR Billing Dimensions

Why a 200-Microservice Estate Generates a Five-Figure ECR Bill

The cost driver is multiplicative. Take a realistic enterprise: 200 microservices, each with ~50 image versions retained (1 per week of active development), average image size 200 MB. That is already 200 × 50 × 0.2 = 2,000 GB of image data, or $200/month in primary-region storage.

Now apply the multipliers most teams hit:

• 10 environments (dev, qa, staging, perf, multiple feature branches with their own images, prod-canary, prod-stable, regional prod variants) → image catalog can be 3–10× the single-environment size depending on whether teams share images across environments.
• 3 regions for production failover → cross-region replication doubles or triples the storage line, plus the data-transfer-in for each new layer push.
• Enhanced Scanning enabled fleet-wide → $0.09 × image push count, which at high CI/CD velocity adds thousands per month.
• No lifecycle policy → image catalog grows monotonically over time; what was 2,000 GB in year one becomes 20,000 GB by year three.

A 200-service estate with these multipliers can land at $5,000–$15,000/month in ECR. The same workload with disciplined lifecycle policies, replication scoped to actually-used regions, and Enhanced Scanning only on production-bound repos lands at $500–$2,000/month — a clean order-of-magnitude saving.

The Lifecycle Policy Is Non-Negotiable

The single highest-impact ECR optimization is a registry-wide default lifecycle policy. Without it, every CI/CD push contributes to a monotonically growing image catalog. With even a modestly aggressive policy, the catalog stabilizes at a steady-state size determined by retention rules rather than developer behavior.

A reasonable starting policy:

• Retain the last 10 tagged images with a production tag pattern (v*, release-*, etc.).
• Retain images from the last 30 days regardless of tag (covers dev/staging work).
• Expire untagged images after 7 days (catches CI/CD intermediate builds).
• For high-velocity repos: expire pr-* and branch-* tags after 14 days (catches feature branch builds).

Cross-Region Replication: Match the Replica Set to Actual Pulls

ECR replication is straightforward to enable and dangerously easy to leave running across regions that never serve traffic. Each replication destination stores its own copy of the image catalog at $0.10/GB-month, and the initial replication of every new layer transfers cross-region at $0.02/GB.

The right approach: replicate only to regions that have running compute pulling from ECR. Audit replication configuration quarterly against the actual EKS/ECS/Lambda regional footprint. If a region has zero pulls in CloudTrail over 60 days, the replication should be disabled.

Enhanced Scanning: Match to Compliance Requirements

Enhanced Scanning via Amazon Inspector is more thorough than Basic Scanning — it covers language-specific package vulnerabilities (Python packages, npm modules, Go modules, etc.) in addition to OS-level CVEs, and continuously re-scans as new CVEs are published. The trade-off is $0.09 per initial scan plus $0.01 per re-scan.

For a team pushing 1000 images/day across the fleet, the initial-scan line alone is $2,700/month, plus the re-scan tail as Inspector’s CVE database updates. Across organizations with high-velocity CI/CD and Enhanced Scanning enabled by default, this routinely crosses $5,000/month.

The right approach: enable Enhanced Scanning on production-bound repositories where vulnerability tracking is a compliance or audit requirement; leave Basic Scanning (free) on development repositories. A repository naming convention (*-prod, *-staging, etc.) plus a registry-level rule can apply Enhanced selectively without per-repository decisions.

Pull-Through Caches: Bandwidth Win, Storage Cost

A pull-through cache stores ECR-side copies of images originally pulled from upstream registries (Docker Hub, ECR Public, Quay, GitHub Container Registry). The cached image bills at the standard ECR storage rate, but every subsequent pull from inside the VPC hits the local cache rather than the internet — removing internet egress data transfer and improving pull latency.

The economics:

• Without pull-through cache: every EKS/ECS node pulling a base image (python:3.12, nginx:1.27, etc.) does so from Docker Hub directly. Inbound to AWS is free; the pull is rate-limited by Docker Hub’s anonymous-pull policy or requires an authenticated account ($5–$11/user/month for Docker Hub Pro/Team).
• With pull-through cache: the first pull from upstream populates the local cache. Subsequent pulls hit ECR, which is free within the same region. Storage at $0.10/GB-month adds maybe $5–$20/month for the cache of common base images; the saving is in bandwidth and reliability.

The win is most apparent at high node-launch frequency — Karpenter-driven autoscaling, frequent CI/CD spawning of test containers, ephemeral compute that pulls fresh on every launch.

The Common Bill-Surprise Pattern: Stale Multi-Architecture Images

Multi-architecture image manifests (linux/amd64 + linux/arm64, sometimes plus windows/amd64) are increasingly common as teams adopt Graviton. Each architecture variant is stored as a separate set of layers under a single manifest. The result: a multi-arch image is roughly 2× the storage of a single-arch image.

The bill-surprise pattern: teams build multi-arch images by default even for workloads that only run on one architecture. The unused architecture’s layers occupy ECR storage indefinitely.

When to Use ECR vs Alternatives

A 30-Day ECR Bill Cleanup Plan

Week 1 — Apply a default lifecycle policy. Audit repositories without a lifecycle policy via aws ecr describe-repositories + aws ecr get-lifecycle-policy. Apply a default policy (retain last 10 tagged + last 30 days + expire untagged after 7 days) across the fleet. This alone often recovers 60%+ of the storage line.

Week 2 — Scope replication. Map every replication rule to its destination region and cross-reference against actual compute footprint. Disable replication to regions with zero pulls in CloudTrail over 60 days. For multi-region setups, document which destinations are active vs DR-only and adjust replication frequency accordingly.

Week 3 — Scope Enhanced Scanning. Identify which repositories actually push to production. Disable Enhanced Scanning on repos whose images never reach production (dev sandboxes, transient CI/CD build artifacts, feature-branch builds). Keep Enhanced Scanning on production-bound repos.

Week 4 — Audit multi-arch and pull-through cache. Identify multi-arch images backing single-arch workloads and switch the build pipeline to single-arch. Enable pull-through caches for Docker Hub and ECR Public if the EKS/ECS fleet pulls these images at high frequency.

Cross-check the container-compute side of the picture in our Fargate pricing calculator to ensure the ECR cleanup pairs with right-sized compute.

What This Post Doesn’t Cover

• Container image signing (cosign, Notation) costs — signing operations may incur additional KMS calls; covered in the KMS pricing post.
• Cross-account ECR sharing — uses standard IAM resource-based policies; no additional ECR-side charge.
• Detailed comparison with third-party registries (Harbor self-hosted, GitHub Container Registry, GitLab Container Registry) — fundamentally different operational models.
• Air-gapped deployment patterns — ECR has limited support for fully air-gapped use; covered in operational guides rather than pricing.

If You Only Do One Thing This Week

Apply a default registry-level lifecycle policy that retains the last 10 tagged images plus images from the last 30 days, and expires untagged images after 7 days. This single change is non-controversial enough to ship across the fleet without per-team negotiation and typically recovers 60–80% of the ECR storage bill within a week as old layers age out. Pair with a Service Control Policy requiring lifecycle policies on new repositories and the fleet stays stable going forward.

For the broader container-compute economics — Karpenter, Spot, instance diversification — the Karpenter vs Cluster Autoscaler post covers the compute side of the same architecture.