Amazon ECR（AWS ECR）とは？料金・ECSとの違いとDockerイメージのpush手順【2026年10月】

Amazon ECR（Amazon Elastic Container Registry、通称AWS ECR）は、Dockerなどのコンテナイメージを保存・配布するAWSのフルマネージドなコンテナレジストリです。レジストリサーバーを自分で立てずに、Amazon ECS・EKS・AWS Lambdaへイメージをそのまま渡せます。この記事では、ECRの仕組みとECSとの違い、東京リージョン（ap-northeast-1）の料金と見落としやすい転送コスト、docker loginからpushまでの手順、2025年11月以降に増えたアーカイブ・署名・レイヤー共有の設定を、2026年10月時点の実コマンドで説明します。

まとめ：Amazon ECRとは何か・料金・push手順の要点

ECRはコンテナイメージ専用の保管庫です。デプロイ先がECS・EKS・Lambdaなら、IAMで権限を管理でき、同一リージョンの実行基盤への転送料金も抑えられるため、非公開イメージの保管先としてECRを第一候補にできます。

• ECRは「置く場所」、ECSとEKSは「動かす場所」です。競合する関係ではなく、ECRのイメージをECSのタスク定義から参照して使います。
• 料金はストレージ1GBあたり月0.10USDと、AWS外への転送量で決まります。同一リージョンのECS・Lambda・Fargateへのpullは転送無料ですが、プライベートサブネットからNATゲートウェイ経由でpullすると1GBあたり0.062USDの処理料金がかかります。
• pushは「リポジトリ作成 → get-login-passwordでログイン → build → tag → push」の順です。認証トークンは12時間で切れます。
• 2025年11月に追加されたアーカイブ保存は、月150TBまでは標準と同じ単価です。コスト削減ではなく、保存期間の要件があるときに使う機能と考えてください。
• 運用開始時に、ライフサイクルポリシーとプッシュ時スキャンを入れておきます。「90日pullされていない」ルールを使うなら、スキャナのpullを除外する設定も必要です。

最短のpush手順は次の4ステップです。前提条件とコマンドの詳細は本文で順に説明します。

Amazon ECRの仕組み：レジストリ・リポジトリ・イメージの3階層

ECRはAmazon Elastic Container Registryの略で、Dockerイメージ、OCIイメージ、Helmチャートなどを保存するレジストリサービスです。構成はレジストリ・リポジトリ・イメージの3階層で、AWSアカウントのリージョンごとに既定のプライベートレジストリが1つあります。その中にアプリごとのリポジトリを作り、各リポジトリにタグ付きのイメージを入れる、という入れ子の関係です。レジストリという仕組みそのものはコンテナレジストリの種類と選び方を解説した記事で、コンテナの基礎はコンテナと仮想マシンの違いから整理したコラムで扱っています。

レジストリのURIは <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com の形式で、リポジトリ名を後ろに付けた <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/my-app がpush・pullの宛先になります。リージョンが違えばレジストリも別物です。東京と大阪で同じ設定を使いたいときは、両方のレジストリに入れる必要があります。

設定項目は「リポジトリ単位」と「レジストリ単位」に分かれます。タグの上書き可否・ライフサイクルポリシー・リポジトリポリシーはリポジトリごと、レプリケーション・プルスルーキャッシュ・スキャン方式・レイヤー共有・署名はレジストリごとに設定します。ここを取り違えると、「設定したのに効かない」と悩むことになります。

ECRとECS・EKS・Docker Hubの違い

ECRとECSは名前が似ていますが、役割が違います。ECRは保管庫、ECSとEKSは実行環境です。

実際のデプロイでは、ECRに置いたイメージをECSのタスク定義やEKSのマニフェストから参照します。ECSでの動かし方はECSでDockerコンテナを動かす手順の解説、Kubernetesで動かす場合はAmazon EKSの仕組みと料金モデルの解説で扱っています。実行基盤そのものを選ぶ段階なら、ECS・EKS・Fargate・Lambdaを比較したAWSのコンテナサービス比較から読むと早く決まります。

