aws-lambda-dotnet is a monorepo of NuGet packages, not a single library

One repository, many independently versioned NuGet packages

The description calls this a repository of libraries, samples and tools for.NET Core developers building AWS Lambda functions. In practice it is a monorepo, and the way it is consumed matters: you take one NuGet package at a time, not this repository as a dependency.

The root layout reflects that. `Libraries/` holds the package sources, `Tools/` holds CLI tooling, `Blueprints/` holds project templates, `LambdaRuntimeDockerfiles/` holds runtime container definitions, `test/` holds the test harness, and `buildtools/` holds build infrastructure. There is also a `CHANGELOG.md` that the README points to for release history, and a `Dockerfile.test` for the build itself.

The repository is not archived and the last push was on 2026-10-16. Recent release tags are dated rather than semantic: release_2026-10-09, release_2026-10-08 and release_2026-10-05. That naming tells you releases are cut frequently and cut as a batch, so individual package versions inside a given release can differ from one another.

Licensing is Apache-2.0, which is the permissive end of the spectrum and matters if you are redistributing anything derived from the event types.

The Events packages are typed wrappers over AWS event payloads

The largest group sits under `Libraries/src` and exists so a function handler receives typed objects instead of raw JSON. Each package corresponds to one AWS event source and has its own README in its own directory.

The catalogue includes `Amazon.Lambda.APIGatewayEvents`, `Amazon.Lambda.ApplicationLoadBalancerEvents`, `Amazon.Lambda.S3Events`, `Amazon.Lambda.SQSEvents`, `Amazon.Lambda.SNSEvents`, `Amazon.Lambda.DynamoDBEvents`, `Amazon.Lambda.KinesisEvents`, `Amazon.Lambda.KinesisAnalyticsEvents`, `Amazon.Lambda.KinesisFirehoseEvents` and `Amazon.Lambda.KafkaEvents`. The list continues with `Amazon.Lambda.CognitoEvents`, `Amazon.Lambda.ConfigEvents`, `Amazon.Lambda.CloudWatchLogsEvents`, `Amazon.Lambda.LexEvents`, `Amazon.Lambda.SimpleEmailEvents` and `Amazon.Lambda.AppSyncEvents`.

That set covers the sources a typical event-driven .NET service touches, and it is the main reason to take a dependency here. The value is not that the JSON changes, it is that your handler signature changes from an untyped string to a type, and a payload shape change becomes a compile error instead of a runtime surprise.

The cost is a package per event source. A service consuming S3, SQS and DynamoDB events references three of them, and each one is versioned on its own schedule. That is manageable but it is not zero.

Amazon.Lambda.Tools moved to dotnet global tools, and the old reference must be deleted

The CLI tooling is `Amazon.Lambda.Tools`, which adds commands to the dotnet CLI for managing Lambda functions, including deploying a function from the CLI. It is installed as a global tool:

dotnet tool install -g Amazon.Lambda.Tools

and updated with:

dotnet tool update -g Amazon.Lambda.Tools

The migration from the older project-based tool happened as of September 10th, 2018, and the version number was set to 3.0.0.0 at that point. The failure mode the README warns about is worth reading carefully, because it produces a confusing symptom: an older project reference silently wins over your globally installed tool.

A pre-migration project file looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
    <AWSProjectType>Lambda</AWSProjectType>
  </PropertyGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Amazon.Lambda.Tools" Version="2.2.0" />
  </ItemGroup>
</Project>

Delete the `DotNetCliToolReference` element. If you do not, the project tool version is used instead of the global tool, and you will be debugging a CLI that you already upgraded.

The second half of that note concerns the AWS Toolkit for Visual Studio. Before .NET Core 2.1 it looked for `Amazon.Lambda.Tools` in the project file to decide whether to show the Lambda deployment menu. Since that reference was going away, the `AWSProjectType` property was added, and the current toolkit looks for either the tools reference or `AWSProjectType` set to `Lambda`. Remove the reference and keep `AWSProjectType`, or your Visual Studio deployment menu disappears.

Blueprints and templates cover scaffolding, and Yeoman is deprecated

The `Blueprints/` directory holds project templates, and the README lists `dotnet CLI Templates` as the current path with Yeoman marked deprecated. There is also a section for Amazon.Lambda.Annotations, which the README describes as letting C# functions use .NET attributes for a more idiomatic experience writing a Lambda function.

Other named packages in the table of contents round out the set: `Amazon.Lambda.AspNetCoreServer`, `Amazon.Lambda.TestUtilities`, `Amazon.Lambda.DurableExecution` and `Amazon.Lambda.Tools`.

`Amazon.Lambda.AspNetCoreServer` is the one with a real architectural consequence. It lets an ASP.NET Core application run inside Lambda, which means the hosting model is a Lambda function rather than a long-lived server. That is a different deployment shape from a container, and it comes with a different set of constraints around connection reuse and cold starts that this repository does not document.

`Amazon.Lambda.TestUtilities` exists for unit testing handlers, which is the practical mitigation for the fact that there is no local emulator in this repository. `Amazon.Lambda.DurableExecution` targets long-running workflows. The README for each lives in its own package directory, and the root README deliberately does not duplicate their contents.

What is not here: no emulator, no local runtime shim

The most common misunderstanding is expecting this repository to let you run a Lambda function on your machine. It does not provide that. What it provides is a set of typed input classes, deployment commands, templates and a few higher-level libraries.

Testing therefore happens through `Amazon.Lambda.TestUtilities`, where you construct the event object yourself and call the handler as a method. That catches type mismatches and handler logic. It does not catch anything about the Lambda execution environment, since the runtime, its layer system, its concurrency model and its environment variables are all outside what this code touches.

The other gap is the README's own coverage. It is an index. The packages list, the global tool install, and the migration instructions are there in full; everything about how a given package behaves is delegated to a per-package README. Anyone assessing this repository for a decision will spend their time in `Libraries/src/*/README.md` rather than at the root.

The table of contents also mentions getting help, feedback and contributing, so there is a community process, but the root document does not restate it.

Batch releases mean you check the changelog, not a version bump

The versioning story is unusual enough to plan around. Recent tags are release_2026-10-09, release_2026-10-08 and release_2026-10-05, cut on consecutive days. There is no semantic version visible in the tag name for the repository as a whole, while the individual NuGet packages inside it do carry their own versions, as the README notes for Amazon.Lambda.Tools, which was set to 3.0.0.0 at the Global Tools migration.

The practical consequence is that updating this repository tells you very little. The README's answer to the release history question is CHANGELOG.md, so that is where you confirm which package versions shipped and when.

For a team with a licensing or audit requirement, note that the root contains a NOTICE file alongside LICENSE. Apache-2.0 requires attribution and patent grant handling in redistributed artifacts, and the NOTICE file is what tells you what attribution text ships with the packages. This is not legal advice, it is the practical reason the file is there.

The repository also carries `.editorconfig`, a CODE_OF_CONDUCT.md, CONTRIBUTING.md, PowerShell/ and a.github/ directory, so the tooling and governance files are present even though the README barely mentions them.

Editorial conclusion

Adopt aws-lambda-dotnet when you are writing C# Lambda functions and want typed event classes instead of hand-written JSON models, plus a dotnet CLI path to deployment. Do not adopt it for local emulation or for a runtime you host yourself, since this repository contains libraries and deployment tooling rather than an emulator. Before pinning versions, check CHANGELOG.md, because releases ship under date-based tags such as release_2026-10-09 rather than semantic versions, and each library has its own README under Libraries/src/.

Frequently asked questions

Official sources

1. aws/aws-lambda-dotnet on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases