Amazon ECR: Private Registries, Image Workflows, and Access Control – SAP-C02 Study Guide

Purpose of This Lesson

Amazon Elastic Container Registry (ECR) is a fully managed registry for storing, organizing, securing, and distributing container images and compatible artifacts. It integrates with Amazon ECS and Amazon EKS, while also supporting standard Docker tools and the Open Container Initiative (OCI) specifications.

For the SAP-C02 exam, ECR is important when choosing a private container image repository, designing image distribution across accounts or Regions, controlling access to images, and integrating container build or deployment workflows with AWS.

Key Concepts

ECR registry and repositories

Each AWS account has a private ECR registry in each AWS Region where it is used. A registry can contain one or more repositories. Repositories organize Docker images, OCI images, and OCI-compatible artifacts.

Repositories can use namespaces to provide logical organization, for example:

team-a/web-app
team-a/api
team-b/worker

The image reference includes the registry, repository, and tag:

123456789012.dkr.ecr.us-east-1.amazonaws.com/team-a/web-app:v1

ECR images are stored using Amazon S3 as the underlying storage service, while ECR provides the registry interface and image-management capabilities.

Standards and client compatibility

ECR supports:

• Docker Registry HTTP API V2
• Open Container Initiative (OCI) standards
• Docker CLI operations such as push, pull, tag, and list

A Docker client can interact with ECR from AWS, an on-premises environment, or a local development machine, provided it has network connectivity and the required permissions.

Private and public repositories

Private ECR repositories require authentication and authorization. Access can be controlled using IAM identity policies and ECR repository resource policies.

Public repositories are designed to make images available broadly. Repository access-control considerations primarily apply to private repositories.

Authentication and authorization

A client must authenticate with the ECR registry before pushing or pulling private images. The AWS CLI can obtain an authorization password, which is passed to docker login.

Authentication establishes that the client can interact with the registry. Authorization is then evaluated through IAM permissions and, where applicable, the repository policy.

This distinction matters in exam scenarios:

• An authorization token does not grant unrestricted access by itself.
• The calling principal still needs permissions for the requested ECR actions.
• Repository policies can control access to a specific repository and can support cross-account access patterns.

ECR image operations

A typical private-image workflow is:

1. Build or customize an image.
2. Create or select an ECR repository.
3. Authenticate the Docker client to the ECR registry.
4. Tag the local image with the full ECR repository URI.
5. Push the tagged image.
6. Configure ECS, EKS, or another container environment to pull and run the image.

Example commands:

aws ecr get-login-password --region us-east-1 | \
  docker login \
  --username AWS \
  --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

docker tag ubuntu:custom \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/team-a/web-app:v1

docker push \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/team-a/web-app:v1

The registry URI, Region, repository name, and image tag must match the intended destination.

Minimum permissions for pushing an image

Pushing an image requires more than a single PutImage permission. The client must authenticate and upload image layers before registering the completed image manifest.

The permissions identified in the lesson include:

• ecr:GetAuthorizationToken
• ecr:BatchCheckLayerAvailability
• ecr:InitiateLayerUpload
• ecr:UploadLayerPart
• ecr:CompleteLayerUpload
• ecr:PutImage

The policy’s Resource can be scoped to a particular repository ARN when the authorization token requirement and policy structure permit it. The authorization-token action commonly requires broader scoping than repository-specific image actions, so policy design must account for the action’s resource-level support.

Image lifecycle policies

ECR lifecycle policies automate image retention and expiration. They can remove images based on rules such as image age or the number of images retained.

Lifecycle policies help control storage growth and reduce manual cleanup, but they must be designed carefully. Deleting an image that is still referenced by a deployment or rollback process can create operational problems.

Image scanning

ECR image scanning helps identify known software vulnerabilities in container images. Scanning should be integrated into the image supply chain so vulnerable images can be detected before deployment.

Scanning identifies potential vulnerabilities; it does not replace secure base-image selection, dependency management, patching, or deployment controls.

Cross-Region and cross-account replication

ECR supports replication of repositories and images across AWS Regions and AWS accounts. Replication is useful for:

• Deploying workloads in multiple Regions
• Reducing image-pull distance and latency
• Supporting disaster recovery
• Distributing approved images to workload accounts
• Separating image-build and runtime environments

Replication does not eliminate the need to design access policies in the destination account. The destination repository, permissions, and deployment configuration must still support the consuming workload.

