AWS Lambda vs Kestrel .NET Core performance

Question

I want to develop a Web API using .NET Core that needs to be able to handle a large number of concurrent requests. Furthermore, the WebAPI needs to connect to a database. The Web API will be internal and won't be exposed on Internet.

I'm considering two possibilities:

• Hosting an ASP.NET Core application in Kestrel in one or more containers / EC2 instances, with or without IIS.
• A serverless solution using AWS Lambda

I'm trying to understand what considerations I need to be aware of that will impact the performance and cost of each of these solutions.

• I understand that a Kestrel server with an application that uses async / await patterns can be expected to handle large numbers of concurrent requests. Database connection pooling means database connections can be efficiently shared between requests.

• In this forum post on AWS Lambda I read that:

I understand this questions more in terms “if AWS Lambda calls: response = Function(request) are thread-safe”.

The answer is yes.

It is because of one very simple reason. AWS Lambda does not allow for another thread to invoke the same lambda instance before the previous thread exits. And since multiple lambda instances of the same function do not share resources, this is not an issue also.

I understood and interpreted this as meaning:

• Each lambda instance can only handle one request at a time.
• This means a large number of instances are needed to handle a large number of concurrent requests.
• Each lambda instance will have its own database connection pool (probably with only a single connection).
• Therefore the total number of database connections is likely to be higher, bounded by the Lambda function level concurrency limit.
• Also as traffic increases and new lambda instances are created to respond to the demand, there will be significant latency for some requests due to the cold start time of each lambda instance.

Is this understanding correct?

Answer 1

Yes, each lambda instance is completely isolated, and are running as a single thread. So in your case there will be a lot of database connections.

One problem with your architecture is that you are trying to mix scalable resource in this case lambda with non scalable resource in this case relational database. I've seen such setups explode in very spectacular ways.

So in your case I'd either go with a number of static servers running Kestrel or another high performance web server or would replace the relational database with something that could smoothly scale, like DynamoDB or maybe AWS Aurora