With the release of .NET 8 AWS Lambda now supports .NET 8 and .NET 6 as managed runtimes. With the availability of ARM64 using Graviton2 there have been vast improvements to using .NET with Lambda.

But how does that translate to actual application performance? And how does .NET compare to other available runtimes. This repository contains a simple serverless application across a range of .NET implementations and the corresponding benchmarking results.

The application consists of an Amazon API Gateway backed by four Lambda functions and an Amazon DynamoDB table for storage.

It includes the below implementations as well as benchmarking results for both x86 and ARM64:

• .NET 6 Lambda
• .NET 6 Top Level statements
• .NET 6 Minimal API
• .NET 6 Minimal API with AWS Lambda Web Adapter
• .NET 6 NativeAOT compilation
• .NET 8
• .NET 8 Native AOT
• .NET 8 Minimal API

• AWS CLI
• AWS SAM
• .NET 8, .NET 6, OR .NET Core 3.1
• Artillery for load-testing the application
• Docker

There are four implementations included in the repository, covering a variety of Lambda runtimes and features. All the implementations use 1024MB of memory with Graviton2 (ARM64) as default. Tests are also executed against x86_64 architectures for comparison.

There is a separate project for each of the four Lambda functions, as well as a shared library that contains the data access implementations. It uses the hexagonal architecture pattern to decouple the entry points, from the main domain and storage logic.

This implementation is the simplest route to upgrade a .NET Core 3.1 function to use .NET 6 as it only requires upgrading the function runtime, project target framework and any dependencies as per the final section of this link.

This implementation uses the new features detailed in this link including

• Top Level Statements
• Source generation
• Executable assemblies

There is a single project named ApiBootstrap that contains all the start-up code and API endpoint mapping. The SAM template still deploys a separate function per API endpoint to negate concurrency issues.

It uses the new minimal API hosting model as detailed here.

Same as minimal API but instead of using Amazon.Lambda.AspNetCoreServer.Hosting/Amazon.Lambda.AspNetCoreServer it is based on Aws Lambda Web Adapter

The code is compiled natively for either Linux-x86_64 or Linux-ARM64 and then deployed manually to Lambda as a zip file. The SAM deploy can still be used to stand up the API Gateway endpoints and DynamoDb table, but won't be able to deploy native AOT .NET Lambda functions yet. Packages need to be published from Linux, since cross-OS native compilation is not supported yet.

Details for compiling .NET 6 native AOT can be found here

The code is compiled for the .NET 8 AWS Lambda managed runtime. The code is compiled as ReadyToRun for cold start speed. This sample should be able to be tested with sam build and then sam deploy --guided.

The code is compiled natively for Linux-x86_64 or ARM64 then deployed to Lambda as a zip file.

Details for compiling .NET native AOT can be found here

There is a single project named ApiBootstrap that contains all the start-up code and API endpoint mapping. The code is compiled natively for Linux-x86_64 then deployed manually to Lambda as a zip file. Microsoft have announced limited support for ASP.NET and native AOT in .NET 8, using the WebApplication.CreateSlimBuilder(args); method.

Details for compiling .NET 8 native AOT can be found here

To deploy the architecture into your AWS account, navigate into the respective folder under the src folder and run 'sam deploy --guided'. This will launch a deployment wizard, complete the required values to initiate the deployment. For example, for .NET 6:

cd src/NET6
sam build
sam deploy --guided

Benchmarks are executed using Artillery. Artillery is a modern load testing & smoke testing library for SRE and DevOps.

To run the tests, use the below scripts. Replace the $API_URL with the API URL output from the deployment:

cd loadtest
artillery run load-test.yml --target "$API_URL"

Below is the cold start and warm start latencies observed. Please refer to the load test folder to see the specifics of the test that were executed.

All latencies listed below are in milliseconds.

is used to make 100 requests / second for 10 minutes to our API endpoints.

AWS Lambda Power Tuning is used to optimize the cost/performance. 1024MB of function memory provided the optimal balance between cost and performance.

For the .NET 8 Native AOT compiled example the optimal memory allocation was 3008mb.

The below CloudWatch Log Insights query was used to generate the results:

filter @type="REPORT"
| fields greatest(@initDuration, 0) + @duration as duration, ispresent(@initDuration) as coldstart
| stats count(*) as count, pct(duration, 50) as p50, pct(duration, 90) as p90, pct(duration, 99) as p99, max(duration) as max by coldstart

The .NET 8 benchmarks include the number of cold and warm starts, alongside the performance numbers. Typically, the cold starts account for 1% or less of the total number of invocations.

*Microsoft do not officially support all ASP.NET Core features for native AOT, some features of ASP.NET may not be supported.

Native AOT container samples use an Alpine base image. A cold start latency of ~1s was seen the first time an image was pushed and invoked.

On future invokes, even after forcing new Lambda execution environments, cold start latency is as seen above. Potential reasons why covered in an AWS blog post on optimizing Lambda functions packaged as containers.

You can find implementations of this project in other languages here:

• ☕ Java
• ☕ Java (GraalVM)
• 🦀 Rust
• 🏗️ TypeScript
• 🐿️ Go
• ⭐ Groovy
• 🤖 Kotlin

See CONTRIBUTING for more information.

This library is licensed under the MIT-0 License. See the LICENSE file.