Amazon ECR
View on GitHubAmazon ECR
Amazon ECR is a managed container image registry that stores, manages, and serves Docker and OCI-compatible container images. It operates as a regional, account-level repository accessible over standard registry APIs and integrates with AWS container runtimes and CI/CD systems. It typically supplies images to deployment targets such as Amazon ECS, Amazon EKS, AWS Fargate, or self-managed container hosts as part of build and deploy pipelines.
🗂 Resource Category
Containers • Developer Tools
🧠 Exam Memory Hook
Think: "Container images + CI/CD + runtime pulls = Amazon ECR"
📖 Ownership
Classification: AWS Managed Service
AWS responsibilities: AWS operates and manages the ECR service platform, regional control plane, API endpoints, storage infrastructure, service availability, and integration hooks. AWS secures and maintains the underlying physical infrastructure, networking, storage platform, and the managed service runtime components. AWS is responsible for patching and maintaining the service infrastructure and control plane that implement repository APIs and replication features.
Customer responsibilities: The customer configures repositories, IAM roles and policies, repository policies, encryption key usage, lifecycle policies, image tag immutability, and access endpoints. The customer is responsible for the container image contents, image signing, vulnerability remediation for OS packages and application libraries inside images, CI/CD integration, and monitoring repository events and metrics. The customer configures monitoring, logging, alerts, and any automation (for example, to remove untagged images or prevent deployment of scanned images) using other services.
Patching responsibilities: AWS patches the physical hosts, networking, storage systems, and the managed ECR control plane and service platform. AWS does not patch customer container images, application code, or libraries packaged inside images. For container hosts, if using AWS Fargate AWS manages the compute infrastructure and runtime patching; if using Amazon EC2 worker nodes the customer patches the guest operating system, container runtime, and installed packages. Customers are responsible for patching application libraries, dependencies, and any software included in container images.
🏗 Typical Architecture
💡 Top 5 Features
- Managed private repositories with IAM-based access control and repository policies
- Support for Docker Registry HTTP API v2 and OCI image formats for push and pull operations
- Optional image vulnerability scanning integrated with the registry workflow
- Lifecycle policies and immutable tag options for controlling retention and immutability
- Encryption of images at rest with AWS KMS and TLS in transit
✅ Top 5 Use Cases
- Provide a regional, managed container image registry for production deployments to Amazon ECS, Amazon EKS, or AWS Fargate.
- Store build-produced container images from CI/CD systems and enforce promotion workflows using tags and lifecycle policies.
- Host internal base images and shared runtime containers for development teams with centralized access control.
- Run image scanning as part of a pipeline to detect vulnerabilities and gate image promotion without performing remediation inside the registry.
- Replicate container repositories across regions or accounts to reduce cross-region pulls and support multi-region deployments.
🏗 Architecture Placement
Amazon ECR sits as a regional, account-level container image registry that receives push requests from CI/CD systems and developer tooling and serves pull requests to container runtimes (ECS, EKS, Fargate, or self-managed hosts). It commonly connects to CI/CD services for image upload, to IAM for access control, and to monitoring services for repository metrics and events. Cross-region replication and public repositories are optional and change where images are stored and accessed. Placement and access patterns depend on repository policies, encryption keys, and network configuration.
🎯 Commonly Used With
- Amazon ECS
- Amazon EKS
- AWS Fargate
- AWS CodeBuild
- AWS Identity and Access Management
🌍 5 Real-World Examples
- A banking CI/CD pipeline pushes signed application images to Amazon ECR and uses repository policies and IAM roles to control which environments can pull production images for auditability.
- A healthcare organisation runs image vulnerability scanning in ECR as a gate in pipelines to prevent deployment of images with known critical vulnerabilities.
- A retail company stores versioned frontend and backend container images in ECR and replicates repositories to a second Region to support lower-latency deployments in that Region.
- A media processing pipeline stores custom transcoding container images in ECR allowing ECS tasks to pull specific image versions for large-scale batch processing.
- A government project uses private ECR repositories with AWS KMS-managed keys and strict repository policies to restrict cross-account access for compliance.
🎓 AWS Exam Clues
- Choose ECR when you need a managed, AWS-integrated container registry for pushing and pulling Docker/OCI images.
- Consider repository policies and IAM roles for fine-grained access control instead of relying on network isolation alone.
- Use ECR image scanning to detect vulnerabilities as part of CI/CD but plan separate remediation and patching processes for image contents.
- Select cross-region replication when multi-region deployments require local image availability and reduced pull latency.
- Remember customers are responsible for image contents and runtime host patching when using self-managed EC2 worker nodes.
📝 Quick Revision
Amazon ECR is a regional managed container image registry for storing and serving Docker/OCI images to AWS container runtimes and CI/CD pipelines. Use it when you need integrated access control, lifecycle management, and optional scanning; customers remain responsible for image contents, vulnerability remediation, and host patching for self-managed nodes.
🏷 Keywords
container registry • OCI • Docker Registry v2 • image scanning • lifecycle policies • repository policies • image immutability • cross-region replication • AWS KMS encryption • push/pull • CI/CD integration • IAM authorization