保管庫としての比較相手はDocker Hubです。OSSの公式イメージを入手するならDocker Hub、自社の非公開イメージをAWS上で動かすならECR、という分担が基本になります。ECRを選ぶ理由は、IAMで権限を一元管理できること、同一リージョン内の転送が無料なこと、Docker Hubのpull回数制限を受けないことの3点です。

他のクラウドや開発基盤のレジストリと比べたい場合は、Azure Container Registry（ACR）の料金プランと作成手順を解説した記事、ソースコードとCIをGitHubに置いているならGitHub Container Registry（ghcr.io）の料金とECR比較が判断材料になります。扱うものがコンテナイメージではなくnpmやMavenのパッケージなら、AWS CodeArtifactによるパッケージレジストリの領分です。

ECRの料金：ストレージ・転送・アーカイブの単価

ECRの請求は、保存したイメージの容量と、AWS外へ出ていく転送量の2つでほぼ決まります。以下の単価はAmazon ECRの公式料金ページと、その元データであるAWS Price List API（AmazonECR・ap-northeast-1）の2026年9月11日版（publicationDate）で確認した値です。

ストレージ単価と無料枠

プライベートリポジトリの標準ストレージは、東京リージョンでも米国東部（バージニア北部）でも1GBあたり月0.10USDです。無料枠は、新規顧客がプライベートリポジトリのストレージを月500MBまで1年間、パブリックリポジトリは新規・既存を問わず月50GBまで常時無料と料金ページに書かれています。

ただし、AWSの無料利用の仕組みは2025年7月に、6か月・クレジット制の無料プランを選ぶ方式へ変わりました。自分のアカウントでどちらの枠が効いているかは、請求コンソールの無料利用枠ページで確かめるのが確実です。新しい無料プランの期限と範囲はAWSを無料で使える範囲と6か月の期限をCLIで確認する手順で整理しています。

ストレージだけなら、常時10GBを置いても月1USD前後です。ただし、pullの回数や通信経路によっては、次に説明する転送とNATの料金がこれを上回ります。

転送料金とNATゲートウェイ経由のpull

料金ページの例示には、ECRと同じリージョンのEC2・Lambda・App Runner・Fargateとの間の転送は無料（0.00USD/GB）と明記されています。一方、インターネット向けの送信は通常のAWSデータ転送料金で、東京リージョンは月10TBまで1GBあたり0.114USDです（Price ListではAWS全体で月100GBまでの送信が0USDの段）。別リージョンのサービスとの転送は、送る側と受ける側の両方でインターネット転送料金がかかる、と同じ箇所に書かれています。

見落としやすいのが、プライベートサブネットのECSタスクやEC2がNATゲートウェイ経由でpullする構成です。ECRの転送自体は無料でも、NATゲートウェイを通ったデータには東京リージョンで1GBあたり0.062USDの処理料金がかかります。1GBのイメージを1日30回pullすると月約900GBで、NAT処理だけで約56USDになる計算です。

対策は、ECRのVPCエンドポイントのドキュメントにあるS3のゲートウェイエンドポイントを作ることです。ECRはイメージのレイヤーをS3に保存しており、pullでは「ECRからマニフェストを取得 → S3からレイヤーを取得」の順に通信します。容量の大半を占めるレイヤーの取得がS3ゲートウェイエンドポイント経由になり、ゲートウェイエンドポイント自体に追加料金はありません。NATを置かない閉域構成では、加えて com.amazonaws.ap-northeast-1.ecr.dkr と com.amazonaws.ap-northeast-1.ecr.api のインターフェイスエンドポイントが必要で、こちらは1エンドポイント・1アベイラビリティーゾーンにつき時間0.014USD（Price ListのVpcEndpoint-Hours）と処理料金1GBあたり0.01USDがかかります。Fargateのプラットフォームバージョン1.4.0以降では両方のインターフェイスエンドポイントが必要です。

アーカイブ・署名・レイヤー共有の料金

2025年11月以降に追加された機能には、それぞれ別の単価があります。東京リージョンの値を並べます。

