Lambda runtimes
Lambda supports multiple languages through the use of runtimes. A runtime provides a language-specific environment that relays invocation events, context information, and responses between Lambda and the function. You can use runtimes that Lambda provides, or build your own.
Each major programming language release has a separate runtime, with a unique runtime identifier, such as nodejs22.x or python3.13. To configure a function to use a new major language version, you need to change the runtime identifier. Since AWS Lambda cannot guarantee backward compatibility between major versions, this is a customer-driven operation.
For a function defined as a container image, you choose a runtime and the Linux distribution when you create the container image. To change the runtime, you create a new container image.
When you use a .zip file archive for the deployment package, you choose a runtime when you create the function. To change the runtime, you can update your function's configuration. The runtime is paired with one of the Amazon Linux distributions. The underlying execution environment provides additional libraries and environment variables that you can access from your function code.
Lambda invokes your function in an execution environment. The execution environment provides a secure and isolated runtime environment that manages the resources required to run your function. Lambda re-uses the execution environment from a previous invocation if one is available, or it can create a new execution environment.
To use other languages in Lambda, such as Go or Rust, use an OS-only runtime. The Lambda execution environment provides a runtime interface for getting invocation events and sending responses. You can deploy other languages by implementing a custom runtime alongside your function code, or in a layer.
Supported runtimes
The following table lists the supported Lambda runtimes and projected deprecation dates. After a runtime is deprecated, you're still able to create and update functions for a limited period. For more information, see Runtime use after deprecation. The table provides the currently forecasted dates for runtime deprecation, based on our Runtime deprecation policy. These dates are provided for planning purposes and are subject to change.
| Name | Identifier | Operating system | Deprecation date | Block function create | Block function update |
|---|---|---|---|---|---|
|
Node.js 22 |
|
Amazon Linux 2023 |
Apr 30, 2027 |
Jun 1, 2027 |
Jul 1, 2027 |
|
Node.js 20 |
|
Amazon Linux 2023 |
Apr 30, 2026 |
Jun 1, 2026 |
Jul 1, 2026 |
|
Node.js 18 |
|
Amazon Linux 2 |
Sep 1, 2025 |
Oct 1, 2025 |
Nov 1, 2025 |
|
Python 3.13 |
|
Amazon Linux 2023 |
Jun 30, 2029 |
Jul 31, 2029 |
Aug 31, 2029 |
|
Python 3.12 |
|
Amazon Linux 2023 |
Oct 31, 2028 |
Nov 30, 2028 |
Jan 10, 2029 |
|
Python 3.11 |
|
Amazon Linux 2 |
Jun 30, 2026 |
Jul 31, 2026 |
Aug 31, 2026 |
|
Python 3.10 |
|
Amazon Linux 2 |
Jun 30, 2026 |
Jul 31, 2026 |
Aug 31, 2026 |
|
Python 3.9 |
|
Amazon Linux 2 |
Nov 3, 2025 |
Dec 8, 2025 |
Jan 8, 2026 |
|
Java 21 |
|
Amazon Linux 2023 |
Jun 30, 2029 |
Jul 31, 2029 |
Aug 31, 2029 |
|
Java 17 |
|
Amazon Linux 2 |
Jun 30, 2026 |
Jul 31, 2026 |
Aug 31, 2026 |
|
Java 11 |
|
Amazon Linux 2 |
Jun 30, 2026 |
Jul 31, 2026 |
Aug 31, 2026 |
|
Java 8 |
|
Amazon Linux 2 |
Jun 30, 2026 |
Jul 31, 2026 |
Aug 31, 2026 |
|
.NET 9 (container only) |
|
Amazon Linux 2023 |
Not scheduled |
Not scheduled |
Not scheduled |
|
.NET 8 |
|
Amazon Linux 2023 |
Nov 10, 2026 |
Dec 10, 2026 |
Jan 11, 2027 |
|
Ruby 3.4 |
|
Amazon Linux 2023 |
Not scheduled |
Not scheduled |
Not scheduled |
|
Ruby 3.3 |
|
Amazon Linux 2023 |
Mar 31, 2027 |
Apr 30, 2027 |
May 31, 2027 |
|
Ruby 3.2 |
|
Amazon Linux 2 |
Mar 31, 2026 |
Apr 30, 2026 |
May 31, 2026 |
|
OS-only Runtime |
|
Amazon Linux 2023 |
Jun 30, 2029 |
Jul 31, 2029 |
Aug 31, 2029 |
|
OS-only Runtime |
|
Amazon Linux 2 |
Jun 30, 2026 |
Jul 31, 2026 |
Aug 31, 2026 |
Note
For new regions, Lambda will not support runtimes that are set to be deprecated within the next 6 months.
Lambda keeps managed runtimes and their corresponding container base images up to date with patches and support for minor version releases. For more information see Lambda runtime updates.
To programmatically interact with other AWS services and resources from your Lambda function, you can use one of AWS SDKs. The Node.js, Python, and Ruby runtimes include a version of the AWS SDK. However, to maintain full control of your dependencies, and to maximize backward compatibility during automatic runtime updates, we recommend that you always include the SDK modules your code uses (along with any dependencies) in your function's deployment package or in a Lambda layer.
We recommend that you use the runtime-included SDK version only when you can't include additional packages in your deployment. For example, when you create your function using the Lambda console code editor or using inline function code in an AWS CloudFormation template.
Lambda periodically updates the versions of the AWS SDKs included in the Node.js, Python, and Ruby runtimes. To determine the version of the AWS SDK included in the runtime you're using, see the following sections:
Lambda continues to support the Go programming language after deprecation of the Go 1.x runtime. For more information, see
Migrating AWS Lambda functions from the Go1.x runtime to the custom runtime on Amazon Linux 2
All supported Lambda runtimes support both x86_64 and arm64 architectures.
New runtime releases
Lambda provides managed runtimes for new language versions only when the release reaches the long-term support (LTS) phase of the language's release
cycle. For example, for the Node.js release cycle
Before the release reaches the long-term support phase, it remains in development and can still be subject to breaking changes. Lambda applies runtime updates automatically by default, so breaking changes to a runtime version could stop your functions from working as expected.
Lambda doesn't provide managed runtimes for language versions which aren't scheduled for LTS release.
The following list shows the target launch month for upcoming Lambda runtimes. These dates are indicative only and subject to change.
-
Java 25 - October 2025
-
Python 3.14 - November 2025
-
Node.js 24 - November 2025
-
.NET 10 - December 2025
Runtime deprecation policy
Lambda runtimes for .zip file archives are built around a combination of operating system, programming language, and software libraries that are subject to maintenance and security updates. Lambda’s standard deprecation policy is to deprecate a runtime when any major component of the runtime reaches the end of community long-term support (LTS) and security updates are no longer available. Most usually, this is the language runtime, though in some cases, a runtime can be deprecated because the operating system (OS) reaches end of LTS.
After a runtime is deprecated, AWS may no longer apply security patches or updates to that runtime, and functions using that runtime are no longer eligible for technical support. Such deprecated runtimes are provided ‘as-is’, without any warranties, and may contain bugs, errors, defects, or other vulnerabilities.
To learn more about managing runtime upgrades and deprecation, see the following sections and Managing AWS Lambda runtime upgrades
Important
Lambda occasionally delays deprecation of a Lambda runtime for a limited period beyond the end of support date of the language version that the runtime supports. During this period, Lambda only applies security patches to the runtime OS. Lambda doesn’t apply security patches to programming language runtimes after they reach their end of support date.
Shared responsibility model
Lambda is responsible for curating and publishing security updates for all supported managed runtimes and container base images. By default, Lambda will apply these updates automatically to functions using managed runtimes. Where the default automatic runtime update setting has been changed, see the runtime management controls shared responsibility model. For functions deployed using container images, you're responsible for rebuilding your function's container image from the latest base image and redeploying the container image.
When a runtime is deprecated, Lambda’s responsibility for updating the managed runtime and container base images ceases. You are responsible for upgrading your functions to use a supported runtime or base image.
In all cases, you are responsible for applying updates to your function code, including its dependencies. Your responsibilities under the shared responsibility model are summarized in the following table.
| Runtime lifecycle phase | Lambda's responsibilities | Your responsibilities |
|---|---|---|
| Supported managed runtime |
Provide regular runtime updates with security patches and other updates. Apply runtime updates automatically by default (see Runtime update modes for non-default behaviors). |
Update your function code, including dependencies, to address any security vulnerabilities. |
| Supported container image | Provide regular updates to container base image with security patches and other updates. |
Update your function code, including dependencies, to address any security vulnerabilities. Regularly re-build and re-deploy your container image using the latest base image. |
| Managed runtime approaching deprecation |
Notify customers prior to runtime deprecation via documentation, AWS Health Dashboard, email, and Trusted Advisor. Responsibility for runtime updates ends at deprecation. |
Monitor Lambda documentation, AWS Health Dashboard, email, or Trusted Advisor for runtime deprecation information. Upgrade functions to a supported runtime before the previous runtime is deprecated. |
| Container image approaching deprecation |
Deprecation notifications are not available for functions using container images. Responsibility for container base image updates ends at deprecation. |
Be aware of deprecation schedules and upgrade functions to a supported base image before the previous image is deprecated. |
Runtime use after deprecation
After a runtime is deprecated, AWS may no longer apply security patches or updates to that runtime, and functions using that runtime are no longer eligible for technical support. Such deprecated runtimes are provided ‘as-is’, without any warranties, and may contain bugs, errors, defects, or other vulnerabilities. Functions that use a deprecated runtime may also experience degraded performance or other issues, such as a certificate expiry, that can cause them to stop working properly.
For at least 30 days after a runtime is deprecated, you’re still able to create new Lambda functions using that runtime. Starting from 30 days after deprecation, Lambda begins blocking the creation of new functions.
For at least 60 days after a runtime is deprecated, you’re still able to update function code and configuration for existing functions. Starting from 60 days after deprecation, Lambda begins blocking the update of function code and configuration for existing functions.
Note
For some runtimes, AWS is delaying the block-function-create and block-function-update dates beyond the usual 30 and 60 days after deprecation. AWS has made this change in response to customer feedback to give you more time to upgrade your functions. Refer to the tables in Supported runtimes and Deprecated runtimes to see the dates for your runtime.
You can update a function to use a newer supported runtime indefinitely after a runtime is deprecated. You should test that your function works with the new runtime before applying the runtime change in production environments, since you will not be able to revert to the deprecated runtime once the 60-day period has passed. We recommend using function versions and aliases to enable safe deployment with rollback.
Note that the exact length of time for which you can continue to create and update functions isn’t fixed. This period can vary for each deprecation and for different AWS Regions. Nominal dates for the blocking of function creates and updates are provided in the Supported Runtimes table in the first section of this page. Lambda will not start blocking function creates or updates before the dates given in this table.
You can continue to invoke your functions indefinitely after the runtime is deprecated. However, AWS strongly recommends that you migrate functions to a supported runtime so that your functions continue to receive security patches and remain eligible for technical support.
Receiving runtime deprecation notifications
When a runtime approaches its deprecation date, Lambda sends you an email alert if any functions in your AWS account use that runtime. Notifications are also displayed in the AWS Health Dashboard and in AWS Trusted Advisor.
-
Receiving email notifications:
Lambda sends you an email alert at least 180 days before a runtime is deprecated. This email lists the $LATEST versions of all functions using the runtime. To see a full list of affected function versions, use Trusted Advisor or see Retrieve data about Lambda functions that use a deprecated runtime.
Lambda sends email notification to your AWS account's primary account contact. For information about viewing or updating the email addresses in your account, see Updating contact information in the AWS General Reference.
-
Receiving notifications through the AWS Health Dashboard:
The AWS Health Dashboard displays a notification at least 180 days before a runtime is deprecated. Notifications appear on the Your account health page under Other notifications
. The Affected resources tab of the notification lists the $LATEST versions of all functions using the runtime. Note
To see a full and up-to-date list of affected function versions, use Trusted Advisor or see Retrieve data about Lambda functions that use a deprecated runtime.
AWS Health Dashboard notifications expire 90 days after the affected runtime is deprecated.
-
Using AWS Trusted Advisor
Trusted Advisor displays a notification at least 180 days before a runtime is deprecated. Notifications appear on the Security
page. A list of your affected functions is displayed under AWS Lambda Functions Using Deprecated Runtimes. This list of functions shows both $LATEST and published versions and updates automatically to reflect your functions' current status. You can turn on weekly email notifications from Trusted Advisor in the Preferences
page of the Trusted Advisor console.
Deprecated runtimes
The following runtimes have reached end of support:
| Name | Identifier | Operating system | Deprecation date | Block function create | Block function update |
|---|---|---|---|---|---|
|
.NET 6 |
dotnet6
|
Amazon Linux 2 |
Dec 20, 2024 |
Oct 1, 2025 |
Nov 1, 2025 |
|
Python 3.8 |
python3.8
|
Amazon Linux 2 |
Oct 14, 2024 |
Oct 1, 2025 |
Nov 1, 2025 |
|
Node.js 16 |
nodejs16.x
|
Amazon Linux 2 |
Jun 12, 2024 |
Oct 1, 2025 |
Nov 1, 2025 |
|
.NET 7 (container only) |
dotnet7
|
Amazon Linux 2 |
May 14, 2024 |
N/A |
N/A |
|
Java 8 |
java8
|
Amazon Linux |
Jan 8, 2024 |
Feb 8, 2024 |
Nov 1, 2025 |
|
Go 1.x |
go1.x
|
Amazon Linux |
Jan 8, 2024 |
Feb 8, 2024 |
Nov 1, 2025 |
|
OS-only Runtime |
provided
|
Amazon Linux |
Jan 8, 2024 |
Feb 8, 2024 |
Nov 1, 2025 |
|
Ruby 2.7 |
ruby2.7
|
Amazon Linux 2 |
Dec 7, 2023 |
Jan 9, 2024 |
Nov 1, 2025 |
|
Node.js 14 |
nodejs14.x
|
Amazon Linux 2 |
Dec 4, 2023 |
Jan 9, 2024 |
Nov 1, 2025 |
|
Python 3.7 |
python3.7
|
Amazon Linux |
Dec 4, 2023 |
Jan 9, 2024 |
Nov 1, 2025 |
|
.NET Core 3.1 |
dotnetcore3.1
|
Amazon Linux 2 |
Apr 3, 2023 |
Apr 3, 2023 |
May 3, 2023 |
|
Node.js 12 |
nodejs12.x
|
Amazon Linux 2 |
Mar 31, 2023 |
Mar 31, 2023 |
Apr 30, 2023 |
|
Python 3.6 |
python3.6
|
Amazon Linux |
Jul 18, 2022 |
Jul 18, 2022 |
Aug 29, 2022 |
|
.NET 5 (container only) |
dotnet5.0
|
Amazon Linux 2 |
May 10, 2022 |
N/A |
N/A |
|
.NET Core 2.1 |
dotnetcore2.1
|
Amazon Linux |
Jan 5, 2022 |
Jan 5, 2022 |
Apr 13, 2022 |
|
Node.js 10 |
nodejs10.x
|
Amazon Linux 2 |
Jul 30, 2021 |
Jul 30, 2021 |
Feb 14, 2022 |
|
Ruby 2.5 |
ruby2.5
|
Amazon Linux |
Jul 30, 2021 |
Jul 30, 2021 |
Mar 31, 2022 |
|
Python 2.7 |
python2.7
|
Amazon Linux |
Jul 15, 2021 |
Jul 15, 2021 |
May 30, 2022 |
|
Node.js 8.10 |
nodejs8.10
|
Amazon Linux |
Mar 6, 2020 |
Feb 4, 2020 |
Mar 6, 2020 |
|
Node.js 4.3 |
nodejs4.3
|
Amazon Linux |
Mar 5, 2020 |
Feb 3, 2020 |
Mar 5, 2020 |
|
Node.js 4.3 edge |
nodejs4.3-edge
|
Amazon Linux |
Mar 5, 2020 |
Mar 31, 2019 |
Apr 30, 2019 |
|
Node.js 6.10 |
nodejs6.10
|
Amazon Linux |
Aug 12, 2019 |
Jul 12, 2019 |
Aug 12, 2019 |
|
.NET Core 1.0 |
dotnetcore1.0
|
Amazon Linux |
Jun 27, 2019 |
Jun 30, 2019 |
Jul 30, 2019 |
|
.NET Core 2.0 |
dotnetcore2.0
|
Amazon Linux |
May 30, 2019 |
Apr 30, 2019 |
May 30, 2019 |
|
Node.js 0.10 |
nodejs
|
Amazon Linux |
Aug 30, 2016 |
Sep 30, 2016 |
Oct 31, 2016 |
In almost all cases, the end-of-life date of a language version or operating system is known well in advance. The following links give end-of-life schedules for each language that Lambda supports as a managed runtime.
Language and framework support policies
-
Node.js – github.com
-
Python – devguide.python.org
-
Ruby – www.ruby-lang.org
-
Java – www.oracle.com
and Corretto FAQs -
Go – golang.org
-
.NET – dotnet.microsoft.com
