You already know how to create Docker images (subchapter 17.1). Now a practical question arises: once you’ve built your image, where do you store it so your AWS servers or services can use it? The answer is an image registry, and AWS’s is called ECR (Elastic Container Registry).

You build an image on your computer. But to deploy it on AWS (in ECS or EKS, which we’ll see next), those services need to download it from somewhere accessible. You can’t run an image that’s only on your laptop; it has to be in a central place that everyone can pull from.

That “central place” is an image registry.

A container registry is a storage for Docker images. You upload (push) your images to it, and then any authorized machine or service downloads (pull) them to run.

You probably know Docker Hub, the most famous public registry. ECR is AWS’s equivalent, designed for your private images.

Analogy: an image registry is like a warehouse or template library. You store your “molds” there (images, remember the analogy from subchapter 17.1), labeled and organized, and anyone with permission can go get the mold they need to make their cookies (containers).

ECR (Elastic Container Registry) is AWS’s private, managed image registry. Its key features:

Your images are private by default: only those you authorize (via IAM, Chapter 7) can upload or download them. This is important because your images contain your code and intellectual property; you don’t want them exposed to the world.

Access control uses IAM (Chapter 7), just like the rest of AWS. You define with policies who can push (upload) and who can pull (download). Apply the least privilege principle (subchapter 7.2): for example, the CI/CD system can upload images and ECS can only download them.

ECR connects naturally with the services that run containers in AWS (ECS and EKS, next subchapters). When you deploy an application, those services download the image directly from ECR, with no complicated setup and within the AWS network (fast and secure).

Like other managed services we’ve seen, AWS takes care of the infrastructure: availability, storage scaling, etc. You just upload and download images.

The typical cycle, connecting development with deployment:

Real-world example: a team develops an API. Their CI/CD system (Chapter 22), every time a change is approved, builds a new image of the API and uploads it to ECR with a version tag (e.g. api:v2.3). Then, ECS downloads that version from ECR and deploys it. ECR is the “bridge” between the code that’s built and the containers that are run.

Within ECR, you organize images into repositories (usually one per application) and each image has a tag that usually indicates the version:

Tags let you have multiple versions of the same application and choose which one to deploy. This is key to being able to roll back to a previous version quickly if a new one causes problems (rollback).

Cost note: ECR charges for image storage. Old images you no longer use accumulate, so it’s a good idea to set up lifecycle policies (similar to those in S3, subchapter 5.3) that automatically delete old versions and keep costs under control.

• A built image must be stored in a registry so AWS services can download and run it; it’s not enough to have it on your laptop.
• ECR (Elastic Container Registry) is AWS’s private, managed image registry (the private equivalent of Docker Hub).
• It’s private and secure (access control with IAM, least privilege) and integrated naturally with ECS and EKS, which download images from there.
• Workflow: you build the image → upload it (push) to ECR → ECS/EKS downloads it (pull) and runs it. It’s the “bridge” between development and deployment.
• You organize images in repositories with version tags, which lets you deploy specific versions and do rollbacks. Use lifecycle policies to delete old images and control costs.

In the next subchapter we’ll look at the service that runs your containers: ECS, with its task definitions, services, and the difference between Fargate and EC2.