アーカイブは「低コストの保存クラス」と説明されていますが、単価が下がるのは月150TBを超えた部分だけです。それ以下の規模では標準と同じ単価に、90日の最低保存期間と取り出し料金が加わるので、費用はむしろ増えます。アーカイブしたイメージはリポジトリあたりのイメージ数の上限（10万）に数えられないため、監査のために過去イメージを大量に残す必要があるときに選ぶ機能です。

レイヤー共有（blob mounting）は2026年1月20日に発表された機能で、同じレジストリ内のリポジトリ間で共通レイヤーを共有できます。ただし、共有設定の有効化に加え、push時にクライアントがマウント用パラメーターを送る必要があります。共通ベースイメージ700MBの上に固有レイヤー300MBを載せたサービスが20リポジトリある構成なら、共有なしで20GB（月2.0USD前後）、共有ありでベース0.7GB＋固有6GBの6.7GB（月0.67USD前後）です。金額の差は小さく、効果が大きいのはpushで同じレイヤーを送り直さずに済む点です。有効化の手順は次の章で説明します。

ECRリポジトリをAWS CLIで作成する手順

前提はAWS CLIとDockerのインストールと、aws configure などでの認証情報の設定です。CLIはバージョン2を使ってください。導入手順はAWS CLIのインストールとv2の設定を解説した記事にまとめています。

タグの上書き禁止とlatestの除外設定

本番用のリポジトリは、同じタグへの上書きを禁止しておくとロールバック時の取り違えを防げます。ただし全タグを IMMUTABLE にすると、latest へ2回目のpushをした時点で ImageTagAlreadyExistsException になります。2025年7月23日に追加された除外フィルタを使えば、latest だけ上書きを許して残りは不変にできます（タグの不変性のドキュメント）。

aws ecr create-repository \
  --repository-name my-app \
  --image-tag-mutability IMMUTABLE_WITH_EXCLUSION \
  --image-tag-mutability-exclusion-filters filterType=WILDCARD,filter=latest \
  --image-scanning-configuration scanOnPush=true \
  --region ap-northeast-1

作成後、push先のURIを控えます。リポジトリ名は2文字以上が必要で、1文字の名前はCLIの入力検証で弾かれます。

aws ecr describe-repositories --repository-names my-app \
  --query "repositories[0].repositoryUri" --output text --region ap-northeast-1

push時のリポジトリ自動作成設定

マイクロサービスが増えると、毎回 create-repository を打つのが手間になります。2025年12月19日に、存在しないリポジトリへpushしたときにECRが作成する機能（create on push）が加わりました。ただしリポジトリ作成テンプレートのドキュメントのとおり、作成時の設定はテンプレートから取られるので、用途に CREATE_ON_PUSH を指定したテンプレートを先に作っておきます。

aws ecr create-repository-creation-template \
  --prefix apps \
  --applied-for CREATE_ON_PUSH \
  --image-tag-mutability IMMUTABLE \
  --region ap-northeast-1

この例では apps/ で始まるリポジトリ（例：apps/api）へ初めてpushした時点で、タグ上書き禁止のリポジトリが作られます。プレフィックスに ROOT を指定すると、他のテンプレートに当たらない全リポジトリが対象です。テンプレートはライフサイクルポリシーやリポジトリポリシーも持てるので、自動作成されたリポジトリにも運用ルールが最初から効きます。

前章のレイヤー共有も、ここで有効にしておくとよいでしょう。設定はレジストリ単位で、次の1行です。

aws ecr put-account-setting --name BLOB_MOUNTING --value ENABLED --region ap-northeast-1

blob mountingのドキュメントによると、共有できるのは同じアカウント・同じリージョンのレジストリ内だけで、リポジトリ同士の暗号化方式と鍵が一致している必要があります。プルスルーキャッシュで作られたイメージは対象外で、レイヤーを借りる側には共有元リポジトリの ecr:GetDownloadUrlForLayer 権限が要ります。

DockerイメージをECRへpushする手順

ECRを使う作業の中心がここです。ログイン、ビルドとタグ付け、CIからのpushの順に説明します。

get-login-passwordによるDocker認証

