ECR: Storing and Pulling Container Images

Amazon Elastic Container Registry (ECR) is a fully managed Docker-compatible container image registry. It stores, manages, and deploys container images securely within AWS. ECR eliminates the need to operate your own registry infrastructure and integrates natively with ECS, EKS, Lambda (container images), and CodeBuild. Images stored in ECR are replicated for high availability and can be scanned for security vulnerabilities automatically.

ECR supports two repository types: Private repositories in Amazon ECR require AWS authentication to pull images—ideal for proprietary application images. Access is controlled by IAM policies and repository resource policies. Public repositories on ECR Public Gallery (public.ecr.aws) allow unauthenticated pulls from anywhere on the internet—ideal for open-source base images, public tools, and AWS-provided images (Lambda base images, ECS-optimised AMI images). Public repositories have a free pull allowance with rate limits for unauthenticated requests.

To push or pull private ECR images, Docker must authenticate using AWS credentials. Use aws ecr get-login-password to obtain a temporary authentication token and pipe it to docker login. The token is valid for 12 hours. In CI/CD pipelines, refresh the token before each push. ECS task agents, Lambda, and EKS worker nodes authenticate to ECR automatically using their IAM role—no manual login needed for runtime pulls in AWS environments.

The standard workflow to push an image to ECR: (1) Build the Docker image locally; (2) Tag the image with the ECR repository URI (format: account.dkr.ecr.region.amazonaws.com/repo-name:tag); (3) Push the tagged image. ECR stores each image layer separately and deduplicates common layers across images, reducing storage costs. Using immutable tags prevents overwriting a tag, ensuring deployed image versions are stable and auditable.

IMMUTABLE tags prevent a tag from being overwritten with a different image. When tag mutability is IMMUTABLE, pushing a new image to an existing tag fails—you must use a new tag. This is a best practice for production: it ensures that :v1.2.3 always refers to exactly the same image digest, enabling reliable rollbacks and auditing. Use MUTABLE tags only for development branches or the :latest convenience tag in non-production environments.

Enable scan on push to automatically scan images for known CVEs when they are pushed. ECR uses the Amazon Inspector integration (enhanced scanning) or the built-in Basic Scanning powered by the open-source Clair scanner. Enhanced scanning provides continuous scanning (not just on push) and covers OS packages and language-specific packages (Node.js, Python, Java). Review scan findings in the ECR console or via EventBridge notifications to your security team.

ECR charges for storage per GB per month. Without management, old images accumulate indefinitely, increasing costs. Lifecycle policies automatically expire and delete images based on rules: for example, keep only the last 10 tagged releases, or delete untagged images older than 7 days. Lifecycle policies run daily. This is especially important in CI/CD pipelines that push new images on every commit, which can accumulate hundreds of images per week.

To pull images from an ECR repository in Account A into ECS/EKS/Lambda in Account B, configure a repository policy (resource-based policy) on the ECR repository in Account A granting the IAM principal from Account B permission to call ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, and ecr:BatchCheckLayerAvailability. This eliminates the need to copy images between accounts and enables centralised image management with distributed consumption.

ECR replication automatically copies images from your primary registry to registries in other AWS Regions (and optionally other accounts). When ECS tasks in another Region pull an image, they pull from the local regional registry—reducing data transfer costs and image pull latency. Configure replication rules at the registry level specifying which repositories to replicate and which destination regions and accounts. Replication is asynchronous and near-real-time.

ECR encrypts images at rest using server-side encryption. By default it uses an AWS-managed key (AWS_MANAGED_KEY). For additional control and auditability, configure a customer-managed KMS key (CMK). With a CMK, you control key rotation, can revoke access by disabling the key, and can audit all decryption operations in CloudTrail. Enable KMS encryption when regulatory compliance (PCI-DSS, HIPAA, FedRAMP) requires customer-controlled encryption keys.

A complete CI/CD pipeline for ECS with ECR: (1) Developer pushes code to Git; (2) CodeBuild builds the Docker image and pushes it to ECR with a commit SHA tag; (3) CodePipeline updates the ECS task definition with the new image URI; (4) ECS performs a rolling update of the service, pulling the new image from ECR. ECS tasks use the Task Execution Role to authenticate to ECR automatically—no credentials need to be managed in the pipeline for runtime pulls.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: ECR private repositories store container images with IAM-controlled access, immutable tags for production stability, and automatic vulnerability scanning with Inspector, Lifecycle Policies automatically expire old and untagged images to control storage costs in active CI/CD environments, and ECR Replication copies images to other Regions and accounts for multi-region deployments at lower pull latency. Next up we explore ECS Service Auto Scaling and load balancing integration.