AWS Lambda .NET 8 Runtime Deprecation: Dates and Upgrade Path

The short answer

AWS deprecates the Lambda .NET 8 runtime, dotnet8, on 10 November 2026, the same day Microsoft ends support for .NET 8. AWS then blocks creating new dotnet8 functions from 29 July 2027 and blocks updating existing ones from 31 August 2027. Functions that use dotnet8 keep running, and AWS says you can continue to invoke them indefinitely. From the deprecation date, though, AWS may no longer apply security patches to the runtime and the functions are no longer eligible for technical support. The upgrade target is the dotnet10 runtime, which AWS lists until 14 November 2028.

The deprecation date follows the runtime's own lifecycle. Our .NET 8 end of life page covers what ends across .NET itself.

Lambda .NET runtime dates

These are the dates AWS publishes on its Lambda runtimes page. AWS says they are for planning and subject to change, but it will not start blocking creates or updates before the dates in its tables.

.NET 9 was only ever offered on Lambda as a container base image, not as a managed runtime for .zip deployments, and it is deprecated on the same day as .NET 8. There is no reason to stop there on the way to .NET 10.

What each stage means for a dotnet8 function

The gap between deprecation and the block dates is easy to misread as extra support. It is not. AWS describes deprecated runtimes as provided "as-is", and its documentation states that Lambda does not apply security patches to a language runtime after its end of support date. The months to August 2027 are time to deploy fixes to your own code on an unpatched runtime, not a support window. AWS has not published any extension of dotnet8 patching past 10 November 2026.

AWS also warns that functions on a deprecated runtime may see degraded performance or other problems, such as a certificate expiry, that stop them working properly. The longer a function stays on dotnet8, the more likely one of those becomes.

Container image functions get no warning

If a function is deployed as a container image built from public.ecr.aws/lambda/dotnet:8, the deprecation applies to the base image too: AWS's responsibility for updating it ends on 10 November 2026. AWS states that deprecation notifications are not available for functions that use container images, so those functions do not appear in the email or the Trusted Advisor check. Under the shared responsibility model, rebuilding container images from a current base image was always your job. After deprecation there is no current .NET 8 base image to rebuild from.

How to find every dotnet8 function

AWS's notification email lists only $LATEST versions. To list every version that uses dotnet8, run this in each Region and each account:

aws lambda list-functions --function-version ALL --region us-east-1 --output text \
  --query "Functions[?Runtime=='dotnet8'].FunctionArn"

Trusted Advisor's "AWS Lambda Functions Using Deprecated Runtimes" check shows both $LATEST and published versions. Container image functions do not carry a runtime identifier, so find those by searching your Dockerfiles for public.ecr.aws/lambda/dotnet:8 and for .NET 8 base images from other registries.

How to upgrade a Lambda function from .NET 8 to .NET 10

1. Retarget the project

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <AWSProjectType>Lambda</AWSProjectType>
</PropertyGroup>

Update Amazon.Lambda.Core, Amazon.Lambda.Serialization.SystemTextJson and the other Amazon.Lambda.* packages to current versions, along with the rest of your dependencies. The move from 8 to 10 crosses two major versions; our .NET 8 to .NET 10 upgrade guide covers the breaking changes.

2. Change the runtime in your deployment configuration

If you deploy with the Amazon.Lambda.Tools global tool, update aws-lambda-tools-defaults.json:

{
  "configuration": "Release",
  "function-architecture": "x86_64",
  "function-runtime": "dotnet10",
  "function-memory-size": 256,
  "function-timeout": 30,
  "function-handler": "MyFunction::MyFunction.Function::FunctionHandler"
}

Then update the tool and deploy:

dotnet tool update -g Amazon.Lambda.Tools
dotnet lambda deploy-function MyFunction

In AWS SAM or CloudFormation, set Runtime: dotnet10 on the function resource. With the AWS CLI alone, change the runtime and the code together. AWS requires code compatible with the new runtime whenever you change it:

