Developing .NET AWS Lambda functions

Practical approaches to structuring, authoring and observing .NET AWS Lambda functions, from the programming model and event-source handling to OpenTelemetry.

Developing a .NET AWS Lambda function usually starts with a very small handler. The interesting design questions appear later, when the function needs configuration, dependency injection, event-source semantics, testing, observability, and a programming model that remains consistent as the number of functions grows.

The articles below look at those concerns from different angles. Some use my AWSLambdaSharpTemplate library to explore an opinionated programming model for Lambda functions, while others look at AWS’s own Lambda Annotations framework or at the mechanics of responding to S3, SNS, and SQS events.

They span several generations of the .NET Lambda ecosystem, so they are not meant to be read as one version-specific tutorial. The older posts show the problems and trade-offs that motivated the original library; the newer ones revisit the programming model in V6 and explore how concerns such as per-record processing and OpenTelemetry fit into it today.

The common theme is keeping the Lambda handler focused on application behavior while making the surrounding runtime and event-source mechanics explicit, reusable, and observable.

Explore this topic

OpenTelemetry for .NET AWS Lambda functions

8 minute read

Lambda functions created with Kralizek.Lambda.Templates can expose invocation, record and source-specific telemetry before application code adds a single span. Here is how that telemetry fits into OpenTelemetry locally with Aspire and wh...