Containers-roadmap: [ECR] [request]: Multi-region endpoints for ECR registries

[rpnguyen]

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
To combine multiple regional registries to form a single "virtual" registry, automatically doing failover and performance-aware routing.

# routes to us-east-1 or ap-southeast-2 depending on what's available and where I'm calling from
docker pull organization-name.ecr.amazonaws.com/repo 

This should work even if I use different accounts for different regions.

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?
Disaster recovery automation. Speeding up registry access.

Are you currently working around this issue?
Tooling to get orchestrators to point to a different regional registry in case of disaster.

[rpnguyen]

Copying over some input previously gathered in #140. Keep the ideas coming and please 👍 this issue to help with prioritization.

I think the best option for me would be if I could choose to not have region on the ECR address and Amazon would load the nearest available from a static link. Like putting Cloudfront in front of ECR. I wonder if that's possible without making my images public. @deleugpn

My need for multi Region Replication is mainly for Disaster Recovery. Ideally we would remove the region from the registry URL and let ECR figure out the best way to serve the request. @pmontanari

A single global name to represent a repository would be ideal and let ECR figure out the best location to serve the image up from. Most of our traffic is from ECR to ECS, but this would simplify configuration but (hopefully) still add a bit of resiliencey in the event of a regional ECR outage. @jlambert121

Having ECR figure out the best way to serve the request would be ideal in active-active architectures, where if one ECR region goes down, ECR can simply figure out where to pull from. DNS control would also be nice in this scenario, but I'm not sure both are possible at the same time. @rdpa

A generic endpoint that is globally distributed and points to nearest AWS owned POP/region. @ajohnstone

Removing the region from the DNS is a must for us as we use a single ECR for all images. I do not know if that would be possible be removing the account from the DNS would be nice as user do not care about which account it sits in. @mbelang

If AWS handled this decision for us and resolved url based on response time or something similar that would also be a huge improvement for DR. This would allow our services in us-east-2 to automatically pull images from us-west-2 if ECR in us-east-2 was experiencing issues, for example. Which today would be a manual change. @bminahan73

I would love to get rid of both the account ID and the region in the image URLs. We want to use the same images in multiple regions and/or accounts, and I don't want to have K8s Deployments for each differing only in the image URL. @MartinEmrich

The single-account, single-region design of ECR is just a pain in the ass. I think most of us would really appreciate a singular registry endpoint, with some settings on which accounts/regions you would like replication for, and not have all this complexity unnecessarily exposed.
I thought org.ecr.amazonaws.com or ecr.amazonaws.com/org/ were nice suggestions. Coping with different registry endpoints involves retagging container images a lot, lots of shuffling bytes around. @michielvermeir

A single ECR image without region specified and ECR team can take care of the traffic or Image Duplication in different regions. @PatrickXYS

[deleugpn]

Since a lot of feedback (myself included) is around having a single entrypoint handled by AWS, I would explicitly mention that for my particular use case I could help Amazon save some costs by specifying which AWS regions ECS will be used upfront so that you don't have to blindly replicate it to all regions