Invoking AWS Lambda API Gateway vs Direct Invocation

Question

Hi there,

I and my team are trying to move process intensive jobs from our Rails application on Heroku to AWS Lambda (Java). We are stuck on deciding whether to invoke lambda functions via API gateway or via AWS Ruby SDK directly. Depending on the use case, we might have to invoke lambda asynchronously as well, our payload is very small (< 1-2 KB). We are considering direct invocation primarily to maximize the execution time. We are looking for the points mentioned below:
1.Is it easy(& faster) for API gateway to verify the IAM role required to invoke lambda?
2.Is there any significant reduction in latency b/w lambda and API gateway?

Thanks in Advance for the answer :)

Answer 1

Most of the time, adding API Gateway does not improve the performance but does add an extra overhead, use API Gateway if any of the additional features it provides are useful to you. If you control the client then can get credentials on the client with permissions to invoke your Lambda functions directly, and you don't want any of the additional API Gateway features then go with the Lambda direct invoke.
Either way, direct lambda calls are faster bcz there's one network hop-less. Maybe you can directly compare lambdas/APIG with regard to the latency of your IAM verification, but we've benchmarked lambda-lambda calls and lambda-APIG-lambda calls, where the lambdas do no work, i.e. simply return the event object.
The average time usually is taken, I am mentioning below:

•lambda-lambda: 27ms
•lambda-APIG: 47ms
So the tax for the extra hop is 20 ms. We use lambda-lambda calls whenever feasible, especially with lambdas we don't want to expose to the world.
Let me know if you and your team's able to complete this task, will be happy to help more :)

Answer 2

Adding API Gateway does not improve performance but does add extra overhead. Use API Gateway if any of the additional feature it provides are useful to you. If you control the client, can get credentials on the client with permissions to invoke your Lambda functions directly, and don't need/want any of the additional API Gateway features, the go with the Lambda direct invoke.

Answer 3

Over the 4 years I implementing Client + AWS SDK on my serverless approach. Direct hit to all microservices we have such as Lambda, DynamoDB, S3, SQS, etc.

To work with this approach, we have to strong understand about IAM Role Policy including its statements concept, Authentication Token, AWS Credential, and Token - Credential exchange.

For me, using SDK is better to implement serverless rather than API Gateway. Why I prefer to implementing SDK instead of API on my serverless infra?

• API Gateway is Costly
• Network hop-less
• In fact, SDK is commonly contain an API to communicate with other applications Class base and simple call such as dynamodb.put(params).promise(), lambda.invoke(params).promise(), s3.putObject(params).promise(), etc. We can see a sample API call like fetch(URL).promise(), the term is not really different
• API is more complex and some case can't or shouldn't be handled with
• SDK is not scalable? No, I dont think so. Because it's class base, it's so scalable.
• Slimming the infra and code writing, i.e to work with s3 no need deploy API+Lambda
• Speed up the process, i.e storing data to dynamodb no need business logic through API+lambda
• Easy maintaining, we only maintain our client code
• Role Policy is more scalable; etc