.net 6 Support End Date

0 views
Skip to first unread message

Marti Buday

unread,
Aug 3, 2024, 5:32:16 PM8/3/24
to loarahukam

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 nodejs20.x or python3.12. 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.

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.

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. These dates are provided for planning purposes and are subject to change.

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 on the AWS Compute Blog.

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, when the release reaches the Active LTS phase.

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.

In response to customer feedback, AWS is delaying the deprecation of the Node.js 16 runtime until 9 months after the end of community LTS. The Node.js 16 runtime will be deprecated on the date provided in the Supported Runtimes table. As stated in the preceding note, between the end of LTS on September 11, 2023 and the deprecation date, Lambda will only apply OS patches to the runtime. No security patches for the language runtime will be applied during this period.

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.

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.

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.

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.

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.

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.

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.

Trusted Advisor displays a notification 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.

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.

Every Microsoft product has a lifecycle. The lifecycle begins when a product is released and ends when it's no longer supported. Knowing key dates in this lifecycle helps you make informed decisions about when to upgrade or make other changes to your software. This product is governed by Microsoft's Modern Lifecycle Policy.

Customers can choose Long Term Support (LTS) releases or Standard Term Support (STS) releases. The quality of all releases is the same. The only difference is the length of support. LTS releases get free support and patches for 3 years. STS releases get free support and patches for 18 months.

A new major release of .NET is published every year in November, enabling developers, the community, and businesses to plan their roadmaps. Even numbered releases are LTS releases that get free support and patches for three years.

Customers choosing LTS need the latest patch update installed to qualify for support. If a system is running 6.0 and 6.0.x has been released, 6.0.x needs to be installed as a first step. Once a patch update has been installed, applications begin using the update by default. LTS releases are supported for three years after general availability.

Customers choosing STS need the latest patch update installed to qualify for support. If a system is running 7.0 and 7.0.x has been released, 7.0.x needs to be installed as a first step. Once a patch update has been installed, applications begin using the update by default. STS releases are supported for 18 months after general availability.

Updates are cumulative and released as patches, with each update built upon all of the updates that preceded it. A device needs to install the latest update to remain supported. Updates may include new features, fixes (security and/or non-security), or a combination of both.

Updates are released on the Microsoft "Patch Tuesday" (second Tuesday of each month), however there is no guarantee that there will be a .NET release on any given Patch Tuesday. Patches are announced on the .NET blog. A digest of monthly releases is published to dotnet/announcements. For more details about .NET servicing and patching, see the .NET releases, patches, and support article.

As the end of life nears for a given .NET version, we recommend that you move to a newer .NET version, and reduce/remove your use of the given .NET version. After support ends, we recommend that you uninstall a given .NET version if you are no longer using it, or install the latest patch, and accelerate your plans to remove your use of that .NET version. Your use of out-of-support .NET versions may put your applications, application data, and computing environment at risk. You are strongly recommended to not use out-of-support software.

Starting with .NET Core 3.1, end of life dates align with Microsoft Patch Tuesday (second Tuesday of each month). For example, .NET 6 was originally released on November 8, 2021 and is supported for three years. But the actual end of support day is the closest Patch Tuesday starting that date, which is November 12, 2024.

Support for ASP.NET Core 2.1 on .NET Framework matches the ASP.NET Support policy for other package-based ASP.NET frameworks. The complete list of packages covered by this policy can be seen in ASP.NET Core 2.1 Supported Packages.

Applications using the Framework Dependent Deployment model benefit from .NET updates delivered by Microsoft update. There is no change to apps that use the Self-Contained Deployment model, so these apps are still responsible for keeping the runtime updated.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages