Amazon ECR vs. Docker Hub vs. GitHub Container Registry
Have you worked with a Linux package manager like
yum before? A container registry is similar, but instead of packages, it distributes container images. A container registry is a crucial aspect of a containerized workflow and infrastructure. This blog post compares three different container registries: Amazon ECR, Docker Hub, and GitHub Container Registry. I’ve selected those three options out of many because they are following unique approaches.
Do you prefer listening to a podcast episode over reading a blog post? Here you go!
A container registry is a central place to store and distribute container images. A container image includes all the data needed to start a container—for example, the operating system, libraries, runtime environments, and the application itself.
The following command builds an image with the files from the current directory. The build image will use the repository
cloudonaut and tags the image with the version
docker build -t cloudonaut:1.0.0 .
After the build succeeded, you can upload the image to the container registry.
docker push cloudonaut:1.0.0
After that, whenever someone tries to start a container based on that image, the daemon will contact the container registry to pull the required image layers.
There are different scenarios for using a container registry. I want to introduce three common ones.
Packaging your software into a container image is an excellent way for distribution as users or customers can get up and running quickly. Not only open-source projects but also ISV make use of this approach. In this scenario, you are looking for a public container registry that anyone can access to pull your images. Of course, only your developers - or even better an automated build - are allowed to push images to the registry.
Whenever you are planning to build a deployment pipeline for continuous deployment, you should start with building the image that will traverse through the pipeline in the following. A private container registry is a perfect place to store the artifact immediately after your pipeline’s build step succeeded. Whenever you deploy a new version of your software to one of your environments (test, prod, etc.), the infrastructure fetches the image from the repository.
Are you developing microservices as a team? Do you need to share your service with other developers or teams so they can run parts of the microservice architecture on their machines? In that scenario, a private container registry allows you to distribute images within your organization.
In the following, you will learn which container registry fits best for each of the described scenarios.
As all major cloud providers do, AWS offers a container registry as a service, as well: Elastic Container Registry (ECR).
The most crucial aspect of ECR is that AWS IAM handles authentication and authorization for the container registry. Therefore, it is easy to access ECR from all the different services AWS provides (ECS, EKS, CodeBuild, and many more). AWS IAM is not easy to use but allows you to define strict access control to your container registry, even with multi-factor authentication (MFA) for push and pull access.
Besides that, ECR offers other security-relevant features:
- Immutable Image Tags: By enabling immutable image tags, you ensure that no one can override an image once it has been pushed to the repository.
- Image Scanning: If desired, ECR will scan images after they have been pushed to a repository. ECR uses the CVEs database of the open-source project Clair to check images for known security vulnerabilities.
Besides that, AWS introduced public registries in December 2020 as well. However, Docker Hub is still more relevant for sharing images pubicly. Currently ECR hosts 62,476 repositories while there are 8,532,342 repositories available on Docker Hub.
It is essential to mention that Amazon ECR provides private repositories only. It is not possible to pull the images without authentication and authorization.
From my personal experience, I can tell that Amazon ECR is a rock-solid service and the best option to manage images for all container workloads running on AWS. So especially, if you do continuous deployments on AWS, ECR is your go-to service.
Docker Hub is the most popular container registry, as it is the default registry for Docker. Many open-source projects and ISVs host their container images on Docker Hub.
Because Docker Hub is the default registry, the command to start a container is straightforward.
docker run nginx:latest
Compare that to launching a container based on the same image hosted on ECR.
docker run 111111111111.dkr.ecr.eu-west-1.amazonaws.com/nginx:latest
That’s the power of defaults. On top of that, think of Docker Hub as a marketplace for container images. That’s why I would state that Docker Hub is the best choice for publicly distributing software.
It is important to mention that Docker Hub made some unpleasant announcements recently. First of all, Docker Hub introduced strict rate limits for repositories on a free plan.
- 100 pulls for unauthenticated users per 6 hours.
- 200 pulls for authenticated users per 6 hours.
Introducing this rate limit broke many deployment pipelines, including one of ours. On top of that, Docker Hub announced a strict retention policy. In the future, Docker Hub will delete images that haven’t been accessed within the last six months. Again, the restriction applies to repositories that are running on the free plan only.
Unluckily, both changes make hosting public repositories on Docker Hub less convenient.
Besides hosting public repositories, Docker Hub offers private repositories as well. However, the pricing model is not compelling. ECR and GitHub Container Registry are better options in that scenario.
As of today, the GitHub Container Registry is still in beta. But it seems to become a good choice for organizations using GitHub to collaborate on source code already. The GitHub Container Registry supports both: public and private repositories.
Accessing the GitHub Container Registry is quite simple for anyone with access to GitHub. All you need to do is create a personal access token. That’s all you need to authenticate for the container registry. A seamless experience for developers.
It is worth mentioning that the GitHub Container Registry integrates well with GitHub Actions (CI/CD). I’ve created a
Hello World example repository to evaluate the service. As expected, I enjoyed the developer experience very much. On top of that, accessing the container registry from GitHub Actions does not incur any data transfer charges.
By the way, GitHub Container Registry provides public repositories. However, anyone who wants to download your container image needs to authenticate with a GitHub user account. Docker Hub allows unauthenticated access as well.
I recommend using the GitHub Container Registry to distribute container images within a team of software developers or an organization. For example, to share pre-build services of a microservice architecture. Also, if you are using GitHub Actions for CI/CD, the integration with GitHub Container Registry might be a pro argument as well.
The following tables compare all three options: Amazon ECR, Docker Hub, and GitHub Container Registry.
|GitHub Container Registry
|Pricing (Public Repository)
Storage: $0.10 per GB
|Pricing (Private Repository)
Storage: $0.10 per GB, Data Transfer: $0.09 per GB
>= $7 per user/month[^2]
Storage: $0.25 per per GB, Outgoing Data Transfer: $0.50 per GB
|Password or Access Token
|Personal Access Token (PAT)
|MFA for Image Push/Pull
|⚠️ n/a during beta
|✅ yes (paid plans only)
|Choose between one of 25 regions worldwide
|Pull: 1,000 per second, Push: 10 per second
|Pull: 100/200 (Free Plan), unlimited (Paid Plan)
There is no one size fits all solution. Choose the container registry based on your needs for a specific scenario. It is not a big deal to use more than one container registry. Amazon ECR shines for container-based workloads running on AWS. Docker Hub is still the best choice for distributing software publicly. And GitHub Container Registry extends the place where you store your source code with a container registry to store your build artifacts.
- 5. https://docs.docker.com/docker-hub/vulnerability-scanning/ ↩