Pull-through cache rules

Pull-through cache rules allow ECR to cache repositories from supported remote public registries in a private ECR registry. This can provide a private, controlled path for retrieving commonly used public images and reduce repeated direct pulls from an external registry.

This feature is different from replication:

• Replication distributes images from an ECR source to other ECR locations.
• Pull-through caching retrieves and caches images from a remote public registry when requested.

Exam-Relevant Takeaways

• ECR is a managed container registry, not a container runtime. ECS and EKS run containers; ECR stores and distributes their images.
• ECS and EKS can pull images from ECR, but the workload’s execution identity must be able to retrieve the image.
• Private ECR access requires both authentication and authorization.
• IAM policies and ECR repository policies can be used to control private repository access.
• Cross-account image access is commonly addressed with a repository policy in the image-owning account plus appropriate permissions for the consuming principal.
• A Docker push requires authorization-token access, layer-upload permissions, and ecr:PutImage.
• Lifecycle policies are used for automated image cleanup and retention.
• Image scanning helps detect known vulnerabilities in images.
• Cross-Region and cross-account replication support image distribution and resiliency.
• Pull-through cache rules cache images from remote public registries in private ECR.
• Correct image tagging is essential: the image must reference the target account, Region, repository, and tag.

Architecture Decision Guide

Requirement	ECR capability or design	Important consideration
Store private application images	Private ECR repository	Use IAM and repository policies to control access
Deploy the same image in several Regions	Cross-Region replication	Confirm destination access and deployment configuration
Share approved images with workload accounts	Cross-account replication or repository policy	Choose replication for distribution; use policy-based access when central hosting is appropriate
Retrieve public base images through a private registry	Pull-through cache rule	This is caching, not general-purpose ECR replication
Remove outdated images automatically	Lifecycle policy	Avoid deleting images required for rollback or active deployments
Detect known vulnerabilities	ECR image scanning	Findings require remediation and release-process controls
Push from a local or on-premises Docker environment	Docker CLI plus ECR authentication	The client needs network connectivity, an authorization token, and ECR permissions
Run a container image	ECS or EKS referencing the ECR image	ECR stores the image; ECS or EKS provides the runtime

Common Exam Traps

• Confusing ECR with ECS or EKS: ECR stores images. It does not schedule or run containers.
• Assuming login equals authorization: Docker authentication obtains a registry token, but IAM and repository policies still determine which operations are allowed.
• Granting only ecr:PutImage: A push also requires permissions for authentication and image-layer upload operations.
• Forgetting the Region in the login command: ECR registries are Region-specific endpoints, and the authentication command must target the intended Region.
• Using a repository policy without considering the caller’s identity policy: Cross-account access generally requires compatible permissions on both sides of the access relationship.
• Treating lifecycle policies as vulnerability controls: Lifecycle policies delete or retain images; they do not scan images for vulnerabilities.
• Confusing replication and pull-through caching: Replication distributes ECR content, while pull-through caching retrieves content from a remote public registry on demand.
• Assuming public images receive the same private-repository controls: Public repositories are intended for broad access; private-repository authorization patterns do not apply in the same way.
• Ignoring image tags and repository paths: A correctly built local image cannot be pushed to the intended repository unless it is tagged with the correct full ECR URI.

Real-World Engineer Notes

• Use immutable or controlled image-tagging practices for production deployments. A mutable tag such as latest can make rollbacks and incident investigation difficult.
• Treat ECR repositories as part of the software supply chain. Restrict who can push, scan images before release, and separate build permissions from runtime pull permissions.
• Use repository namespaces to organize teams, applications, and environments, but do not treat namespaces as an independent security boundary.
• Keep lifecycle rules aligned with the deployment process. Retain enough historical versions for rollback, audit, and recovery requirements.
• For multi-account environments, decide whether a central account should host images and grant pull access, or whether images should be replicated into each workload account.
• Replication improves availability of image distribution, but it does not automatically make an application deployment resilient. The runtime, networking, configuration, and data layers also require multi-Region or multi-account planning.
• When using external public images, pull-through caching can improve control and consistency, but image provenance and vulnerability management remain the team’s responsibility.

Quick Reference Summary

