Amazon Elastic Container Registry (ECR)

Purpose of This Lesson

Amazon Elastic Container Registry (ECR) is a fully managed container registry for storing and distributing container images and OCI-compatible artifacts. This lesson focuses on ECR architecture, private repository access control, Docker authentication and image-push workflows, and operational features such as image scanning, lifecycle policies, replication, and pull-through cache rules.

For the AWS Certified CloudOps Engineer Associate SOA-C03 context, the important skill is recognizing which ECR capability or permission supports a given container-image workflow.

Key Concepts

• Managed container registry: ECR stores container images and OCI-compatible artifacts without requiring you to operate the registry infrastructure.
• Service integrations: ECR integrates with Amazon ECS and Amazon EKS for container deployments.
• Standards support: ECR supports the Open Container Initiative (OCI) and Docker Registry HTTP API V2 standards.
• Docker compatibility: Docker tools and commands such as push, pull, list, and tag can be used with ECR.
• Repository organization: Namespaces can be used to organize repositories.
• Private and public repositories: Public repositories allow everyone to access the contained images. The lecture specifically identifies IAM and repository resource-based access control for private repositories.
• Regional access: ECR can be accessed from cloud, on-premises, or local Docker environments.
• Image lifecycle management: Lifecycle policies help manage how long images remain in repositories.
• Image scanning: Scanning identifies software vulnerabilities in container images.
• Replication: ECR supports cross-Region and cross-account replication.
• Pull-through cache rules: These rules allow repositories from remote public registries to be cached in a private ECR registry.

ECR Architecture and Image Operations

An ECR private registry is provided for each AWS account. Within the registry, you can create one or more repositories, and each repository stores container images or OCI-compatible artifacts.

The main ECR components are:

1. Registry: The account-level private ECR registry that contains repositories.
2. Authorization token: A client uses an authorization token to authenticate to ECR before pushing or pulling images.
3. Repository: The logical location that contains Docker images, OCI images, and OCI-compatible artifacts.
4. Repository policy: A resource-based policy that controls access to a repository.
5. Images: The versioned container artifacts stored in repositories.

A typical workflow is to download and customize an Ubuntu image, push the customized image to a private ECR repository, and then run a task using that image. ECS and EKS can consume images stored in ECR as part of container deployment workflows.

Public Versus Private Repositories

Public repositories are intended for images that everyone should be able to access. Private repositories require access control. IAM policies can grant permissions to identities, while repository policies provide resource-based control over repository access. Access can be limited to specific API actions, including actions such as creating, listing, describing, deleting, and getting repository or image information.

Private Repository Permissions for Image Pushes

A principal pushing an image to a private repository needs IAM permissions. The minimum permissions identified in the lesson are:

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

The policy resource can be scoped to a specific repository ARN to restrict the permissions to one repository rather than allowing them broadly. Authentication and repository authorization are separate concerns: the authorization token authenticates the Docker client to ECR, while IAM and repository policies determine whether the requested operations are allowed.

Docker Authentication and Push Workflow

The standard private-repository push sequence is:

1. Authenticate the Docker client to ECR. Use the AWS CLI to retrieve an ECR authorization password for the target Region and pipe it to Docker login:

   aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com

1. Tag the local image with the ECR destination. The tag includes the registry endpoint, repository name, and image tag:

   docker tag <local-image>:<local-tag> <account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<image-tag>

1. Push the tagged image. Push the fully qualified image reference to ECR:

   docker push <account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<image-tag>

The tag is important because Docker uses the fully qualified registry and repository name to identify the ECR destination. Authentication alone does not upload an image, and tagging alone does not grant access.

Exam- or Assessment-Relevant Takeaways

• Choose ECR when the requirement is a managed AWS registry for Docker or OCI images used by ECS, EKS, or other Docker-compatible environments.
• A client must authenticate to ECR before it can push or pull images; the workflow uses an ECR authorization token.
• A private-repository push requires both authentication and the appropriate IAM permissions.
• The image-push permission set includes layer-upload actions, authorization-token retrieval, layer-availability checking, and ecr:PutImage.
• Use a repository policy when resource-based access control is needed for a repository.
• Use lifecycle policies to manage image retention and image lifecycle.
• Use image scanning to identify software vulnerabilities in images.
• Use cross-Region or cross-account replication when images must be available in other Regions or accounts.
• Use pull-through cache rules when a private ECR registry should cache repositories from remote public registries.
• A repository ARN can scope permissions to a specific private repository.

