ECR pricing: what to model (storage + transfer)

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-01-27. Editorial policy and methodology.

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Data Egress Cost Calculator API Response Size Transfer Calculator VPC Data Transfer Cost Calculator Cross-region Transfer Cost Calculator

Use this page when you need to decide what belongs inside the ECR bill before you debate retention policy, image slimming, or pull reduction.

This guide is about bill boundaries: registry storage, ECR-native transfer, replication-linked storage duplication, and the adjacent NAT, workload-side, or network-path costs that should be tracked beside the ECR bill rather than blended into it.

Inside the ECR bill vs beside the ECR bill

Inside the ECR bill: registry storage, ECR transfer charges, and storage duplication created by replication strategy.
Beside the ECR bill: NAT gateway processing, internet or inter-region network path costs outside the registry line item, and workload-side pull amplification.
Why this distinction matters: teams often blame ECR for architecture-side network costs that should be budgeted beside the registry bill, not hidden inside it.

What to model on the registry bill itself

Stored GB-month: how many retained image bytes live in the registry over the month.
Transfer inside the ECR scope: image movement that the registry itself bills for, tied to where workloads and replicas pull from.
Replication-linked storage duplication: copies created because you keep the same artifacts in more than one place.
Bill ownership: whether the spend belongs to the registry bill itself or to the workload and network path consuming that registry.

Boundary choices that change ownership

Pull path: same-region pulls, cross-region pulls, internet paths, and private-subnet paths do not belong to the same budget bucket.
Replication strategy: replication can reduce some pull-path costs while increasing registry-side storage duplication.
Runner and cluster location: where CI runners and workloads live determines whether the cost story is registry-native, network-adjacent, or both.

How to gather inputs without mixing jobs

Storage input: bring in the defendable GB-month model from the estimate page instead of counting repo history here.
Transfer input: separate registry-side transfer from workload-side network costs before assigning ownership.
Adjacency list: list NAT, cross-region network, and rollout-side pull amplification beside the ECR bill instead of hiding them in one blended number.

When this is not the right page

Go to estimate ECR storage (GB-month) if you still need to measure repo classes, image sizes, push frequency, or retention windows.
Go to ECR cost optimization if you already know the cost owner and need production changes such as retention enforcement or pull-path cleanup.

ECR cost calculator Estimate storage

Validation checklist

Validate that storage and transfer inputs belong to the ECR bill rather than to an adjacent network or workload bill.
Validate transfer boundary explicitly: same region vs cross-region vs internet vs private-subnet NAT changes ownership and attribution.
Validate replication assumptions so duplicated storage is not mistaken for ordinary retention drift.