aws lambda update-function-code --function-name my-function --zip-file fileb://function.zip
aws lambda update-function-configuration --function-name my-function --runtime dotnet10

3. Use versions and aliases for rollback

Publish a version, point an alias at it and shift traffic once the new version is healthy. After 31 August 2027 you may not be able to roll a function back to dotnet8, so get rollback working on dotnet10 rather than relying on the old runtime.

4. For container image functions, change the base image

FROM public.ecr.aws/lambda/dotnet:10

The base image tag and the TargetFramework in your project must use the same .NET version. Rebuild, push to Amazon ECR and update the function to the new image.

Alternatives to the managed runtime

• AWS base image for .NET 10. public.ecr.aws/lambda/dotnet:10, on Amazon Linux 2023, with the same deprecation date as dotnet10. Suits teams that already build images.
• OS-only runtime. provided.al2023, deprecated on 30 June 2029, with a self-contained build that uses Amazon.Lambda.RuntimeSupport as the bootstrap. AWS's custom runtime template sets "function-runtime": "provided.al2023" and "msbuild-parameters": "--self-contained true". Note what this changes: the .NET runtime now ships inside your package, so you own its patching. A self-contained .NET 8 build on provided.al2023 is still an unsupported .NET 8.
• A non-AWS base image. AWS documents building Lambda images from another registry's base image, including Microsoft's .NET images, provided you add Amazon.Lambda.RuntimeSupport as the runtime interface client. The base image's own lifecycle then applies.

None of these extends .NET 8. They change who supplies the runtime, which matters only if that supplier still patches .NET 8.

If a function cannot move by 10 November

For most Lambda functions, moving to dotnet10 is a small change and the right one. OSSeva does not patch the managed dotnet8 runtime that AWS operates, and cannot.

For a function that cannot be retargeted in time, the container path is where OSSeva fits. OSSeva for .NET keeps .NET 8 patched past 10 November 2026 and ships patched Docker base images for the .NET runtime. Built with Amazon.Lambda.RuntimeSupport, as AWS documents for non-AWS base images, a container image function can run on a .NET 8 runtime that still receives fixes while the upgrade to .NET 10 is scheduled. Artifacts are signed with GPG and Sigstore. The same builds cover any .NET 8 services you run on EC2, ECS or EKS. See .NET 8 extended support and our comparison of .NET 8 extended support providers. OSSeva for .NET is priced per application runtime environment; book a discovery call for a quote.

Frequently asked questions

When is the AWS Lambda .NET 8 runtime deprecated?

On 10 November 2026. AWS blocks creating new dotnet8 functions from 29 July 2027 and blocks updating existing ones from 31 August 2027.

Will my Lambda functions stop working when dotnet8 is deprecated?

No. AWS states that you can continue to invoke functions on a deprecated runtime indefinitely. They stop receiving security patches and technical support, and may hit problems such as certificate expiry over time.

Is there a .NET 10 runtime for AWS Lambda?

Yes. AWS lists dotnet10 on Amazon Linux 2023, with deprecation scheduled for 14 November 2028, and a matching base image at public.ecr.aws/lambda/dotnet:10.

Can I use .NET 9 on AWS Lambda?

Only as a container image, and AWS deprecates that base image on 10 November 2026, the same day as dotnet8. Move to .NET 10 instead.

How do I find all Lambda functions using .NET 8?

Run aws lambda list-functions --function-version ALL with --query "Functions[?Runtime=='dotnet8'].FunctionArn" in every Region and account, or use the Trusted Advisor deprecated runtimes check. Search your Dockerfiles for container image functions, which AWS does not include in its notices.

Does AWS keep patching dotnet8 until the update block in August 2027?

No. From 10 November 2026 AWS may no longer apply security patches, and it states that Lambda does not patch a language runtime after its end of support date. The block dates only limit creating and updating functions.

Can I still deploy dotnet8 functions after 10 November 2026?

Through the AWS CLI, AWS SAM or CloudFormation, yes, until the block dates. The Lambda console stops creating or updating them on the deprecation date.