ECR Repository Policy

Amazon Elastic Container Registry – ECR

~ Last updated on : ~ jayendrapatil ~ 1 Comment

Elastic Container Registry – ECR

  • Amazon Elastic Container Registry – ECR is a fully managed, secure, scalable, reliable container image registry service.
  • makes it easy for developers to share and deploy container images and artifacts.
  • is integrated with ECS, EKS, Fargate, and Lambda, simplifying the development to production workflow.
  • eliminates the need to operate your own container repositories or worry about scaling the underlying infrastructure.
  • hosts the images, using S3, in a highly available and scalable architecture, allowing you to deploy containers for the applications reliably.
  • is a Regional service with the ability to push/pull images to the same AWS Region. Images can be pulled between Regions or out to the internet with additional latency and data transfer costs.
  • supports cross-region and cross-account image replication.
  • integrates with AWS IAM and supports resource-based permissions.
  • supports public and private repositories.
  • automatically encrypts images at rest using S3 server-side encryption or AWS KMS encryption and transfers the container images over HTTPS.
  • supports tools and docker CLI to push, pull and manage Docker images, Open Container Initiative (OCI) images, and OCI-compatible artifacts.
  • supports OCI Image and Distribution specification version 1.1, which includes support for Reference Types (referrers) for storing and discovering artifacts related to a container image such as signatures, SBOMs, and attestations.
  • provides two types of image scanning: basic scanning (AWS native, for OS vulnerabilities) and enhanced scanning (Amazon Inspector integration, for OS and programming language vulnerabilities).
  • supports ECR Lifecycle policies that help with managing the lifecycle of the images in the repositories, including expiring and archiving images.
  • supports managed container image signing using AWS Signer to automatically sign images on push.
  • supports pull through cache to automatically sync container images from upstream registries.
  • supports automatic repository creation on image push.
  • supports cross-repository layer sharing (blob mounting) to optimize storage and improve push performance.

Elastic Container Registry - ECR

ECR Components

  • Registry
    • ECR private registry hosts the container images in a highly available and scalable architecture.
    • A default ECR private registry is provided to each AWS account.
    • One or more repositories can be created in the registry and images stored in them.
    • Repositories can be configured for either cross-Region or cross-account replication.
    • Private Registry is enabled for basic scanning, by default.
    • Enhanced scanning can be enabled which provides an automated, continuous scanning mode that scans for both operating system and programming language package vulnerabilities.
    • Registry supports up to 100,000 repositories per Region per account (increased from 10,000 in Nov 2024).
  • Repository
    • An ECR repository contains Docker images, Open Container Initiative (OCI) images, and OCI compatible artifacts.
    • Repositories can be controlled with both user access policies and individual repository policies.
    • Each repository supports up to 100,000 images (increased from 20,000 in Aug 2025).
    • Repositories can be automatically created on image push using repository creation templates.
  • Image
    • Images can be pushed and pulled to the repositories.
    • Images can be used locally on the development system, or in ECS task definitions and EKS pod specifications.
    • Images support two storage classes: standard and archive (for rarely accessed images).
  • Repository policy
    • Repository policies are resource-based policies that can help control access to the repositories and the images within them.
    • Repository policies are a subset of IAM policies that are scoped for, and specifically used for, controlling access to individual ECR repositories.
    • A user or role only needs to be allowed permission for an action through either a repository policy or an IAM policy but not both for the action to be allowed.
    • Resource-based policies also help grant the usage permission to other accounts on a per-resource basis.
  • Authorization token
    • A client must authenticate to the registries as an AWS user before they can push and pull images.
    • An authentication token is used to access any ECR registry that the IAM principal has access to and is valid for 12 hours.
    • Authorization token’s permission scope matches that of the IAM principal used to retrieve the authentication token.

