ECR Revisited

I have been using ECR for ages now. But I normally use it via the Docker CLI, configuring it via Terraform/CloudFormation or using it in CI/CD pipelines. For a product that I use on a very regular basis it is a long time since I have looked at the UI.

When I looked at it for the first time in a while I was surprised by a few new features that have appeared.

This does also highlight one of my biggest AWS challenges. There are now so many features and changes that it is almost impossible to keep on top of the announcements for all the AWS services. Trying to sort out what is relevant to me from the flood of AWS announcements is a real headache.

What is ECR?

ECR stands for Elastic Container Registry. It is the AWS managed solution for storing container images. It can be used with the various AWS container solutions (ECS, EKS, Fargate and Beanstalk). It can equally be used with an on-premise solution, running Docker on ec2 etc.

ECR is a fully managed solution and has minimal configuration. It is quick and easy to get going. You don't need to worry about scaling and there is a simple pricing model based on storage and data transfer out.

As with most AWS services transfer in is free. Transfer out charges are only applicable to data leaving AWS and cross-region traffic.

ECR Features

These are the key features of ECR both new and old.

Public/Private registries

ECR has the the ability to create both private an public registries. If you want to host your own open source project or share software then use a public registry. For private content then use a private registry. Registry authentication is done via AWS IAM.

To log in to ECR via docker you will need to either use the ECR Docker Credential Helper or use the was cli to get a login password. Both of these will work with your regular AWS config files, ec2 roles etc and let you do a docker login.

You can set permission on repositories using IAM or by creating a repository policy.

One note is you can't change between public and private repositories. They have a different URL structure so if you change your mind you will have to recreate.

Image replication

ECR is specific to a region. It is possible to set up both per-region and per account replication. You can also create filters limiting the scope of replication.

Per-account replication can be very helpful for shipping images to a production account or sharing with a customer (this is in addition to the ability to use policies to share images).

Per-region replication is useful for back-ups. It can also be useful for containers are frequently pulled from other regions. Replicating an image once can be much cheaper than frequent cross-region pulls.

VPC endpoints

If you want to use ECR in a private VPC (or subnet) you can create a VPC endpoint so all communication stays within your VPC. This is great for private subnets or where you want all your traffic to stay within your VPC.

Image scanning

AWS offers the ability to scan container images using the open source Claire scanner. There are 2 flavours of scanning, basic and enhanced (there is an additional price for enhanced).

Basic scans on push or manual scans can be triggered. Enhanced scanning provides more continuous scanning of both OS and popular programming language packages and uses Amazon Inspector.

Basic scanning can be limited by filter. With enhanced scanning you can limit both basic and continuous scanning by filter.

With enhanced scanning you can use event bridge to receive scan reports and take action.

Lifecycle policies

The lifecycle policies are quite simplistic and only expire images removing them from the repository. Lifecycle rules can be created for all images or for specific tags. They can also created based on age of image or count of images.

Early on ECR had some relatively small service limits. These have been greatly expanded but it is worth setting up lifecycle rules especially when pushing frequently with a CICD system.

Pull through cache

A pull through cache can be used to mirror an upstream public repository. You can create registry rules to mirror multiple up-stream sources. ECR will cache for 24h from when an image is pulled. This can be useful for when multiple developers are using the same image. It also means you you can have all your images in one place and use the same ECR features.

There is one slight issue with ECR pull through cache that does impact its usefulness. For the initial pull it uses a redirect if the cache is not populated. This means the initial pull for an image will fail if you don't have direct access to the up stream repository. If you are using ECR with a private endpoint in a subnet without internet access it will break.

Multi-architecture support

With AWS graviton and the launch of M1 MacBooks there is now a need to build images for both ARM and x86 processors (note: I am ignoring the non 64-bit architectures).

Containers can now be built targeting different architectures. It is possible to have 2 (or more) different images with the same name and tag with different architectures. A client will pull the correct one based on its requirements.

It is also possible to build multiple containers for different environments simultaneously using docker buildx. It is quite common for CI/CD pipelines to produce multiple versions of the same image targeting different architecture.

ECR supports all of this pretty seamlessly. If you push an x86 and arm version of the same container clients will pull the correct image. If you have a mixed fleet of Graviton and x86 or you have developers who use a mixed fleet of Macs it is easy to adapt your workflows.

KMS Encryption

ECR has all the KMS features you would expect. If you have a requirement to encrypt images that can be very useful.

What I like about ECR

I have used a number of tools for hosting a private Docker registry. So far ECR is the most reliable. You don't need to worry about scaling or load and making sure what will probably be a critical system is available. One thing I have seen a lot with self-hosted systems is major problems in the morning in development systems that have been off overnight. Often multiple systems will all try and pull container images at once. This can require self-hosted systems to be over specified.

If you use a different account for production deploys it is easy to build in a cross account replication step if necessary. The integrated security scanning can also be very useful, especially if you have developers who don't keep their images up-to-date.

Occasionally some of the features can be a little bit basic - like if you have some complex lifecycle rules. If that is the case you can easily extend the functionality using Lambda functions.

The main thing about ECR is it just works. Unlike some of the other products in this space that are also maven and pypi repos, ECR does one thing and does it well. Most of the time you can pretty much forget ECR is there. I don't think there is any higher praise than that.