ひとことで言うと
プライベートなコンテナイメージレジストリです。GenAIの文脈では、自前で組んだ推論コンテナ（SageMaker AIのBring Your Own Container、ECS/EKS上のMCPサーバ）の出発点として登場します。Bedrockのようなフルマネージドサービスの利用だけで完結するなら、ECRは表に出てきません。
要するに、検品付きの倉庫です。SageMaker AI・ECS・EKSに配るコンテナイメージは、まずここに預けます。しかも預けた瞬間（push時）に中身の脆弱性を検品してくれます。
Bedrockはこの倉庫を経由しません。モデルもインフラも借りるだけの構成なら、GenAIスタックの中にECRが一度も出てこないこともあります。
なぜ生まれたか
GenAIアプリの構成要素のうち、**「自分でコンテナ化して持ち込むもの」**は必ずどこかからイメージを配る必要があります。SageMaker AIでフレームワーク非対応のカスタムアルゴリズムを動かす（Bring Your Own Container）、ECS/EKSで自前のMCPサーバやエージェント基盤をコンテナとして配置する、といった場面です。
SageMaker AIは学習・推論の両方でDockerコンテナを前提にしており、独自コンテナを使う場合は自分でビルドしたイメージを用意します。この「自分でビルドしたイメージをどこに置き、どう安全性を担保するか」という問いに対する答えがECRです。
| 自前で持ち込むもの | ECRが引き受ける役割 |
|---|---|
| SageMaker AIのBYOCイメージ | プライベートリポジトリでの保管・IAM権限管理 |
| ECS/EKS上のMCPサーバイメージ | push時点での脆弱性スキャン |
| 複数リージョンへの配布 | クロスリージョンレプリケーション |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| SageMaker AIのBYOCイメージ保管 | 独自フレームワーク・独自アルゴリズムのコンテナをプッシュし、学習・推論ジョブから参照する | D1・D2 |
| ECS/EKS上のMCPサーバ・エージェント基盤 | 自作のツールサーバ・オーケストレーション層のイメージを配布する | D2 |
| サプライチェーンの脆弱性検査 | イメージスキャンでOS・言語パッケージの既知脆弱性をpush時に検出する | D3 |
| クロスリージョン・クロスアカウント配布 | レプリケーション設定で複数リージョン・複数アカウントに同じイメージを配る | D2 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| SageMaker AIで独自フレームワークの推論コンテナを使いたい | 事前ビルドイメージが対応していない → ECRに独自コンテナをプッシュしてBYOC | Bedrockのカスタムモデルインポートで代替しようとする（対応形式が違う） |
| コンテナのOS・言語パッケージの脆弱性を継続的に検出したい | 変化する脆弱性情報に追従したい → 拡張スキャン（Amazon Inspector連携・継続スキャン） | 基本スキャン（OSのみ・push時のみ）で足りると判断する |
| 複数リージョンのECS/EKSクラスタに同じエージェントイメージを配りたい | リージョンをまたぐ配布 → クロスリージョンレプリケーション | 各リージョンで手動push・手動同期を運用する |
基本スキャンと拡張スキャンは検出範囲が違います。基本スキャンはOSの脆弱性のみでpush時または手動実行、拡張スキャンはAmazon Inspector経由でOSに加えて言語パッケージ（PyTorch・Transformers等のPythonライブラリを含む）の脆弱性まで継続的に検出します。GenAIの推論コンテナはPythonのMLライブラリを大量に含むため、言語パッケージの脆弱性を継続的に見るなら拡張スキャンが必須です。
実務でどう使うか
- プルスルーキャッシュで外部レジストリ（Docker Hub等）のイメージをECR経由でキャッシュできます。 ベースイメージの提供元がダウンした場合でも、自分のECR内のキャッシュからは引き続き取得できます
- VPCインターフェースエンドポイントを使うと、NATゲートウェイなしでプライベートサブネットからイメージをpullできます。 ECS/EKSのタスクがプライベートサブネットに閉じている構成では実質必須です
- ライフサイクルポリシーで古いイメージを自動削除しないと、モデルの実験サイクルが速いGenAI開発では際限なくストレージが増えます
- マネージド署名でイメージの真正性を検証できます。 自前でビルドしたモデル配信コンテナの改ざん検知に使えます
| 機能 | 効果 |
|---|---|
| プルスルーキャッシュ | 外部レジストリ障害時もキャッシュから取得可能 |
| VPCインターフェースエンドポイント | NATゲートウェイなしでプライベートサブネットからpull |
| ライフサイクルポリシー | 実験サイクルの速いGenAI開発でのストレージ肥大化を防止 |
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock | Bedrockはコンテナの概念自体が表に出ない。ECRが登場するのは自前でコンテナ化したものを動かす場面に限られる |
| Bedrock Custom Model Import | Custom Model Importはモデルの重みを持ち込む仕組みで、コンテナイメージではない。BYOC（ECR経由）とは別の経路 |
| SageMaker AIの事前構築済みコンテナ | フレームワークが対応していればAWS提供の事前構築イメージで足り、ECRに独自イメージを置く必要はない。対応外の場合だけBYOCでECRが要る |
| CodeArtifact | CodeArtifactはパッケージ（ライブラリ）の管理、ECRはコンテナイメージの管理。GenAIのCI/CDパイプラインでは両方が別々の役割で登場しうる |
想起チェック
Q1. SageMaker AIで独自フレームワークの学習コードを動かしたい。事前構築済みコンテナが対応していない場合の定石は？
**自分でDockerイメージをビルドしてECRにプッシュし、SageMaker AIのジョブからそのイメージを参照するBring Your Own Container（BYOC）**です。
Q2. 推論コンテナに含まれるPythonのMLライブラリ（PyTorch等）の脆弱性まで継続的に検出したい。基本スキャンで足りるか？
足りません。 基本スキャンはOSの脆弱性のみが対象です。言語パッケージの脆弱性まで検出するには、Amazon Inspector連携の拡張スキャンが必要です。