Lambda response time vs API Gateway response time - Why so much difference?

Hello,

Your observations regarding latency are valid.

You mentioned that when testing via postman you observed high latency. Please note, high latency must be addressed when an API endpoint that’s integrated with a Lambda function takes too long to send responses to a client.

To identify the section of the request/response flow that’s causing high latency, review the IntegrationLatency and Latency metrics of the API Gateway. Note the values and timestamps when these metrics have high values. The values can explain the cause for high latency.

IntegrationLatency explains the time between when API Gateway relays a request to the backend and when it receives a response from the backend. Whereas latency refers to the time between when API Gateway receives a request from a client and when it returns a response to the client. The latency includes the integration latency and other API Gateway overhead.

There is typically some added latency when using API Gateway with Lambda due to multiple factors, including network overhead and additional processing within the API Gateway. However, the difference you’re seeing when testing from Postman (300-400ms) versus the API Gateway console (80-120ms) indicates that network latency and potential client-side issues might be significant contributors.

Also, kindly note, when testing the API from console, Authorizers does not comes into picture.

Here's a breakdown of the problem and ways to optimize it:

➨ API Gateway Overhead: API Gateway adds its own processing latency, such as Authorization checks (Cognito Authorizer), data transformations.

➨ Cognito Authorizer Overhead: If the authorizer has to validate a token each time, this can add additional processing time, especially if the token isn't cached.

➨ Network Latency: The additional time (300-400ms in Postman) likely comes from geographical distance between the client and the API Gateway's endpoint.

Here’s how you can reduce latency and bring it closer to the Lambda execution time:

➨ Enable API Gateway Caching : Caching reduces the need to invoke the Lambda function for repeated requests with the same parameters. Effect: Can eliminate Lambda invocations for frequently accessed resources. Kindly refer the same in the documentation[1].

➨ Use Amazon CloudFront as a CDN : CloudFront is a content delivery network that caches API Gateway responses closer to your users. Effect: Significantly reduces network latency for geographically distributed clients. For more details, please refer document[2].

➨ Optimize Cognito Authorizer Performance : Cognito Authorizer validates JWT tokens on every request, which can add latency. Effect: Reduces the authorization overhead.

➨ Use proxy integrations : Switching to proxy integration can slightly reduce latency compared to non-proxy integration, especially if mapping templates or additional transformations are currently in use.

➨ Using Resource policy based invocations : for the latency perspective, resource policy based invocation has a benefit over role-based policy. For in details explanation o how resource policy based invocations are better than role based , please refer the third party documentation[3].

Kindly note, AWS doesn’t endorse any third party articles and they are meant to be used for references purpose only.

After implementing the suggested optimizations, you may expect a reduction in latency, especially for repetitive requests, geographically distributed clients, or scenarios where caching can be applied. Therefore, please review the above recommendations and implement the one that best suits to your use case.

References

[1] Cache settings for REST APIs in API Gateway - Amazon API Gateway : https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html#:~:text=You%20can%20enable%20API%20caching,of%20requests%20to%20your%20API.

[2] Reduce latency for end-users with multi-region APIs with CloudFront | Amazon Web Services : https://aws.amazon.com/blogs/networking-and-content-delivery/reduce-latency-for-end-users-with-multi-region-apis-with-cloudfront/#:~:text=CloudFront%20then%20validates%20the%20request's,to%20the%20client%20by%20CloudFront.

[3] https://medium.com/@lancers/low-hanging-fruit-to-reduce-api-gateway-to-lambda-latency-8109451e44d6

The difference in response times you're observing between direct Lambda execution and API Gateway invocation is not uncommon, and there are several factors contributing to this latency:

1. API Gateway overhead: API Gateway adds some processing time for request handling, authentication, and routing.

2. Cognito Authorizer: The Cognito Authorizer adds an additional step in the request processing, which can contribute to the overall latency.

3. Network latency: When you're testing from Postman, you're introducing additional network hops and potential geographical distance, which can significantly increase the response time.

4. API Gateway to Lambda communication: There's some overhead in the communication between API Gateway and Lambda.

To get closer to the Lambda execution time, you can consider the following approaches:

1. Use Lambda function URLs: If you don't need the advanced features of API Gateway, you could use Lambda function URLs. These provide a direct HTTP(S) endpoint for your Lambda function and can offer lower latency as they scale directly with your Lambda function's concurrency limits.

2. Optimize your Lambda function: Ensure your function is well-optimized, using techniques like code minification, efficient dependencies, and appropriate memory allocation.

3. Implement caching: If your API responses are cacheable, you can use API Gateway caching to reduce latency for subsequent requests.

4. Consider using Amazon CloudFront: Implementing a content delivery network (CDN) like CloudFront in front of your API can help reduce latency, especially for geographically distributed users.

5. Optimize the Cognito Authorizer: If possible, fine-tune your authorizer to minimize its execution time.

6. Use provisioned concurrency: This can help eliminate cold starts and potentially reduce overall latency.

Remember that while these optimizations can help, it's unlikely you'll achieve the same response time as direct Lambda invocation when going through API Gateway due to the inherent additional processing and network hops involved.

Sources
Select a method to invoke your Lambda function using an HTTP request - AWS Lambda
Select a method to invoke your Lambda function using an HTTP request - AWS Lambda
Community | We Improved Our Lambda Warm Start Speed by 95%! Here’s How

There is typically some added latency when using API Gateway with Lambda due to multiple factors, including network overhead and additional processing within the API Gateway. However, the difference you’re seeing when testing from Postman (300-400ms) versus the API Gateway console (80-120ms) indicates that network latency and potential client-side issues might be significant contributors.

This is a great answer! Testing from the API Gateway Management Console means that the data transfer between API Gateway and Lambda happens within AWS’s optimized network, even if the servers are in different locations.

• [Postman] - <internet> - <AWS Network [API-Gateway] - [Lambda]>: (300-400ms)
• <AWS Network [Mgmt. console] - [API-Gateway] - [Lambda]>: (80-120ms)

As AWS Gen AI mentioned, using Lambda Function URLs is the best way to bypass API Gateway. However, I understand that this approach would require changes to the architecture.

If your architecture allows it, using edge computing (CloudFront + Lambda@Edge) is even faster than Lambda. However, it does come with some limitations (though I personally love it!). (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)

Best