You’re probably storing duplicate container layers across many ECR repos. And you’re re-uploading those unchanged layers on every single push.
Amazon ECR now lets you share layers across repos with blob mounting. Push once, and reuse everywhere across your services and environments. Teams report up to 70 percent faster pushes in real tests. And up to 50 percent lower storage for multi-repo setups when services share common runtimes.
Highlights
- Blob mounting in ECR reuses layers across repos in the same registry and region.
- It works with Docker and BuildKit, with no Dockerfile changes required.
- It integrates with ECS, EKS, and Lambda, with no runtime changes.
- Keep repos separate, while still sharing the same common base layers.
- Verify via push logs, layer digests, and repository storage metrics.
Why it helps
- Many services share the same base OS and language runtime. But they push them repeatedly into separate repos, wasting time and storage.
- Blob mounting lets the target repo reference a layer already in the source repo. No re-uploading needed at all during the push process, really.
- Think of it like a registry-side link for identical, content-addressed layers.
Setup basics
- Use the same account registry and region for source and target repos.
- Create a dedicated base repo for common shared runtimes today. For example, ecr-base/runtime and service repos like services/orders too.
- Ensure IAM permissions cover reading from the base repo and writing to service repos. Typical actions: ecr:BatchCheckLayerAvailability, ecr:InitiateLayerUpload, ecr:UploadLayerPart, ecr:CompleteLayerUpload, ecr:PutImage, ecr:BatchGetImage, ecr:GetAuthorizationToken.
- Modern Docker and BuildKit will automatically attempt cross-repo mounts when pushing if the content digest matches.
Workflow impact
- Push once, reuse everywhere: service repos mount base layers instead of uploading them again.
- Faster CI and less flaky uploads because fewer large blobs are transmitted.
- Lower storage because identical bytes are no longer duplicated across repos.
How to roll out quickly
1) Create a base repository and push a hardened runtime image. Then record the digest for that image in your notes.
2) In service Dockerfiles, use FROM with the base image pinned by digest.
3) Push each service image to its own repo for isolation.
4) Verify pushes show mounted or reused layers and that service repo storage does not balloon.
Verification tips
- Inspect docker push output carefully for mounted or reused layer messages.
- Compare layer digests across repos to confirm layers are actually shared.
- Watch ECR repository size metrics; base-layer bytes should accumulate in the base repo, not the service repos.
- Keep base layers stable and versioned; pin OS packages and runtimes.
- Use multi-stage builds to separate heavy builder layers and the runtime.
- Order Dockerfile steps to keep heavy layers unchanged when app code changes.
Mounting may not occur
- Base drift from tag updates happens; prefer digest pinning for stability.
- Permissions can prevent reading from the source repo, blocking mounts.
- Source and target are in different regions or different registries.
- Very old clients that do not issue cross-repo mount hints.
Scope and limits
- Mounting only occurs within the same ECR registry and region.
- Cross-account scenarios may fall back to uploads even with pull access.
- Pull behavior for ECS, EKS, and Lambda is unchanged.
Measuring impact
- Baseline push durations and ECR storage before rollout, then compare after.
- Expect pushes dominated by small app layer deltas rather than large base layers.
Security and compliance
- ECR scanning, encryption, repository immutability, and signatures behave the same.
- Signatures tied to image digests remain valid across repos when layers are shared.
Quick start playbook
1) Create a dedicated base repo for your common runtimes first.
2) Push the base image once, and record its digest for reference.
3) Pin all service Dockerfiles to that base digest for consistency.
4) Push services, then check push logs for mounted or reused layers.
5) Monitor repository sizes and costs; expand the pattern across services.
Bottom line
Blob mounting in ECR is a standards-based, low-friction way to speed up pushes and cut storage. Start with one shared base, pin by digest, and let the registry reuse identical layers across your repos.