ECRへの認証は、一時パスワードを発行する get-login-password の出力を docker login に渡す方法が標準です。AWS CLIのget-login-passwordリファレンスによると、発行される認可トークンの有効期間は12時間で、AWS CLIバージョン2、またはバージョン1なら1.17.10以降で使えます。

aws ecr get-login-password --region ap-northeast-1 \
  | docker login --username AWS --password-stdin <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com

「Login Succeeded」と出れば成功です。旧来の aws ecr get-login はAWS CLI v2で削除されています。12時間ごとのログインを省きたい開発端末では、AWSが公開しているamazon-ecr-credential-helper（最新はv0.12.0、2026年2月27日公開）をDockerの認証ヘルパーに登録すると、キャッシュしたトークンを利用し、必要に応じて自動で取得・更新します。

pushするIAMプリンシパルには、ecr:GetAuthorizationToken に加えて ecr:BatchCheckLayerAvailability・ecr:InitiateLayerUpload・ecr:UploadLayerPart・ecr:CompleteLayerUpload・ecr:PutImage・ecr:BatchGetImage を対象リポジトリに許可します。なお、ecr:GetAuthorizationToken のResourceは * にします。pullだけならAWS管理ポリシー AmazonEC2ContainerRegistryPullOnly（2024年10月追加）で足ります。権限設計の考え方はAWS IAMのユーザー・ロール・ポリシーの違いを解説した記事を参照してください。

Dockerイメージのビルド・タグ付け・push手順

ログイン後、イメージをビルドし、ECRのURIをタグとして付けてからpushします。URIを付け忘れると、push先がDocker Hubになります。

docker build -t my-app .
docker tag my-app:latest <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
docker push <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

本番デプロイでは latest ではなく、コミットハッシュやビルド番号をタグに使います。前章の除外フィルタで latest だけ上書き可にしてあれば、git rev-parse --short HEAD の値のタグと latest を同時に付けてpushできます。Dockerfileの書き方はDockerfileの主要命令とベストプラクティスの解説が参考になります。

レイヤーの上限は2026年8月3日に引き上げられ、docker pushでは1レイヤー200GBまで置けるようになりました。AWSの発表によると、SDKやCLIのUploadLayerPartでpushする場合は50GBのままで、中東（バーレーン）と中東（UAE）は対象外です。クォータのドキュメントは2026年10月時点でも52,000MiBのままなので、LLMの重みなどを丸ごと入れる場合は発表の側を基準にしてください。

GitHub ActionsのOIDC認証とECRへのpush設定

CIからpushするなら、アクセスキーをSecretsに置かず、OIDCでIAMロールを引き受ける構成にします。aws-actions/configure-aws-credentials（v6.3.0、2026年9月15日公開）でロールを引き受け、aws-actions/amazon-ecr-login（v2.1.7、2026年8月19日公開）でログインします。

次のYAMLはジョブ内部の抜粋です。on と jobs を定義したワークフローの、DockerとAWS CLIが使える runs-on（例：ubuntu-latest）のジョブ直下に、permissions と steps を同じ階層で置きます。IAMのOIDCプロバイダーと信頼ポリシーは事前に作成し、role-to-assume を自分のロールARNに置き換えてください。

permissions:
  id-token: write
  contents: read
steps:
  - uses: actions/checkout@v7
  - uses: aws-actions/configure-aws-credentials@v6
    with:
      role-to-assume: arn:aws:iam::123456789012:role/gha-ecr-push
      aws-region: ap-northeast-1
  - id: ecr
    uses: aws-actions/amazon-ecr-login@v2
  - run: |
      IMAGE=${{ steps.ecr.outputs.registry }}/my-app:${{ github.sha }}
      docker build -t "$IMAGE" .
      docker push "$IMAGE"

amazon-ecr-login はジョブの終了時に既定でログアウトし（skip-logout の既定はfalse）、パスワードはログ上でマスクされます。OIDCの信頼ポリシーとsub条件の書き方はconfigure-aws-credentialsのOIDC設定を解説した記事、ビルドキャッシュやマルチアーキの設計はGitHub ActionsでDockerイメージをビルドする記事で扱っています。

ECRからpullする手順とECR Public・プルスルーキャッシュ