ECR Image Scanning

  • ECR provides two scanning modes: Basic Scanning and Enhanced Scanning.
  • Basic Scanning
    • Uses AWS native scanning engine (Clair-based scanning was deprecated as of February 2, 2026).
    • Scans for operating system vulnerabilities.
    • Enabled by default for all private registries.
    • Supports scan on push or manual scanning.
    • Scanning configuration is managed at the registry level (repository-level PutImageScanningConfiguration API is deprecated).
  • Enhanced Scanning
    • Powered by Amazon Inspector integration.
    • Provides automated, continuous scanning for both OS and programming language package vulnerabilities.
    • Re-evaluates images whenever new vulnerabilities are published, not just at push time.
    • Maps ECR images to running containers in ECS tasks and EKS pods to help prioritize vulnerabilities.
    • Supports minimal and security-focused container base images.
    • Now surfaces image use status to identify which images are actively running.

ECR Managed Signing

  • ECR supports managed container image signing (launched Nov 2025) to verify that images are from trusted sources.
  • Managed signing automatically signs container images using AWS Signer when images are pushed to ECR.
  • Eliminates the need to install and configure client-side signing tools.
  • Allows centralized governance of signing as a registry configuration.
  • Signatures are stored as OCI referrers in the same repository as the image.
  • Manual signing using Notation CLI with AWS Signer is also supported for client-side workflows.

ECR Pull Through Cache

  • Pull through cache automatically syncs container images from supported upstream registries into ECR private registry.
  • Provides reduced latency of in-region image pulls with built-in ECR security features (lifecycle policies, enhanced scanning).
  • Supports multiple upstream registries including Docker Hub, GitHub Container Registry, Quay, ECR Public, Azure Container Registry, GitLab, Chainguard, and other ECR private registries.
  • ECR to ECR pull through cache (launched Mar 2025) allows syncing images between ECR registries cross-region and cross-account in a cost-effective way by caching only images that are pulled.
  • Automatically creates repositories in the downstream registry for cached images.
  • Supports frequent syncs with upstream to keep cached images up to date (at least once every 24 hours).
  • Now supports automatic discovery and sync of OCI referrers (signatures, SBOMs, attestations) from upstream registries (Apr 2026).

ECR Repository Creation on Push

  • ECR supports automatic repository creation on image push (launched Dec 2025).
  • Simplifies container workflows by automatically creating repositories if they don’t exist when an image is pushed.
  • Eliminates the need to pre-create repositories before pushing container images.
  • New repositories are created according to defined repository creation template settings.
  • Repository creation templates allow configuring encryption, lifecycle policies, access permissions, and tag immutability for automatically created repositories.

ECR Cross-Repository Layer Sharing (Blob Mounting)

  • ECR supports cross-repository layer sharing through blob mounting (launched Jan 2026).
  • Allows sharing common image layers across repositories within a registry.
  • Especially valuable for managing multiple microservices or applications built from common base images.
  • Reduces storage costs by deduplicating common layers.
  • Improves push performance by avoiding re-uploading layers that already exist in the registry.
  • When enabled, ECR automatically checks for existing layers in the registry during push operations.

ECR Archive Storage Class

  • ECR supports an archive storage class for rarely accessed container images (launched Nov 2025).
  • Images can be archived based on criteria such as image age, count, or last pull time via lifecycle policies.
  • Images can also be archived individually using the ECR Console or API.
  • Archived images do not count against the image per repository limit.
  • An unlimited number of images can be archived.
  • Archived images are not accessible for pulls but can be restored via Console, CLI, or API within 20 minutes.
  • A 90-day minimum storage duration applies for archived images.
  • Lifecycle policies cannot delete images archived for less than 90 days.

ECR Lifecycle Policies

  • Lifecycle policies help manage the lifecycle of images in repositories.
  • Define rules to automatically expire or archive unused images based on criteria such as image age, image count, or last pull time.
  • Support tag pattern matching (e.g., prod*) to target specific images.
  • Affected images are expired or archived within 24 hours of policy creation.
  • Support referring artifacts – references are deleted when a subject image is deleted by a lifecycle policy rule.
  • Preview rules to see exactly which container images are affected before the rule runs.

ECR CloudWatch Metrics

  • ECR metric data is automatically sent to CloudWatch in one-minute periods.
  • Supports repository-level metrics including image pull counts.
  • New metrics (Feb 2026): RepositoryCount and ImagesPerRepositoryCount help identify growth trends and monitor usage patterns.
  • Can be used to set up alarms for anomalous behavior in image storage growth.

