Earlier this year, Amazon announced availability of C# as a first-class citizen for AWS Lambda services. This solution is based on .NET Core and allows to use .Net ecosystem for building serverless services.

Tooling

Tooling and integration with Visual Studio are surprisingly good. VS2017 support is in preview, but even the preview extension is pretty stable. C#-based Lambdas can be deployed and tested directly from Visual Studio, with a couple of clicks. Lambda tools can also be used from .NET Core CLI, which enables command line-based Continuous Integration and Continuous Deployment scenarios.

Deployment

C# Lambdas support two main workflows – simple Lambda Function and serverless application hosted by Lambda. While the first case is simple, the serverless model is more interesting as it allows to host the whole ASP.NET Core Web API site in Lambda. In this case, AWS tools, with help of CloudFormation, deploys and configures API Gateway endpoint and Lambda which routes all requests to the corresponding Web API controllers/actions. In the same time, Web API site can still be run locally for testing purposes. This model provides a huge productivity boost comparing with a traditional model when Lambda shall be deployed to AWS first and only then can be tested.

AWS Developer blog provides tutorials on creating a new C# Lambda or converting existing ASP.NET Web API site in Serverless application. While the tutorials are well written, they miss a couple of important points:

• AWS Lambda does not support .NET Core 1.1 – this is a design decision to support only LTS versions of .Net Core (netcoreapp1.0 at the moment)
• Sometimes, first publish of C# Lambda may not wire Lambda and API Gateway properly. In this case, calling Lambda from the associated gateway will results in a security error. The easy way to fix it, is to open API Gateway resource associated with the Lambda and save it, even without changes. It fixes the missing security items.
• The guide describing migration of the existing Web API site does not mention a couple of additional changes, which are required. Default .NET Core Web application template uses Microsoft.NET.Sdk.Web as a SDK. However, this SDK references libuv runtime component which is missing on AWS and raises runtime exception. This is a known issue in .NET Core and was recently fixed in v1.1 but not available in production. To avoid this issue, Web application for Lambda shall use Microsoft.NET.Sdk instead (and set EXE as an output type).

Performance

Performance of the solution is yet to be profiled, but the quick measurements show performance enough to proceed with the spikes. Latency for the cold Lambda (which is almost not relevant as you may use some techniques to keep Lambdas warm) is about 5s for the “Hello World” type of API and the average latency for the warm Lambdas is about 80ms.