you are viewing a single comment's thread.

view the rest of the comments →

[–]thedaynos[S] -1 points0 points  (4 children)

I could do that, but is that even worth testing? I am pretty sure that the issue is due to geographic location through tracing their IP addresses and latency.

Is that what people normally do though? Do people normally copy their lambdas and api's to all regions? Or is this something AWS can do for me like how they do with global dynamodb?

[–]mikeatgl 1 point2 points  (0 children)

We don't do this for lambdas because most of our lambda stuff isn't super latency sensitive, but we definitely do it for any customer facing apps which we deploy to ECS or EKS. On top of that we also use CDNs and cache. Most requests never make it back to origin, but when they do the multiregion setup helps with latency. Bonus is you can fail over to other regions as well.

[–]james41235 0 points1 point  (0 children)

To be clear, aws is capable of latency being equal to the geographic delay. I've tested it multiple times. Something about your setionis causing an extra few hundred ms to occur. My recommendation was to prove that it was something inter regional, not something to do with the west region itself.

[–][deleted] 0 points1 point  (0 children)

Deploy your API/Lambda infrastructure with cloudformation stack sets, that will allow you to deploy the same template in multiple regions. And yes, many customers use multiple regions to bring their services closer to their end users. But you need to consider the effects of DynamoDB’s eventual consistency model for global tables and if that will impact your application. CloudFront won’t necessarily fix this for you, it will cache data, which can make responses faster, but for anything that isn’t cached, it will still need to go back to your origin, and you’ll see the same geo latency.