4.1.2. Container Image Management with Amazon ECR
š” First Principle: A container image is a portable, immutable package of your application and all its dependencies. Amazon ECR is the private registry that stores, versions, and secures those images ā the container equivalent of AMI management for EC2. Every container running in ECS or EKS launched from an image stored somewhere; ECR makes that "somewhere" secure, versioned, and integrated with AWS IAM.
ECR Core Concepts:
| Concept | Description |
|---|---|
| Repository | A named collection of container images (like a folder for one application) |
| Image | A specific packaged container artifact |
| Tag | A mutable label on an image (e.g., latest, v1.2.3) |
| Digest | An immutable SHA256 hash of the image content ā the true identity of an image |
| Registry | The ECR endpoint for your account/region (account-id.dkr.ecr.region.amazonaws.com) |
Image Scanning: ECR can automatically scan images for known OS and application vulnerabilities (CVEs) using two scanning modes:
- Basic scanning: Uses Clair to scan on push or on demand; checks OS packages
- Enhanced scanning: Uses Amazon Inspector 2; continuous scanning, broader coverage including application packages, produces detailed findings with severity scores
ECR Lifecycle Policies: Automatically expire old images to control storage costs. Rules can target:
- Untagged images older than N days
- Tagged images not matching specific patterns
- More than N images with a specific tag prefix
Example: "Keep the last 10 tagged images matching release-*; delete all untagged images older than 1 day."
ECR Replication: Automatically replicate images to other regions or accounts. Cross-region replication ensures your container images are available in your DR region without manual push/pull workflows.
Pull-Through Cache: ECR can act as a caching proxy for public registries (Docker Hub, Amazon ECR Public, Quay). Instead of pulling from the internet on every container start, images are cached in your private ECR and served from there ā improving speed and avoiding rate limits.
ECR Image Immutability: When enabled, prevents image tags from being overwritten. latest can't be pushed twice with different content. This enforces reproducibility ā you always know exactly what v1.2.3 contains.
ā ļø Exam Trap: ECR image tags are mutable by default ā pushing a new image with the same tag overwrites it. If your pipeline pulls my-app:latest, you might get different content on different pulls. Enable image tag immutability to prevent this. For truly reliable deployments, reference images by their digest (sha256:abc123...) rather than a mutable tag.
Reflection Question: A deployment pipeline pulls my-app:production from ECR and deploys it to ECS. A developer accidentally pushes a broken image with the same production tag. The next ECS deployment pulls the broken image and causes an outage. What ECR feature prevents this from happening?