pushしたイメージを別の環境で使うときも、先に get-login-password でログインしてからpullします。ECSやEKSのノードは、タスク実行ロールやノードロールの権限でECRから直接pullするので、手動のログインは要りません。

docker pull <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

誰にでも配りたいイメージの置き場所は、プライベートのECRではなくAmazon ECR Publicです。ECR Publicはログインなしでpullでき、Amazon Linuxの公式イメージなら public.ecr.aws/amazonlinux/amazonlinux:latest で取得できます。AWSアカウントなしの匿名pullでも月500GBまで、アカウントで認証すれば月5TBまで転送が無料です。

プルスルーキャッシュは、上流レジストリのイメージを自分のプライベートレジストリ経由でpullしてキャッシュする仕組みです。対応する上流は次のとおりで、2026年3月18日にChainguardが加わりました。

• 認証不要：Amazon ECR Public、Kubernetesのコンテナイメージレジストリ、Quay
• Secrets Managerの認証情報が必要：Docker Hub、Azure Container Registry、GitHub Container Registry、GitLab Container Registry（SaaS版のみ）、Chainguard
• IAMロールが必要：別アカウントのAmazon ECR

認証情報のシークレットは、名前を ecr-pullthroughcache/ で始め、ルールと同じアカウント・リージョンに置きます。キャッシュ済みのタグは、pullされたときに直近24時間以内に上流と照合していなければ上流へ更新を確かめに行きます。2026年4月17日からは、上流にある署名やSBOMなどのOCI referrersも合わせて同期されます。Lambdaはプルスルーキャッシュ経由のイメージ取得に対応していません。また、インターフェイスエンドポイントだけの閉域構成では、初回pullのためにNATゲートウェイへの経路が必要です。

上流がプルスルーキャッシュに対応していない自前レジストリなどからは、2026年6月15日に追加されたサードパーティレジストリからの移行ガイドに沿って一度だけコピーします。ガイドは、Dockerfileやタスク定義から dkr.ecr を含まないイメージ参照を grep で洗い出す手順から始まり、コピー後の digest 照合までを6ステップで示しています。

ライフサイクルポリシーで古いイメージを削除する手順

pushを続けたまま放置すると、ストレージ課金が増え、脆弱な古いイメージが残り続けます。毎日pushするマイクロサービスでは、ライフサイクルポリシーを最初に入れておきます。

ポリシーのJSONとプレビューでの確認

「pushから1日を超えたタグなしイメージを削除」「新しい順に20個を超えたイメージを削除」の2ルールは、ライフサイクルポリシーのプロパティに沿うと次のJSONになります。tagStatus が any のルールは、rulePriority を最大にして最後に評価させる決まりです。

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Expire untagged images older than 1 day",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 1
      },
      "action": { "type": "expire" }
    },
    {
      "rulePriority": 2,
      "description": "Keep only the latest 20 images",
      "selection": {
        "tagStatus": "any",
        "countType": "imageCountMoreThan",
        "countNumber": 20
      },
      "action": { "type": "expire" }
    }
  ]
}

上のJSONを作業ディレクトリに lifecycle.json として保存し、次のコマンドを1つずつ実行します。start-lifecycle-policy-preview の後、get-lifecycle-policy-preview の status が COMPLETE になるまで待ち、削除対象の一覧を確かめます。意図した対象だけだと確認できてから、最後の put-lifecycle-policy を実行してください。プレビュー自体は何も削除しません。適用後、条件を満たしたイメージは24時間以内に削除されます。

aws ecr start-lifecycle-policy-preview --repository-name my-app \
  --lifecycle-policy-text file://lifecycle.json --region ap-northeast-1
aws ecr get-lifecycle-policy-preview --repository-name my-app --region ap-northeast-1
aws ecr put-lifecycle-policy --repository-name my-app \
  --lifecycle-policy-text file://lifecycle.json --region ap-northeast-1

全ルールは同時に評価され、その後 rulePriority の小さい順に適用されます。下位ルールも上位ルールの対象イメージを識別・集計しますが、上位ルールで保護されるイメージを削除することはできません。そのため、pushから1日以内のタグなしイメージは2つ目のルールでも消えず、残る数が一時的に20個を超えることがあります。1ポリシーに入れられるルールは50個までです。

