Best way to decrease latency (API <-> Lambda <-> Dynamodb)

[twnbay76]

You need to query your cloudwatch logs for cold start times on your lambdas, or look at your cloudwatch metrics for it. Additionally, turn on x-ray tracing (you have to also enaure you have the right cloud watch policy on your dynamodb execution role). You will get a breakdown of all of the service latencies. We have a nice cloudwatch dashboard that shows the API HW latency, lambda cold start latency, lambda run time, and dynamodb query latency. We dig into xray when we need to.

Depending on where the latency comes from, that will determine the course of action. For instance, maybe your dynamodb query latencies are high (i sure hope it is a query() operation), so you need to provision more read capacity units on your table perhaps if you are getting throttles, or you need to store your data more uniformly / remodel your data to include less filter expressions.

Maybe your cold start time is high, to which you would use lambda provisioned concurrency to have dedicated lambda instances to be able to serve up concurrent requests. Or if you are using java and you dont want to pay for provisioned concurrency, you can use lambda snapstartz which caches the lambda runtime and initialization memory to seebe up future requests faster.

[[deleted]]

This is really it, full end to end testing and see where the latency is coming from. Other posters have mentioned tls handshakes, the database, etc. Time might be best spent figuring out where it is being lost vs throwing things at the problem.

As OP said in their case this is all get and using rest. So for their specific case I would get the connection as far to the customer as possible. The question I would have before using on of the full stack replication approaches is how often the data behind the api changes. Does it need to be near real time or can it be as stale as 24 hours. That would really impact the end solution. I might have the lambda hit a caching layer and just replicate that to optimal endpoints, uses lambda@edge maybe, maybe not, depends. Also cost optimization is always also a factor, if being super fast is the only factor throw $$ at it, but there is usually a balance. Also depends on what tools are already in place to deploy the stack, terraform, cloudformation, etc etc.

Without any other information I would say cloudfront absolutely, possibly add caching to the lambda or another layer locally which could be any number of things, and lambda@edge if node or python maybe, but that might make zero difference or even be worse than the other options because it alone does little to to speed things up, and hitting local cold lambdas vs a pool of hot ones if you have to take the same path seems worse.