Amazon ECR のコンテナイメージ管理 - ライフサイクルポリシーとイメージスキャン
プライベートリポジトリのライフサイクルポリシーで古いイメージを自動削除し、イメージスキャンで脆弱性を検出する運用パターンを紹介します。
ECR の基本とリポジトリ管理
ECR は Docker コンテナイメージと OCI アーティファクトのマネージドレジストリで、1 イメージあたり最大 42 GB のレイヤーをサポートします。プライベートリポジトリとパブリックリポジトリ (ECR Public) を提供しており、プライベートリポジトリは IAM ポリシーでアクセスを制御します。特定の IAM ロールのみがイメージのプッシュ・プルを許可する設定が可能で、リポジトリポリシーを使えば別の AWS アカウントからのプルも制御できます。イメージは AES-256 で保存時に暗号化され、KMS のカスタマーマネージドキー (CMK) も選択できます。CMK を使用するとキーの自動ローテーションや監査ログとの統合が可能になりますが、プル時の KMS API 呼び出しが増える点に注意が必要です。イメージタグのイミュータビリティを有効にすると、同じタグで異なるイメージを上書きプッシュすることを防止でき、デプロイの再現性を保証します。リポジトリ名はプレフィックスで階層化が可能で (例: team-a/app-frontend)、IAM ポリシーでプレフィックス単位のアクセス制御を実装できます。
ライフサイクルポリシーとコスト管理
ライフサイクルポリシーはリポジトリ内のイメージを自動的にクリーンアップするルールです。タグ付きイメージの保持数 (例: 最新 10 個を保持)、タグなしイメージの保持期間 (例: 7 日以上経過したものを削除)、特定のタグプレフィックスに基づくルールを定義できます。ルールには優先度を設定でき、複数ルールが競合した場合は優先度の高いルールが適用されます。CI/CD パイプラインで頻繁にイメージをプッシュする環境では、ライフサイクルポリシーなしではストレージコストが際限なく増加します。本番用イメージ (prod-*) は 30 世代保持し、開発用イメージ (dev-*) は 5 世代のみ保持するといった差別化が推奨されます。ポリシーのプレビュー機能を使えば、実際に削除される前にどのイメージが対象になるかを確認できます。ECR のストレージ料金はリージョンごとに 1 GB あたり月額で課金されるため、不要なイメージの蓄積は直接コストに影響します。
イメージスキャンとレプリケーション
基本スキャンはプッシュ時に OS パッケージの脆弱性を Clair エンジンで検出します。拡張スキャンは Inspector と統合し、OS パッケージに加えてプログラミング言語パッケージ (npm、pip、Maven) の脆弱性も検出します。拡張スキャンは継続的に実行され、新しい CVE が公開されると既存イメージが再スキャンされます。スキャン結果は EventBridge に発行されるため、Critical/High の脆弱性検出時に SNS 通知や自動修復パイプラインをトリガーする構成が可能です。クロスリージョンレプリケーションはイメージを指定したリージョンに自動複製し、マルチリージョンの ECS/EKS デプロイでイメージのプル時間を短縮します。クロスアカウントレプリケーションも可能で、中央のイメージリポジトリからワークロードアカウントにイメージを配信する構成に活用できます。レプリケーションはフィルタルールで対象リポジトリを限定でき、全リポジトリを複製する必要はありません。 コンテナ技術の知見を広げたい場合はAmazon の専門書も活用できます。
CI/CD パイプラインとの統合パターン
ECR は CI/CD パイプラインのイメージビルド・デプロイフローの中核を担います。CodeBuild や GitHub Actions からイメージをビルドしてプッシュする構成が一般的です。認証トークンは GetAuthorizationToken API で取得し、有効期間は 12 時間です。ビルド時にはマルチステージビルドを使い、最終イメージサイズを小さく保つことがプル時間とストレージコストの削減に効果的です。キャッシュ戦略として、ECR はリモートキャッシュに対応しており、BuildKit の --cache-to と --cache-from オプションで中間レイヤーを ECR に保存してビルドを高速化できます。プルスルーキャッシュを設定すると Docker Hub や GitHub Container Registry などのパブリックレジストリからのプルを ECR 経由でキャッシュし、外部レジストリのレート制限を回避できます。イメージのタグ戦略としては、Git のコミットハッシュや CI のビルド番号をタグに使い、latest タグへの過度な依存を避けることが推奨されます。
設計上の注意点とトラブルシューティング
ECR を運用する際に注意すべき点がいくつかあります。リポジトリあたりのイメージ数には上限があり、デフォルトではリポジトリあたり 10,000 イメージです。上限に近づいた場合はライフサイクルポリシーの見直しか上限緩和申請が必要です。VPC 内からのアクセスには VPC エンドポイント (PrivateLink) を設定することで、インターネットゲートウェイを経由せずにイメージをプル・プッシュでき、セキュリティとネットワークコストの両面で有利です。ECR 用のエンドポイントは ecr.api と ecr.dkr の 2 つが必要で、S3 ゲートウェイエンドポイントも合わせて設定します (イメージレイヤーは S3 に保存されるため)。プルのスロットリングが発生した場合はリトライロジックの実装と、イメージレイヤーの共有 (共通ベースイメージの利用) によるプルサイズの削減が有効です。マルチアーキテクチャイメージ (AMD64 と ARM64 の同居) はマニフェストリストで管理し、Graviton インスタンスと x86 インスタンスの混在環境で同じイメージ URI を使用できます。
まとめ
ECR はコンテナイメージのライフサイクル全体を管理するマネージドレジストリです。ライフサイクルポリシーでストレージコストを自動最適化し、イメージスキャンで脆弱性を継続的に検出します。CI/CD パイプラインとの緊密な統合により、ビルドからデプロイまでのイメージ配信を効率化し、プルスルーキャッシュや VPC エンドポイントなどの機能で運用上の課題を解決します。クロスリージョン・クロスアカウントレプリケーションで、マルチリージョン・マルチアカウント環境のコンテナイメージ配布を一元管理できます。