「90日pullされていない」ルールがスキャナで効かなくなる問題

2025年11月のアーカイブ追加と同時に、countType に最終pull日時で判定する sinceImagePulled が加わりました。ただしライフサイクルポリシーの評価規則では、sinceImagePulled は「アーカイブする」条件で、直接の削除には使えません。削除するには、アーカイブした日時で判定する sinceImageTransitioned と expire の組み合わせを別のルールに書きます。アーカイブには90日の最低保存期間があり、月150TBまでは標準と同じ単価なので、「使われていないイメージを消す」目的なら、push日時（sinceImagePushed）や件数（imageCountMoreThan）で消すほうが安く済みます。pull日時の条件が向くのは、監査のために使われなくなったイメージも一定期間残す必要がある場合です。

このルールには落とし穴もあります。pull時刻の更新除外のドキュメントによると、ECRはAmazon Inspector以外のすべてのpullで LastRecordedPullTime を更新します。CrowdStrike・Snyk・Trivyなどの外部スキャナが毎日全イメージをpullしている環境では、どのイメージも「昨日pullされた」ことになり、ルールがいつまでも発火しません。

スキャナが使うIAMロールを除外リストに登録すれば、そのロールのpullでは日時が更新されなくなります。登録は1アカウントあたり100件までです。

aws ecr register-pull-time-update-exclusion \
  --principal-arn arn:aws:iam::123456789012:role/trivy-scanner \
  --region ap-northeast-1
aws ecr describe-images --repository-name my-app \
  --query "imageDetails[].[imageTags[0],lastRecordedPullTime]" --output table --region ap-northeast-1

この例では、外部スキャナが使用するIAMロールのARNを除外対象に登録します。sinceImagePulled のルールを入れる前に、2行目の describe-images で最終pull日時がスキャンの時刻にそろっていないかを見てください。そろっていれば、スキャナのpullが日時を上書きしています。Trivyをレジストリのスキャンに使う設定はTrivyの使い方とCI設定の解説にまとめています。

脆弱性スキャンとイメージ署名の初期設定

ECRのベーシックスキャンは、AWSネイティブの技術でOSパッケージのCVEを検出します。旧来のClairベースのスキャンは2026年2月2日に廃止が完了し、全アカウントがAWSネイティブ方式へ移行済みです。前章の scanOnPush=true を付けたリポジトリは、pushのたびに検査されます。同じイメージのスキャンは24時間に1回まで、レジストリ全体で24時間に10万イメージまでという上限があります。

OSだけでなく、npmやpipなどの言語パッケージまで継続的に検査したい場合は、Amazon Inspectorと連携する拡張スキャンに切り替えます。拡張スキャンは2025年6月から、どのイメージがEKSやECSで稼働中かも表示するようになりました。Inspector側の対応範囲と料金はAmazon Inspectorの対応スキャンと料金の解説にあります。

2025年11月21日には、push時にAWS Signerで自動署名するマネージド署名も加わりました。マネージド署名のドキュメントによると、署名ルールはレジストリあたり10個まで作れて、pushするIAMプリンシパルに signer:SignPayload の権限が必要です。署名の検証を手元で行う場合は、引き続きNotation CLIを入れます。署名単価を1件0.02USDとすると、1日100回のpushで毎回1件の署名に成功する場合、30日で60USDです。複数の署名ルールに一致して複数の署名が生成される場合は、その件数分を計上します。本番に出すリポジトリだけをフィルタで対象にするのが現実的です。

ECRのpush・loginでよくあるエラーと上限値

つまずく箇所は、認証・リージョン・タグの3つに集中します。

まず、ログインしたリージョンとpush先URIのリージョンが一致しているかを確認します。aws sts get-caller-identity で使っているアカウントを、aws --version でCLIのバージョンを確かめると早く切り分けられます。create on pushを当てにしている場合、「repository does not exist」はテンプレートのプレフィックスとリポジトリ名が合っていないサインでもあります。