Tool / Feature Decision Guide

Requirement	ECR capability or workflow
Store Docker or OCI images in a managed AWS service	Create an ECR repository in the account’s private registry
Allow general access to published container images	Use a public repository
Restrict access to private images	Combine IAM policies and repository resource-based policies
Connect a Docker client before image operations	Retrieve an authorization token with aws ecr get-login-password and log in with Docker
Send a local image to ECR	Tag it with the ECR registry/repository reference, then use docker push
Reduce image-retention clutter	Configure an ECR lifecycle policy
Identify vulnerabilities in stored images	Enable or use ECR image scanning
Make images available across Regions or accounts	Configure cross-Region or cross-account replication
Cache content from a remote public registry in a private registry	Configure a pull-through cache rule

Common Traps / Misconceptions

• Authentication is not authorization. The ECR token authenticates the Docker client, but IAM and repository policies still determine which operations are permitted.
• A local image does not automatically belong to ECR. It must be tagged with the destination registry and repository before it is pushed.
• docker tag does not upload an image. It changes or adds the image reference locally; docker push performs the upload.
• ecr:PutImage is not the entire push permission set. The lecture identifies additional permissions for authorization, layer availability, and layer upload operations.
• Public and private repositories have different access models. Public repositories allow everyone to access their images, while private repositories use access control.
• A repository policy is not the same as a lifecycle policy. A repository policy controls access; a lifecycle policy manages image retention and lifecycle.
• Pull-through caching is not the same as replication. Pull-through cache rules cache content from remote public registries, while replication copies ECR images across Regions or accounts.
• ECR is not limited to ECS. It integrates with ECS and EKS and can be accessed from cloud, on-premises, or local Docker environments.

Real-World Engineer / Analyst Notes

• Treat the image reference as part of the deployment configuration. A wrong account ID, Region, repository name, or tag directs the push to the wrong destination or causes it to fail.
• When troubleshooting a failed push, check the workflow in order: Docker authentication, image tag, target repository, IAM permissions, and repository policy.
• Scope push permissions to a repository ARN when the workload should not be able to write to every repository in the registry.
• Use image scanning and lifecycle management as operational controls rather than treating the registry as passive storage.
• Cross-account and cross-Region requirements should be identified early because they influence repository access policies and replication configuration.
• Pull-through caching can centralize consumption of public images in a private registry, but it serves a different purpose from distributing images that originate in your own ECR repositories.

Quick Reference Summary

• ECR is a fully managed registry for Docker, OCI images, and OCI-compatible artifacts.
• Each AWS account has an ECR private registry that can contain multiple repositories.
• ECR integrates with ECS and EKS and supports Docker Registry HTTP API V2 and OCI standards.
• Private repository operations require authentication plus appropriate IAM or repository-policy authorization.
• Authenticate with aws ecr get-login-password, tag with docker tag, and upload with docker push.
• Private image pushes require ecr:GetAuthorizationToken, layer-upload permissions, ecr:BatchCheckLayerAvailability, and ecr:PutImage.
• Lifecycle policies manage image retention; scanning identifies vulnerabilities.
• Replication supports cross-Region and cross-account distribution.
• Pull-through cache rules cache repositories from remote public registries in a private ECR registry.

Flashcards

Q: A team needs a managed registry for Docker images consumed by Amazon ECS and Amazon EKS. Which AWS service should it use?
A: Amazon Elastic Container Registry (ECR). It is a managed container registry integrated with both ECS and EKS and supports Docker and OCI image formats.

Q: What must a Docker client do before pushing or pulling an image from a private ECR registry?
A: It must authenticate using an ECR authorization token, commonly obtained with aws ecr get-login-password and passed to docker login.

