To secure an Amazon ECR registry, turn on tag immutability, choose the scanning type that matches your risk, limit who can push and pull with narrow IAM permissions, set lifecycle rules that never delete what production runs, and make scan findings block or open a ticket instead of sitting in a console.
What does AWS secure and what is left to you?
The ECR security chapter states the shared responsibility model: AWS secures the infrastructure that runs the service, and you are responsible for the sensitivity of your data, your company's requirements and applicable laws. The chapter's topics are identity and access management, data protection, compliance validation, infrastructure security and cross service confused deputy prevention. Your settings sit in the first two and in the repository options below.
Why make tags immutable?
The ECR user guide explains that when tag immutability is on, pushing an image with a tag that already exists returns an ImageTagAlreadyExistsException. It affects all tags in the repository. The console also offers a mutable option with tag exclusions, where you list tag names or wildcards that stay mutable, and the guide recommends the mutable setting for repositories that use pull through cache so ECR can update cached images.
Take a constructed incident. A pipeline pushes payments:prod on every release. An engineer pushes a debug build under the same tag, and nodes that restart pull the debug image. With immutable tags the second push fails, and your deploy refers to version tags or digests that cannot change under it.
Deploy by digest where you can. A digest names exact content.
Which scanning type should you pick?
ECR offers two types. Basic scanning uses AWS native technology with the CVE database to scan for operating system vulnerabilities, on push or manually. Enhanced scanning integrates with Amazon Inspector for automated, continuous scanning, covering both operating system and programming language package vulnerabilities, with scan on push and continuous scan. As new vulnerabilities appear, results update and an event goes to EventBridge.
Two notes from the guide. Switching between the types makes previously established scans unavailable until you switch back. And archived images cannot be scanned, so restore them first.
For a team shipping Python or Node services, language packages are where most findings sit, which favors the enhanced type. A basic scan that only reads the OS layer gives a false sense of safety.
How should lifecycle rules be set?
Lifecycle policies use rules with a priority, a selection by tag status (tagged, untagged or any), a count type such as images more than a number or since image pushed, and an action. Storage class can be standard or archive.
The risk is the rule that expires an image that production still runs. Write rules that keep the newest release tags per repository and expire only untagged images or old build tags, and test the policy preview before applying it.
What about access?
Use separate roles for pushing from CI, pulling from nodes and administering the registry. CI gets push to named repositories only. Nodes get pull. People rarely need either. The confused deputy chapter exists because services acting on your behalf can be tricked into acting for someone else, so read that chapter before granting another AWS service access to your repositories.
How to check or apply this
- Turn on tag immutability for every production repository and list any exceptions with reasons.
- Reference images by digest in deployment manifests.
- Enable enhanced scanning on repositories with language dependencies, and basic scanning where only the OS layer matters.
- Send scan events to a queue that opens tickets or blocks promotion.
- Review lifecycle policies in preview and check none can remove an image in use.
- Split roles for push, pull and administration, and review them quarterly.
- Keep an inventory of the components inside each image so a new CVE can be matched in minutes.
Quick check
Do immutable tags stop a bad image from being deployed?
No. It stops an existing tag from being overwritten. You still need scanning, review and digest based deploys.
Will scanning on push catch vulnerabilities published next week?
Basic scan on push checks at push time. Enhanced scanning offers continuous scanning, which updates results as new vulnerabilities appear.
Sources
- Amazon ECR User Guide, Security in Amazon ECR
- Amazon ECR User Guide, Image tag mutability
- Amazon ECR User Guide, Image scanning
- Amazon ECR User Guide, Lifecycle policy examples
Last reviewed: 18 October 2026.