ECR with VPC Endpoints

  • ECR can be configured to use an Interface VPC endpoint, that enables you to privately access Amazon ECR APIs through private IP addresses.
  • AWS PrivateLink restricts all network traffic between the VPC and ECR to the Amazon network. You don’t need an internet gateway, a NAT device, or a virtual private gateway.
  • VPC endpoints currently don’t support cross-Region requests.
  • VPC endpoints currently don’t support ECR Public repositories.
  • VPC endpoints only support AWS provided DNS through Route 53.

ECR Security Best Practices

  • Use enhanced scanning with Amazon Inspector for continuous vulnerability monitoring.
  • Enable managed image signing to verify image provenance and integrity.
  • Use lifecycle policies to automatically clean up or archive unused images.
  • Configure VPC endpoints to keep ECR traffic on the AWS private network.
  • Use repository policies with least-privilege access.
  • Enable tag immutability to prevent image tags from being overwritten.
  • Use KMS encryption for sensitive container images.
  • Use pull through cache to avoid direct dependencies on external registries.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is using Amazon Elastic Container Service (Amazon ECS) to run its container-based application on AWS. The company needs to ensure that the container images contain no severe vulnerabilities. Which solution will meet these requirements with the LEAST management overhead?
    1. Pull images from the public container registry. Publish the images to Amazon ECR repositories with scan on push configured.
    2. Pull images from the public container registry. Publish the images to a private container registry hosted on Amazon EC2 instances. Deploy host-based container scanning tools to EC2 instances that run ECS.
    3. Pull images from the public container registry. Publish the images to Amazon ECR repositories with scan on push configured.
    4. Pull images from the public container registry. Publish the images to AWS CodeArtifact repositories in a centralized AWS account.
  2. A company wants to ensure that only signed and verified container images are deployed to their Amazon EKS clusters. They want minimal operational overhead for the signing process. Which approach should they use?
    1. Use a third-party signing tool integrated with their CI/CD pipeline.
    2. Enable ECR managed signing with AWS Signer on their ECR repositories.
    3. Manually sign images using Notation CLI before pushing to ECR.
    4. Use AWS Lambda to sign images after they are pushed to ECR.
  3. A company manages hundreds of microservices using Amazon ECS and stores container images in Amazon ECR. They want to reduce storage costs for images that share common base layers across multiple repositories. Which ECR feature should they enable?
    1. ECR image replication
    2. ECR lifecycle policies
    3. ECR cross-repository layer sharing (blob mounting)
    4. ECR pull through cache
  4. A development team wants to avoid pre-creating ECR repositories for every new microservice. They want repositories to be automatically created with consistent settings when images are pushed. What should they configure?
    1. An AWS Lambda function triggered by CloudTrail events.
    2. An AWS Config rule to auto-remediate missing repositories.
    3. ECR repository creation templates with create-on-push enabled.
    4. An AWS CloudFormation stack with dynamic resource creation.
  5. A company has container images in ECR that are only needed for compliance audits and are rarely pulled. They want to reduce storage costs while keeping the images available if needed. Which ECR feature should they use?
    1. ECR lifecycle policies to delete old images
    2. Move images to S3 Glacier manually
    3. ECR archive storage class
    4. ECR cross-region replication to a cheaper region
  6. A company uses multiple third-party container registries (Docker Hub, GitHub Container Registry) and wants to reduce latency and improve security when pulling images. Which ECR feature should they implement?
    1. ECR cross-region replication
    2. ECR pull through cache with upstream registry rules
    3. ECR public repositories
    4. ECR lifecycle policies
  7. An organization wants continuous vulnerability scanning of their container images that also identifies which vulnerable images are actively running in their ECS and EKS environments. Which scanning configuration should they use?
    1. ECR basic scanning with scan on push
    2. Third-party vulnerability scanner integrated with CI/CD
    3. ECR enhanced scanning with Amazon Inspector
    4. AWS Config rules for container compliance

References

AWS Resource-based Policies

~ Last updated on : ~ jayendrapatil

