[ECR] [request]: ECR to ECR pull-through cache

[wosiu]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
ECR launched pull through cache for some docker registries including: ECR Public, Quay.io and recently dockerhub and few more which require authentication. Customers also want the same functionality for another private ECR:

Other people were already mentioning this need in some other ticket that was recently closed without addressing these:
#1584 (comment)
#1584 (comment)

Which service(s) is this request for?
ECR

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Ability to have a regional pull-through cache for docker images stored in an ECR in another aws region.
This is for:

1. Reliability - to not rely on an ECR in a single region for tens of environments across the whole world. Imagine the central ECR is down - we cannot scale workloads, because docker images cannot be downloaded.
2. Cost savings - currently each node needs to fetch an image from central region which causes cross-region transfer = costs + latency. The worst part is where this traffic goes through NAT Gateways (private subnets).
3. Simplify security/compliance - scan images only in a central region.

Why not ECR cross-region replication (a.k.a. mirroring) then?

Well, because we don't want to mirror all the docker images produced by our CI system to every region, but only the ones that are actually used. Only ~10% of images we build are eventually deployed on production environments.

Why not implementing "push" model on a CI level then?

Well, it would vastly complicate the deployment process, harder to deploy outside automations, harder to setup retention policies.

Pull-through cache is ideal approach for this. We can have shorter retention policies for images in regional pull-though cache ECRs. If image is kicked out, it can be refetched again if needed from the central region where longer retention policy is applied.

Are you currently working around this issue?
Some alternatives are competitors like GCR, or jFrog Artifactory with jFrog Edge (which doesn't integrate with AWS as nicely as ECR). Or deploy self-managed tools in EKS (like Harbor), which requires additional work to setup and maintenance. Or enable some extra Admission Control in EKS like k8s-image-swapper, but this doesn't currently work nice with signed images.

Additional context
There were many votes already for this feature in the past as a part of: #1584 (including mine), but this one was closed after pull-through cache for authenticated registries was added - which is a separate thing.

[wosiu]

Bonos point: ECR pull-through pointing to another ECR pull-through:

Why?

1. simplification of the setup
2. compliance. To have a single gate with vulnerability scanner enabled.

JFrog Artifactory is capable of doing this BTW.

[mwos-sl]

@rnene100 is there already some ETA for this one?

[rnene100]

This is under-consideration and we are working through understanding the scoping and effort for this. We aren't able to provide an ETA at this time. Thank you for your patience!

[Josephineci]

Does this issues fall in line with pulling a cache ECR image from one AWS ECR registry account and caching it to a different AWS ECR registry account? @wosiu @mwos-sl

[wosiu]

Yes

…

On Tue, Apr 30, 2024, 09:23 Josephine C. ***@***.***> wrote: Does this issues fall in line with pulling a cache ECR image from one AWS ECR registry account and caching it to a different AWS ECR registry account? @wosiu <https://github.com/wosiu> @mwos-sl <https://github.com/mwos-sl> — Reply to this email directly, view it on GitHub <#2208 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABF4AJHDDCZE7ZQYPZPXNR3Y75BF5AVCNFSM6AAAAAA7TQL6FSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBUGU3TKMBTGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>