AWSが提供する完全マネージド型のDockerコンテナレジストリ。インフラは全てAWS管理のため、自前のコンテナリポジトリの運用やインフラ管理が不要。AWSと完全に統合されているので、従来の方法（IAM）でアクセス権の管理が可能と、AWS環境でコンテナワークロードを展開するときにはほぼ必須のサービス。一点、DockerHUBのみたいにインターネットへのパブリック公開はできません。
以下、ECRを実際にAWS上に構築するときに考慮すべき点を、優先順が高いものから挙げていきます。
- イメージタグの変更可能性設定
- イメージスキャンの自動化
- ライフサイクルポリシーの設定
イメージタグの変更可能性（Image Tag Mutability）は、ECR構築上最優先で考慮すべき点です。結論から言うと、プロダクション運用を見据えたECRの設計においては、イメージタグを変更不可に設定することを強く推奨します。
イメージタグの変更不可設定により、ECRで作成したレジストリ内のlatestタグを利用したイメージの運用ができなくなります。これにより、プロダクション環境におけるトラブルが発生したときのトレーサビリティを確保します。
例えば、あるイメージをlatestタグを利用して作成。ECSのタスク定義で指定しそのタスク定義のバージョンをサービスで展開し、プロダクションで運用している状態とします。
運用環境で障害が発生しログから該当するタスク定義とコンテナ定義が特定されたとして、その時ECR側ですでに別のイメージがアップされて更新されていた場合、障害発生したイメージの特定→そこから派生するソースコードの特定ができなくなります。
ソースコードへのトレーサビリティを確保するため、Gitのコミットハッシュや、タグを、コンテナイメージのタグに付与するのが良い。
- 組織内で広く使うコンテナイメージで、定期的に最新バージョンを利用者側で使ってもらいたい
- 最新のイメージのみを強制して利用してもらいたい
- Googleのdistrolessは基本latesタグのみサポート
- distroless: 🥑 Language focused docker images, minus the operating system.
- ECSへのデプロイ時、タスク定義やサービス定義の更新手間を省略し、サービス定義の最新バージョンのデプロイだけでデプロイを完結させたい
現在、イメージタグ変更可能性設定は、CloudFormationのプロパティに対応していません。そのため、ECRをCloudFormationで作成する場合は、別途手動かCLIで有効化する必要があります。
完全無料なので、設定しておきましょう。具体的には、プッシュ時に自動的にスキャンする設定にすることで、特段の運用なくイメージスキャンの実施が可能です。
スキャン結果の活用については、EventBridge連携して自前で実装する必要があります。
現在、イメージスキャンのプッシュ時自動スキャン設定は、CloudFormationのプロパティに対応していません。そのため、ECRをCloudFormationで作成する場合は、別途手動かCLIで有効化する必要があります。
Amazon ECR ライフサイクルポリシー - Amazon ECR
ECRの過去イメージはそのまま利用していても、明示的に削除しない限りは自動で削除されません。イメージはバイナリファイルで容量も大きくなりがちなので、料金面で負担になる場合があります。
- ストレージコストは 1 か月あたり GB 単位で 0.10USD（参考までにS3標準は0.025USD/GB at 東京リージョン）
ライフサイクルポリシーを利用することで、過去分のイメージを自動的に削除できます。以下に、20個以上の古いイメージを自動的に削除するポリシーのCloudFormationテンプレートを記載します。
Resources:
ecrPhpApp:
Type: AWS::ECR::Repository
Properties:
RepositoryName: !Sub ${SystemName}-ecr-php-app
LifecyclePolicy:
LifecyclePolicyText: |
{
"rules": [
{
"rulePriority": 1,
"description": "Delete more than 20 images",
"selection": {
"tagStatus": "any",
"countType": "imageCountMoreThan",
"countNumber": 20
},
"action": {
"type": "expire"
}
}
]
}