Harbor・Amazon ECR・GitHub Container Registry の違い|用途別の選び方
Docker Hub 以外にも、企業向け・クラウドネイティブ・OSS連携など、用途別に最適化されたレジストリが複数あります。本記事では代表的な3つ(Harbor・Amazon ECR・GitHub Container Registry)を比較し、どんなときに何を選ぶかの判断軸を整理します。
💡 この記事のゴール
① 3レジストリの位置づけと特徴
② 機能比較早見表
③ ユースケース別の推奨マッピング
④ 他の選択肢(GAR / ACR / GitLab等)の位置も把握
① 3レジストリの位置づけと特徴
② 機能比較早見表
③ ユースケース別の推奨マッピング
④ 他の選択肢(GAR / ACR / GitLab等)の位置も把握
目次
1. 3レジストリ概観
| レジストリ | 一言で | ホスティング |
|---|---|---|
| Harbor | CNCF製のエンタープライズ向けOSS | 自前運用(オンプレ / VM / K8s) |
| Amazon ECR | AWS マネージドレジストリ | AWS クラウド |
| GitHub Container Registry | GitHub に統合されたレジストリ | GitHub クラウド |
2. Harbor
元々VMware が開発し、現在はCNCFの卒業プロジェクト。オンプレで本格運用したい企業向けのフル機能OSS。
強み
- RBAC:プロジェクト単位・ロール単位の細かい権限
- 脆弱性スキャン統合:Trivy などが標準で組み込み済み
- レプリケーション:別レジストリとの同期
- Webhook:push時に外部システム通知
- Content Trust(Notary)・Cosign 対応:署名管理
- OIDC/LDAP:既存認証基盤と連携
向く場面
- 社内向けの本格レジストリ(数百〜数千エンジニア規模)
- オンプレ・閉域環境でのクラウドレジストリ代替
- 複数リージョン・複数拠点へのレプリケーション要件
向かない場面
- 個人〜小チーム(運用コスト過剰)
- K8sクラスター無しでの運用は重め
3. Amazon ECR
AWS 内で動くマネージドレジストリ。特に ECS/EKS/Lambda などAWSサービスと組み合わせる時の標準。
強み
- IAM 統合:AWS IAM ポリシーでアクセス制御
- プライベートが標準・公開用の ECR Public もあり
- スキャン:Basic(無料)/ Enhanced(有料・Amazon Inspector)
- ライフサイクルポリシー:古いタグの自動削除
- レプリケーション:別リージョン・別アカウントへ自動複製
- Immutable tag 設定:上書き防止
認証の特徴
# AWS CLI でログイントークンを取得 → docker login に渡す(12時間有効)
aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin \
123456789.dkr.ecr.us-east-1.amazonaws.com
# push
docker tag myapp:1.0 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0
向く場面
- AWS 上でアプリを動かしている(ECS/EKS/Fargate/Lambda)
- IAM ベースの認可を一元管理したい
- AWS ネットワーク内での高速 pull が必要
4. GitHub Container Registry
GitHub に統合されたレジストリ。ghcr.io で始まるホスト名。GitHub Actions との組み合わせで爆速のCI/CDループを組めます。
強み
- GitHub Actions でゼロ設定 push:
GITHUB_TOKENで自動認証 - リポジトリ単位の権限:GitHub のアクセス権をそのまま引き継ぐ
- Organization連携:チームで権限管理
- パブリックは無料・プライベート(個人無料)も寛容
- OCI 準拠:Cosign 署名・SBOM 添付に最適
認証
# ローカルから(PAT)
echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin
# GitHub Actions 内(ワークフローに書くだけ)
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
# タグは常に ghcr.io//:
docker push ghcr.io/myorg/myapp:1.0
向く場面
- GitHub でコード管理している OSS・プロジェクト
- Actions でビルド→push したい(認証が極めてシンプル)
- Sigstore/Cosign でモダンな署名運用を入れたい
5. 機能比較早見表
| 項目 | Docker Hub | Harbor | Amazon ECR | GHCR |
|---|---|---|---|---|
| ホスティング | SaaS | 自前 | AWS | GitHub SaaS |
| コスト | 無料〜 | インフラ費用のみ | 従量 | 無料〜(寛容) |
| RBAC | ○(Team有料) | ◎ プロジェクト単位 | IAM 統合 | GitHub 権限 |
| 脆弱性スキャン | Scout(プラン依存) | Trivy組込 | Inspector | dependabot連携 |
| Immutable tag | 有料プラン | ◎ | ◎ | ◎ |
| Pull Rate Limit | あり(無料) | なし | なし | なし(実質) |
| 署名(Cosign) | 可 | 統合 | 可 | ◎ Actions連携 |
| レプリケーション | Mirror機能 | ◎ | ◎ | なし |
| 閉域運用 | × | ◎ | VPCエンドポイント | × |
6. 用途別の選び方
| あなたの状況 | おすすめ | 理由 |
|---|---|---|
| OSSを広く配布したい | Docker Hub or GHCR | 無料・見つけてもらいやすい |
| 個人開発・小さなプロジェクト | GHCR | GitHub Actions連携が圧倒的に楽 |
| AWSで本番運用 | ECR | IAM・VPC・ECS/EKS と完全統合 |
| 社内大規模・オンプレ | Harbor | RBAC・レプリケーション・完全制御 |
| GCP で運用 | Google Artifact Registry | GCP IAM 統合 |
| Azure で運用 | Azure Container Registry | Azure AD 統合 |
| 閉域環境(インターネット無し) | Harbor or registry:2 | SaaSは使えない |
| Rate Limit 回避だけしたい | Mirror で Docker Hub をキャッシュ(Harbor) | 既存資産を活かせる |
7. その他の選択肢
| レジストリ | 特徴 |
|---|---|
| Google Artifact Registry | 旧GCR後継。GCP統合、Docker以外のパッケージも管理 |
| Azure Container Registry | Azure統合、ACR Tasks でビルドも可 |
| GitLab Container Registry | GitLab に同梱。CI/CD も一元化 |
| Quay | Red Hat製。OpenShift 寄り |
| JFrog Artifactory | 大企業向け。Docker以外の成果物も管理 |
8. まとめ
| 迷ったら | 選ぶ |
|---|---|
| OSS配布 | Docker Hub / GHCR |
| 個人・小規模 | GHCR |
| AWS運用 | ECR |
| GCP運用 | Artifact Registry |
| Azure運用 | ACR |
| 社内大規模・オンプレ | Harbor |
| CI/CD最速 | GHCR + GitHub Actions |
✅ 第7章完了!次のステップ
レジストリ編はここまで。第8章 セキュリティでは「本番で事故らない」ためのコンテナ防御術(rootless、capabilities、読み取り専用、Seccomp/AppArmor、脆弱性スキャン、Secrets管理)を総ざらいします。本章で作ったイメージを安全に動かすための章です。
レジストリ編はここまで。第8章 セキュリティでは「本番で事故らない」ためのコンテナ防御術(rootless、capabilities、読み取り専用、Seccomp/AppArmor、脆弱性スキャン、Secrets管理)を総ざらいします。本章で作ったイメージを安全に動かすための章です。



コメント