Cargando...
Cargando...
Fully managed, secure, and scalable Docker/OCI container image registry — native to AWS, built for production.
Amazon Elastic Container Registry (ECR) is a fully managed container image registry that makes it easy to store, manage, share, and deploy container images and artifacts. It integrates natively with Amazon ECS, EKS, and AWS Fargate, eliminating the need to operate your own registry infrastructure. ECR supports both private repositories (with IAM-based access control) and public repositories (via ECR Public / gallery.ecr.aws) for open-source or community images.
Store, version, scan, and distribute container images securely within AWS without managing registry infrastructure, while integrating natively with ECS, EKS, Fargate, CodePipeline, and Inspector.
Use When
Avoid When
Private Repositories
IAM and resource-based policies control access; supports cross-account sharing via repository policies
ECR Public Repositories
gallery.ecr.aws — no authentication required for pulls; suitable for open-source images only
Image Tag Immutability
Configurable per repository; prevents tag overwrite for reproducible deployments
Lifecycle Policies
Automatically expire images based on age or count; runs asynchronously (not real-time)
Basic Image Scanning (Clair)
On-push or manual; scans for OS-level CVEs
Enhanced Scanning (Amazon Inspector)
Continuous, automatic scanning; includes OS and programming language package vulnerabilities
Cross-Region Replication
Configured at registry level; replicates all repositories unless filtered
Cross-Account Replication
Requires destination account to grant permission via registry policy
Pull-Through Cache
Cache upstream public registry images (Docker Hub, ECR Public, Quay, etc.) in private ECR
OCI Artifact Support
Store Helm charts, WASM modules, and other OCI-compatible artifacts
KMS Encryption (CMK)
Must be configured at repository creation; cannot change encryption type afterward
VPC Endpoints (PrivateLink)
com.amazonaws.<region>.ecr.api and com.amazonaws.<region>.ecr.dkr — both required for full private connectivity
Resource-Based Repository Policies
JSON policies attached directly to repositories; enables cross-account access without assuming roles
EventBridge Integration
ECR emits events for image pushes, scans, and lifecycle policy actions
AWS Organizations Integration
Replication and policies can be scoped to organizational units
Helm Chart Storage
Store and retrieve Helm charts as OCI artifacts using Helm 3.7+
Multi-Architecture Images (Image Index)
Store manifest lists for multi-arch images (amd64, arm64, etc.)
Serverless Container Deployment Pipeline
high freqECS task definitions reference ECR image URIs. Fargate pulls images directly from ECR at task launch. IAM task execution role must have ecr:GetAuthorizationToken and ecr:BatchGetImage permissions. No CodeDeploy agent is required for ECS/Fargate deployments.
CI/CD Container Build and Push
high freqCodeBuild builds Docker images and pushes to ECR as part of a CodePipeline stage. CodeBuild service role needs ECR push permissions. The buildspec.yml uses `aws ecr get-login-password` to authenticate. This is the canonical AWS-native CI/CD pattern for containers.
Continuous Vulnerability Scanning
high freqEnhanced Scanning integrates ECR with Amazon Inspector for continuous CVE scanning of images. Findings appear in Inspector console and can be forwarded to Security Hub and EventBridge for automated remediation workflows. Replaces the older Basic Scanning (Clair) for production environments.
Kubernetes Native Image Pull
high freqEKS worker nodes (EC2 or Fargate profiles) pull images from ECR using the node IAM role or IRSA (IAM Roles for Service Accounts). ECR is the recommended registry for EKS workloads — no credential rotation needed as IAM handles authentication.
Centralized Multi-Account Image Governance
high freqA central 'tooling' account hosts ECR repositories. Cross-account repository policies grant pull access to workload accounts. This pattern centralizes image governance and scanning without replicating images to every account — the correct enterprise pattern vs. naive replication to all accounts.
Lambda Container Image Deployment
high freqLambda functions can be deployed as container images up to 10 GB stored in ECR. The Lambda service role automatically gets read access to ECR in the same account. Cross-account Lambda container images require explicit ECR repository policy permissions.
Event-Driven Image Lifecycle Automation
high freqECR publishes events to EventBridge for image push, scan completion, and lifecycle policy deletions. Use EventBridge rules to trigger Lambda or Step Functions for automated compliance checks, Slack notifications, or deployment triggers on new image push.
Private Network Image Pulls (No Internet Gateway Required)
high freqCreate VPC Interface Endpoints for ECR API (ecr.api) and ECR Docker (ecr.dkr) plus an S3 Gateway Endpoint (ECR stores image layers in S3). This allows ECS/EKS workloads in private subnets to pull images without internet access — critical for security-sensitive architectures.
Blue/Green ECS Deployment
high freqCodeDeploy (not the CodeDeploy agent) orchestrates blue/green deployments for ECS by shifting traffic between task sets. The new task set pulls the updated image from ECR. The CodeDeploy AGENT is NOT used — it is only for EC2/On-Premises deployments. This is a critical exam trap.
The CodeDeploy AGENT is NEVER required for ECS or Fargate deployments. It is only used for EC2 and On-Premises deployments. ECS blue/green deployments use CodeDeploy (the service) but not the agent. Expect this to appear as a distractor answer.
For private subnet workloads (ECS/EKS in private subnets) to pull from ECR without an Internet Gateway, you need THREE endpoints: (1) com.amazonaws.region.ecr.api, (2) com.amazonaws.region.ecr.dkr, AND (3) an S3 Gateway Endpoint (because ECR stores image layers in S3). Missing the S3 endpoint is the #1 VPC endpoint misconfiguration for ECR.
ECR authentication tokens (from `aws ecr get-login-password`) expire after exactly 12 hours — not 24 hours. Long-running CI/CD pipelines or batch jobs must re-authenticate before this window. Build token refresh logic into pipelines.
Tag Immutability is DISABLED by default (MUTABLE). For production, compliance, and reproducible deployments, always enable IMMUTABLE tags. This prevents the `latest` tag from being silently overwritten — a major security and operational risk.
ECR Enhanced Scanning (Amazon Inspector) provides CONTINUOUS scanning — it re-scans images when new CVEs are published, not just on push. Basic Scanning (Clair) only scans on push or manually. For compliance questions, Enhanced Scanning is almost always the correct answer.
AWS Config rules can DETECT non-compliant ECR configurations (e.g., scanning not enabled, tag immutability off) but CANNOT prevent non-compliant image deployments. For preventive controls, use IAM policies, SCPs (Service Control Policies), or admission controllers (OPA/Gatekeeper in EKS).
The CodeDeploy AGENT is NEVER used for ECS or Fargate deployments — only for EC2/On-Premises. ECS blue/green uses the CodeDeploy SERVICE via appspec.yml with no agent required. This appears as a distractor in almost every ECS deployment question.
For private subnet ECR access, you need THREE VPC endpoints: ecr.api (Interface) + ecr.dkr (Interface) + S3 (Gateway). Missing the S3 Gateway Endpoint will cause all image pulls to fail because ECR stores image layers in S3 internally.
AWS Config DETECTS non-compliant ECR configurations but CANNOT prevent non-compliant deployments. For preventive controls use IAM deny policies, SCPs, or Kubernetes admission controllers. Detective ≠ Preventive — know the difference for every security question.
Cross-account image sharing should use REPOSITORY POLICIES (resource-based policies on the ECR repository) — not IAM roles — as the primary mechanism. This avoids the need for workload accounts to assume a cross-account role just to pull images.
Lifecycle policies are evaluated asynchronously — image deletion is NOT immediate. Do not design systems that depend on real-time cleanup. Deletions happen within 24 hours of policy evaluation.
ECR Public repositories at gallery.ecr.aws require NO authentication for pulls. This means they are completely unsuitable for internal enterprise images. Use private ECR repositories with repository policies for any image that should not be publicly accessible.
Lambda container images MUST be stored in ECR (not Docker Hub or other registries). The image must be in the SAME AWS account and region as the Lambda function, OR you must configure cross-account ECR repository policies explicitly.
For multi-account enterprise architectures, the CORRECT governance pattern is a CENTRALIZED ECR registry in a dedicated tooling/shared-services account with cross-account repository policies — NOT replicating images to every account. Replication duplicates storage costs and scatters enforcement.
Pull-through cache rules allow you to cache Docker Hub, ECR Public, Quay, and GitHub GHCR images in your private ECR. This solves Docker Hub rate limiting for AWS workloads and improves pull performance. Cached images count toward your private ECR storage costs.
Common Mistake
Replicating ECR images to all accounts in an AWS Organization is equivalent to centralized image governance.
Correct
Replication copies images to each account but DUPLICATES storage costs and SCATTERS policy enforcement. True centralized governance uses a single ECR registry in a shared-services account with cross-account repository policies granting pull access to workload accounts — images live in one place, governance is enforced centrally.
This is a top exam trap in SAP-C02 and DOP-C02. The question will describe a multi-account setup and ask for the MOST cost-effective or governable approach. Replication sounds appealing but is the wrong answer for governance. Remember: centralize the registry, share via policy, don't replicate for governance purposes.
Common Mistake
AWS Config rules can prevent non-compliant container images from being deployed.
Correct
AWS Config is a DETECTIVE control — it identifies non-compliant configurations AFTER the fact (e.g., scanning not enabled, tag immutability disabled). It CANNOT intercept or block image pulls or deployments. Preventive controls require IAM deny policies, SCPs, or Kubernetes admission controllers (OPA/Gatekeeper).
The detective vs. preventive control distinction is heavily tested across SAA-C03, SAP-C02, and DOP-C02. When a question asks how to PREVENT a bad deployment, AWS Config is never the right answer — it can only alert or remediate after the fact.
Common Mistake
ECR Public repositories can be used for internal enterprise images with controlled access.
Correct
ECR Public repositories are COMPLETELY OPEN to the internet — anyone can pull images without any authentication. They are designed for open-source projects and community images only. Internal enterprise images must use PRIVATE ECR repositories with IAM and resource-based repository policies.
Candidates confuse 'public' as meaning 'accessible across accounts' rather than 'accessible to the entire internet without authentication.' This trap appears when questions describe cross-account image sharing — the correct answer is private ECR + repository policy, not ECR Public.
Common Mistake
Running a self-managed Docker registry on EC2 gives you more control and flexibility than Amazon ECR.
Correct
A self-managed registry on EC2 requires you to manage HA, storage, authentication, TLS, backup, patching, and scaling yourself. ECR provides all of these natively PLUS native IAM integration, cross-account access, automated vulnerability scanning via Inspector, replication, lifecycle policies, and VPC PrivateLink — with zero infrastructure management.
This misconception appears in migration and modernization scenarios (SAP-C02, DOP-C02). The question will describe a self-managed registry and ask for the AWS-native replacement. ECR is always superior for AWS workloads unless there is a very specific compliance requirement that ECR cannot meet (which is rare).
Common Mistake
The CodeDeploy agent must be installed on ECS container instances or Fargate tasks to enable blue/green deployments.
Correct
The CodeDeploy AGENT is ONLY required for EC2 and On-Premises deployment targets. ECS blue/green deployments are orchestrated by the CodeDeploy SERVICE (via appspec.yml and task definition updates) without any agent. Fargate tasks have no persistent instance where an agent could even run.
This is one of the most commonly wrong answers in CodeDeploy + ECS questions. The agent is only for EC2/On-Premises. For ECS, CodeDeploy shifts traffic between target groups using ALB weighted routing — no agent involved. Remember: Fargate = no server = no agent.
Common Mistake
ECR Basic Scanning and Enhanced Scanning are equivalent — both provide continuous vulnerability detection.
Correct
Basic Scanning (powered by Clair) only scans images ON PUSH or when manually triggered. It does NOT re-scan when new CVEs are discovered. Enhanced Scanning (powered by Amazon Inspector) provides CONTINUOUS scanning — it automatically re-evaluates images when new vulnerability data is published, even for images pushed weeks ago.
This distinction is tested in security and DevSecOps scenarios. If a question asks about detecting newly published CVEs in already-stored images, Enhanced Scanning is the only correct answer. Basic Scanning would miss vulnerabilities discovered after the image was pushed.
Common Mistake
You only need one VPC endpoint to pull ECR images from a private subnet.
Correct
You need THREE endpoints for full private ECR connectivity from a VPC: (1) Interface Endpoint for ECR API (ecr.api), (2) Interface Endpoint for ECR Docker registry (ecr.dkr), AND (3) Gateway Endpoint for S3 (because ECR stores image layers in Amazon S3 internally). Missing the S3 Gateway Endpoint causes image pulls to fail even with both ECR endpoints configured.
This is a frequent trap in networking and security architecture questions. The S3 dependency is non-obvious because ECR appears to be a standalone service. Always remember: ECR data plane = S3 under the hood. Three endpoints, not one or two.
ECR VPC Endpoints: 'API + DKR + S3 = Three Keys to Private ECR' — you need all three or image pulls fail in private subnets.
ECR Auth Token: '12 hours, not 24' — half a day, like a work shift. Refresh before your pipeline's shift ends.
Tag Immutability: 'MUTABLE by default = MUTABLE-take' — it's a mistake to leave it mutable in production. Flip it to IMMUTABLE.
CodeDeploy Agent: 'Agent = EC2 Only' — Fargate has no floor to stand on, so no agent can live there.
Basic vs Enhanced Scanning: 'Basic = Birth scan only, Enhanced = Eternal vigilance' — Enhanced never stops watching even after the image is stored.
Centralized ECR Governance: 'One Registry to Rule Them All' — centralize in a shared-services account, share via policy, never replicate for governance.
CertAI Tutor · SAA-C03, SAP-C02, DEA-C01, DOP-C02, CLF-C02, DVA-C02 · 2026-02-21