AWS Lambda is a serverless platform for running code without managing the underlying hardware. It is very flexible and can run many different workloads including full C # APIs using ASP.NET Core.
Wait, can you do that on Lambda?
Yeah! Not only can you perform functions based on .NET runtime environments, but you can also respond to requests using all of the tools provided by ASP.NET. You can build APIs that communicate with databases, such as the AWS Managed RDS Database, while being fully scalable and running on serverless functions.
While previous versions of ASP.NET running on the .NET Framework (the old Windows runtime only) were known to be cumbersome, the new ASP.NET Core stack running on .NET Core 3.1 and the new. NET 5 have improved performance and memory usage.
This would not normally be possible, as ASP.NET uses its own HTTP web server called Kestrel to respond to requests, which would not work because this is handled by the Lambda runtime. However, AWS has provided an ingenious solution for this; Traditionally, an ASP.NET setup usually involves their Kestrel web server behind IIS or NGINX. This communicates with the ASP.NET framework to handle requests.
AWS created a proxy class,
Amazon.Lambda.AspNetCoreServer, which takes care of everything in front of ASP.NET. This allows you to reuse most of your code while still linking your API to Lambda.
This means that you will have to use API Gateway, but that’s not a bad thing because API Gateway is very useful for managing your API. It allows you to strictly define all the rules that make your API work; of course, you will need to configure your ASP.NET application to handle all API Gateway requests.
This does not mean that each execution will take 2 seconds to load the page. Once the first load is done, everything is initialized and it is kept “hot” in Lambda for 5 minutes. If someone else requests it, the function will treat the request as if it were running normally on a real server.
AWS includes a builder for ASP.NET Lambda projects that is preconfigured with standard code and deployment to CloudFormation. We recommend that you start here, test things out, and then move your API code around, but if you want to integrate it into an existing project, AWS also has a guide for this.
You will need the AWS Toolkit for Visual Studio extension installed, which you can manage from “Extensions” on the menu bar. This is what contains the project templates for AWS applications.
From the main Visual Studio start screen, create a new project:
You will probably want to put this in its own solution, so select “Blank Solution” under “Other”.
Then you can right-click in the files pane to add a new project and select “AWS Serverless Application” or “AWS Serverless Application with Testing”, depending on your preference.
Make sure it’s in C #, unless you want to use F # for some reason.
Also, keep in mind that this is a “Serverless Application” project, which manages all resources through the infrastructure service as code from AWS, CloudFormation. If you just want to create Lambda functions, there is a project for that as well.
You will be taken to a submenu where you can choose the type of plan you want to create. Select “ASP.NET Core Web API” and create the project.
For the most part, this is configured as a standard ASP.NET project. The main difference is that the traditional
Program.cs is replaced by
LambdaEntryPoint.cs as the main entry point, and it contains the shim class that links the code from AWS to that from ASP.NET
IWebHostBuilder, which is used to start the application.
Once everything is up and running, you will need to copy your controllers, models and services, and replace
Startup.cs with your config.
Using your API
To deploy this project, AWS includes built-in publishing options using the AWS Toolkit extension. Right click on your project and select “Publish to AWS Lambda …”
You will need to give it a bucket to download to and define a name for the CloudFormation deployment.
It will take a second to download and publish, but then you can access the AWS Lambda Management Console to see your function. It will have an automatically generated name using the CloudFormation stack name as a prefix.
Under Configuration> Triggers, you can view all API Gateway triggers that call this function and test it for yourself using the endpoint.
You can also view the full CloudFormation stack that is created automatically using your configuration.
If you want to change it, you will need to change the
serverless.template in your project. For more information, you can refer to our guide to using AWS CloudFormation.