ECR (Elastic Container Registry)

Amazon Elastic Container Registry (ECR) is AWS’s managed registry for container images. It stores Docker and OCI images and OCI-compatible artefacts, authenticates through IAM, and works with the standard docker and crane tooling. Amazon ECS, Amazon EKS, AWS Batch and Lambda container images all pull from it.

Storing images is the least interesting thing it does. The features below are what make it a supply-chain control point rather than a bucket with a Docker API in front.

Private and public registries

Every account gets one private registry per Region, holding repositories with resource-based policies. Amazon ECR Public is a separate service for images you want the world to pull, backed by the ECR Public Gallery.

Authenticate with a token from IAM:

aws ecr get-login-password --region eu-west-2 \
  | docker login --username AWS --password-stdin \
    <account-id>.dkr.ecr.eu-west-2.amazonaws.com

Tag immutability

A repository can be configured so that a tag, once pushed, cannot be moved to a different image. Turn this on. Without it, myapp:1.4.2 is a mutable pointer, which means a deployment is not reproducible, a rollback may not roll back, and an image that passed a scan can be replaced by one that did not.

With immutable tags, deployments reference either an immutable tag or the image digest (myapp@sha256:...), and the digest is what belongs in a task definition or manifest for anything that must be exactly reproducible.

Vulnerability scanning

Two modes:

• Basic scanning matches package versions against the Common Vulnerabilities and Exposures database for the operating system layers. It can run on push, or on demand.
• Enhanced scanning, powered by Amazon Inspector, continuously rescans images already in the registry as new vulnerabilities are published, and covers application-language package dependencies as well as OS packages.

Enhanced scanning is the one that matters operationally: a critical vulnerability disclosed a month after an image was built does not announce itself on push. Wire the findings into a pipeline gate and into alerting, or the scan results are just a list nobody reads.

Lifecycle policies

Registries fill up with images nobody will pull again, and you pay per gigabyte-month for all of them. A lifecycle policy expires images by age or count against tag-status rules — for example, keep the last 30 images tagged prod, expire untagged images after 7 days. Policies can be evaluated in preview mode against the current repository contents before being applied, which is worth doing: a mistaken rule deletes the image a rollback needs.

Pull through cache

A pull through cache rule mirrors an upstream public registry — Docker Hub, Amazon ECR Public, Quay, GitHub Container Registry, Kubernetes registries — into your private registry on first pull, and keeps the cached copy current.

This solves three problems at once: builds and deployments stop depending on a third-party registry’s availability, upstream rate limits stop breaking pipelines, and every image that enters the estate passes through your own scanning and policy.

Replication and repository creation templates

Registry-level replication copies images to other Regions and other accounts automatically, which is how you avoid a cross-Region pull on every task launch in a multi-Region deployment.

Repository creation templates define the settings ECR applies to repositories it creates on your behalf — during a pull through cache, a create-on-push, or a replication action — so tag immutability, encryption, repository policy, lifecycle policy and tags are correct on repositories nobody explicitly created.

Cross-account access

Two mechanisms, and the difference matters:

• Repository policy on the ECR side grants another account or principal permission to pull (or push).
• IAM policy in the consuming account grants its principals permission to make the call.

Both must allow the action. A cross-account pull that fails with an authorization error is almost always missing one of the two. For a shared-services registry, put the repository policy on the registry account and grant the workload accounts’ task execution roles the matching permissions.

Encryption and signing

Images are encrypted at rest by default with an AWS managed key; a repository can instead use a customer managed KMS key where key control or key rotation policy is a requirement. Managed signing generates cryptographic signatures when images are pushed, which is the foundation for verifying at deploy time that an image came from your pipeline.

Cost

You pay for stored data, for data transfer out on pulls, and for opt-in actions such as signing and replication. The two levers that actually move the bill are a lifecycle policy that expires dead images and replication that is scoped to the Regions you deploy in rather than all of them.