XI本部クラウドイノベーションセンター所属、2年目の米田です。別ブログにてAmazon ECR と FutureVulsを用いたコンテナイメージ運用について紹介させていただきましたが、実際に使っていく中で、Amazon ECR には想像以上に多くの便利な機能が備わっていることに気づきました。本記事では、その中でも日々の運用を効率化したり、セキュリティや管理性を高めたりするうえで役立つ ECR の機能について、実体験を交えながらいくつかご紹介します。
これから Amazon ECR に触れていく方や、すでに利用しているものの「なんとなく使っている」という方にとっても、本記事が少しでも参考になれば幸いです。

まずは復習

以前のブログでは、代表的なコンテナオーケストレーションサービスであるAmazon Elastic Kubernetes Service（Amazon EKS）と Amazon Elastic Container Service（Amazon ECS）の 2 つのサービスについてご紹介しました。これらのサービスは、コンテナのデプロイやスケーリング、可用性の確保など、アプリケーション実行基盤として重要な役割を担っています。
また、それらのサービスへアプリケーションをデプロイするためのコンテナイメージの管理先として、Amazon Elastic Container Registry（Amazon ECR）についても取り上げました。
Amazon ECR は、主に Docker コンテナイメージを管理するためのフルマネージドなレジストリサービスであり、Amazon ECS、Amazon EKS、AWS Lambda（コンテナイメージ形式での実行）など、AWS の主要なコンテナ関連サービスと高い互換性を持っています。そのため、AWS 上でコンテナを利用する際の標準的なイメージ管理基盤として利用されるケースも多く、セキュリティ、可用性、運用性の観点からも安心して利用できるサービスとなっています。

Amazon ECR の主な機能

Amazon ECR には、単なるコンテナイメージの保管場所にとどまらず、セキュリティや運用効率を高めるためのさまざまな機能が備わっています。例えば、イメージのスキャンによる脆弱性検出、ライフサイクルポリシーによる不要なイメージの自動削除、IAM と連携した細かなアクセス制御など、実運用において役立つ機能が充実しています。
私自身の理解を整理する意味も込めて、本記事では面白いと感じた機能について、実際の利用シーンも想定しながらご紹介します。

タグフィルタ

Amazon ECRでコンテナイメージを管理する際、イメージタグの上書き可否を制御できることをご存知でしょうか。ECRのイメージタグミュータビリティは、同じタグ名で異なるイメージを上書きできるかどうかを制御する機能です。

MUTABLE（ミュータブル） - デフォルトの設定

同じタグで何度でも上書き可能
例えば latestタグを更新し続けるような運用に適している

IMMUTABLE（イミュータブル）

一度プッシュしたタグは二度と上書きできない
セキュリティとトレーサビリティを重視する運用に最適

IMMUTABLE_WITH_EXCLUSION（除外設定付きイミュータブル） - 比較的新しい機能

基本的にイミュータブルだが、特定のタグパターンだけミュータブルにできる
柔軟性とセキュリティのバランスが取れた設定

例えば、latest タグを使ってコンテナイメージを運用しているプロジェクトでは、latest を継続的に更新するためにイメージをミュータブル（上書き可能）に設定しているケースが多く見られます（いわゆるlatest運用）。確かにこの設定にしておくと、同じタグ名であれば常に最新のイメージを参照できるという利便性はありますが、意図せず古いバージョンが上書きされてしまったり、本番環境と開発環境でイメージ内容が一致しなくなるといったリスクが高まるという危険性も伴います。
このような運用による問題を避けるために、Amazon ECR では タグフィルタ機能 が登場しました。タグフィルタを利用することで、特定のタグ名や形式に対してのみ更新を許可したり、逆に更新を制限することができます。例えば、latest タグはミュータブルのままにしておきつつ、その他の重要なタグはイミュータブルに固定する、といった運用が可能になります。

タグフィルタ機能はコンソール上から簡単に設定できるだけでなく、Terraform の AWS プロバイダーでもすでにサポートされています。インフラをコードとして管理している場合でも、Terraform で柔軟にルールを定義・再利用できるため、安定したタグ運用を実現しやすくなっています。

resource "aws_ecr_repository" "this" {
  name                 = "blog-app"
  image_tag_mutability = "IMMUTABLE_WITH_EXCLUSION"

  image_tag_mutability_exclusion_filter {
    filter      = "latest"
    filter_type = "WILDCARD"
  }
}

アーカイブストレージクラス

Amazon ECRを使い続けていると、過去のバージョンのコンテナイメージが蓄積され、ストレージコストが気になってきます。削除するにはコンプライアンス上の保持が必要だったり、いざというときのロールバック用に残しておきたかったりと、なかなか削除できないイメージも多いはずです。

そんな課題を解決するために、AWSは2024年にアーカイブストレージクラス（Archive Storage Class）機能をリリースしました。この機能を使うと、アクセス頻度の低いコンテナイメージを通常ストレージの約3割削減されたコストで保管できます。厳密には、最初の150TBまでは標準ストレージと同じコスト（$0.10）なのですが、それ以上のアーカイブがある場合はディスカウントされるようです（以下リファレンスですが、日本語版では情報が掲載されておりませんでしたのでご注意ください）。
https://aws.amazon.com/jp/ecr/pricing/

