Conceptly
← All Concepts
📦

Amazon ECR

ComputeFully Managed Container Image Registry

ECR is a registry that stores container images by version and makes them available for deployment targets to pull. It is the storage layer for executable image artifacts produced by your build flow.

Architecture Diagram

🔗 Relationship

Dashed line animations indicate the flow direction of data or requests

Why do you need it?

As soon as you start building container images, version ownership, storage location, and pull permissions all become operational questions. If you depend only on public registries or temporary storage, access control and deployment automation become shaky fast.

Why did this approach emerge?

Early container teams used Docker Hub or self-hosted registries, but permission management and build integration were cumbersome. A managed image registry tailored to AWS workloads — ECR — became necessary.

How does it work inside?

ECR stores Docker images in repositories, and ECS, Fargate, and SageMaker pull images from it. Access is controlled with IAM, and pipelines push build results directly.

What is it often confused with?

ECR and S3 can both hold artifacts, but the meaning is different. ECR is a container image registry, while S3 is a general-purpose object store for files and deployment artifacts. If you need to manage container image versions and pull paths, look at ECR; if you need general object storage for backups and static files, look at S3.

When should you use it?

Well-suited for internal container image management, versioning build artifacts for container deployments, and storing custom ML images. Not a fit for storing general files that are not container images.

Container image managementCI/CD pipelinesMulti-region deploymentVulnerability scanning