Amazon ECR（Elastic Container Registry）入門｜DockerイメージをAWSで安全に管理するライフサイクルポリシーと料金ガイド

ECSやEKSでコンテナを動かしているのに、Dockerイメージの置き場所を後回しにしていませんか？DockerHubは手軽ですが、本番AWSインフラで使い続けるとレート制限や想定外のデータ転送コストに直面することがあります。

この記事では、Amazon ECR（Elastic Container Registry）の仕組みをオンプレのプライベートレジストリ（HarborやDocker Trusted Registry）と比較しながら解説します。リポジトリ作成・Dockerイメージのプッシュ・ECS/EKSからのプル・ライフサイクルポリシーによる自動クリーンアップ・脆弱性スキャン・料金の見積もりまで、現場で使える知識を体系的にまとめました。

なぜAmazon ECRなのか？（DockerHubとオンプレレジストリとの違い）

コンテナを本番で動かすには、Dockerイメージを置く「レジストリ」が必要です。選択肢は大きく3つあります。

・DockerHub: 導入は手軽だが、無料プランはプル回数に上限がある。IPあたり6時間で100プルまでという制限は、ECSがタスクを繰り返し起動する環境では簡単に超えてしまう
・オンプレのプライベートレジストリ（Harbor、Docker Trusted Registryなど）: 社内ネットワークに置けるが、OSのパッチ当て・HA構成・ストレージ拡張のたびにメンテナンスコストが発生する
・Amazon ECR: AWSマネージドのコンテナレジストリ。同一リージョン内のECS/EKSへのデータ転送は無料で、IAMと統合されたアクセス制御が使える

オンプレ時代に社内Harborを運用した経験がある方なら、その手間はよくわかるはずです。検証サーバーの脆弱性対応、ストレージ増設のたびに発生するメンテウィンドウ、HA用のレプリカ管理——ECRを使えばこれらが一切不要になります。

IAMとの統合も大きなメリットです。「このECSタスクはこのリポジトリからしかプルできない」「このCI環境はプッシュのみ可能」という細かい権限設計が、別途ユーザー管理システムを用意せずに実現できます。オンプレ時代にLDAP連携でHarborのユーザー管理に苦労した経験があるなら、IAMポリシー一本で済む体験は新鮮に感じるはずです。

Amazon ECRの基本的な使い方

1. リポジトリの作成

AWSマネジメントコンソールで「Elastic Container Registry」を開き、「リポジトリを作成」をクリックします。

設定で押さえるポイントは2つです。

・可視性の設定: 社内アプリや本番サービスのイメージは「プライベート」を選択。OSSツールの配布目的でない限り、パブリックにする理由はありません
・タグのイミュータビリティ: 「有効」にすることを強く推奨します。同じタグ（例: latest）で別のイメージを上書きできなくなり、デプロイの再現性が保たれます

リポジトリ作成後、URIは次の形式で払い出されます。

# リポジトリURIの形式
{AWSアカウントID}.dkr.ecr.{リージョンコード}.amazonaws.com/{リポジトリ名}

# 東京リージョン（ap-northeast-1）の例
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app

2. Dockerイメージのプッシュ

ECRへのプッシュは「ECR認証 → タグ付け → プッシュ」の3ステップです。AWS CLIを使った手順を示します。

# AWS CLI: ECRへの認証（東京リージョンの例）
aws ecr get-login-password --region ap-northeast-1 \
  | docker login --username AWS \
  --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com

# ローカルのDockerイメージにECRのURIでタグを付ける
docker tag my-app:latest \
  123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

# ECRにプッシュ
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

認証トークンの有効期限は12時間です。GitHub ActionsやAWS CodePipelineなどのCI/CDパイプラインでは、ビルドのたびに認証ステップを入れておくのが基本です。

コンソール上のリポジトリ画面から「プッシュコマンドを表示」をクリックすると、アカウントIDとリージョンが埋め込み済みのコマンドがそのまま確認できます。初回はここをコピーして使うと確実です。

3. ECS・EKSからのイメージプル

ECSタスク定義のコンテナイメージURIにECRのURIをそのまま指定するだけです。ECSはタスク実行ロール（Task Execution Role）に「AmazonECRReadOnly」ポリシーが付いていれば自動的にプルできます。

EKSの場合は、ノードグループのインスタンスロールにECRの読み取り権限を付与するか、IAM Roles for Service Accounts（IRSA）を使ってPodレベルで権限を制御します。EKSのPodに対してIRSAで権限を絞る構成は、最小権限の原則に沿った現場のベストプラクティスです。

料金の仕組み（コスト感覚）

ECRの料金は主にストレージ料金とデータ転送料金の2つです（2026年6月時点）。

月額コストの試算例
プライベートリポジトリのストレージ30GB（圧縮後）、東京リージョン内のECSからのプルのみの場合：
30GB × $0.10 ＝ $3.00/月（2026年6月時点の為替レートで約450円）

