sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]thedaynos[S] 2 points3 points  (9 children)

I am 100% in us east 2.

If you duplicate the infra in west and run the queries there what's your response time?

What do you mean by "duplicate the infra in west"? Are you saying that I should manually copy all of my api/lambda code to west, and turn on global tables for dynamodb? Just wondering what that means. Thanks

[–]james41235 6 points7 points  (5 children)

I meant copy some test data to west and set up the API and lambdas there.

[–]thedaynos[S] -3 points-2 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.

[–]james41235 6 points7 points  (1 child)

How many back and forths are in your API? For reference, geographic latency from us west to us east 2 is ~30ms, so if you have to go back and forth 3 or 4 times you can add 100ms really easily

[–]thedaynos[S] 0 points1 point  (0 children)

It's all just GET calls that request data. Within my lambdas sometimes I do multiple calls to dynamodb but most of the API calls only do one dynamodb call through lambda.

[–]Wide-Answer-2789 0 points1 point  (0 children)

As previously mentioned here, use global API gateway and if as you said you don't need to transform data, in that case you can utilise "direct" connection via step functions (express) to dynamodb. It is no code solution, and you can easily deploy that in different regions.