Amazon ECR概要

この章では、AWSのコンテナレジストリサービスであるAmazon ECRについて学びます。これにより、リポジトリ・タグ・イメージURIの構造やAWS CLIを使ったECR操作の基本が理解できます。

1. 本章の概要

1.1 本章の目的

独自のコンテナイメージを本番運用するには、それを保管・配布するコンテナレジストリが必要です。AWSではECRがこの役割を担い、IAMベースのアクセス制御や自動スキャンなどマネージドサービスの利点を享受できます。

1.2 本章で学ぶ内容

コンテナレジストリの役割、ECRの基本構造（リポジトリ・タグ・イメージURI）、AWS CLIを使ったECR操作を扱います。あわせて、主なユースケースと設計のポイントも整理します。

2. Amazon ECRとは

2.1 コンテナレジストリの役割

コンテナレジストリは、Dockerイメージを保存・管理・配布するためのサービスです。これまでは、ローカル環境でイメージを作成し、コンテナを起動してきました。しかし、実際の開発プロジェクトではチームで開発を進めるため、イメージを共有・管理する場所が必要になります。また、インターネット上で公開するシステムの場合、本番サーバ等から取得（Pull）できる場所にイメージを配置しなければなりません。これらの「イメージの置き場所」となるのが、コンテナレジストリです。

また、ハンズオンで実施したように、頻繁に利用される構成を「ベースイメージ」としてあらかじめ用意し、それを配布・再利用するといった役割も担っています。

2.2 Amazon ECRの位置づけ

Amazon ECR（Elastic Container Registry）は、AWSが提供するコンテナレジストリサービスです。コンテナレジストリとしてはDocker Hubも有名ですが、AWS上で動かすシステムでイメージを使うなら、ECRを利用するほうが効率的でメリットも大きいです。

ECRには以下の特徴があります。

AWSサービスとの連携がしやすい

ECRはAWSのサービスそのものですので、他のAWSサービスからコンテナイメージを利用する場合の連携が非常にスムーズです。具体的には、以下のサービス等ですぐに使えるようになっています。

Amazon ECS（Elastic Container Service）
Amazon EKS（Elastic Kubernetes Service）
AWS Lambda など

IAM（Identity and Access Management）を使って「誰が」「どのサービスが」イメージを操作できるかを細かく設定できる点も、AWSサービスならではの特徴です。

管理の手間が少ない（フルマネージド）

ECRはフルマネージド型のサービスであるため、裏側のサーバ管理やメンテナンスはAWS側で行ってくれます。そのため、利用者はイメージの登録（プッシュ）をするだけでよく、管理の手間を省くことができます。

なお、SaaSとして提供されるDocker Hubも、この点においては同様です。

高い可用性と耐久性を持つ

ECRに保存したイメージの実体は、裏側でAmazon S3に保存されています。S3の仕組みによって高い可用性と耐久性が確保され、データが消えてしまうリスクを最小限に抑えられます。AWS公式のWhat is Amazon Elastic Container Registry?でも「Amazon Elastic Container Registry (Amazon ECR) is an AWS managed container image registry service that is secure, scalable, and reliable.」と紹介されており、フルマネージドかつ高い信頼性を持つレジストリサービスとして位置付けられています。

以上の点から、AWS環境においてコンテナイメージを使用する場合は、ECRを採用することが一般的です。

💡 ポイント
Docker Hubは、世界最大のコンテナレジストリで、nginxやalpineなどの公式イメージを含む膨大な数のイメージが公開されています。一方、ECRはAWSのサービスとして提供されるため、IAMによるアクセス制御やECS・EKSとのシームレスな連携が強みです。AWS環境でシステムを構築する場合は、自分たちのアプリケーションイメージの管理にECRを利用するのが一般的です。なお、ECRにもパブリックリポジトリ（ECR Public Gallery）があり、AWSが提供する公式ベースイメージなども公開されています。

💡 ポイント

Docker Hubは、世界最大のコンテナレジストリで、nginxやalpineなどの公式イメージを含む膨大な数のイメージが公開されています。一方、ECRはAWSのサービスとして提供されるため、IAMによるアクセス制御やECS・EKSとのシームレスな連携が強みです。AWS環境でシステムを構築する場合は、自分たちのアプリケーションイメージの管理にECRを利用するのが一般的です。なお、ECRにもパブリックリポジトリ（ECR Public Gallery）があり、AWSが提供する公式ベースイメージなども公開されています。

3. ECRの基本構造

続いて、ECRを扱う上での基本構造をみていきたいと思います。

3.1 リポジトリ

リポジトリは、関連するイメージをまとめて管理する単位です。通常、作成するイメージの種類ごとに、1つのリポジトリを作成します。

例えば、以下のようなリポジトリ構成が考えられます。

my-app/web - Webフロントエンドのイメージ
my-app/api - APIサーバのイメージ
my-app/batch - バッチ処理のイメージ

このようにリポジトリを用意し、この中にイメージを格納（プッシュ）していきます。

3.2 イメージタグ

イメージタグは、同一リポジトリ内でイメージのバージョンを識別するために使用します。一般的に以下のようなタグ付け規則が使われます。

タグの例	用途
latest	最新バージョン
v1.0.0	セマンティックバージョニング
abc1234	Gitコミットハッシュ
20240115	日付ベース

どのようなタグを付けるかは、プロジェクトごとにルールを定めて運用することが一般的です。

例えば簡易的な管理が目的であれば、最新バージョンに latest とつけるだけでも構いません。細かいバージョンごとにしっかり管理したい場合は、セマンティックバージョニング、Gitコミットハッシュ、日付ベースでの管理などが適しています。

