New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[request]: Cross Region Routing #97
Comments
Hello guys, We currently have the same need for cross-region routing as we have a set of services distributed across the world with a set of core services running only in a single region. @lewislabs - I've noticed that you mentioned that you worked around this problem with VPC Peering and a custom service discovery? Would you be able to give me more details (either on this thread or privately?) We are considering Consul as an alternative but I would much rather stick to AWS. Thx, |
@lewislabs and @isaac-mj would a Managed Ingress (#37) get you far enough? This would allow you to have multiple meshes in distinct regions, while still having your core mesh that others could talk to via its ingress. In my mind, cross-region routing needs to at least get to the point where a single logical service can be deployed in multiple regions and, via Envoy, the shortest-cost (which tends to be both latency and $$$-wise :-p) endpoints are used for routing. This (to me) sounds more powerful than what you actually need to accomplish your goal. |
@lewislabs Can you please tell us more about the custom service discovery routing - what exactly does it do? |
@dastbe I think managed ingress could solve the problem, but maybe I need some more clarity on what managed ingress looks like. The problem we have is can be described by this simple example.
I believe we could quite easily achieve the above with inter-region VPC peering + Managed Ingress? But now if we deployed instances of Service B into the mesh in us-east-1. Would there be a way for traffic to preference sticking within the same region where it can or is this something that's going to require additional custom configuration? |
When I say custom service discovery that's probably the wrong term. We run an instance of eureka and have custom libraries built around that to do routing based on the eureka service repository. |
Yes, that is our recommended approach. We are researching on how to support the ingress use case (#37). Since both AWS Cloud Map and AWS App Mesh are regional services, the service discovery and app mesh routing will keep traffic within the region. Further, we are investigating how to enable the AZ aware routing use case (#94). |
@shubharao sounds like both #37 and #94 could solve the problem. Thanks! |
Tell us about your request
Support for cross region routing with AppMesh.
Which integration(s) is this request for?
All ideally but ECS, EC2 and Fargate would be the priority for me.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We have services that run in a number of AWS regions (and accounts) and would like to be able to use AppMesh to connect these services and manage routing through a single control plane.
A service runs in a particular region because it's been latency optimized for a specific set of users but we also run some core shared microservices in another region that are dependencies. We can replicate these core services across regions but there's a significant overhead there (including database replication) that we would like to avoid.
Are you currently working around this issue?
VPC Peering and using custom service discovery routing (not using AppMesh)
Additional context
Anything else we should know?
Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
The text was updated successfully, but these errors were encountered: