Amazon ECR Container Image Management - Lifecycle Policies and Image Scanning
Learn how to automatically clean up old images with private repository lifecycle policies and detect vulnerabilities with image scanning.
ECR Basics and Repository Management
ECR is a managed registry for Docker container images and OCI artifacts, and the maximum size of a layer is 52,000 MiB. It provides both private repositories and public repositories (ECR Public). Private repositories use IAM policies for access control, allowing configurations where only specific IAM roles can push and pull images. Repository policies enable cross-account pull control as well. Images are encrypted at rest with AES-256, and KMS customer managed keys (CMK) are also available. Using CMKs enables automatic key rotation and integration with audit logs, and pull operations incur additional KMS API calls. Enabling image tag immutability prevents overwriting an image with the same tag. Repository names can be hierarchically organized using prefixes (e.g., team-a/app-frontend), and IAM policies can implement prefix-based access control.
Lifecycle Policies and Cost Management
Lifecycle policies are rules that automatically clean up images within a repository. You can define rules for tagged image retention count (e.g., keep the latest 10), untagged image retention period (e.g., delete after 7 days), and rules based on specific tag prefixes. Rules can be assigned priorities, and when multiple rules conflict, the higher-priority rule takes precedence. In environments where CI/CD pipelines frequently push images, storage costs grow as images accumulate without lifecycle policies. One configuration option is to set retention by tag, such as 30 generations of production images (prod-*) and 5 of development images (dev-*). The policy preview feature lets you verify which images will be affected before actual deletion occurs. ECR storage is billed per GB per month per region, so accumulated unnecessary images directly impact costs.
Image Scanning and Replication
Basic scanning uses AWS native technology with the Common Vulnerabilities and Exposures (CVEs) database to scan for operating system vulnerabilities, either on push or manually. Enhanced scanning integrates with Inspector to detect vulnerabilities in programming language packages (npm, pip, Maven) in addition to OS packages. Enhanced scanning runs continuously, and existing images are re-scanned when new CVEs are published. Scan results are published to EventBridge, enabling configurations that trigger SNS notifications or automated remediation pipelines when Critical/High vulnerabilities are detected. Cross-region replication automatically copies images to specified regions, reducing image pull times for multi-region ECS/EKS deployments. Cross-account replication is also available, enabling architectures where images are distributed from a central repository to workload accounts. Replication can be limited to specific repositories using filter rules, so you don't need to replicate everything.
CI/CD Pipeline Integration Patterns
ECR stores the images built in CI/CD pipelines and serves them at deployment. One configuration option is to build and push images from CodeBuild or GitHub Actions. Authentication tokens are obtained via the GetAuthorizationToken API and are valid for 12 hours. Using multi-stage builds to keep final image sizes small can reduce pull times and storage costs. For caching strategy, ECR supports remote caching, allowing BuildKit's --cache-to and --cache-from options to store intermediate layers in ECR for faster builds. Configuring pull-through cache caches pulls from public registries like Docker Hub or GitHub Container Registry via ECR, avoiding external registry rate limits. For image tags, you can use Git commit hashes or CI build numbers and reduce reliance on the latest tag.
Design Considerations and Troubleshooting
There are several points to consider when operating ECR. The default limit is 100,000 images per repository. When approaching this limit, you can review lifecycle policies or request a limit increase. Setting up VPC endpoints (PrivateLink) for access from within a VPC allows pulling and pushing images without routing through an internet gateway. ECR requires two endpoints - ecr.api and ecr.dkr - plus an S3 gateway endpoint (since image layers are stored in S3). If pull throttling occurs, you can implement retry logic and reduce pull sizes by sharing image layers through common base images. Multi-architecture images (co-located AMD64 and ARM64) are managed via manifest lists, allowing the same image URI to be used in mixed environments with both Graviton and x86 instances.
Summary
ECR is a managed registry for storing, scanning, and replicating container images. Lifecycle policies automatically delete unneeded images, and image scanning detects vulnerabilities (continuous scanning is enhanced scanning). ECR can be used for image delivery from build to deployment in CI/CD pipelines and offers features like pull-through cache and VPC endpoints. Cross-region and cross-account replication enables centralized management of container image distribution across multi-region, multi-account environments.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon ECR official page
- Amazon ECS official page
- Amazon Inspector official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.