{"id":176,"date":"2026-04-13T02:19:08","date_gmt":"2026-04-13T02:19:08","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-elastic-container-registry-amazon-ecr-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-containers\/"},"modified":"2026-04-13T02:19:08","modified_gmt":"2026-04-13T02:19:08","slug":"aws-amazon-elastic-container-registry-amazon-ecr-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-containers","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-elastic-container-registry-amazon-ecr-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-containers\/","title":{"rendered":"AWS Amazon Elastic Container Registry (Amazon ECR) Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Containers"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Containers<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Amazon Elastic Container Registry (Amazon ECR) is AWS\u2019s managed container image registry. It stores, manages, and delivers container images (and related artifacts) so your build pipelines and runtime platforms (like Amazon ECS, Amazon EKS, AWS Lambda container images, and on-prem Kubernetes) can pull trusted images quickly and securely.<\/p>\n\n\n\n<p>In simple terms: Amazon ECR is \u201cDocker Hub for your AWS account,\u201d with deep AWS security controls (IAM), private networking options (VPC endpoints), and integrations with AWS container runtimes.<\/p>\n\n\n\n<p>Technically, Amazon ECR is a regional service that provides a per-account registry in each AWS Region. Inside that registry you create repositories that hold versioned container images, identified by tags and immutable digests. It supports pushing and pulling images over HTTPS, fine-grained authorization, encryption, image scanning, lifecycle management, and replication.<\/p>\n\n\n\n<p>The core problem Amazon ECR solves is container artifact management at scale: you need a secure place to publish images from CI, control who can pull them in production, keep storage under control, scan for vulnerabilities, and replicate images across accounts\/regions for reliability and latency.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Amazon Elastic Container Registry (Amazon ECR)?<\/h2>\n\n\n\n<p><strong>Official purpose:<\/strong> Amazon Elastic Container Registry (Amazon ECR) is an AWS-managed container registry for storing, sharing, and deploying container images and artifacts. It is designed to integrate with AWS identity, security, and container services.<br\/>\nOfficial docs: https:\/\/docs.aws.amazon.com\/AmazonECR\/latest\/userguide\/what-is-ecr.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Private image registry (Amazon ECR private)<\/strong> for your AWS accounts.<\/li>\n<li><strong>Public registry (Amazon ECR Public)<\/strong> for publishing public container images.<\/li>\n<li><strong>Push\/pull images<\/strong> using standard container tooling (Docker-compatible workflows).<\/li>\n<li><strong>Access control<\/strong> using IAM policies and resource-based repository policies.<\/li>\n<li><strong>Image scanning<\/strong> options (basic scanning in ECR; enhanced scanning integrates with Amazon Inspector\u2014verify current capabilities in official docs).<\/li>\n<li><strong>Lifecycle policies<\/strong> to automatically expire old images.<\/li>\n<li><strong>Replication<\/strong> across Regions and\/or accounts.<\/li>\n<li><strong>Pull-through cache rules<\/strong> to cache upstream images (useful for controlling external dependencies and improving pull performance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Registry:<\/strong> The top-level container registry scoped to an AWS account and Region (for ECR private). You interact with registry endpoints when authenticating and pushing\/pulling.<\/li>\n<li><strong>Repository:<\/strong> A named collection of images (for example, <code>payments-api<\/code>).<\/li>\n<li><strong>Image:<\/strong> A container image stored in a repository, identified by:<\/li>\n<li><strong>Tag<\/strong> (mutable label like <code>v1.2.3<\/code> or <code>prod<\/code>)<\/li>\n<li><strong>Digest<\/strong> (immutable content address like <code>sha256:...<\/code>)<\/li>\n<li><strong>Authorization token:<\/strong> A short-lived credential used by Docker\/clients to authenticate to ECR.<\/li>\n<li><strong>Repository policy:<\/strong> Resource-based policy to allow cross-account access.<\/li>\n<li><strong>Lifecycle policy:<\/strong> JSON rules that expire images based on age\/count\/tag patterns.<\/li>\n<li><strong>Replication configuration:<\/strong> Rules to replicate images to other registries\/regions.<\/li>\n<li><strong>Pull-through cache rule:<\/strong> Configuration that caches external registry images into ECR.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed registry service<\/strong> (fully managed control plane and storage). You do not manage servers, disks, or patching for the registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional vs global<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon ECR private is regional.<\/strong> Your AWS account has an ECR registry per Region, and repositories are created per Region.<\/li>\n<li><strong>Amazon ECR Public is separate<\/strong> and is designed for public distribution (it is not simply \u201cthe same private registry made public\u201d).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>Amazon ECR commonly sits between:\n&#8211; <strong>CI systems<\/strong> (AWS CodeBuild, GitHub Actions, Jenkins, GitLab CI, etc.) that build and push images\n&#8211; <strong>Runtime platforms<\/strong> (Amazon ECS, Amazon EKS, AWS Lambda container images, AWS Batch, Amazon SageMaker, and Kubernetes outside AWS) that pull and run images\n&#8211; <strong>Security services<\/strong> (IAM, AWS KMS, AWS CloudTrail, Amazon Inspector, AWS Config, Amazon EventBridge) for access control, encryption, auditability, vulnerability response, and governance<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Amazon Elastic Container Registry (Amazon ECR)?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduces operational overhead:<\/strong> No need to run and patch your own registry (e.g., self-hosted Harbor).<\/li>\n<li><strong>Improves delivery speed:<\/strong> Faster and more reliable artifact access for deployments, especially when co-located in AWS Regions.<\/li>\n<li><strong>Stronger governance:<\/strong> Central place to enforce policies (tag immutability, lifecycle cleanup, scanning) across teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>First-class AWS integration:<\/strong> Works naturally with ECS\/EKS\/Lambda and IAM.<\/li>\n<li><strong>Private networking options:<\/strong> Use VPC endpoints to keep image pulls off the public internet.<\/li>\n<li><strong>Digest-based immutability:<\/strong> Use image digests for repeatable deployments and rollbacks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lifecycle management:<\/strong> Automatically delete stale images to control sprawl.<\/li>\n<li><strong>Replication:<\/strong> Move images closer to workloads and improve resilience.<\/li>\n<li><strong>Event-driven workflows:<\/strong> Trigger actions on image push\/scan results (often via EventBridge\u2014verify events in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based access control<\/strong> and <strong>repository resource policies<\/strong> for cross-account sharing.<\/li>\n<li><strong>Encryption at rest<\/strong> (with AWS-managed keys by default; customer-managed KMS keys are supported).<\/li>\n<li><strong>Audit logging<\/strong> via AWS CloudTrail.<\/li>\n<li><strong>Image vulnerability scanning<\/strong> options to support secure SDLC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Designed for scale<\/strong> across many repositories and frequent pull\/push activity.<\/li>\n<li><strong>Regional locality<\/strong> can reduce latency for deployments compared to an external registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Amazon ECR when:\n&#8211; You run containers on AWS (ECS\/EKS\/Fargate\/Lambda container images).\n&#8211; You want IAM-native authZ\/authN and CloudTrail auditing.\n&#8211; You need controlled, private distribution of images across multiple AWS accounts.\n&#8211; You want lifecycle cleanup and replication without running your own registry.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When they should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; <strong>You need a registry outside AWS<\/strong> for strict data residency in non-AWS environments (or you can\u2019t use AWS endpoints).\n&#8211; <strong>You require advanced artifact types\/workflows<\/strong> that are not supported in your region\/account configuration (verify support for OCI artifacts like Helm charts if required).\n&#8211; <strong>Your organization is standardized on another registry<\/strong> (e.g., JFrog Artifactory, GitHub Container Registry) and AWS integration is not a priority.\n&#8211; <strong>You need air-gapped\/offline registry operations<\/strong> (self-hosted solutions may be more suitable).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Amazon Elastic Container Registry (Amazon ECR) used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and software companies running microservices on ECS\/EKS<\/li>\n<li>Financial services and healthcare (strong audit, IAM control, encryption needs)<\/li>\n<li>Media\/gaming (frequent deploys, scaling, multi-region delivery)<\/li>\n<li>Retail\/e-commerce (CI\/CD at scale, multi-account environments)<\/li>\n<li>Public sector (governance, compliance, controlled distribution)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building golden images and base images<\/li>\n<li>DevOps\/SRE teams standardizing CI\/CD and runtime image sources<\/li>\n<li>Security teams enforcing scanning, immutability, and provenance patterns<\/li>\n<li>Application teams shipping services via containers<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices and APIs<\/li>\n<li>Batch jobs (AWS Batch)<\/li>\n<li>ML inference containers (SageMaker)<\/li>\n<li>Event-driven workloads packaged as container images (Lambda)<\/li>\n<li>Internal tooling images used by CI pipelines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-account landing zones (shared services + workload accounts)<\/li>\n<li>Multi-region active-active or active-passive applications<\/li>\n<li>Hybrid Kubernetes (EKS + on-prem) where ECR is used as the source of truth<\/li>\n<li>GitOps pipelines where \u201cimage is the deployable artifact\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test:<\/strong> rapid iteration with frequent tags, short-lived images, aggressive lifecycle policies<\/li>\n<li><strong>Production:<\/strong> strict immutability, digest pinning, cross-account access, scanning gates, replication, and controlled retention for rollback and audit requirements<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Amazon Elastic Container Registry (Amazon ECR) is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) CI builds push versioned images for ECS services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need a consistent place for CI to publish images and ECS to pull them.<\/li>\n<li><strong>Why ECR fits:<\/strong> Native integration with ECS task definitions and IAM.<\/li>\n<li><strong>Example:<\/strong> CodeBuild builds <code>orders-api:1.8.4<\/code> and pushes to ECR; ECS service deploys the new image.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) EKS cluster pulls private images without public internet<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Private subnets can\u2019t (or shouldn\u2019t) pull from public registries.<\/li>\n<li><strong>Why ECR fits:<\/strong> Works with VPC endpoints (<code>ecr.api<\/code>, <code>ecr.dkr<\/code>) and IAM roles for service accounts (IRSA) patterns.<\/li>\n<li><strong>Example:<\/strong> An EKS node group in private subnets pulls ECR images via VPC endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Cross-account image sharing for a multi-account platform<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Central platform account produces \u201cgolden\u201d images; workload accounts must pull them.<\/li>\n<li><strong>Why ECR fits:<\/strong> Repository policies and IAM allow controlled cross-account pull.<\/li>\n<li><strong>Example:<\/strong> Shared services account hosts <code>base-java<\/code> image; 20 workload accounts pull it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Multi-region disaster recovery image replication<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Your Region fails or has limited access; you still need images to deploy.<\/li>\n<li><strong>Why ECR fits:<\/strong> Replication configuration supports distributing images across Regions.<\/li>\n<li><strong>Example:<\/strong> Replicate from <code>us-east-1<\/code> to <code>us-west-2<\/code> for DR readiness.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Vulnerability scanning on push for security gates<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must identify vulnerable packages before promotion to production.<\/li>\n<li><strong>Why ECR fits:<\/strong> ECR scanning options integrate with AWS security tooling.<\/li>\n<li><strong>Example:<\/strong> Images pushed to <code>dev<\/code> repo are scanned; pipeline blocks promotion if critical findings exist.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Lifecycle policy to prevent \u201cimage sprawl\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> CI pushes hundreds of tags; storage costs grow and repos become messy.<\/li>\n<li><strong>Why ECR fits:<\/strong> Lifecycle rules can expire untagged or old images automatically.<\/li>\n<li><strong>Example:<\/strong> Keep last 20 <code>main-*<\/code> images and delete untagged images older than 7 days.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Pull-through cache to control upstream dependency risk<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You rely on Docker Hub but want fewer external pulls and better resilience.<\/li>\n<li><strong>Why ECR fits:<\/strong> Pull-through cache rules cache upstream images into ECR.<\/li>\n<li><strong>Example:<\/strong> Cache <code>library\/nginx<\/code> so deployments do not depend directly on Docker Hub availability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Lambda container images for serverless packaging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Functions exceed ZIP limits or require OS-level dependencies.<\/li>\n<li><strong>Why ECR fits:<\/strong> Lambda can deploy container images stored in ECR.<\/li>\n<li><strong>Example:<\/strong> A Python function with heavy dependencies is packaged as an image and deployed to Lambda.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Shared internal tools images (linters, migration tools, CLIs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need standardized tooling in CI\/CD across teams.<\/li>\n<li><strong>Why ECR fits:<\/strong> Centralized, permissioned distribution.<\/li>\n<li><strong>Example:<\/strong> A <code>db-migrator<\/code> image is used by pipelines across multiple repos.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Blue\/green and canary deployments using immutable digests<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Tags can drift; you need deterministic rollouts and rollbacks.<\/li>\n<li><strong>Why ECR fits:<\/strong> Every image has an immutable digest you can pin in deployment definitions.<\/li>\n<li><strong>Example:<\/strong> ECS uses <code>image@sha256:...<\/code> so \u201cprod\u201d always runs exactly the tested build.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Partner distribution using ECR Public (when appropriate)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want to publish a public container image with AWS-managed hosting.<\/li>\n<li><strong>Why ECR fits:<\/strong> ECR Public provides a public registry option.<\/li>\n<li><strong>Example:<\/strong> An open-source agent image is published to ECR Public and referenced in documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Environment promotion with separate repositories and policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need strict control over what reaches production.<\/li>\n<li><strong>Why ECR fits:<\/strong> Use separate repos (<code>app-dev<\/code>, <code>app-prod<\/code>) with tighter policies on prod.<\/li>\n<li><strong>Example:<\/strong> Only release automation role can push to <code>app-prod<\/code>, while dev teams push to <code>app-dev<\/code>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on important current features of Amazon Elastic Container Registry (Amazon ECR). For details and the latest updates, verify in official docs: https:\/\/docs.aws.amazon.com\/AmazonECR\/latest\/userguide\/what-is-ecr.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Private repositories<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Stores container images privately in your AWS account\/Region.<\/li>\n<li><strong>Why it matters:<\/strong> Keeps proprietary code private and close to AWS compute.<\/li>\n<li><strong>Practical benefit:<\/strong> ECS\/EKS deployments can pull with IAM control.<\/li>\n<li><strong>Caveats:<\/strong> Regional scoping means you must plan for multi-region needs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Amazon ECR Public<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Hosts public container images intended for broad distribution.<\/li>\n<li><strong>Why it matters:<\/strong> Allows publishing without running your own public registry infrastructure.<\/li>\n<li><strong>Practical benefit:<\/strong> Useful for open-source images, public agents, examples.<\/li>\n<li><strong>Caveats:<\/strong> Public distribution changes your threat model; use strong supply-chain practices.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM authentication and authorization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses AWS IAM identities\/roles and policies to allow\/deny actions.<\/li>\n<li><strong>Why it matters:<\/strong> Centralized enterprise authZ patterns, MFA, roles, and audit.<\/li>\n<li><strong>Practical benefit:<\/strong> CI roles push; runtime roles pull; humans have limited access.<\/li>\n<li><strong>Caveats:<\/strong> Docker login uses an ECR authorization token (short-lived). Token management is required in automation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Repository policies (resource-based)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows cross-account access to specific repositories.<\/li>\n<li><strong>Why it matters:<\/strong> Enables hub-and-spoke multi-account image distribution.<\/li>\n<li><strong>Practical benefit:<\/strong> One platform account can share approved images.<\/li>\n<li><strong>Caveats:<\/strong> Ensure least privilege; avoid allowing broad principals like <code>*<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Image tagging and digest addressing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports tags and immutable digests.<\/li>\n<li><strong>Why it matters:<\/strong> Tags are convenient but mutable; digests ensure repeatability.<\/li>\n<li><strong>Practical benefit:<\/strong> Use tags for human workflows, digests for production deployments.<\/li>\n<li><strong>Caveats:<\/strong> If you rely only on tags like <code>latest<\/code>, you risk non-reproducible rollouts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tag immutability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Prevents overwriting tags after they\u2019re pushed (when enabled).<\/li>\n<li><strong>Why it matters:<\/strong> Protects release tags from being replaced.<\/li>\n<li><strong>Practical benefit:<\/strong> Guarantees <code>v1.2.3<\/code> always refers to the same content.<\/li>\n<li><strong>Caveats:<\/strong> You must adjust CI logic (new tags per build, don\u2019t \u201cre-push\u201d same tag).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lifecycle policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Automatically expires images matching rules (age\/count\/tag status).<\/li>\n<li><strong>Why it matters:<\/strong> Prevents runaway storage costs and keeps repos manageable.<\/li>\n<li><strong>Practical benefit:<\/strong> Delete untagged images after a short grace period; keep only last N releases.<\/li>\n<li><strong>Caveats:<\/strong> Poorly designed policies can delete images still needed for rollback\u2014test carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Image scanning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Scans images for known vulnerabilities (capability varies by scanning mode\/region).<\/li>\n<li><strong>Why it matters:<\/strong> Helps detect vulnerable packages before deployment.<\/li>\n<li><strong>Practical benefit:<\/strong> Gate promotions or create tickets automatically from findings.<\/li>\n<li><strong>Caveats:<\/strong> Scanning is not a complete security solution; you still need SBOM\/provenance and patch processes. Enhanced scanning and integrations may incur cost\u2014verify in pricing and Inspector docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Replication<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Automatically replicates images to other Regions and\/or accounts (based on configuration).<\/li>\n<li><strong>Why it matters:<\/strong> Improves resilience and reduces latency for geographically distributed workloads.<\/li>\n<li><strong>Practical benefit:<\/strong> DR-ready image availability; faster deploys in secondary Regions.<\/li>\n<li><strong>Caveats:<\/strong> Replication increases storage and may increase data transfer costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pull-through cache rules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Caches images from upstream registries into ECR.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces dependency on upstream availability and rate limits.<\/li>\n<li><strong>Practical benefit:<\/strong> Standardizes external base images and speeds pulls.<\/li>\n<li><strong>Caveats:<\/strong> You must manage cache freshness and approvals; caching does not automatically make an image \u201ctrusted.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption at rest (KMS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Encrypts stored data; supports AWS-managed keys and customer managed keys (CMKs) in AWS KMS.<\/li>\n<li><strong>Why it matters:<\/strong> Compliance and data protection.<\/li>\n<li><strong>Practical benefit:<\/strong> Central key management and audit for encryption usage.<\/li>\n<li><strong>Caveats:<\/strong> CMKs can introduce KMS request costs and permission complexity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Event and audit integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> API activity logged to CloudTrail; events can integrate with EventBridge-based automation (verify event types in official docs).<\/li>\n<li><strong>Why it matters:<\/strong> Traceability and automated response.<\/li>\n<li><strong>Practical benefit:<\/strong> Trigger pipeline steps or security workflows on image push\/scan completion.<\/li>\n<li><strong>Caveats:<\/strong> CloudTrail logs must be stored and governed (S3 retention, encryption, access controls).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level, Amazon ECR sits in the middle of a container supply chain:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Build system<\/strong> builds an image.<\/li>\n<li><strong>Build system authenticates<\/strong> to ECR using AWS credentials to obtain an authorization token.<\/li>\n<li><strong>Build system pushes<\/strong> image layers and manifest to a repository.<\/li>\n<li><strong>Runtime platform<\/strong> (ECS\/EKS\/Lambda) authenticates (usually via an IAM role) and <strong>pulls<\/strong> the image from ECR.<\/li>\n<li>Optional: <strong>Scanning<\/strong> occurs; <strong>events<\/strong> and <strong>findings<\/strong> flow to security tooling.<\/li>\n<li>Optional: <strong>Replication<\/strong> copies images to other registries.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> Create repositories, set policies, configure replication\/lifecycle, request auth tokens.<\/li>\n<li><strong>Data plane:<\/strong> Push\/pull image layers and manifests over HTTPS. Image layers are stored durably by AWS (implementation details are abstracted; do not rely on internal storage assumptions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related AWS services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Amazon ECS \/ AWS Fargate:<\/strong> Task definitions reference ECR images.\n&#8211; <strong>Amazon EKS:<\/strong> Kubernetes workloads pull ECR images; nodes\/IRSA roles require permissions.\n&#8211; <strong>AWS Lambda (container images):<\/strong> Functions can deploy from ECR images.\n&#8211; <strong>AWS CodeBuild \/ CodePipeline:<\/strong> Build and publish images to ECR.\n&#8211; <strong>Amazon Inspector:<\/strong> Enhanced image scanning workflows (verify current integration details).\n&#8211; <strong>AWS KMS:<\/strong> Encryption with customer-managed keys.\n&#8211; <strong>AWS CloudTrail:<\/strong> Audit ECR API actions.\n&#8211; <strong>Amazon EventBridge:<\/strong> Event-driven automation around pushes\/scans (verify event patterns).\n&#8211; <strong>Amazon VPC endpoints (PrivateLink):<\/strong> Private access from VPC without internet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> is foundational for authZ\/authN.<\/li>\n<li><strong>KMS<\/strong> if you choose customer-managed keys.<\/li>\n<li><strong>VPC endpoints<\/strong> for private pulls\/pushes from private subnets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Authentication is based on <strong>AWS IAM credentials<\/strong>:<\/li>\n<li>Users\/roles call <code>ecr:GetAuthorizationToken<\/code><\/li>\n<li>Docker uses token as basic auth to the registry<\/li>\n<li>Authorization is enforced by:<\/li>\n<li>Identity-based IAM policies (user\/role)<\/li>\n<li>Resource-based repository policies (cross-account)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>By default, ECR is accessed via public AWS service endpoints over HTTPS.<\/li>\n<li>For private networks:<\/li>\n<li>Use <strong>Interface VPC endpoints<\/strong> for <code>ecr.api<\/code> and <code>ecr.dkr<\/code>.<\/li>\n<li>You commonly also need an <strong>S3 gateway endpoint<\/strong> for efficient\/private layer transfers (verify the current endpoint requirements in official docs for your environment).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudTrail:<\/strong> Record repository changes, auth token requests, replication changes, deletions.<\/li>\n<li><strong>CloudWatch \/ EventBridge:<\/strong> Build automation around events.<\/li>\n<li><strong>Config\/Organizations (governance):<\/strong> Enforce baseline policies like tag immutability, scanning on push, and CMK usage via guardrails (implementation varies by org).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer \/ CI] --&gt;|docker build| Img[Container Image]\n  Dev --&gt;|GetAuthorizationToken| IAM[IAM]\n  Dev --&gt;|docker push| ECR[(Amazon ECR Repository)]\n  Runtime[Amazon ECS \/ EKS \/ Lambda] --&gt;|docker pull| ECR\n  ECR --&gt;|optional scan| Scan[Image Scanning]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Accounts[\"AWS Organizations Multi-Account\"]\n    subgraph Shared[\"Shared Services Account\"]\n      CI[CI\/CD (CodeBuild\/GitHub Actions Runner)] --&gt;|push| ECRHub[(ECR Repo: approved-images)]\n      Sec[Security Automation] --&gt;|evaluate scan findings| Gate[Promotion Gate]\n    end\n\n    subgraph WorkloadA[\"Workload Account A\"]\n      ECS[ECS\/EKS Runtime] --&gt;|pull| ECRSpokeA[(ECR Repo policy: pull allowed)]\n    end\n\n    subgraph WorkloadB[\"Workload Account B\"]\n      EKS[EKS Runtime] --&gt;|pull| ECRSpokeB[(ECR Repo policy: pull allowed)]\n    end\n  end\n\n  ECRHub --&gt;|replication| ECRSpokeA\n  ECRHub --&gt;|replication| ECRSpokeB\n\n  subgraph Network[\"Private Networking\"]\n    VPCE1[VPC Endpoint: ecr.api]\n    VPCE2[VPC Endpoint: ecr.dkr]\n  end\n\n  ECS -.private access.-&gt; VPCE1\n  ECS -.private access.-&gt; VPCE2\n  EKS -.private access.-&gt; VPCE1\n  EKS -.private access.-&gt; VPCE2\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start the hands-on lab and production design work, ensure the following are in place.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>active AWS account<\/strong> with billing enabled.<\/li>\n<li>Choose a target <strong>AWS Region<\/strong> that supports Amazon ECR (most commercial regions do; verify for specialized regions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>Minimum for the lab (conceptually):\n&#8211; Ability to create and delete ECR repositories.\n&#8211; Ability to authenticate and push\/pull images.<\/p>\n\n\n\n<p>Practical options:\n&#8211; For a learning lab, you can attach an AWS-managed policy like <strong>AmazonEC2ContainerRegistryPowerUser<\/strong> or similar to your IAM principal <strong>temporarily<\/strong> (verify the exact managed policy names in IAM).\n&#8211; For production, create a least-privilege policy for:\n  &#8211; CI push role\n  &#8211; Runtime pull role\n  &#8211; Admin role (lifecycle, replication, policy management)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ECR incurs costs for <strong>storage<\/strong>, and potentially for <strong>data transfer<\/strong> and <strong>scanning<\/strong> depending on configuration and usage. See Section 9.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CLI v2<\/strong> installed and configured: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li><strong>Docker<\/strong> installed (or another OCI-compatible client):<\/li>\n<li>Docker Engine: https:\/\/docs.docker.com\/engine\/install\/<\/li>\n<li>Optional but recommended:<\/li>\n<li><code>jq<\/code> for JSON viewing in shell scripts<\/li>\n<li>Git if you want to track Dockerfile changes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon ECR is regional for private repos. Pick one Region for the lab, for example <code>us-east-1<\/code>.<\/li>\n<li>If you plan to use replication, ensure destination Regions are enabled for your account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Amazon ECR has quotas (repositories per registry, image size limits, API request rates, etc.). Quotas can change and vary by region\/account.<br\/>\nCheck current quotas in official docs and Service Quotas:\n&#8211; ECR quotas: https:\/\/docs.aws.amazon.com\/AmazonECR\/latest\/userguide\/service-quotas.html (verify URL in official docs)\n&#8211; Service Quotas console: https:\/\/console.aws.amazon.com\/servicequotas\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM for identity and permissions (required)<\/li>\n<li>Optional:<\/li>\n<li>KMS for customer-managed encryption keys<\/li>\n<li>VPC endpoints for private networking<\/li>\n<li>Inspector for enhanced scanning<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Amazon ECR pricing is usage-based. Exact prices vary by Region and can change; do not hardcode numbers in design docs\u2014use the official pricing page and AWS Pricing Calculator.<\/p>\n\n\n\n<p>Official pricing:\n&#8211; Amazon ECR pricing: https:\/\/aws.amazon.com\/ecr\/pricing\/\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<p>Common cost drivers include:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Storage (GB-month)<\/strong>\n   &#8211; You pay for the amount of image data stored in repositories over time.\n   &#8211; Lifecycle policies are the primary control for this cost.<\/p>\n<\/li>\n<li>\n<p><strong>Data transfer<\/strong>\n   &#8211; Pulling images can incur data transfer charges depending on where the client is:<\/p>\n<ul>\n<li>Within the same Region and AWS service context may have different network billing than pulling across Regions or out to the internet.<\/li>\n<li>Cross-region replication can increase inter-region data transfer.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Image scanning<\/strong>\n   &#8211; Basic scanning and enhanced scanning have different behaviors and billing implications.\n   &#8211; Enhanced scanning commonly ties into Amazon Inspector pricing (verify current billing model and what actions trigger charges).<\/p>\n<\/li>\n<li>\n<p><strong>API requests (if applicable)<\/strong>\n   &#8211; Some registries charge per request; Amazon ECR\u2019s current model should be verified on the pricing page for your Region and use case. If your workload is extremely high-scale, validate request-related costs and throttling behavior in official docs.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>AWS Free Tier details can change and differ across services and time periods. Do not assume ECR has a specific free tier allocation.<br\/>\nVerify current Free Tier eligibility here:\n&#8211; https:\/\/aws.amazon.com\/free\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CI build costs:<\/strong> CodeBuild\/GitHub runners\/EC2 compute time to build images.<\/li>\n<li><strong>NAT Gateway costs:<\/strong> If your private subnets pull images via NAT instead of VPC endpoints, NAT data processing charges can be significant.<\/li>\n<li><strong>KMS costs:<\/strong> Customer-managed key usage incurs KMS request charges and management overhead.<\/li>\n<li><strong>Log storage costs:<\/strong> CloudTrail logs stored in S3 and analyzed with Athena can add cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High-frequency auto-scaling (many nodes pulling images) can create large data transfer volumes.<\/li>\n<li>Multi-region replication increases storage and potentially inter-region transfer.<\/li>\n<li>Pull-through cache reduces repeated external pulls but still stores cached layers (storage increases).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>lifecycle policies<\/strong>:<\/li>\n<li>Aggressively expire untagged images.<\/li>\n<li>Keep a fixed number of release tags for rollback.<\/li>\n<li>Prefer <strong>digest pinning<\/strong> and avoid rebuilding identical images with different tags.<\/li>\n<li>Minimize image size:<\/li>\n<li>Multi-stage builds<\/li>\n<li>Smaller base images<\/li>\n<li>Remove build tools from runtime layers<\/li>\n<li>Use <strong>VPC endpoints<\/strong> to reduce NAT data processing costs for private subnets pulling images.<\/li>\n<li>Use replication selectively:<\/li>\n<li>Replicate only production repos\/tags to secondary regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A small team might store:\n&#8211; A few repositories\n&#8211; A handful of images per repo\n&#8211; Low pull frequency (dev\/test)<\/p>\n\n\n\n<p>Costs will mainly be:\n&#8211; <strong>Storage GB-month<\/strong> (often small if you keep images trimmed and lifecycle-managed)\n&#8211; Minimal data transfer if most pulls happen within the same Region<\/p>\n\n\n\n<p>Use the AWS Pricing Calculator with:\n&#8211; Estimated total stored GB\n&#8211; Estimated monthly pull data transfer out (if any)\n&#8211; Scanning mode and expected scan volume (if enabled)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, costs typically come from:\n&#8211; Large fleets pulling images during scaling events or node replacements\n&#8211; Multi-account and multi-region replication (storage doubles\/triples)\n&#8211; Enhanced scanning at scale (if enabled)\n&#8211; NAT Gateway data processing (if pulling over NAT)<\/p>\n\n\n\n<p>A common cost-control pattern is:\n&#8211; Put workloads in private subnets\n&#8211; Add ECR VPC endpoints and S3 gateway endpoint\n&#8211; Enforce lifecycle cleanup\n&#8211; Keep images small and stable\n&#8211; Replicate only what you must<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create an Amazon Elastic Container Registry (Amazon ECR) private repository, build a small container image locally, push it to ECR, pull it back to verify, enable scanning on push, add a lifecycle policy, and then clean up resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Configure environment variables.\n2. Create an ECR repository with scanning on push enabled.\n3. Authenticate Docker to Amazon ECR.\n4. Build a small Docker image locally.\n5. Tag and push the image to ECR.\n6. Verify the image exists and (if enabled) check scan settings.\n7. Add a lifecycle policy to expire untagged images.\n8. Pull the image from ECR to confirm end-to-end success.\n9. Clean up by deleting the image and repository.<\/p>\n\n\n\n<p>This lab is designed to be low-cost:\n&#8211; The image is tiny.\n&#8211; The repository stores minimal data.\n&#8211; You will delete everything at the end.<\/p>\n\n\n\n<blockquote>\n<p>Note: If you enable enhanced scanning or integrate with Amazon Inspector, costs can apply. For a basic lab, keep to basic scanning settings unless you explicitly want to explore enhanced scanning and have confirmed pricing.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment (AWS CLI + variables)<\/h3>\n\n\n\n<p>1) Confirm AWS CLI is installed and you can call AWS APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws --version\naws sts get-caller-identity\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see your AWS Account ID, user\/role ARN, and CLI version output.<\/p>\n\n\n\n<p>2) Set variables for the lab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_REGION=\"us-east-1\"\nexport REPO_NAME=\"ecr-lab\/hello\"\nexport IMAGE_TAG=\"v1\"\nexport ACCOUNT_ID=\"$(aws sts get-caller-identity --query Account --output text)\"\n<\/code><\/pre>\n\n\n\n<p>3) Confirm Docker is installed:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker version\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Docker client\/server versions are displayed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create an Amazon ECR repository<\/h3>\n\n\n\n<p>Create a repository with scanning on push enabled and tag immutability disabled (you can enable it later depending on your workflow).<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr create-repository \\\n  --region \"${AWS_REGION}\" \\\n  --repository-name \"${REPO_NAME}\" \\\n  --image-scanning-configuration scanOnPush=true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> JSON output describing the repository, including <code>repositoryUri<\/code>.<\/p>\n\n\n\n<p>Capture the repository URI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export REPO_URI=\"$(aws ecr describe-repositories \\\n  --region \"${AWS_REGION}\" \\\n  --repository-names \"${REPO_NAME}\" \\\n  --query \"repositories[0].repositoryUri\" \\\n  --output text)\"\n\necho \"Repo URI: ${REPO_URI}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Authenticate Docker to Amazon ECR<\/h3>\n\n\n\n<p>Use the recommended AWS CLI v2 authentication flow:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr get-login-password --region \"${AWS_REGION}\" \\\n  | docker login --username AWS --password-stdin \"${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>Login Succeeded<\/code><\/p>\n\n\n\n<p>If it fails, see Troubleshooting.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a small container image locally<\/h3>\n\n\n\n<p>Create a temporary folder and a simple Dockerfile:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p ecr-lab &amp;&amp; cd ecr-lab\ncat &gt; Dockerfile &lt;&lt;'EOF'\nFROM alpine:3.20\nRUN adduser -D appuser\nUSER appuser\nCMD [\"sh\", \"-c\", \"echo Hello from Amazon ECR &amp;&amp; sleep 3600\"]\nEOF\n<\/code><\/pre>\n\n\n\n<p>Build the image:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker build -t hello-ecr:local .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Docker build completes successfully and an image named <code>hello-ecr:local<\/code> exists.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker images | grep hello-ecr\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Tag and push the image to Amazon ECR<\/h3>\n\n\n\n<p>Tag the local image with the ECR repository URI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker tag hello-ecr:local \"${REPO_URI}:${IMAGE_TAG}\"\n<\/code><\/pre>\n\n\n\n<p>Push it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker push \"${REPO_URI}:${IMAGE_TAG}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see layers being pushed and a final digest output.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Verify the image in the repository<\/h3>\n\n\n\n<p>List images:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr list-images \\\n  --region \"${AWS_REGION}\" \\\n  --repository-name \"${REPO_NAME}\"\n<\/code><\/pre>\n\n\n\n<p>Describe the image details (including digest):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr describe-images \\\n  --region \"${AWS_REGION}\" \\\n  --repository-name \"${REPO_NAME}\" \\\n  --image-ids imageTag=\"${IMAGE_TAG}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The image is present with <code>imageDigest<\/code> and metadata.<\/p>\n\n\n\n<p>If you used scan-on-push, you can confirm the repository scanning configuration:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr describe-repositories \\\n  --region \"${AWS_REGION}\" \\\n  --repository-names \"${REPO_NAME}\" \\\n  --query \"repositories[0].imageScanningConfiguration\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>scanOnPush<\/code> is <code>true<\/code>.<\/p>\n\n\n\n<blockquote>\n<p>Viewing scan findings: The exact commands and availability depend on scanning mode and account configuration. Verify the current \u201cbasic scanning\u201d and \u201cenhanced scanning\u201d workflows in official docs before relying on a particular CLI command for findings.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Add a lifecycle policy (to manage costs)<\/h3>\n\n\n\n<p>A common policy is to expire untagged images after a short time, because CI systems often create untagged layers during rebuilds.<\/p>\n\n\n\n<p>Create a lifecycle policy JSON:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; lifecycle.json &lt;&lt;'EOF'\n{\n  \"rules\": [\n    {\n      \"rulePriority\": 1,\n      \"description\": \"Expire untagged images older than 7 days\",\n      \"selection\": {\n        \"tagStatus\": \"untagged\",\n        \"countType\": \"sinceImagePushed\",\n        \"countUnit\": \"days\",\n        \"countNumber\": 7\n      },\n      \"action\": { \"type\": \"expire\" }\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Apply it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr put-lifecycle-policy \\\n  --region \"${AWS_REGION}\" \\\n  --repository-name \"${REPO_NAME}\" \\\n  --lifecycle-policy-text file:\/\/lifecycle.json\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Policy text is returned in the output.<\/p>\n\n\n\n<p>Preview lifecycle actions (non-destructive preview):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr get-lifecycle-policy-preview \\\n  --region \"${AWS_REGION}\" \\\n  --repository-name \"${REPO_NAME}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A preview is generated. (If there are no matching images yet, the preview may show no expirations.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Pull the image from ECR (end-to-end validation)<\/h3>\n\n\n\n<p>Remove the local tagged image and pull it again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker rmi \"${REPO_URI}:${IMAGE_TAG}\" || true\ndocker pull \"${REPO_URI}:${IMAGE_TAG}\"\n<\/code><\/pre>\n\n\n\n<p>Run it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker run --rm \"${REPO_URI}:${IMAGE_TAG}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Output includes <code>Hello from Amazon ECR<\/code> and the container runs (sleeps). Use Ctrl+C to stop it if needed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Repository exists:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">aws ecr describe-repositories --region \"${AWS_REGION}\" --repository-names \"${REPO_NAME}\"\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Image exists:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">aws ecr describe-images --region \"${AWS_REGION}\" --repository-name \"${REPO_NAME}\"\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You can pull successfully:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">docker pull \"${REPO_URI}:${IMAGE_TAG}\"\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lifecycle policy is attached:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">aws ecr get-lifecycle-policy --region \"${AWS_REGION}\" --repository-name \"${REPO_NAME}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common errors and fixes:<\/p>\n\n\n\n<p>1) <strong><code>no basic auth credentials<\/code> when pushing<\/strong>\n&#8211; Cause: Docker is not logged in to ECR or token expired.\n&#8211; Fix:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr get-login-password --region \"${AWS_REGION}\" \\\n  | docker login --username AWS --password-stdin \"${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com\"\n<\/code><\/pre>\n\n\n\n<p>2) <strong><code>AccessDeniedException<\/code> for ECR actions<\/strong>\n&#8211; Cause: IAM permissions missing.\n&#8211; Fix:\n  &#8211; Ensure your IAM principal has permissions like <code>ecr:CreateRepository<\/code>, <code>ecr:GetAuthorizationToken<\/code>, and push\/pull permissions.\n  &#8211; For learning, temporarily attach an appropriate ECR managed policy; for production use least privilege.<\/p>\n\n\n\n<p>3) <strong>Wrong Region \/ wrong repository URI<\/strong>\n&#8211; Symptom: repository not found, or login succeeded but push fails.\n&#8211; Fix:\n  &#8211; Confirm <code>AWS_REGION<\/code> matches the repo\u2019s Region.\n  &#8211; Re-fetch <code>REPO_URI<\/code> from <code>describe-repositories<\/code>.<\/p>\n\n\n\n<p>4) <strong>Corporate proxy or firewall blocks Docker push\/pull<\/strong>\n&#8211; Cause: HTTPS endpoints blocked.\n&#8211; Fix:\n  &#8211; Allowlist ECR endpoints for your Region.\n  &#8211; Consider running the lab from an EC2 instance in AWS.<\/p>\n\n\n\n<p>5) <strong>Private subnet pulling issues<\/strong>\n&#8211; Symptom: ECS\/EKS can\u2019t pull images in private subnets.\n&#8211; Fix:\n  &#8211; Add VPC endpoints for <code>ecr.api<\/code> and <code>ecr.dkr<\/code> and typically an S3 gateway endpoint (verify exact requirements in the ECR private networking documentation).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete the repository (and all images) to avoid ongoing storage charges:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr delete-repository \\\n  --region \"${AWS_REGION}\" \\\n  --repository-name \"${REPO_NAME}\" \\\n  --force\n<\/code><\/pre>\n\n\n\n<p>Remove local lab files:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cd .. &amp;&amp; rm -rf ecr-lab\n<\/code><\/pre>\n\n\n\n<p>Optionally remove local images:<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker rmi hello-ecr:local || true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Repository no longer exists; local files removed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate repositories by domain and lifecycle<\/strong> (e.g., <code>payments-api<\/code>, <code>base-images\/java17<\/code>, <code>platform\/agent<\/code>).<\/li>\n<li><strong>Use immutable digests for production deployments<\/strong> to prevent tag drift.<\/li>\n<li><strong>Plan for multi-account distribution<\/strong>:<\/li>\n<li>Prefer hub-and-spoke models with repository policies and\/or replication.<\/li>\n<li>Keep \u201cproducer\u201d and \u201cconsumer\u201d responsibilities clear.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use separate IAM roles<\/strong>:<\/li>\n<li>CI push role (push only to specific repos)<\/li>\n<li>Runtime pull role (read-only pull for specific repos)<\/li>\n<li>Admin role (repo policy, replication, lifecycle changes)<\/li>\n<li><strong>Avoid human long-lived credentials<\/strong>; prefer SSO\/role assumption.<\/li>\n<li><strong>Use resource-based repository policies<\/strong> for cross-account pulls; avoid broad principals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Aggressively expire untagged images<\/strong> (they often add cost without providing rollback value).<\/li>\n<li><strong>Keep only last N releases<\/strong> (and maybe last N per major version).<\/li>\n<li><strong>Shrink images<\/strong> to reduce storage and pull bandwidth.<\/li>\n<li><strong>Use VPC endpoints<\/strong> to reduce NAT gateway processing costs for private workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keep images small<\/strong> to speed up pulls, scale-outs, and cold starts.<\/li>\n<li><strong>Use caching sensibly<\/strong> (pull-through cache for external registries where it makes sense).<\/li>\n<li><strong>Avoid rebuilding identical layers<\/strong> unnecessarily; structure Dockerfiles for layer reuse.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Enable replication for DR<\/strong> where needed.<\/li>\n<li><strong>Use multiple tags + digest pinning<\/strong>:<\/li>\n<li>Tag for human readability (<code>v1.2.3<\/code>)<\/li>\n<li>Digest for deployments (<code>@sha256:...<\/code>)<\/li>\n<li><strong>Treat the registry as a critical dependency<\/strong> and design runbooks for ECR access failures (e.g., regional failover strategy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardize naming and tagging<\/strong>:<\/li>\n<li>Repo naming conventions (<code>team\/service<\/code>, <code>platform\/component<\/code>)<\/li>\n<li>Tagging conventions (<code>semver<\/code>, <code>gitsha<\/code>, <code>build-&lt;id&gt;<\/code>, environment tags)<\/li>\n<li><strong>Automate lifecycle policies<\/strong> across repos (IaC).<\/li>\n<li><strong>Audit with CloudTrail<\/strong> and retain logs per compliance requirements.<\/li>\n<li><strong>Use Infrastructure as Code<\/strong> (CloudFormation\/CDK\/Terraform) to manage repos, policies, replication, and encryption settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent metadata:<\/li>\n<li>Repository description and tags (AWS resource tags) to track owner, cost center, environment, compliance.<\/li>\n<li>Apply organization-wide controls via:<\/li>\n<li>SCPs (Service Control Policies) where appropriate<\/li>\n<li>AWS Config rules (if you have them) to detect non-compliant repositories (e.g., scanning disabled)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authentication:<\/strong> AWS IAM credentials obtain an ECR authorization token.<\/li>\n<li><strong>Authorization:<\/strong> IAM identity policies + repository resource policies.<\/li>\n<li>Recommended patterns:<\/li>\n<li><strong>Least privilege<\/strong> roles for CI and runtime.<\/li>\n<li><strong>Short-lived credentials<\/strong> via role assumption (STS).<\/li>\n<li>Centralized identity (AWS IAM Identity Center) for humans.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit:<\/strong> HTTPS for push\/pull.<\/li>\n<li><strong>At rest:<\/strong> Encrypted by default using AWS-managed keys; you can choose <strong>customer-managed KMS keys<\/strong> for stricter control and auditing.<\/li>\n<\/ul>\n\n\n\n<p>Recommendations:\n&#8211; Use CMKs if compliance requires key ownership and rotation control.\n&#8211; Ensure KMS key policies allow the required ECR service usage and the roles that access the repository.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Default access is via public AWS endpoints.<\/li>\n<li>For private environments:<\/li>\n<li>Use <strong>VPC endpoints<\/strong> for ECR (<code>ecr.api<\/code>, <code>ecr.dkr<\/code>) and validate S3 endpoint requirements.<\/li>\n<li>Restrict egress; avoid routing image pulls through NAT when not necessary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do <strong>not<\/strong> bake secrets into container images.<\/li>\n<li>Use secrets managers:<\/li>\n<li>AWS Secrets Manager or SSM Parameter Store for runtime secrets<\/li>\n<li>Workload identity (task roles \/ IRSA) to fetch secrets at runtime<\/li>\n<li>Ensure CI logs do not print the ECR password\/token.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and retain <strong>CloudTrail<\/strong> logs for ECR actions:<\/li>\n<li>Repository policy changes<\/li>\n<li>Lifecycle policy changes<\/li>\n<li>Replication config changes<\/li>\n<li>Image deletions<\/li>\n<li>Consider centralizing logs in a security account with immutable storage controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many compliance programs require:<\/li>\n<li>encryption at rest<\/li>\n<li>access logging<\/li>\n<li>least privilege<\/li>\n<li>vulnerability management<\/li>\n<li>ECR can support these, but you must implement the governance controls around it (policies, scanning workflows, retention).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Using <code>latest<\/code> tag in production deployments.<\/li>\n<li>Allowing broad cross-account access (<code>Principal: \"*\"<\/code>) in repo policies.<\/li>\n<li>Allowing CI to push to production repos without gates.<\/li>\n<li>Not enabling scanning (or ignoring scan results).<\/li>\n<li>Keeping old vulnerable images indefinitely without lifecycle\/retention policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce:<\/li>\n<li>Tag immutability for release repos<\/li>\n<li>Digest pinning for production<\/li>\n<li>Scanning and promotion gates<\/li>\n<li>Least privilege IAM for push\/pull<\/li>\n<li>Multi-account separation (dev vs prod, shared services vs workloads)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Use this section as a checklist during design and operations. Always verify the latest constraints in official docs and Service Quotas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ quotas (examples to validate)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional scope:<\/strong> ECR private repositories are regional; multi-region requires replication and separate repos.<\/li>\n<li><strong>Quotas:<\/strong> Repository counts, image counts, API request rate limits, and image size limits exist (verify current values).<\/li>\n<li><strong>Authorization token lifetime:<\/strong> The Docker login token is short-lived; automation must refresh it.<\/li>\n<li><strong>Tag mutability defaults:<\/strong> If tag immutability is not enabled, tags can be overwritten (risk for release tags).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some features (e.g., enhanced scanning integrations) may not be available in every region or partition (commercial, GovCloud, China). Verify for your environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NAT Gateway data processing<\/strong> during pulls from private subnets can dwarf ECR storage costs.<\/li>\n<li><strong>Replication<\/strong> doubles storage and can add transfer costs.<\/li>\n<li><strong>Enhanced scanning<\/strong> may generate additional charges at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Most standard Docker workflows are supported, but advanced artifact workflows should be validated (OCI artifacts, Helm charts, provenance\/signing integrations). Verify in official docs for your tooling requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lifecycle policies can delete images you still need if rules are too aggressive.<\/li>\n<li>Cross-account pulls require both:<\/li>\n<li>Repository policy allowing the consumer account<\/li>\n<li>IAM permissions in the consumer account role to call pull-related actions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from Docker Hub\/Artifactory:<\/li>\n<li>Retagging and rewriting CI scripts<\/li>\n<li>Handling rate limits vs caching needs<\/li>\n<li>Preserving image digests may not be possible if you rebuild rather than copy\u2014plan carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tight AWS IAM integration is a strength, but it also means non-AWS environments must still be able to assume roles or otherwise obtain credentials for pulling private images.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Amazon Elastic Container Registry (Amazon ECR) is one of several choices for container registries. The \u201cbest\u201d option depends on security model, ecosystem fit, and operational requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Amazon Elastic Container Registry (Amazon ECR)<\/strong><\/td>\n<td>AWS-centric container platforms (ECS\/EKS\/Lambda)<\/td>\n<td>IAM authZ\/authN, CloudTrail audit, VPC endpoints, lifecycle, replication, AWS integrations<\/td>\n<td>Regional scoping for private repos; AWS-dependent auth patterns<\/td>\n<td>You run most workloads on AWS and want native security and ops<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon S3 (as artifact store, not a registry)<\/strong><\/td>\n<td>Storing build artifacts, not container registries<\/td>\n<td>Cheap storage, flexible<\/td>\n<td>Not a container registry; no native image push\/pull semantics<\/td>\n<td>Only for non-container artifacts; not a substitute for ECR<\/td>\n<\/tr>\n<tr>\n<td><strong>Docker Hub<\/strong><\/td>\n<td>Public\/community distribution<\/td>\n<td>Huge ecosystem, easy to use<\/td>\n<td>Rate limits, external dependency, weaker enterprise IAM integration vs AWS<\/td>\n<td>Public images, community sharing, simple setups<\/td>\n<\/tr>\n<tr>\n<td><strong>GitHub Container Registry (GHCR)<\/strong><\/td>\n<td>GitHub-native workflows<\/td>\n<td>GitHub auth model, repo proximity<\/td>\n<td>Runtime pulls from AWS may incur egress; enterprise governance depends on GitHub setup<\/td>\n<td>You\u2019re all-in on GitHub and want code + packages together<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Artifact Registry<\/strong><\/td>\n<td>GCP-centric deployments<\/td>\n<td>Tight GCP integration<\/td>\n<td>Not AWS-native; cross-cloud auth and networking complexity<\/td>\n<td>Most workloads are on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Container Registry (ACR)<\/strong><\/td>\n<td>Azure-centric deployments<\/td>\n<td>Tight Azure integration<\/td>\n<td>Not AWS-native<\/td>\n<td>Most workloads are on Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Harbor (self-managed)<\/strong><\/td>\n<td>Air-gapped\/on-prem\/strict control<\/td>\n<td>Full control, many enterprise features<\/td>\n<td>Ops overhead, patching, scaling, backup, HA complexity<\/td>\n<td>You must self-host for policy\/data residency\/air-gap reasons<\/td>\n<\/tr>\n<tr>\n<td><strong>JFrog Artifactory (self-managed\/managed)<\/strong><\/td>\n<td>Large enterprises with broad artifact needs<\/td>\n<td>Multi-format artifacts, mature governance<\/td>\n<td>Cost\/complexity; not AWS-native by default<\/td>\n<td>You need one enterprise artifact platform across many ecosystems<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Multi-account regulated environment (finance\/healthcare)<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA regulated enterprise runs hundreds of microservices on Amazon EKS across multiple AWS accounts (dev, staging, prod). They need:\n&#8211; strict change control and audit trails\n&#8211; separation of duties (build vs deploy)\n&#8211; vulnerability scanning and controlled promotion\n&#8211; multi-region DR readiness<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Shared services account hosts \u201csource\u201d ECR repositories:\n  &#8211; <code>platform\/base-images\/*<\/code>\n  &#8211; <code>approved\/apps\/*<\/code>\n&#8211; CI pipelines assume a <strong>build role<\/strong> to push images to ECR.\n&#8211; Promotion workflow:\n  &#8211; Only a release automation role can apply production tags or copy\/promote images.\n  &#8211; Production deployments reference <strong>immutable digests<\/strong>.\n&#8211; Scanning:\n  &#8211; Scan on push enabled; enhanced scanning via Inspector considered for production repos (verify current scanning setup).\n&#8211; Replication:\n  &#8211; Replicate production images to a secondary region for DR.\n&#8211; Networking:\n  &#8211; EKS clusters in private subnets use VPC endpoints for ECR to avoid internet\/NAT dependency.\n&#8211; Governance:\n  &#8211; CloudTrail centralized logging; alarms on repository policy changes.\n  &#8211; Lifecycle policies standardized and deployed via IaC.<\/p>\n\n\n\n<p><strong>Why Amazon ECR was chosen<\/strong>\n&#8211; Deep AWS integration with IAM, CloudTrail, VPC endpoints, and container runtimes.\n&#8211; Cross-account sharing with repository policies fits the multi-account pattern.\n&#8211; Lifecycle and replication reduce operational burden.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Deterministic deployments via digest pinning.\n&#8211; Reduced risk from tag overwrites (immutability for release repos).\n&#8211; Better audit posture with CloudTrail logs and controlled access paths.\n&#8211; Faster DR deployments with replicated images.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Single account, fast CI\/CD<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA startup runs 10 services on Amazon ECS Fargate. They want a simple, secure place to store images and automate cleanup, without operating infrastructure.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; One ECR repo per service: <code>svc-auth<\/code>, <code>svc-api<\/code>, <code>svc-worker<\/code>\n&#8211; GitHub Actions builds and pushes images using an IAM role (OIDC federation) with push permissions.\n&#8211; ECS services automatically deploy new task definitions referencing <code>:gitsha<\/code> tags (and optionally digests).\n&#8211; Lifecycle policy:\n  &#8211; Keep last 30 images\n  &#8211; Expire untagged images after 3 days<\/p>\n\n\n\n<p><strong>Why Amazon ECR was chosen<\/strong>\n&#8211; Minimal setup and native AWS runtime integration.\n&#8211; IAM-based access without separate registry credentials.\n&#8211; Lifecycle rules keep costs and clutter down.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Faster deployments with less tooling overhead.\n&#8211; Clear rollback path using recent retained images.\n&#8211; Lower storage costs through automated cleanup.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Amazon Elastic Container Registry (Amazon ECR) a Docker registry?<\/strong><br\/>\nYes, it is a managed container registry service that supports standard push\/pull workflows with common container tooling. It\u2019s designed to work well with Docker\/OCI-style images.<\/p>\n\n\n\n<p>2) <strong>Is Amazon ECR private global or regional?<\/strong><br\/>\nAmazon ECR private is <strong>regional<\/strong>. You have a registry per AWS account per Region. Plan replication if you need multi-region availability.<\/p>\n\n\n\n<p>3) <strong>What\u2019s the difference between Amazon ECR private and Amazon ECR Public?<\/strong><br\/>\nECR private stores images privately within your AWS account\/Region. ECR Public is designed to host images intended for public distribution.<\/p>\n\n\n\n<p>4) <strong>How do I authenticate to Amazon ECR?<\/strong><br\/>\nTypically, you use AWS CLI to fetch an authorization token (<code>ecr get-login-password<\/code>) and pass it to <code>docker login<\/code>. Workloads authenticate using IAM roles.<\/p>\n\n\n\n<p>5) <strong>Do I need to create an IAM user for CI?<\/strong><br\/>\nBest practice is <strong>not<\/strong> to use long-lived IAM users. Prefer role-based access with short-lived credentials (e.g., GitHub Actions OIDC to assume an IAM role).<\/p>\n\n\n\n<p>6) <strong>Should I deploy using tags or digests?<\/strong><br\/>\nUse <strong>digests<\/strong> for production to guarantee immutability and repeatability. Tags are useful for human readability, but tags can be overwritten unless immutability is enabled.<\/p>\n\n\n\n<p>7) <strong>What is tag immutability and when should I enable it?<\/strong><br\/>\nTag immutability prevents overwriting an existing tag. Enable it for release repositories where <code>v1.2.3<\/code> must always refer to the same image.<\/p>\n\n\n\n<p>8) <strong>How do I share images across AWS accounts?<\/strong><br\/>\nUse repository policies (resource-based) to allow a principal in another account to pull (or push if needed). The consumer role also needs IAM permissions to pull.<\/p>\n\n\n\n<p>9) <strong>How do I keep ECR costs under control?<\/strong><br\/>\nUse lifecycle policies, delete untagged images, keep only necessary release history, reduce image sizes, and avoid NAT charges by using VPC endpoints where appropriate.<\/p>\n\n\n\n<p>10) <strong>Does Amazon ECR support vulnerability scanning?<\/strong><br\/>\nYes, scanning is supported. The exact scanning modes (basic vs enhanced) and billing depend on your configuration and region\u2014verify in official docs and the pricing page.<\/p>\n\n\n\n<p>11) <strong>How do I use ECR with private subnets?<\/strong><br\/>\nUse VPC endpoints for ECR (<code>ecr.api<\/code> and <code>ecr.dkr<\/code>). You may also need an S3 gateway endpoint to avoid routing image layer traffic through NAT (verify current networking guidance).<\/p>\n\n\n\n<p>12) <strong>Can Amazon ECS and Amazon EKS pull from ECR without storing credentials?<\/strong><br\/>\nYes. They can use IAM roles (task role \/ execution role for ECS; node\/IRSA patterns for EKS) to authorize pulls, rather than embedded credentials.<\/p>\n\n\n\n<p>13) <strong>What happens if I delete an image tag?<\/strong><br\/>\nDeleting a tag can make it harder to track releases. The image may still exist by digest if referenced elsewhere, but behavior depends on how images are referenced and what tags remain. Plan your retention strategy.<\/p>\n\n\n\n<p>14) <strong>Can I replicate images to another region?<\/strong><br\/>\nYes, ECR supports replication configurations. Replication increases storage and can increase transfer costs.<\/p>\n\n\n\n<p>15) <strong>Is ECR a good choice for multi-cloud?<\/strong><br\/>\nIt can be, but the IAM- and AWS-endpoint-based access model is AWS-centric. For multi-cloud you may prefer a registry that matches your identity\/networking strategy across clouds, or accept the integration work to pull from ECR outside AWS.<\/p>\n\n\n\n<p>16) <strong>What\u2019s the safest way to promote images from dev to prod?<\/strong><br\/>\nUse separate repositories or controlled tags, require scanning and review gates, and deploy by digest. Avoid allowing developers to push directly to production repositories.<\/p>\n\n\n\n<p>17) <strong>How do lifecycle policies interact with rollback needs?<\/strong><br\/>\nIf policies expire too aggressively, rollback images may disappear. Keep a fixed number of release images per service and test lifecycle rules with previews before applying broadly.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Amazon Elastic Container Registry (Amazon ECR)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Amazon ECR User Guide<\/td>\n<td>Canonical docs for repositories, auth, lifecycle, replication, networking: https:\/\/docs.aws.amazon.com\/AmazonECR\/latest\/userguide\/<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>What is Amazon ECR?<\/td>\n<td>High-level concepts and service overview: https:\/\/docs.aws.amazon.com\/AmazonECR\/latest\/userguide\/what-is-ecr.html<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Amazon ECR Public documentation<\/td>\n<td>Public registry concepts and workflows: https:\/\/docs.aws.amazon.com\/AmazonECRPublic\/latest\/userguide\/what-is-ecr-public.html<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Amazon ECR Pricing<\/td>\n<td>Current pricing dimensions and region-specific pricing: https:\/\/aws.amazon.com\/ecr\/pricing\/<\/td>\n<\/tr>\n<tr>\n<td>Official tool<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Build estimates without guessing: https:\/\/calculator.aws\/#\/<\/td>\n<\/tr>\n<tr>\n<td>Official CLI reference<\/td>\n<td>AWS CLI <code>ecr<\/code> command reference<\/td>\n<td>Exact commands and parameters for automation: https:\/\/docs.aws.amazon.com\/cli\/latest\/reference\/ecr\/<\/td>\n<\/tr>\n<tr>\n<td>Official security<\/td>\n<td>AWS CloudTrail User Guide<\/td>\n<td>How to audit ECR API actions via CloudTrail: https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html<\/td>\n<\/tr>\n<tr>\n<td>Official architecture<\/td>\n<td>AWS Architecture Center \u2013 Containers<\/td>\n<td>Patterns and reference architectures for containers on AWS: https:\/\/aws.amazon.com\/architecture\/containers\/<\/td>\n<\/tr>\n<tr>\n<td>Official containers docs<\/td>\n<td>Amazon ECS Developer Guide<\/td>\n<td>Shows how ECS pulls ECR images and uses roles: https:\/\/docs.aws.amazon.com\/AmazonECS\/latest\/developerguide\/Welcome.html<\/td>\n<\/tr>\n<tr>\n<td>Official containers docs<\/td>\n<td>Amazon EKS User Guide<\/td>\n<td>EKS patterns and IAM integration relevant to pulling images: https:\/\/docs.aws.amazon.com\/eks\/latest\/userguide\/what-is-eks.html<\/td>\n<\/tr>\n<tr>\n<td>Official labs\/tutorials<\/td>\n<td>AWS Workshops (Containers)<\/td>\n<td>Hands-on labs often include ECR usage; pick updated ones: https:\/\/workshops.aws\/<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>AWS YouTube Channel<\/td>\n<td>Service deep-dives and re:Invent sessions (search for \u201cAmazon ECR\u201d): https:\/\/www.youtube.com\/@AmazonWebServices<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams, beginners<\/td>\n<td>CI\/CD, containers, AWS DevOps tooling, registry usage patterns<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students, early-career engineers, DevOps learners<\/td>\n<td>DevOps fundamentals, SCM + CI\/CD practices, container workflows<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams, sysadmins moving to cloud<\/td>\n<td>CloudOps, operations practices, monitoring, AWS operations<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers, ops leads<\/td>\n<td>Reliability, incident response, SLOs, production readiness<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops\/SRE teams adopting automation<\/td>\n<td>AIOps concepts, automation, operational analytics<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify offerings)<\/td>\n<td>Learners seeking trainer-led guidance<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify offerings)<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training platform (verify offerings)<\/td>\n<td>Teams needing short-term help or coaching<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify offerings)<\/td>\n<td>Engineers needing practical troubleshooting help<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact services)<\/td>\n<td>Container platforms, CI\/CD, cloud operations<\/td>\n<td>ECR repo standardization, cross-account distribution model, pipeline hardening<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training<\/td>\n<td>DevOps transformation, CI\/CD, containers<\/td>\n<td>Building secure ECR workflows, implementing lifecycle + scanning gates, multi-account rollout<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify exact services)<\/td>\n<td>Toolchain integration, automation, operations<\/td>\n<td>Migrating from Docker Hub to ECR, implementing VPC endpoints for private pulls, IAM least privilege<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Amazon ECR<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Linux basics (processes, networking, filesystems)<\/li>\n<li>Docker fundamentals:<\/li>\n<li>Dockerfiles, images vs containers, layers, tagging<\/li>\n<li>Build context, multi-stage builds<\/li>\n<li>AWS fundamentals:<\/li>\n<li>IAM users\/roles\/policies, STS<\/li>\n<li>VPC basics (subnets, routing, endpoints, NAT)<\/li>\n<li>CloudTrail basics<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Amazon ECR<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runtime orchestration:<\/li>\n<li>Amazon ECS + Fargate (task definitions, services, deployments)<\/li>\n<li>Amazon EKS (Kubernetes basics, IAM integration, node roles\/IRSA)<\/li>\n<li>CI\/CD on AWS:<\/li>\n<li>CodePipeline, CodeBuild, CodeDeploy or third-party CI with OIDC<\/li>\n<li>Supply-chain security:<\/li>\n<li>Vulnerability management, patch cadence<\/li>\n<li>Signing\/provenance approaches (tooling varies\u2014verify what you adopt)<\/li>\n<li>SBOM generation and policy gates<\/li>\n<li>Governance:<\/li>\n<li>AWS Organizations, SCPs, central logging, policy-as-code<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Cloud Engineer<\/li>\n<li>Security Engineer (container security \/ DevSecOps)<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>Amazon ECR is covered indirectly within broader AWS certifications:\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified DevOps Engineer \u2013 Professional\n&#8211; AWS Certified Security \u2013 Specialty (security controls and auditing concepts)<\/p>\n\n\n\n<p>Check AWS Certification paths here:\n&#8211; https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<p>1) Build a CI pipeline that pushes images to ECR with <code>gitsha<\/code> tags and uses lifecycle policies.\n2) Implement cross-account pull using repository policies (platform account \u2192 workload account).\n3) Add VPC endpoints for ECR and run ECS tasks in private subnets without NAT for image pulls.\n4) Implement image promotion:\n   &#8211; <code>app-dev<\/code> repo \u2192 <code>app-prod<\/code> repo\n   &#8211; digest pinning in ECS\/EKS deployments\n5) Add automated checks:\n   &#8211; scan on push\n   &#8211; block releases when severe vulnerabilities are detected (workflow depends on scanning mode\u2014verify details)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Container image:<\/strong> A packaged filesystem and metadata used to create containers (includes application and dependencies).<\/li>\n<li><strong>Container registry:<\/strong> A service that stores and distributes container images.<\/li>\n<li><strong>Repository (ECR):<\/strong> A logical collection of images under a name (e.g., <code>team\/service<\/code>).<\/li>\n<li><strong>Registry (ECR):<\/strong> The top-level ECR namespace for an AWS account (and Region for private ECR).<\/li>\n<li><strong>Tag:<\/strong> A human-readable label pointing to an image (e.g., <code>v1.0.0<\/code>). Usually mutable unless tag immutability is enabled.<\/li>\n<li><strong>Digest:<\/strong> An immutable cryptographic identifier (e.g., <code>sha256:...<\/code>) for image content.<\/li>\n<li><strong>Lifecycle policy:<\/strong> Rules that automatically expire images to control storage and clutter.<\/li>\n<li><strong>Replication:<\/strong> Automated copying of images to other registries\/regions\/accounts.<\/li>\n<li><strong>Pull-through cache:<\/strong> A caching mechanism that stores images from an upstream registry inside ECR to reduce external dependency.<\/li>\n<li><strong>IAM role:<\/strong> An AWS identity with permissions that can be assumed by services, users, or external identity providers.<\/li>\n<li><strong>Repository policy:<\/strong> A resource-based policy attached to an ECR repository to grant cross-account access.<\/li>\n<li><strong>VPC endpoint:<\/strong> Private connectivity from a VPC to an AWS service without traversing the public internet.<\/li>\n<li><strong>CloudTrail:<\/strong> AWS service that logs API activity for audit and investigation.<\/li>\n<li><strong>NAT Gateway:<\/strong> Network service that allows private subnets outbound internet access; can be a major cost driver for large image pulls.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Amazon Elastic Container Registry (Amazon ECR) is AWS\u2019s managed registry for container images (and related artifacts), tightly integrated with AWS IAM, CloudTrail, and container runtimes like ECS and EKS. It matters because container-based delivery depends on a secure, reliable artifact source\u2014and ECR provides that with lifecycle policies, replication options, scanning capabilities, and private networking integrations.<\/p>\n\n\n\n<p>From an architecture standpoint, ECR fits as the artifact backbone of your container platform: CI pushes versioned images, production pulls immutable digests, and platform\/security teams enforce governance through policies, scanning, and audit logs.<\/p>\n\n\n\n<p>Cost-wise, the biggest drivers are stored GB-month, data transfer (especially via NAT), replication overhead, and scanning at scale. Security-wise, the biggest wins come from least-privilege IAM, repository policies for cross-account sharing, tag immutability, digest-based deployments, encryption controls, and CloudTrail auditing.<\/p>\n\n\n\n<p>Use Amazon ECR when you want AWS-native container artifact management with strong security and operational controls. Next step: integrate ECR into a full delivery workflow\u2014CI build\/push, vulnerability scanning gates, and ECS\/EKS deployments pinned by digest\u2014then harden it with multi-account governance and private networking.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Containers<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,27],"tags":[],"class_list":["post-176","post","type-post","status-publish","format-standard","hentry","category-aws","category-containers"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/176","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=176"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/176\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=176"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=176"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=176"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}