3.3 イメージURI

ECRのイメージは、URIという形式で管理されます。このURIを指定して、イメージをプッシュしたり、他のサービスからイメージを取得するといった操作が可能です。

URIは以下の形式で構成されます。

＜AWSアカウントID＞.dkr.ecr.＜リージョン＞.amazonaws.com/＜リポジトリ名＞:＜タグ＞

例：

123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app/api:v1.0.0

なお、URIの値はECRの画面上で確認できるため、厳密に形式を覚える必要はありません。

4. ECRの主な機能

続いて、ECRの主な機能を見ていきたいと思います。

4.1 パブリックリポジトリとプライベートリポジトリ

ECRのリポジトリは、パブリックリポジトリとプライベートリポジトリに分けられます。

パブリックリポジトリは、インターネット上で公開され、誰でも自由にイメージを検索・取得（プル）できるリポジトリです。主にオープンソースソフトウェアなどの配布に利用されます。

プライベートリポジトリは、AWSアカウント内のユーザや、許可されたメンバーのみがアクセスできるリポジトリです。AWSの権限管理（IAM）と連携することで、「誰がイメージを操作できるか」を厳密に制御できるため、企業のアプリケーション資産を安全に管理するのに適しています。

4.2 イメージスキャン

ECRでは、リポジトリにプッシュされたイメージに対して、セキュリティの脆弱性診断を自動または手動で実行できます。OSパッケージなどの既知の脆弱性（CVE）を検出し、その深刻度を可視化してくれるため、安全性が確認されたイメージのみを本番環境へデプロイできるようになります。AWS公式のScan images for software vulnerabilities in Amazon ECRでは「Amazon ECR uses AWS native technology with the Common Vulnerabilities and Exposures (CVEs) database to scan for operating system vulnerabilities.」（Basic scanning）と説明されており、CVEデータベースに基づくスキャン方式が採用されていることが分かります。

4.3 ライフサイクルポリシー

あらかじめ設定したルールに基づいて、古いイメージやタグのないイメージを自動的に削除できる機能です。「作成から30日が経過したもの」や「最新の10世代より古いもの」といった指定が可能なため、ストレージコストの最適化と、リポジトリの整理を自動化できます。

4.4 レプリケーション

リポジトリに保存されたイメージを、別のリージョンや別のAWSアカウントへ自動的にコピーできる機能です。

「東京リージョンのイメージを大阪リージョンにも置く」といった災害対策（DR）や、海外拠点のシステム向けにイメージを配布する際などに役立ちます。物理的に近い場所からイメージを取得させることで、デプロイ時間の短縮にもつながります。

5. 主なユースケース

ECRは、AWSでコンテナを運用する際の基盤となるサービスです。以下に代表的なユースケースを紹介します。

5.1 Amazon ECSとの連携

ECRにプッシュしたイメージは、Amazon ECS（Elastic Container Service）から直接参照できます。ECSのタスク定義でECRのイメージURIを指定するだけで、プライベートなイメージを使ったコンテナを起動できます。IAMによる認証が自動的に行われるため、追加の認証設定は不要です。

5.2 CI/CDパイプラインでの活用

CI/CDパイプラインにおけるECRの役割を以下に示します。

flowchart LR
  DEV[開発者] --> GH[GitHub]
  GH --> CICD[CI/CD ビルド]
  CICD -- "イメージをpush" --> ECR[Amazon ECR]
  ECR -- "イメージをpull" --> ECS[ECS デプロイ]

GitHub ActionsやAWS CodeBuildなどのCI/CDツールと連携し、コードの変更を検知して自動的にイメージをビルド・プッシュする構成が一般的です。イメージタグにGitコミットハッシュやビルド番号を使用することで、どのコードからビルドされたイメージかを追跡できます。

5.3 マルチリージョン展開

ECRはリージョンごとにリポジトリを作成します。グローバルに展開するアプリケーションでは、各リージョンにイメージをレプリケートすることで、コンテナの起動時間を短縮し、リージョン間のデータ転送コストを削減できます。ECRのレプリケーション機能を使用すると、この複製を自動化できます。

6. 設計のポイント

ECRを運用する際の主要な検討項目を以下にまとめます。

設計項目	検討内容	推奨・注意事項
リポジトリの命名規則	イメージの識別方法	`アプリケーション名/コンポーネント名`のような階層構造を推奨（例：`my-app/api`、`my-app/web`）
タグ付け戦略	バージョン管理の方法	本番環境では`latest`を避け、セマンティックバージョニングやGitコミットハッシュを使用
ライフサイクルポリシー	古いイメージの管理	「タグなしイメージは1日後に削除」「最新10個以外は削除」などのルールを設定してストレージコストを最適化
イメージスキャン	セキュリティ対策	プッシュ時の自動スキャンを有効化し、脆弱性を早期に検出
IAMポリシー	アクセス制御	本番リポジトリへのプッシュ権限は限定的に、プル権限は必要なサービスにのみ付与
クロスアカウントアクセス	複数アカウントでの共有	共通イメージは専用アカウントで管理し、他アカウントにはプル権限のみを付与

7. まとめ

この章では、Amazon ECRについて学びました。

Amazon ECRは、AWSが提供するコンテナレジストリである
リポジトリ単位でイメージを管理し、タグでバージョンを識別する
aws ecr get-login-password により、Dockerクライアントを認証できる
docker tag でECRのURI形式にタグ付けし、docker push でイメージを送れる
ECRはECS・EKSなどのAWSサービスと統合されており、そのままコンテナのデプロイに使える

次の章では、AWSのコンテナオーケストレーションサービスであるECSとFargateについて学びます。