大量にpullする構成では、ECRのサービスクォータも確認しておきます。既定値はリージョンごとに、マニフェストを取るBatchGetImageが毎秒2,000、レイヤーを取るGetDownloadUrlForLayerが毎秒3,000、GetAuthorizationTokenが毎秒500、PutImageが毎秒10です。リポジトリ数とリポジトリあたりのイメージ数はどちらも10万までで、いずれも引き上げを申請できます。2026年2月からは、リポジトリ数とイメージ数をCloudWatchのメトリクス（RepositoryCount・ImagesPerRepositoryCount）で監視できます。

ECRを採用する条件と見送る場面

ECRに寄せるべきなのは、デプロイ先がECS・EKS・Lambdaのいずれかで、イメージを社外に公開しない場合です。複数リージョンへ配る構成でも、2026年8月17日にレジストリあたり25本へ増えたレプリケーションルールとリポジトリ作成テンプレートで設定をそろえられます。

見送ってよいのは次の3つの場面です。

• 実行環境がオンプレミスや他クラウドに散らばっている場合。東京リージョンから外へのpullは1GBあたり0.114USDかかり、ECRを選ぶ理由が薄れます。
• ソースコードとCIがGitHubにあり、イメージもGitHub Actionsから配るだけの小規模な構成。GHCRのほうがIAMロールの準備が要らず、設定が少なく済みます。
• OSSとして誰にでも配りたいイメージ。プライベートのECRではなく、ECR PublicかDocker Hubに置きます。

移行は、本番のECS・EKSが参照するイメージからECRへ移し、ベースイメージの取得はプルスルーキャッシュで段階的にAWS内へ寄せる順番が安全です。リポジトリの設計、ECS・EKSのデプロイパイプライン、IAMの権限設計までまとめて整えたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）サービスでご相談いただけます。

Amazon ECRのよくある質問

Amazon ECRとは何ですか？ECSとの違いは？

Amazon ECRは、コンテナイメージを保存・配布するAWSのフルマネージドなレジストリです。ECSはそのイメージを動かす実行サービスです。ECRに置いたイメージをECSのタスク定義から参照してデプロイするので、両者は競合せず、組み合わせて使います。

ECRの料金はいくらですか？

東京リージョンのストレージは1GBあたり月0.10USDで、新規顧客にはプライベートリポジトリ月500MBを1年間無料とする枠が料金ページに記載されています。同一リージョンのECSやLambdaへのpullは転送無料ですが、NATゲートウェイ経由のpullには1GBあたり0.062USDの処理料金がかかり、インターネット向けの送信は1GBあたり0.114USDです。

ECRへdocker pushするにはどうすればよいですか？

aws ecr get-login-password の出力を docker login --password-stdin に渡してログインし、ローカルのイメージにECRのURIをタグとして付けてから docker push します。push先のリポジトリが無い場合は、先に作成するか、CREATE_ON_PUSHのリポジトリ作成テンプレートを用意しておきます。

docker loginのトークンはどれくらい有効ですか？

ECRの認証トークンは発行から12時間有効です。切れると「no basic auth credentials」になるので、get-login-password を再実行します。CIではジョブごとにログインから始め、開発端末ではamazon-ecr-credential-helperを登録すると再ログインの手間がなくなります。

ECR Publicとプライベートリポジトリの違いは何ですか？

プライベートリポジトリはIAMで権限を管理する非公開の置き場所で、社内やAWS内のデプロイに使います。ECR Publicは誰でもログインなしでpullできる公開ギャラリーで、ストレージは月50GBまで常時無料、匿名pullの転送は月500GBまで無料です。

関連記事

• ECSでDockerコンテナを動かす手順：ECRへのpush・タスク定義・料金とEKSとの違い【2026年10月】
• AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順
• コンテナレジストリとは？種類・選び方から企業の導入判断まで解説
• GitHub Container Registry（ghcr.io）の料金と使い方｜無料の範囲・Docker Hub/ECR比較【2026年10月】
• GitHub ActionsでDockerイメージをビルドする｜push先とキャッシュ・マルチアーキの設計