AWS Lambda is a serverless platform for running code without managing the underlying hardware. It’s very flexible, and can run many different workloads, including full C# APIs using ASP.NET Core.
Wait, You Can Do This On Lambda?
Yep! Not only can you run functions based on .NET runtimes, you can respond to requests using all the tools provided to you from ASP.NET. You can create APIs that talk to databases, like AWS’s managed RDS database, all while being perfectly scalable running on serverless functions.
While previous versions of ASP.NET run on .NET Framework (the older, Windows-only runtime) have been known to be bulky, the new ASP.NET Core stack running on .NET Core 3.1 and the newer .NET 5 have made significant performance and memory usage improvements.
This wouldn’t normally be possible, as ASP.NET uses its own HTTP web server called Kestrel to respond to requests, which wouldn’t work as that is handled by the Lambda runtime. However, AWS has provided an ingenious fix for this; traditionally, an ASP.NET setup usually involves their Kestrel web server behind IIS or NGINX. This talks to the ASP.NET framework to handle requests.
AWS has created a proxy class,
Amazon.Lambda.AspNetCoreServer, which takes care of everything in front of ASP.NET. This lets you reuse most of your code while bridging your API to Lambda.
This means you will need to use API Gateway, but that’s not a bad thing as API Gateway is very useful for managing your API. It allows you to strictly define all the rules that make your API function; of course, you will need to have your ASP.NET app configured to handle all requests from API Gateway.
This doesn’t mean every execution is going to take 2 seconds to load the page. Once the first load happens, everything is initialized, and it’s kept “hot” in Lambda for 5 minutes. If someone else requests it, the function will handle the request like it normally would running on an actual server.
Setting Up ASP.NET
AWS includes a generator for ASP.NET Lambda projects that is pre-configured with the boilerplate code and deployment to CloudFormation. We recommend that you start here, test things out, and then move your API code over, but if you’d like to jam it into an existing project, AWS has a guide for that as well.
You’ll need the AWS Toolkit for Visual Studio extension installed, which you can manage from “Extensions” in the menu bar. This is what contains the project templates for AWS applications.
From the main Visual Studio splash screen, create a new project:
You’ll probably want to put this in its own solution, so select “Blank Solution” under “Other.”
Then, you can right click in the file pane to add a new project, and select “AWS Serverless Application,” or “AWS Serverless Application with Tests,” whichever you prefer.
Make sure this is 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 the resources through AWS’s infrastructure-as-code service, CloudFormation. If you just wanted to make some Lambda functions, there’s a project for that too.
You’ll be taken to a sub-menu where you can choose what type of blueprint you want to build. Select “ASP.NET Core Web API” and create the project.
For the most part, this is configured like a standard ASP.NET project. The main difference is that the traditional
Program.cs is replaced by
LambdaEntryPoint.cs as the main entrypoint, and it contains the shim class that bridge’s AWS’s code to ASP.NET’s
IWebHostBuilder, which is used to start the application.
Once it’s all up and running, you will need to copy over your controllers, models, and services, and replace
Startup.cs with your configuration.
Using Your API
To deploy this project, AWS includes built in publish options using the AWS Toolkit Extension. Right click your project and select “Publish to AWS Lambda…”
You’ll need to give it a bucket to upload to, and set a name for the CloudFormation deployment.
It will take a second to upload and publish, but you’ll then be able to go to the AWS Lambda Management Console to view your function. It will have an auto-generated name using the CloudFormation stack name as the prefix.
Under Configuration > Triggers, you can view all the API Gateway triggers that call this function, and test it out 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’ll need to edit the
serverless.template in your project. For more info, you can refer to our guide on using AWS CloudFormation.