Q: A local image has been built, but docker push is targeting the wrong location. What step is likely missing or incorrect?
A: The image must be tagged with the fully qualified ECR registry endpoint, repository, and image tag using docker tag.

Q: Which command performs the actual upload of a tagged local image to ECR?
A: docker push <registry>/<repository>:<tag>. The preceding docker tag command only creates the destination image reference locally.

Q: What is the difference between IAM policies and ECR repository policies?
A: IAM policies grant permissions to identities, while repository policies are resource-based policies attached to repositories. Both can participate in controlling access to private repositories.

Q: Which ECR permissions are central to a private image push?
A: The workflow requires ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, layer-upload permissions including ecr:InitiateLayerUpload, ecr:UploadLayerPart, and ecr:CompleteLayerUpload, plus ecr:PutImage.

Q: How can ECR push permissions be restricted to one repository?
A: Scope the policy’s resource element to the ARN of the specific repository instead of granting access broadly.

Q: When should an engineer choose an ECR lifecycle policy?
A: Use it when image retention and cleanup need to be managed. It addresses image lifecycle rather than access control.

Q: When is image scanning the appropriate ECR feature?
A: Use image scanning when the goal is to identify software vulnerabilities in stored container images.

Q: How does cross-Region replication differ from a pull-through cache rule?
A: Replication makes ECR images available across Regions or accounts. A pull-through cache rule caches repositories from remote public registries in a private ECR registry.

Q: A company wants everyone to access its published container images. What repository type matches that requirement?
A: A public ECR repository, because public repositories allow everyone to access the contained images.

Q: What are the main ECR objects in the private-registry model?
A: The registry contains repositories; repositories contain images and OCI-compatible artifacts; authorization tokens authenticate clients; and repository policies control repository access.

Practice Questions

Question 1

A developer has a local Docker image and wants to push it to a private ECR repository. The developer has not yet connected Docker to ECR. Which sequence is most appropriate?

A. Run docker push, then retrieve an authorization token
B. Retrieve the ECR login password, run Docker login, tag the image with the ECR destination, and push it
C. Create a lifecycle policy, then run docker pull
D. Configure replication, then run docker tag without a registry endpoint

Correct answer: B

Explanation: The client must authenticate first, then tag the image with the ECR registry/repository reference, and finally use docker push.

Question 2

An IAM principal can successfully authenticate to ECR but receives an authorization error while pushing an image. Which conclusion is most accurate?

A. Authentication proves that all ECR API actions are allowed
B. The Docker image must be public
C. The principal may be missing one or more required private-repository IAM permissions or repository-policy permissions
D. ECR does not support Docker push operations

Correct answer: C

Explanation: The authorization token handles client authentication, but private image pushes also require the relevant IAM and repository-policy authorization, including layer-upload actions and ecr:PutImage.

Question 3

An organization wants to limit a deployment role so it can push images only to the production repository, not to every private repository. What should the administrator do?

A. Use an ECR lifecycle policy
B. Scope the policy resource to the production repository ARN
C. Use a public repository
D. Configure a pull-through cache rule

Correct answer: B

Explanation: The ECR policy resource can be scoped to a specific repository ARN, limiting the role’s access to that repository.

Question 4

A platform team wants images from a remote public registry to be available through its private ECR registry without manually importing each image. Which feature best matches this requirement?

A. Cross-account replication
B. Image scanning
C. Pull-through cache rules
D. Repository lifecycle policies

Correct answer: C

Explanation: Pull-through cache rules cache repositories from remote public registries in a private ECR registry. Replication addresses distribution of ECR images across Regions or accounts.

WordPress Metadata

Suggested Slug:
amazon-ecr-architecture-access-image-workflows

Meta Description:
Study Amazon ECR architecture, authentication, repository permissions, Docker image workflows, lifecycle management, scanning, and replication for AWS CloudOps Engineer Associate preparation.

Tags:
Amazon ECR, AWS Certified CloudOps Engineer Associate, Docker, Amazon ECS, Amazon EKS, IAM, Container Registries, Container Image Security, AWS CLI, DevOps Automation