Elastic Container Registry (ECR)
7 questions found
What is Amazon Elastic Container Registry and how does it fit into a containerized application workflow?
Beginner
Amazon Elastic Container Registry, or ECR, is a fully managed Docker container registry that lets you store, manage, and deploy container images securely, integrating tightly with services like ECS, EKS, and Fargate, so once you build and push a container image to ECR, it can be pulled directly by those services during deployment without needing to manage your own separate container registry infrastructure.
aws ecr create-repository --repository-name my-app
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
Real-world example
A development team builds a Docker image for their application, pushes it to a private ECR repository, and then configures their ECS task definition to pull that exact image directly from ECR during deployment.
Common follow-ups: What is the difference between ECR and a public registry like Docker Hub?;Can ECR store images for non Docker container formats?
Amazon ECS (Elastic Container Service);AWS Fargate
How do you authenticate Docker to push and pull images from a private ECR repository?
Beginner
You authenticate Docker to ECR using the AWS CLI's ecr get-login-password command, which retrieves a temporary authentication token that is then piped directly into a docker login command, granting Docker time limited access to push and pull images from your private ECR repository, relying on your existing IAM credentials rather than requiring a separate, permanently stored registry password.
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com
Real-world example
A CI/CD pipeline automatically authenticates to ECR using temporary credentials derived from its assumed IAM role, pushing a newly built container image without ever needing a separately managed, long lived registry password stored anywhere in the pipeline configuration.
Common follow-ups: How long does an ECR authentication token remain valid before needing to be refreshed?;What IAM permissions are required to push and pull images from ECR?
IAM;AWS CodePipeline
CodeBuild & CodeDeploy (CI/CD)
How can ECR repository policies control which IAM users, roles, or other AWS accounts can access a specific container image repository?
Intermediate
ECR repository policies work similarly to S3 bucket policies, letting you explicitly define which IAM principals, potentially including principals from a completely different AWS account, are allowed to perform specific actions such as pulling or pushing images to a particular repository, which is especially useful when sharing container images across multiple accounts in an organization without making the repository publicly accessible.
aws ecr set-repository-policy --repository-name my-app --policy-text file://ecr-repository-policy.json
Real-world example
A company sharing a common base container image across several development teams in separate AWS accounts configures an ECR repository policy that grants pull access to those specific accounts, without needing to duplicate the same image into every individual account's own registry.
Common follow-ups: How do you grant cross account access to a specific ECR repository?;What is the difference between a repository policy and an IAM policy for controlling ECR access?
IAM;AWS Organizations & Multi Account Strategy
How does ECR image scanning help identify security vulnerabilities within container images before they are deployed?
Intermediate
ECR image scanning automatically analyzes the operating system packages and, with enhanced scanning enabled, application dependencies within a container image against known vulnerability databases, flagging any identified vulnerabilities along with their severity level, which can be configured to run automatically every time a new image is pushed, giving teams visibility into security risks before a vulnerable image is ever deployed to production.
aws ecr start-image-scan --repository-name my-app --image-id imageTag=latest
Real-world example
A security conscious development team enables automatic scanning on push for their ECR repositories, catching a critical vulnerability in a base image dependency before that image is ever deployed to their production ECS cluster.
Common follow-ups: What is the difference between basic scanning and enhanced scanning in ECR?;How do you integrate ECR scan results into a CI/CD pipeline to block deployment of vulnerable images?
AWS Security Hub & GuardDuty;AWS CodePipeline
CodeBuild & CodeDeploy (CI/CD)
How do ECR lifecycle policies help automatically manage and clean up old or unused container images to control storage costs?
Intermediate
ECR lifecycle policies let you define rules that automatically expire and delete older container images based on criteria such as image age or the total number of images to retain, which is important since container repositories can otherwise accumulate a large number of old, unused images from every single build over time, unnecessarily increasing storage costs if left completely unmanaged.
aws ecr put-lifecycle-policy --repository-name my-app --lifecycle-policy-text file://lifecycle-policy.json
Real-world example
A development team configures a lifecycle policy on their ECR repository that automatically deletes any untagged image older than fourteen days, preventing years worth of intermediate build artifacts from silently accumulating unnecessary storage costs.
Common follow-ups: How do you protect specific tagged images, like production releases, from being automatically deleted by a lifecycle policy?;What is a reasonable retention policy for a typical CI/CD pipeline?
AWS Cost Management & Billing;AWS CodePipeline
CodeBuild & CodeDeploy (CI/CD)
How can ECR pull through cache repositories simplify managing dependencies on public container registries while maintaining private, controlled access?
Advanced
ECR pull through cache lets you create a private ECR repository that automatically caches images pulled from an upstream public registry, such as Docker Hub or the AWS public ECR gallery, the first time they are requested, meaning subsequent pulls of the same image are served from your own private, faster ECR cache rather than repeatedly hitting the external public registry, which also helps avoid public registry rate limiting issues that can otherwise disrupt CI/CD pipelines.
aws ecr create-pull-through-cache-rule --ecr-repository-prefix docker-hub --upstream-registry-url registry-1.docker.io
Real-world example
A company experiencing intermittent CI/CD pipeline failures due to Docker Hub rate limiting sets up an ECR pull through cache, ensuring all subsequent builds pull common base images from their own private, reliable ECR cache instead of directly hitting the public registry every single time.
Common follow-ups: What upstream registries are supported for ECR pull through cache?;How does pull through cache interact with ECR lifecycle policies for cached images?
AWS CodePipeline
CodeBuild & CodeDeploy (CI/CD);Amazon ECS (Elastic Container Service)
How should an organization design a comprehensive container image governance strategy across multiple ECR repositories, teams, and AWS accounts?
Advanced
A comprehensive governance strategy typically centralizes shared base images in a dedicated shared services account with carefully scoped cross account repository policies, enforces mandatory image scanning with defined vulnerability severity thresholds that block deployment of non compliant images, applies consistent lifecycle policies to control storage costs across all repositories, and establishes clear tagging conventions, such as immutable tags for production releases, ensuring consistency, security, and cost control as the number of teams and repositories grows across the organization.
aws ecr put-image-tag-mutability --repository-name production-app --image-tag-mutability IMMUTABLE
Real-world example
A large enterprise centralizes its approved base images in a dedicated shared account, enforces immutable tags for all production repositories to prevent accidental overwrites, and requires every image to pass a defined vulnerability severity threshold before deployment, establishing consistent container governance across dozens of development teams.
Common follow-ups: What is the benefit of enforcing immutable image tags for production repositories?;How do you balance strict governance requirements against development team velocity?
AWS Organizations & Multi Account Strategy;AWS Security Hub & GuardDuty