ECR - Container Registry, Image Scanning, and Lifecycle Policies

What you will learn

• What ECR is and why teams use it instead of Docker Hub in AWS environments
• Private vs Public ECR repositories
• The ECR push and pull workflow from your CI/CD pipeline
• Image scanning — basic and enhanced scanning with Inspector
• Lifecycle policies — automatic deletion of old images to control costs
• Cross-account access — sharing images between AWS accounts
• Pull-through cache — caching public images inside ECR for reliability and speed
• Image immutability — preventing tag overwrites in production
• ECR in the ECS and EKS deployment pipeline

Why this matters

Every team running containers on AWS needs somewhere to store Docker images. Docker Hub is the public default — but it has rate limits, images are publicly visible by default, and pulling from Docker Hub adds external network dependency to every ECS or EKS deployment. ECR is the AWS-native answer. Images live in your AWS account, authentication is handled by IAM, images are private by default, no rate limits on pulls within AWS, and it integrates natively with ECS, EKS, and CodePipeline. Most importantly — your container deployments never depend on an external service being available.

What is Amazon ECR

ECR (Elastic Container Registry) is a fully managed Docker image registry. Think of it as Docker Hub but hosted inside your AWS account.

Private vs Public Repositories

Private ECR:

Public ECR (ECR Public Gallery):

The Push and Pull Workflow

The standard workflow for getting your Docker image into ECR and running on ECS or EKS:

Step by step:

ECR stores layers. If two images share the same base layer, ECR stores it only once. Subsequent pushes with the same layers are instant — only new layers are uploaded.

Image Scanning — Vulnerability Detection

ECR scans your images for known security vulnerabilities in OS packages and application libraries.

Basic Scanning (free):

Enhanced Scanning (paid — uses Amazon Inspector):

Enable scanning at repository level:

Lifecycle Policies — Control Storage Costs

Every CI/CD push creates a new image. Without lifecycle policies, images accumulate indefinitely. A busy team pushing 10 images per day has 300 images per month — most of them old versions nobody will ever use.

Lifecycle policies automatically expire and delete old images based on rules you define.

Common policy patterns:

Setting up in the console:

Remember

Set up a lifecycle policy when you create the repository — not after 6 months when you notice storage costs have grown. Once a repository has thousands of images, cleaning up requires deleting them one by one.

Image Immutability — Prevent Tag Overwriting

By default, you can push a new image with the same tag and it overwrites the old one. latest pushed today replaces latest from yesterday.

Enable at repository level:

Cross-Account Access

Teams often need to share images between accounts — a shared infrastructure account stores base images, application accounts pull from it.

Grant another account pull access via repository policy:

Account 987654321098 can now pull images from this repository. They still need to authenticate using their own credentials and call ecr:GetAuthorizationToken in your account.

Pull-Through Cache — Cache Public Images Locally

Your ECS tasks need nginx:latest, node:18, or python:3.12 from Docker Hub. Every pull goes to Docker Hub — rate limits apply, and your deployment depends on Docker Hub availability.

Pull-through cache creates a mirrored copy of public registries inside your ECR.

No Docker Hub rate limits. No external dependency during deployments. Images cached in your region.

Supports: Docker Hub, Quay, GitHub Container Registry, Kubernetes (registry.k8s.io), Amazon ECR Public.

Hands-on Lab — Create Repository, Push Image, Set Lifecycle Policy

Step 1 — Create an ECR repository

Step 2 — Authenticate and push a Docker image

Step 3 — View the image and scan results

Step 4 — Create a lifecycle policy

Step 5 — Cleanup

Common Mistakes to Avoid

Common Mistake

Not setting a lifecycle policy and discovering 6 months later that image storage costs are significant. ECR charges per GB stored. A repository with 2,000 old images adds up. Set the policy when you create the repository.

Common Mistake

The most common ECS deployment failure is an ECR image pull error. The cause is almost always a missing IAM permission on the ECS Task Execution Role. It needs: ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, and ecr:GetDownloadUrlForLayer. Check the execution role first when a container fails to start.

Tip

Use versioned tags alongside latest. Always push both :v1.2 and :latest. ECS and EKS should reference the specific version tag in production — not latest. The :latest tag is for humans to see what the current version is. Deployments referencing :latest make rollbacks impossible and create unpredictable behaviour.