• Service: Amazon Elastic Container Registry (ECR)
• Primary purpose: Managed storage and distribution of Docker and OCI container images and artifacts
• Integrates with: Amazon ECS, Amazon EKS, Docker tools, OCI-compatible clients
• Private access model: IAM policies plus ECR repository policies
• Authentication: Obtain an ECR authorization password with the AWS CLI and pass it to docker login
• Push workflow: Authenticate, tag, then push
• Push permissions: Authorization token, layer availability/upload, and image registration actions
• Image governance: Lifecycle policies and image scanning
• Distribution features: Cross-Region replication, cross-account replication, and pull-through cache rules
• Underlying storage: Amazon S3

Flashcards

1. What is Amazon ECR?

Amazon ECR is a managed registry for storing and distributing Docker images, OCI images, and OCI-compatible artifacts.

2. Which AWS services commonly consume images from ECR?

Amazon ECS and Amazon EKS commonly pull container images from ECR.

3. Does ECR run containers?

No. ECR stores and distributes images. ECS, EKS, or another container runtime runs them.

4. What must a Docker client do before pushing to a private ECR repository?

It must authenticate to the ECR registry and have the required IAM and repository-policy permissions.

5. Which permission obtains an ECR authorization token?

ecr:GetAuthorizationToken.

6. Name the principal permissions required to push image content.

ecr:BatchCheckLayerAvailability, ecr:InitiateLayerUpload, ecr:UploadLayerPart, ecr:CompleteLayerUpload, and ecr:PutImage, along with authorization-token access.

7. What controls access to a private ECR repository?

IAM identity policies and ECR repository resource policies.

8. What does an ECR lifecycle policy do?

It automates image retention and deletion based on configured rules.

9. What is ECR image scanning used for?

It identifies known software vulnerabilities in container images.

10. What is the difference between ECR replication and pull-through caching?

Replication distributes ECR images to other accounts or Regions. Pull-through caching retrieves and caches images from remote public registries in private ECR.

Practice Questions

Question 1

A company builds container images in a central AWS account and deploys them to ECS clusters in several workload accounts. The company wants each workload account to have a local copy of approved images for deployment. Which solution best meets this requirement?

A. Configure pull-through cache rules in every workload account.

B. Configure ECR cross-account and cross-Region replication from the central registry as required.

C. Store the images in Amazon S3 and configure ECS to pull them directly.

D. Make the central ECR repositories public.

Correct answer: B

Explanation: ECR replication distributes images across accounts and Regions, making approved images available close to the consuming workloads. Pull-through caching is intended to cache content from remote public registries, not distribute private images from a central ECR registry.

Question 2

A developer can successfully obtain an ECR login password but receives authorization errors while pushing an image. The IAM policy grants only ecr:GetAuthorizationToken and ecr:PutImage. What is the most likely correction?

A. Grant s3:PutObject on the ECR backing bucket.

B. Grant the required ECR layer-upload actions, including BatchCheckLayerAvailability, InitiateLayerUpload, UploadLayerPart, and CompleteLayerUpload.

C. Replace ECR with Amazon S3.

D. Grant ecs:RunTask.

Correct answer: B

Explanation: A push uploads image layers before registering the image manifest. The principal needs the ECR layer-upload permissions in addition to authorization-token access and PutImage. Direct access to ECR’s underlying S3 storage is not the correct integration model.

Question 3

An organization wants to ensure that container images older than a defined retention period are removed automatically, while also detecting known vulnerabilities before deployment. Which ECR features should it use?

A. Pull-through cache rules and replication

B. Lifecycle policies and image scanning

C. Repository namespaces and public repositories

D. IAM roles and ECS capacity providers

Correct answer: B

Explanation: Lifecycle policies automate image retention and deletion. Image scanning identifies known vulnerabilities. The other options address organization, distribution, or runtime concerns rather than both requirements.

Question 4

An ECS task in Account B must pull an image from a private ECR repository owned by Account A. Which statement best describes the access design?

A. The task only needs an ECR authorization token; repository permissions are not evaluated.

B. Account A should use an ECR repository policy to allow the appropriate principal from Account B, and the consuming workload must have compatible permissions.

C. The repository must be converted to a public repository.

D. The ECS task must write directly to the S3 bucket used by ECR.

Correct answer: B

Explanation: Private ECR access requires authentication and authorization. A repository policy in the owning account can allow cross-account access, while the consuming identity also needs the permissions required to retrieve the image.