AWS Services

Amazon Elastic Container Registry

Understand Amazon ECR as AWS container image registry, including repositories, image tags, pull permissions, scanning, lifecycle policies, and ECS deployment flow.

foundation6 min readUpdated 2026-06-02CloudCertificationSecurityOperations
Container RegistryRepositoryImageImage TagImage DigestImage ScanningLifecycle Policy

After this, you will understand

ECR is the missing piece between building a container image and reliably deploying that image into ECS, Lambda, or Kubernetes.

Plain version

ECR stores container images and controls who can push, pull, scan, replicate, and expire them.

Decision pressure

Learners focus on ECS tasks but forget the registry permissions, image scanning, tag immutability, and lifecycle cleanup that make deployments safe.

Exam-ready model

Treat ECR as deployment supply-chain infrastructure: protect push access, scan images, use stable tagging, and expire old images deliberately.

Think before readingWhy can an ECS task fail before your app code starts if ECR permissions are wrong?
The ECS task execution role must be able to pull the container image from ECR before the container can start.

Reading in progress

This page is saved in your local study history so you can continue later.

Next: AWS Lambda

Study path

Read these in order

Start with the mechanics, then move into the patterns that explain why the system is shaped this way.

  1. 1Amazon API Gatewayaws-services

Concepts Covered

  • Container image registries
  • ECR repositories
  • Image tags and digests
  • Push and pull permissions
  • ECS task execution role
  • Image scanning
  • Lifecycle policies
  • Cross-account access
  • Replication
  • Container supply chain traps

1. Plain-English Mental Model

Amazon Elastic Container Registry, or ECR, is AWS's managed container image registry.

A container image is the packaged application artifact. ECS, EKS, Lambda container image functions, and deployment pipelines need somewhere to store and retrieve those images.

The simple model is:

build image -> push to ECR repository -> compute service pulls image -> run container

ECR is not the orchestrator. It does not decide how many tasks run or which load balancer routes traffic. ECS, EKS, Lambda, or another service runs the container. ECR stores and protects the image artifact.

For SAA-C03, ECR usually appears in container deployment, image permissions, scanning, lifecycle cleanup, and ECS task startup questions.

2. Why This Service Exists

Containers need a trusted image source.

If every deployment pulls from a developer laptop, public registry, or manually copied tarball, production becomes fragile. Teams need access control, private repositories, image scanning, lifecycle cleanup, and regional availability near compute.

ECR exists to provide managed private and public registries integrated with IAM, ECS, EKS, Lambda, CodeBuild, CodePipeline, and other AWS deployment tooling.

The registry is part of the software supply chain. A bad image can contain vulnerable packages, leaked secrets, malicious code, or old dependencies. A wrong tag can deploy the wrong version.

The exam often tests whether you understand that containerized deployment has two halves:

registry stores image
orchestrator runs image

3. The Naive Approach And Where It Breaks

The naive design stores images wherever they were first built:

developer laptop -> docker run in production

That cannot support repeatable deployment, scanning, rollback, or access control.

Another naive design uses latest for every deployment. Tags can move. If latest points to a new image unexpectedly, rollback and audit become confusing.

Another mistake is allowing every CI job and developer to push to production repositories. If write access is too broad, the image supply chain can be compromised.

Another common ECS failure is missing pull permission. The application code never starts because ECS cannot pull the image from ECR with the task execution role.

4. Core Primitives

A registry is the top-level ECR registry in an account and Region.

A repository stores images and artifacts. Repository policies control access to that repository.

An image tag is a human-readable pointer such as v1.2.3 or prod. An image digest is content-addressed and immutable for a specific image.

Push permissions allow CI/CD systems to upload images. Pull permissions allow compute services to retrieve images.

Image scanning can inspect images for known vulnerabilities depending on configuration.

Lifecycle policies expire old images based on rules, such as keeping only the latest N tagged releases.

Replication can copy images across Regions or accounts for availability or deployment locality.

5. Architecture Use Cases

Use ECR for ECS and Fargate deployments:

CI build -> ECR push -> ECS service deployment -> Fargate task pulls image

Use ECR for Lambda functions packaged as container images when the function exceeds normal zip-package needs or wants container packaging.

Use cross-account repository policies when a central build account publishes images and workload accounts pull them.

Use image scanning and lifecycle policies as part of a production deployment pipeline.

Use immutable tags or digest pinning where auditability matters. Deployment systems should know exactly which image ran.

Use replication when workloads run in multiple Regions and should pull images locally.

7. Security Model

ECR access is controlled with IAM and repository policies.

CI/CD roles need push access to specific repositories. Runtime roles, such as ECS task execution roles, need pull access.

Do not grant broad push access to production image repositories.

Enable image scanning where vulnerability visibility is required. Scanning helps detect known vulnerabilities, but it does not prove the image is safe.

Use lifecycle policies to remove old images, but avoid deleting images needed for rollback.

Use KMS encryption if customer-managed key control is required. Most architectures rely on ECR's managed encryption behavior unless compliance requires more.

Treat image tags as release artifacts. Protect tag mutation if tag integrity matters.

8. Reliability And Resilience

ECR is regional. If deploying in multiple Regions, replicate images or push to regional repositories.

ECS tasks need to pull images at startup. If image pull fails due to permission, network path, missing tag, or repository issue, tasks cannot start.

Use VPC interface endpoints for ECR API and Docker registry endpoints when private subnets need to pull images without internet or NAT.

Keep rollback images available. Lifecycle policies should not delete the only known-good image.

Use immutable deployment references, such as image digests, when repeatability is critical.

9. Performance And Scaling

Large images slow deployments. Smaller images pull faster and reduce startup time.

Layer caching can help build speed, but runtime image pulls still need network and registry access.

For Fargate or private ECS tasks, ECR endpoints and S3 access may be needed for private image pulls depending on architecture. Missing endpoints can cause slow or failed starts in locked-down VPCs.

Parallel deployments can create many image pulls at once. Watch service limits and deployment configuration.

Scanning and signing workflows add pipeline time, but improve supply chain control.

10. Cost Model

ECR cost includes storage, data transfer, pull-through cache or replication features where used, and scanning features depending on configuration.

Lifecycle policies reduce storage cost by expiring old images.

Cross-Region replication and pulls across Regions can add data transfer cost.

Large images increase storage and transfer.

Keeping enough images for rollback is worth the storage cost. Keep intentionally, not accidentally.

12. SAA-C03 Exam Signals

"Private container image registry" points to ECR.

"ECS task cannot pull image" points to ECR permissions, task execution role, network path, or missing image/tag.

"Scan container images for vulnerabilities" points to ECR image scanning.

"Remove old container images automatically" points to lifecycle policies.

"Deploy containers on ECS/Fargate" often includes ECR as image source.

"Use images across accounts or Regions" points to repository policies and replication.

13. Common Exam Traps

Do not confuse ECR with ECS. ECR stores images. ECS runs containers.

Do not confuse task role with task execution role for image pulls.

Do not rely on mutable latest tags for production auditability.

Do not delete rollback images through an aggressive lifecycle policy.

Do not assume image scanning fixes vulnerabilities automatically.

Do not forget private VPC endpoints when tasks cannot reach ECR from locked-down subnets.

Review Amazon ECS And AWS Fargate, AWS Lambda, and AWS Key Management Service.

Official AWS references:

What to study next

These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.