AWS Resource-based Policies

  • Resource-based policies allow attaching a policy directly to the resource you want to share, instead of using a role as a proxy.
  • Resource-based policies allow granting usage permission to other AWS accounts or organizations on a per-resource basis.
  • Resource-based policy specifies the Principal, in the form of a list of AWS account ID numbers, can access that resource and what they can access.
  • Using cross-account access with a resource-based policy, the User still works in the trusted account and does not have to give up their permissions in place of the role permissions.
  • Users can work on the resources from both accounts at the same time and this can be useful for scenarios e.g. copying objects from one bucket to the other bucket in a different AWS account.
  • Resources that you want to share are limited to resources that support resource-based policies
  • Resource-based policies need the trusted account to create users with permissions to be able to access the resources from the trusted account.
  • Only permissions equivalent to, or less than, the permissions granted to the account by the resource owning account can be delegated.

S3 Bucket Policy

  • S3 Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
  • Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address).
  • Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner
  • Policies can either add or deny permissions across all (or a subset) of objects within a bucket
  • Only the bucket owner is allowed to associate a policy with a bucket
  • Bucket policies can cater to multiple use cases
    • Granting permissions to multiple accounts with added conditions
    • Granting read-only permission to an anonymous user
    • Limiting access to specific IP addresses
    • Restricting access to a specific HTTP referer
    • Restricting access to a specific HTTP header for e.g. to enforce encryption
    • Granting permission to a CloudFront OAI
    • Adding a bucket policy to require MFA
    • Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
    • Granting permissions for S3 inventory and Amazon S3 analytics
    • Granting permissions for S3 Storage Lens

Glacier Vault Policy

  • S3 Glacier vault access policy is a resource-based policy that can be used to manage permissions to the vault.
  • A Vault Lock policy is a Vault Access policy that can be locked. After you lock a Vault Lock policy, the policy can’t be changed. You can use a Vault Lock Policy to enforce compliance controls.

KMS Key Policy

  • KMS Key Policy helps determine who can use and manage those keys and is a primary mechanism for controlling access to a key.
  • KMS Key Policy can be used alone to control access to the keys.
  • A KMS key policy MUST be used, either alone or in combination with IAM policies or grants to allow access to a KMS CMK.
  • IAM policies by themselves are not sufficient to allow access to keys, though they can be used in combination with a key policy.
  • IAM user who creates a KMS key is not considered to be the key owner and they don’t automatically have permission to use or manage the KMS key that they created.

API Gateway Resource Policy

  • API Gateway resource policies are attached to an API to control whether a specified principal (typically an IAM role or group) can invoke the API.
  • API Gateway resource policies can be used to allow the API to be securely invoked by:
    • Users from a specified AWS account.
    • Specified source IP address ranges or CIDR blocks.
    • Specified virtual private clouds (VPCs) or VPC endpoints (in any account).
  • Resource policies can be used for all API endpoint types in API Gateway: private, edge-optimized, and Regional.

Lambda Function Policy

  • Lambda supports resource-based permissions policies for Lambda functions and layers.
  • Resource-based policy can be used to allow an AWS service to invoke the function on your behalf.
  • Resource-based policies apply to a single function, version, alias, or layer version.

EFS File System Policy

  • EFS supports IAM resource policy using file system policy.
  • EFS evaluates file system policy, along with any identity-based IAM policies to determine the appropriate file system access permissions to grant.
  • An “allow” permission on an action in either an IAM identity policy or a file system resource policy allows access for that action.

ECR Repository policy

    • Repository policies are resource-based policies that can help control access to the repositories and the images within them.
    • Repository policies are a subset of IAM policies that are scoped for, and specifically used for, controlling access to individual ECR repositories.
    • A user or role only needs to be allowed permission for an action through either a repository policy or an IAM policy but not both for the action to be allowed.
    • Resource-based policies also help grant the usage permission to other accounts on a per-resource basis.

SNS Policy

  • SNS policy can be used with a particular topic to restrict who can work with that topic e.g, who can publish messages to it, subscribe to it, etc.
  • SNS policies can grant access to other AWS accounts, or to users within your own AWS account.

SQS Policy

  • SQS policy system lets you grant permission to other AWS Accounts, whereas IAM doesn’t.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References