AWS ECR: ECS Fargateに必要なコンテナレジストリ（そして壊れるまで見えない理由）

AWS ECRとは何か、なぜ重要なのか？

AWS ECR (Elastic Container Registry) はAmazonのマネージドコンテナイメージストレージです。プライベートなDocker Hubのようなものですが、AWSに組み込まれています。ECS Fargateでコンテナを実行するたびに、タスクはどこかからイメージをプルする必要があります どこか — そしてECRはほとんどのチームがイメージを保管する場所です。

2026年7月1日現在、コンテナオーケストレーションは本格的なクラウドデプロイメントの必須条件です。ECS Fargateを実行している場合、ほぼ確実にECRも使用しているでしょう。しかし、ここで問題があります：ECRは少し目に見えにくいのです。壊れるまでは機能しますが、壊れたときのエラーメッセージは役に立ちません。タスクは起動に失敗します ResourceInitializationError。チームメイトは肩をすくめます。6ヶ月後、レジストリに5年間放置されたタグなしイメージがあり、ストレージとして毎月400ドルの料金が静かに請求されていることに気付きます。このガイドでは、ECRのドキュメントがごまかしている部分を網羅します：プルが実際にどのように機能するか、プライベートサブネットタスクが失敗する理由、そして請求額を妥当な範囲に保つ方法です。

ECRがECS Fargateでどのように機能するか

ECS Fargateタスクが開始されるとき、コンテナイメージをプルする必要があります。タスクにはDockerがローカルにインストールされていません — Amazonのマネージドインフラストラクチャ上で実行されています。そのため、FargateエージェントはECRに到達し、認証を行い、イメージをダウンロードします。

その認証こそ、誰も語らない重要な要素です。Fargateタスクはユーザー名とパスワードでログインしません。代わりに、IAMロール — 具体的にはタスクに割り当てた実行ロールを使用します。ECRはそのロールのアクセス許可をチェックします。ロールがイメージを読み取ることができれば素晴らしいです。そうでなければ、タスクは（多かれ少なかれ）静かに失敗します（一般的なエラーが表示されます）。

また、ECRは特定のAWSリージョンに存在します。もしタスクが us-east-1 にあり、イメージが eu-west-1にある場合、タスクは追加の設定なしではそれをプルできません。通常は問題になりませんが、知っておく価値はあります。

IAM権限：見えない壁

ここでほとんどの人がつまずきます。ECSタスクには実行ロールが必要です — これはイメージのプル、ログの書き込み、および他のAWSサービスとの通信に使用するIDです。そのロールにはECRから読み取るための特定のアクセス許可が必要です。

最低限必要なものは次のようになります:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Resource": "arn:aws:ecr:us-east-1:REPLACE_WITH_ACCOUNT_ID:repository/REPLACE_WITH_REPO_NAME"
    },
    {
      "Effect": "Allow",
      "Action": "ecr:GetAuthorizationToken",
      "Resource": "*"
    }
  ]
}

その2番目のステートメントが重要です。 GetAuthorizationToken は 唯一の 特定のリポジトリに適用されないECRアクションです — グローバルに適用されます。これがないと、タスクはECRへの認証さえできず、他のすべてが失敗します。

これを間違えると、タスクは1分間 PROVISIONING のままになり、その後 ResourceInitializationErrorで失敗します。「やあ、IAMロールがECRを読み取れないよ」というログはありません。エラーは曖昧です。そのため、タスクが起動しないときに最初に確認するのは実行ロールです。

プライベートサブネットの失敗とその原因

Fargateタスクがプライベートサブネットにあるとします（優れたセキュリティ対策です）。インターネットへの直接アクセスはありません — すべてのアウトバウンドトラフィックはNATゲートウェイを経由します。ここで、タスクがECRからイメージをプルしようとします。

ECRはAWSサービスなので、インターネット上に存在します（正確にはパブリックエンドポイントとVPCエンドポイントの両方を持っています）。プライベートサブネットタスクがECRのパブリックエンドポイントにアクセスすると、リクエストはNATゲートウェイを通過して戻ってきて、機能する はずです 。通常は機能します。

しかし、時には機能しません。NATゲートウェイがタスクとは異なるAZにある場合や、ルートテーブルの設定を間違えている場合、リクエストは静かに失敗します。または、セキュリティグループがポート443（HTTPS）でのエグレスをブロックしている場合、ECRは応答できません。

通常、修正は次のいずれかです:

1. ECR用にVPCエンドポイントを使用する。 VPC内にVPCエンドポイントを作成すると、Fargateはパブリックインターネットの代わりにエンドポイントを介してイメージをプルします。これはより安全で高速です。
2. NATゲートウェイが到達可能であることを確認する。 ルートテーブルを確認します — ECRへのトラフィックはNATを経由してルーティングされる必要があります。
3. アウトバウンドHTTPSを開く。 タスクのセキュリティグループには、ECRに到達するためにポート443のエグレスが必要です。
4. CloudWatchログを確認する。 タスクのCloudWatchロググループには、エラーメッセージを掘り下げると手がかりがあることがよくあります。

プライベートサブネットにいる場合、VPCエンドポイントが最適解です。すべてのトラフィックをAWS内に保ち、NAT料金を回避し、さらに高速です。一度設定すれば、忘れてしまって構いません。

ECRの価格設定とイメージクリーンアップの理解

ECRのコストはシンプルです：保存されたイメージデータに対してのみ支払います。プルあたりの料金やプッシュあたりの料金はありません。ストレージのみです。

注意点: プッシュしたすべてのイメージレイヤーは、削除しない限り永久に保存されます。同じイメージタグ（「latest」タグなど）を繰り返しプッシュすると、水面下では各プッシュが新しいイメージになります。数年後には、何千ものタグなしイメージがそこに置かれていることになります。

単一のイメージは、ベースOSやパッケージに応じて500 MBから2 GBになることがあります。それに数百、数千のビルドを掛けると、テラバイト単位になります。月に1 GBあたり約0.10ドルで、それは高額になります。

解決策はライフサイクルポリシーです。これは、「30日間使用されていないイメージを削除する」や「タグごとに最後の10個のイメージのみを保持する」というルールです。妥当な例を以下に示します:

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 10 images",
      "selection": {
        "tagStatus": "tagged",
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "Delete untagged images after 30 days",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 30
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

これにより、最後の10個のタグ付きイメージが保持され、30日より古いタグなしイメージが削除されます。ECRをセットアップするときにこれを適用すれば、突然400ドルの請求に驚くことは決してありません。

ECRの問題のデバッグ

タスクの起動に失敗した場合、エラーメッセージは通常役に立ちません。しかし、答えはほぼ常に次のいずれかです:

1. 不正なIAM権限。 実行ロールがリポジトリを読み取れません。
2. 間違ったリポジトリまたはリージョン。 タスクは app.example.com/myimage:latest を探していますが、あなたはそれを us-east-1にプッシュしました。 eu-west-1.
3. ネットワークの問題。 プライベートサブネット、セキュリティグループ、またはルートテーブルがECRへのアクセスをブロックしています。
4. イメージが存在しません。 タグをプッシュし、削除してから使用しようとしました。
5. ECR APIスロットリング。 稀ですが、一度に何百ものイメージをプルしている場合、ECRがレート制限を行う可能性があります。

トラブルシューティングするには:

• IAMコンソールでタスクの実行ロールを確認します。ECRの権限はありますか？
• タスクのCloudWatchロググループを確認します。多くの場合、 awslogs の出力の中に手がかりが隠されています。
• 同じVPC内のEC2インスタンスから手動でイメージをプルしてみてください。それが機能する場合、問題はネットワークかタスク設定内のIAMです。
• VPCエンドポイント（使用している場合）を確認します。タスクのサブネットから到達可能ですか？

結論

ECRは複雑ではありませんが、詳細を見落としやすいです。ECSタスクと外界の間に位置し、設定を間違えるとすべてが停止します。正しく行うべき3つのことは、IAMアクセス許可（ GetAuthorizationTokenを含む）、ネットワークアクセス（特にプライベートサブネットにおいて）、およびイメージクリーンアップ（ライフサイクルポリシー）です。この3つを行えば、ECRは良い意味で目に見えなくなります — 単純に機能し、請求額は妥当なまま維持されます。

メリット

• 完全マネージド — 自分で運用するコンテナレジストリはありません
• IAMと統合 — きめ細かいアクセス制御が組み込まれています
• 安価 — ストレージのみの支払いで、プルごとの料金はありません
• 高速 — イメージはタスクと同じAWSリージョン内にあります
• 利用可能なVPCエンドポイント — セキュリティと速度のためにトラフィックをAWS内に保ちます
• ライフサイクルポリシー — 自動クリーンアップにより請求の驚きを防ぎます

デメリット

• エラーメッセージが不透明 — "ResourceInitializationError"は何も教えてくれません
• リージョン別 — 1つのリージョンにあるイメージは、回避策なしでは別のリージョンのタスクからは見えません
• 組み込みの通知なし — イメージストレージが警告なしに膨れ上がる可能性があります
• IAMの複雑さ — 実行ロールには多くの動的要素があります
• VPCエンドポイントのセットアップは手動です — プライベートサブネットアクセスの保護はもっと簡単であるべきです
• タグなしイメージのクリーンアップは手動です — ライフサイクルポリシーはデフォルトでは有効になりません

注意

このガイドではプレースホルダー値を使用しています。リポジトリ名は REPLACE_WITH_REPO_NAME、アカウントIDは REPLACE_WITH_ACCOUNT_IDであり、リージョンは一般的な例です。常にAWSアカウントからの実際の値に置き換えてください。これらの設定を本番環境にデプロイする前に、まずサンドボックス環境でテストしてください。IAMの変更やネットワーク設定は実行中のワークロードを中断する可能性があるため、変更は慎重に行い、ロールバック計画を用意してください。自己責任で進め、すべてのプレースホルダーが実際の正しい値に置き換えられていることを確認してください。

よくある質問

• CI/CDパイプラインからECRにイメージをプッシュするにはどうすればよいですか？
• パブリックECRリポジトリとプライベートECRリポジトリの違いは何ですか？
• AWSの外部からECRイメージをプルすることはできますか？
• ECRイメージのセキュリティ脆弱性をスキャンするにはどうすればよいですか？
• なぜ突然ECRの請求額がこんなに高くなったのですか？
• ECRを使用する必要がありますか、それともDocker Hubや他のレジストリを使用できますか？
• 別のAWSアカウントに自分のECRリポジトリへのアクセスを許可するにはどうすればよいですか？
• 実行中のタスクが使用しているイメージを削除するとどうなりますか？

タグ

#aws #ecr #ecs #containers #fargate #devops #cloudnative #iam