コンテナイメージはレイヤー単位で重複排除（dedupe）が効くため、実際のストレージ消費は想定より少ないことが多いです。ただし、古いイメージやタグなしイメージが蓄積されると話は別です。それを解決するのが次のライフサイクルポリシーです。

ライフサイクルポリシーと脆弱性スキャン（実務Tips）

【重要】ライフサイクルポリシーで古いイメージを自動削除

CI/CDパイプラインが毎ビルドでイメージをプッシュする構成では、タグのないイメージ（untagged image）が際限なく蓄積します。放置すると無駄なストレージコストが積み上がります。ライフサイクルポリシーで自動削除を設定しておきましょう。

コンソールでリポジトリを開き、「ライフサイクルポリシー」→「ルールを作成」をクリックします。以下のJSONポリシー例では「タグなしイメージを30日後に削除」「タグ付きイメージは最新10世代を超えたら削除」という2ルールを組み合わせています。

# ライフサイクルポリシーのJSON例
{
  "rules": [
    {
      "rulePriority": 1,
      "description": "タグなしイメージを30日後に削除",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 30
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "タグ付きイメージは最新10世代を保持",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["v"],
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

ポリシー適用前に「ドライラン」で削除対象イメージを確認できるのも便利です。本番のレジストリに適用する前に必ずドライランで影響範囲を確認してください。

脆弱性スキャン（Basic ScanningとEnhanced Scanning）

ECRにはコンテナイメージのOSパッケージに含まれる既知脆弱性（CVE）を検出するスキャン機能があります。

・Basic Scanning: プッシュ時に自動スキャンを有効にできる。OSレベルの脆弱性を検出。追加料金なし
・Enhanced Scanning: Amazon InspectorとECRを統合した高度スキャン。OSパッケージに加えて、Node.js・Python・Javaなどのアプリケーション依存ライブラリの脆弱性も検出。インスペクターの利用料金が発生

本番環境で使うイメージには、少なくともBasic Scanningを有効化しておくことを推奨します。スキャン結果はコンソールから確認でき、Amazon EventBridgeと組み合わせればCRITICAL・HIGHレベルの脆弱性が検出されたときにSlackへ通知する仕組みも作れます。

クロスリージョンレプリケーション

東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）でECSを動かすマルチリージョン構成では、ECRのクロスリージョンレプリケーションが便利です。東京のリポジトリにプッシュするだけで、大阪にも自動コピーされます。

「プッシュ先は東京だけ管理すればいい」という運用のシンプルさと、大阪リージョンのECSから最速でプルできる可用性を両立できます。クロスリージョン転送料金は発生しますが、管理の一元化メリットが上回るケースがほとんどです。

よくあるトラブルと対処法

認証エラー: no basic auth credentials

ECRの認証トークンは12時間で失効します。`docker pull` や `docker push` 時に「no basic auth credentials」や「authorization token has expired」エラーが出たら、再度 `aws ecr get-login-password | docker login` を実行してトークンを更新してください。

CI/CDパイプラインでは、ビルドジョブの冒頭に認証ステップを毎回入れるのが定石です。GitHub Actionsなら `aws-actions/amazon-ecr-login` アクションが認証を自動化してくれます。

プルのタイムアウト（ECSタスク起動が遅い）

ECSタスクを起動するたびにイメージのプルに数分かかる場合、イメージサイズが大きすぎる可能性があります。ベースイメージを `ubuntu:22.04` から `ubuntu:22.04-slim` や `alpine` バリアントに変更する、マルチステージビルドでビルドツールを本番イメージに含めないなど、イメージの軽量化が根本対策です。

また、プライベートサブネットのECSからECRにアクセスする場合、NAT Gateway経由よりも「ECR VPCエンドポイント」を設定してAWS内部ネットワーク経由でプルする構成のほうが、速度向上とNAT Gatewayコスト削減を同時に達成できます。`com.amazonaws.ap-northeast-1.ecr.api` と `com.amazonaws.ap-northeast-1.ecr.dkr` の2エンドポイントを設定します。

同じタグで異なるイメージを参照してしまう

タグのイミュータビリティを有効にしていない場合、CIが同じタグ（例: `latest`）で別のイメージを上書きプッシュし、古いタスクと新しいタスクが混在することがあります。

対処策は2つです。①リポジトリのイミュータビリティを有効化する、②`latest` ではなくGitのコミットSHA（例: `v1.2.3-abc1234`）をタグに使う。イミュータビリティを有効にすると同じタグで上書きできなくなり、コミットSHAタグを使うとどのコードからビルドされたイメージかが一目でわかるようになります。

本記事のまとめ

Amazon ECRは、ECSやEKSと組み合わせることで「コンテナイメージの置き場所問題」をシンプルに解決できるサービスです。DockerHubのレート制限やオンプレレジストリのメンテナンスコストから解放され、IAMによるアクセス制御とライフサイクルポリシーによるコスト管理が一体化しています。

ECSやEKSの設計についてさらに深く学びたい方は、本サイトの関連記事「Amazon ECS入門」や「Amazon EKS入門」もあわせてご覧ください。また、Linuxサーバーとコンテナの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。