Amazon ECR徹底解説：Artifact Registry・Azure Container Registry比較で学ぶ「コンテナレジストリ設計」の実務
はじめに
Amazon ECR（Amazon Elastic Container Registry）は、AWS が提供するフルマネージドのコンテナイメージレジストリです。Docker イメージだけでなく、OCI イメージや OCI 互換アーティファクトも保存・管理でき、IAM によるアクセス制御、脆弱性スキャン、ライフサイクルポリシー、レプリケーション、pull through cache など、実運用で必要になりやすい機能がかなり揃っています。AWS の公式ドキュメントでも、ECR は secure, scalable, and reliable な managed container image registry service であり、Docker image、OCI image、OCI compatible artifacts を扱えると説明されています。
このテーマが役に立つのは、ECS や EKS、Fargate、Kubernetes 基盤を触るインフラ担当の方だけではありません。アプリケーション開発チームにとっても、コンテナレジストリは「イメージを置く倉庫」以上の存在です。どのタグを残すか、誰が push できるか、脆弱性をどこで検査するか、ベースイメージ更新をどう追うか、別リージョンや別アカウントへどう配るかといった論点が、リリース速度と安全性に直結するからです。ECR はこれらを AWS の権限・監査・ネットワーク設計の中へ自然に取り込みやすいのが特徴です。
比較対象としては、Google Cloud の Artifact Registry、Azure の Azure Container Registry（ACR） がとても分かりやすいです。Artifact Registry は Google Cloud の統合体験の一部としてアーティファクトを中央保存できるサービスで、コンテナだけでなく複数種別のパッケージを扱う「universal package manager」として案内されています。しかも Google Cloud では、旧来の Container Registry から Artifact Registry への移行が推奨されており、現在の標準的な選択肢は Artifact Registry です。Azure Container Registry は、あらゆる種類のコンテナデプロイに向けたプライベートレジストリとして、イメージと関連アーティファクトの保存・管理、Azure 内でのビルド自動化、geo-replication、Private Link などを提供します。
最初に結論を申し上げると、AWS 上でコンテナ運用をするなら Amazon ECR はかなり自然で扱いやすいです。一方で、コンテナ以外のパッケージもまとめて一元管理したいなら Artifact Registry が魅力的ですし、Microsoft / Azure の基盤と近い場所でレジストリ運用をしたいなら ACR が整理しやすいです。つまり、どれが一番優れているかではなく、どのクラウドのデリバリ基盤に寄せるか、レジストリに何を載せるか、どこまで自動化したいか で選ぶと失敗しにくいです。
1. Amazon ECRとは何か
Amazon ECR は、AWS アカウントごとに用意されるプライベートレジストリを中心に、コンテナイメージや OCI アーティファクトを安全に保存・配布するサービスです。公式ドキュメントでは、各 AWS アカウントにデフォルトの private registry が提供され、高可用かつスケーラブルなアーキテクチャで private image repositories を管理できると説明されています。さらに、パブリック向けの配布が必要な場合には Amazon ECR Public も別サービスとして提供されています。
ここで大切なのは、ECR を「Docker Hub の社内版」くらいの感覚で終わらせないことです。実務では、レジストリはソフトウェアサプライチェーンの入口です。どのイメージがいつ作られ、どのタグがどのコミットに紐づき、脆弱性はどう評価され、誰が本番用リポジトリへ push できるのか、別リージョンや別アカウントへどう複製されるのか、といった管理の中心になります。ECR は IAM によるリソースベース権限、スキャン、ライフサイクルポリシー、レプリケーションなどを持つため、単なる保管庫より一段上の運用を作りやすいです。
また、ECR は AWS のコンテナ実行基盤と非常に近いのが魅力です。ECS、EKS、Fargate と組み合わせたときに、権限、認証、リージョン設計、監査の文脈が揃いやすく、レジストリだけ別思想の製品を持ち込まずに済みます。この「AWS の流れの中で自然に置ける」ことは、地味ですが運用上とても大きいです。
2. ECRの主要機能：実務で効くのはこの4つです
2-1. ライフサイクルポリシー
ECR のライフサイクルポリシーは、古くなったイメージや不要なタグを自動整理するための機能です。AWS 公式では、ライフサイクルポリシーによって未使用イメージのクリーンアップルールを定義でき、プレビューで影響確認もできると説明されています。さらに、ポリシーに基づく archive または expire の処理は最大 24 時間以内に反映され、アクションは CloudTrail に記録されます。
これは実務ではとても重要です。コンテナ開発では、CI のたびにタグ付きイメージが増えやすく、放っておくと「どれが現役でどれが不要か」が曖昧になります。その結果、レジストリ容量だけでなく、事故時の切り戻し判断や脆弱性対応の対象把握まで難しくなります。ですので、ECR を入れたら最初にやるべきなのは、むしろ push の自動化よりも「何世代残すか」「latest をどう扱うか」「本番タグは消さないか」を言語化し、ライフサイクルポリシーに落とすことです。
2-2. 脆弱性スキャン
ECR はイメージスキャン機能を持っています。AWS 公式では、ECR がソフトウェア脆弱性スキャンを提供し、basic scanning と enhanced scanning の設定があることが説明されています。basic scanning では push 時や手動スキャンが可能で、イメージは 24 時間に 1 回スキャンできます。enhanced scanning はレジストリ単位・リージョン単位で構成します。
ここでの実務ポイントは、「スキャンがある＝安全」ではないことです。スキャン結果は、運用に載せて初めて意味を持ちます。たとえば、重大脆弱性が見つかったらデプロイを止めるのか、一定期間の猶予を設けるのか、ベースイメージ更新を自動で促すのか、といったルールが必要です。ECR はスキャン機能を提供しますが、組織としては「どの深刻度から止めるか」を決めるほうが先です。
2-3. レプリケーション
ECR private registry は、cross-Region と cross-account のレプリケーションをサポートします。AWS 公式では、宛先アカウントに許可ポリシーを設定すれば、ソースレジストリから別アカウント・別リージョンへ private repository を複製できると説明されています。
この機能が役立つのは、マルチアカウント運用や災害対策です。たとえば、開発アカウントでビルドしたイメージを本番アカウント側へ配る、東京リージョンでビルドした成果物を大阪へ事前複製しておく、といった設計がしやすくなります。レジストリを「各環境で個別に作る」より、「信頼できる供給元から複製する」設計のほうが、サプライチェーン管理としても分かりやすいです。
2-4. Pull through cache
ECR は pull through cache rules を使って、上流レジストリの内容を private registry に同期・キャッシュできます。AWS 公式では、Amazon ECR Public、Kubernetes container image registry、Quay などを上流に設定できると説明されています。
これは、外部レジストリ依存を減らしたい場合にとても便利です。たとえば、本番クラスタが毎回外部パブリックレジストリへ pull に行く設計は、可用性・速度・監査の面で不安が残ります。ECR 側でキャッシュしておけば、配布経路の統制と可視性が上がり、セキュリティスキャンやアクセス制御も組み込みやすくなります。
3. GCP Artifact Registryとの比較
Artifact Registry は、Google Cloud の統合アーティファクトレジストリです。公式ドキュメントでは、Artifact Registry がアーティファクトとビルド依存関係を中央保存できる “universal package manager” であり、コンテナイメージだけでなく非コンテナ成果物も扱えると説明されています。また Google Cloud では、Container Registry からの移行先として Artifact Registry が推奨されています。
この時点で、ECR との違いがかなり見えます。ECR はコンテナレジストリとして非常に強い一方、Artifact Registry はコンテナを含む複数種別アーティファクトの一元管理基盤として見るほうがしっくりきます。もし組織として「コンテナだけでなく、言語パッケージや依存物も同じ方針で管理したい」という要件が強いなら、Artifact Registry の設計思想はとても魅力的です。
Artifact Registry には remote repositories と virtual repositories があります。公式概要では、remote repositories によって上流のパブリックソースをキャッシュし、脆弱性スキャンや依存情報の管理に役立てられること、virtual repositories により複数レポジトリを単一エンドポイントのように扱えることが説明されています。さらに、Container Scanning API を有効にすると、Artifact Registry に push したイメージは自動スキャンされます。2024 年以降はリポジトリ単位でスキャンの有効/無効を切り替えられることもリリースノートで案内されています。
実務的にまとめると、
- ECR は AWS のコンテナ供給ラインをきれいに整えたい場合に自然
- Artifact Registry は コンテナ＋他パッケージを一元管理したい場合に魅力
です。コンテナレジストリだけを見ると ECR はとてもわかりやすいですが、組織全体のアーティファクト戦略まで広げると Artifact Registry の守備範囲は広いです。
4. Azure Container Registryとの比較
Azure Container Registry（ACR）は、Azure のプライベートコンテナレジストリで、コンテナイメージや関連アーティファクトをビルド・保存・管理できます。公式ドキュメントでは、ACR が private registry service であり、ビルドから保存、管理までを担うと説明されています。さらに、ACR Tasks により Azure 上でオンデマンドビルドや、ソース更新・ベースイメージ更新・タイマーによる自動ビルドが可能です。
ここで ECR との違いとして目立つのが、レジストリ内ビルド機能の強さです。ECR 自体はビルド実行基盤ではなく、基本は外部 CI/CD やビルドパイプラインと組み合わせて使います。一方 ACR は Tasks により、レジストリの近くでビルド・再ビルド・ベースイメージ追従を自動化しやすいです。特に、ベースイメージ更新時に依存するアプリケーションイメージを自動リビルドできる点は、セキュリティ運用にとても相性が良いです。
また、ACR の Premium SKU では geo-replication、Private Link、より高いスループットや API concurrency が使えます。Azure の SKU ドキュメントでは、Basic / Standard / Premium の 3 段階があり、Premium で geo-replication と Private Link がサポートされると明記されています。geo-replication を有効にすると、push されたイメージは各 geo-replica に同期されます。
現場向けに言うと、
- ECR は AWS に自然に馴染むコンテナレジストリ
- ACR は レジストリ＋ビルド自動化＋ geo-replication を Azure 内で完結しやすい
という違いです。Microsoft / Azure の基盤で完結したい組織には ACR の体験はかなり分かりやすく、逆に AWS のデプロイ基盤と一体で考えるなら ECR のほうが素直です。
5. 料金の考え方
ECR の料金は比較的わかりやすく、保存したデータ量とデータ転送が中心です。AWS の料金ページと FAQ では、前払いなし・コミット不要で、private / public repositories に保存したデータ量と、インターネットなどへのデータ転送に対して課金されると説明されています。例として、同一リージョン内で ECS on EC2 や Fargate が pull する場合は data transfer out が課金されないケースが示されています。
Artifact Registry の料金は、公式ページで storage、data transfer、vulnerability scanning が中心と説明されています。つまり、ECR と似ていますが、スキャン機能が料金上でもより明示的に見えやすいです。
ACR は、Basic / Standard / Premium の SKU ベースで、日額・含有ストレージ・機能差が分かれており、Premium で geo-replication などが追加されます。Azure の価格ページでは、Basic / Standard / Premium ごとに含有ストレージやサポート機能が整理されています。
この違いをかなり実務的に言い換えると、
- ECR：容量と転送量を中心に素直に増える
- Artifact Registry：容量・転送・スキャンを合わせて見る
- ACR：SKU 選択が先にあり、その上で容量や機能を考える
です。
サンプル：費用が増えやすいパターン
- CI ごとにタグを残し続けて保存量が膨らむ
- 別リージョンやインターネットへの pull が多い
- スキャン対象を広げすぎて運用ノイズも費用も増える
- Premium 機能が必要ないのに ACR を上位 SKU にしている
ですので、どのクラウドでも「何を何世代残すか」が最初のコスト最適化になります。レジストリは小さな部品に見えますが、CI/CD が活発な組織ほど、整理しないと静かに費用が膨らみます。
6. Amazon ECRが特に向いているケース
Amazon ECR が最も自然にハマるのは、AWS 上で ECS / EKS / Fargate を中心にコンテナ運用するチームです。イメージの保管、権限制御、デプロイ、監査、レプリケーションまでを AWS の文脈で揃えやすく、外部レジストリや別クラウドの認証体系をまたがずに済みます。
また、コンテナ配布の統制を強めたいチームにも向いています。pull through cache、image scanning、lifecycle policies、cross-account replication を組み合わせれば、パブリックレジストリ依存を減らしながら、自社のソフトウェア供給ラインを見える化しやすいです。これは、社内のセキュリティ要件や監査要件が強くなってくるほど価値が増します。
さらに、“まずはコンテナだけ” をしっかり整えたい組織にも向いています。Artifact Registry のように守備範囲を広く取るのではなく、まずは Docker / OCI イメージと関連アーティファクトの管理に集中し、その品質を上げたい場合、ECR はかなりわかりやすいです。コンテナ基盤を安定させてから、他パッケージ管理へ広げる考え方と相性が良いです。
7. よくある失敗と、その避け方
7-1. タグ戦略を決めない
「latest だけで運用」「コミット SHA とリリースタグが混在」「本番タグもCIタグも同じ扱い」といった状態だと、後から事故時の切り戻しや脆弱性対応が難しくなります。ECR を入れたら、まずタグ命名規則と保持方針を決め、ライフサイクルポリシーへ落とすのがおすすめです。
7-2. スキャン結果を見ているだけで運用しない
脆弱性スキャンを有効にしても、対応基準がないと「見つかったが誰も止めない」状態になりがちです。重大度しきい値、例外申請、ベースイメージ更新方針を先に決めると、スキャンが生きてきます。
7-3. パブリックレジストリへ直接依存し続ける
開発初期は楽ですが、本番クラスタが毎回外部へ pull に行くと、可用性・監査・速度の面で不安が残ります。pull through cache や private registry へのミラーを使って、供給経路を自社側へ寄せると運用が安定します。
7-4. クラウドごとの差を軽く見る
ECR、Artifact Registry、ACR はどれも「コンテナレジストリ」ですが、Artifact Registry はアーティファクト全般、ACR は Tasks や Premium 機能を含む構成、ECR は AWS のコンテナ運用ラインとの一体感に強みがあります。名前が似ているから同じ、ではなく、自社の供給ラインにどれが合うか で選ぶと失敗しにくいです。
まとめ
Amazon ECR は、AWS のコンテナ運用に自然に溶け込むフルマネージド・コンテナレジストリです。private registry、public registry、ライフサイクルポリシー、イメージスキャン、cross-Region / cross-account replication、pull through cache などを持ち、単なる保存庫ではなく、コンテナ供給ラインの中核として使いやすいのが魅力です。
Artifact Registry は、コンテナに加えて他パッケージもまとめて管理しやすい統合アーティファクト基盤で、Google Cloud における現在の標準選択肢です。ACR は、プライベートレジストリとしての基本機能に加えて、ACR Tasks や Premium SKU の geo-replication、Private Link など、Azure 内で完結したコンテナ供給ラインを作りやすいのが強みです。
かなり実務的に言うと、
- AWS 上でコンテナを安定運用したい → Amazon ECR
- コンテナ以外も含めたアーティファクト統合管理をしたい → Artifact Registry
- Azure 上でビルド自動化や geo-replication まで含めて整理したい → Azure Container Registry
という整理がいちばんわかりやすいです。
最初の一歩としては、ECR を選ぶ場合でも、いきなり全リポジトリを作り込むのではなく、1つの本番系サービスに対して、タグ戦略・ライフサイクルポリシー・スキャン運用だけ先に整える のがおすすめです。それだけでも、レジストリは「ただの倉庫」から「説明できる供給ライン」へ大きく変わります。
参考情報
- Amazon ECR の概要、OCI 対応、IAM 連携、private/public registry。
- ECR のライフサイクルポリシー、スキャン、pull through cache、レプリケーション。
- Artifact Registry の概要、移行推奨、remote/virtual repositories、脆弱性スキャン。
- Azure Container Registry の概要、SKU、geo-replication、Tasks。