Using AWS edge services to migrate some of our services to improve latency, some questions on how to go about it.

There's a lot of detail required to answer this question so the majority of the answers are "it depends" and even with that detail provided, the answers might still be "it depends".

For example, you don't say how the clients consume the data which is produced. Is it a private network? Do you require the data to be distributed in such a way that any client can access any data at low latency? What size is the data? What type of data is it? I could go on but you get the idea - this isn't an easy question to answer and I'd strongly recommend that you get in touch with your local AWS Solutions Architect to have a conversation about this because anything provided here is not going to provide nearly enough detail.

To answer your specifics questions:

1. Yes, but it depends. First I'd look at a number of blog post that we have about this (search for "multi region"). Some examples: one, two and three for starters but there are many more.
2. Because it's not clear where the clients are I've assumed in (1) that they are accessing services via public networks. But private networks work in many cases too (noting that CloudFront is a CDN that is internet-based and isn't applicable to private networks). You can do some level of latency-based routing in private networks using Route 53.
3. YouTube (particularly re:Invent presentations) will be helpful as will blog posts. But it's difficult to recommend specific content without understanding what you are intending to do in more details. Ref: My comment above about having a conversation with your AWS Solutions Architect.
4. Yes.
5. I'm not sure what you mean by this. Can you use a mix of services where some are local to the client and some are remote? Yes - absolutely; at the end of the day it's just networking. Only you (with feedback from your customer) can say whether that is acceptable in terms of latency or not.

Bear in mind that with all things there are tradeoffs and compromises. Large-scale (and even small-scale) multi-region distributed systems are difficult to build and maintain - so while there may be large benefits to the end-user you have to consider how the system will operate and also how it will fail in order to determine whether the cost of building it will be worth it.

Hi,

Edge functions have some known limitations: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-function-restrictions-all.html

Before going there, did you already think about a standard multi-region replication of your application ?

• Route53 geo-based routing will allow you to use the closest region to your user. See https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html
• DDB global database will simplify data management around data inconsistencies due to replication. https://aws.amazon.com/dynamodb/global-tables/

Going on this path will allow you to enjoy full functionality of AWS services rather than having to deal with Edge limitations. Going to Edge should be the next step if multi-region deployment is not good enough.

Best,

Didier

Lots of good answers above so not restating.

Most of the services you mentioned are fully managed services you won't see on Outposts or edge like Local Zones. At it's most fundamental layer edge provides storage and compute with some managed service operational win on top. Think ALB, RDS, EMR. You can build all those buy hand but they make ops easier. Services like DynamoDB, Batch, and Lambda are fully managed serverless services and won't be on Outposts or LZ.

Here for services on Outposts -> https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html

My two recommendations.

1. Connect with your AWS Solutions Architect and work with them to design a solution, lots of "it depends" here. Outposts for example were created based on feedback to solve for latency sensitive applications, local processing, and data sovereignty. If your use case is not one of those, it may not be a good fit.
2. Work backwards from the outcome for your customer, they have a pain point today, and does it fall inside one of the three use cases above? If they want to understand how edge fits with AWS, we can help with that as well.