項目	標準ストレージ	アーカイブストレージ
月額コスト（ap-northeast-1）	$0.10/GB	$0.07/GB（約3割減）
アクセス時間	即座	復元が必要（数時間）
最小保存期間	なし	90日間
使用シーン	頻繁にpull/deploy	長期保管・コンプライアンス
復元コスト	なし	pull時に復元料金が発生

過去バージョンの長期保管
ロールバック用の古いバージョン
メンテナンス終了した古いバージョン

などで用意しておくべきイメージに対して、本機能を駆使することが多いようです。
アーカイブは手動で実施することもできますし、もちろんCLIやライフサイクルポリシーを使ってイメージを遷移させることもできます。以下はそれぞれの設定例です。

コンソール
CLI

aws ecr put-image-lifecycle-policy \
  --repository-name blog-app \
  --image-ids imageTag=v1.0.0

ライフサイクルポリシー

resource "aws_ecr_lifecycle_policy" "this" {
  repository = aws_ecr_repository.this.name

  policy = jsonencode({
    rules = [
      {
        rulePriority = 1
        description  = "90日以上前のイメージをアーカイブ"
        selection = {
          tagStatus   = "any"
          countType   = "sinceImagePushed"
          countUnit   = "days"
          countNumber = 90
        }
        action = {
          type = "archive"
        }
      },
    ]
  })
}

簡単に設定できそうですね。アーカイブするとプルすることはできなくなり、エラーが返ってきます。

$ docker pull <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/<リポジトリ名>@tag                                     
Error response from daemon: unknown: The requested image is in an inaccessible state. Please restore if needed

プルする（使用する）ことはできませんが、describe-images や list-images などをつかった詳細表示は可能です。
こうなると、めったに使わなさそうなイメージはすべてアーカイブしてしまった方が良い気もしますが、復元には一定のコストがかかります。また復元には20分ほど時間がかかるようです（とはいえ自分が試してみたときは数分で復元されてました）。何時間もかかるようなものではないようなので、障害復旧とかでもプロジェクトの要件次第では利用できるかもしれません。

# 復元リクエスト
aws ecr restore-archived-images \
  --repository-name blog-app \
  --image-ids imageTag=v1.0.0

アーカイブ後は削除も可能ですが、アーカイブされたイメージの最小ストレージ期間は 90 日間なようで、ライフサイクルポリシーで削除するには最低でも90日を設定する必要があるようです。もし90日未満のイメージを削除したい場合は、batch-delete-image API を使った手動削除になるので、もし短期間のみのアーカイブを望むのであればアーカイブ設定は不適切になります。

ちなみにですが、2025年8月よりECRのリポジトリあたり 100,000 のイメージまでがサポートされているようです。
https://aws.amazon.com/jp/about-aws/whats-new/2025/08/amazon-ecr-supports-100000-images/

このサポートが保証するイメージ数に、アーカイブしたイメージが含まれるのかはわかりませんでした...。　コストだけでなく、キャパシティも最適化されると良いですね。

プルタイム更新の除外

Amazon ECRでは、コンテナイメージがプルされるたびに「最終プル時刻（LastRecordedPullTime）」が更新されます。この情報は、sinceImagePulledを使ったライフサイクルポリシーで「実際に使われていないイメージを自動削除する」という賢い運用に活用できます。
そんな中で、この時刻の更新を実施しないようにする方法も存在します。それがプルタイム更新の除外機能（Pull Time Update Exclusion）です。特定のIAMロールからのプルをLastRecordedPullTimeの更新対象から除外することで、より正確なライフサイクル管理が可能になります。

最近のアップデート機能のため、現時点ではまだ詳細な情報は多くありませんが、例えばセキュリティスキャナー（Snyk、Trivy、CrowdStrike など）や CI/CD パイプライン上のテスト処理が頻繁にコンテナイメージを pull すると、実際には本番環境で利用されていないイメージであっても「最近使用された」と判定されてしまうといった課題が想定されます。
その結果、本来であれば削除対象となるはずの古いイメージが、ECR のライフサイクルポリシーによって削除されず、不要なイメージが溜まり続けてしまう可能性があります。

こうした課題に対して、今回制御した制御機能を活用することで、スキャンやテスト用途の pull を「実運用の利用」とは区別して扱えるようになり、ライフサイクルポリシーをより正確に機能させることができます。

まとめ

今回は、Amazon ECR における運用をより安全かつ効率的にするための機能として、

ミュータブル・イミュータブルのタグ制御（タグフィルタ）、
アーカイブ機能、
プルタイムの更新除外機能

の 3 つを紹介しました。
これらの機能を活用することで、

タグの誤更新によるリスクを抑えられる
利用頻度の低いイメージを適切に保管・整理できる
ライフサイクルポリシーをより意図通りに運用できる

といったようなメリットが得られます。
ECR は単なるイメージ保管庫ではなく、工夫次第で運用負荷やコスト、セキュリティリスクの低減にも大きく貢献してくれるサービスだと感じました。
紹介できなかった機能もあるので第二弾としてまた掲載できればと思っております。
本記事が、これから ECR を本格的に活用していく方の参考になれば幸いです。