Amazon ECR: Storing Container Images

Amazon ECR (Elastic Container Registry) is a managed container registry — a place to store, version, and retrieve container images. Once an image is built (the previous lesson's Dockerfile-to-image step), it needs somewhere for other systems to pull it from later, whether that's a teammate's machine, a CI pipeline, or — the subject of the next two lessons — a running ECS or Fargate task.

ECR organizes images into repositories — each repository typically corresponds to one application or component. Within a repository, each pushed image gets a tag (a label, such as a version number or a build identifier) so specific versions can be referenced and retrieved deliberately, rather than only ever having "whatever the latest push happens to be."

This is worth stating plainly, because the name alone doesn't make it obvious: ECR stores images; it does not run them. A pushed image just sits in ECR, versioned and ready, until something else — an ECS task, a Fargate task, or a developer's own machine — pulls it and runs it as a container.

Pushing to and pulling from ECR is controlled by IAM permissions (Module 2), the same least-privilege discipline this course has applied to every AWS service so far — a CI pipeline that only needs to push new images shouldn't be granted broader ECR (or account-wide) permissions than that. Access to ECR should never depend on a real access key embedded in a script or a container image; the identity performing the push or pull (a CI pipeline's role, a developer's own credentials, or a task's own IAM role, covered in a later lesson) should authenticate through IAM the same way every other AWS interaction in this course has.