AWS Lambda Runtime Deprecation: Find and Upgrade Functions Before Blocks

Every AWS Lambda managed runtime has an end date, and functions left on a deprecated runtime keep running unpatched until the day a hotfix cannot be deployed. AWS deprecates a runtime when its language version or operating system leaves community long-term support, then blocks function creation and finally blocks function updates. This guide is a runbook for that cycle: how the policy works, the current published schedule, how to find every affected function and version across accounts, how to upgrade and roll back safely, and what it costs to wait. It is written for cloud platform, DevOps and security teams who receive AWS Health or Trusted Advisor runtime notices. For Lambda security in general (execution roles, resource policies, secrets), see the AWS Lambda Security Guide.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Deprecation does not stop invocations. AWS states you can keep invoking functions on a deprecated runtime indefinitely, but security patches may stop and the functions lose technical support, so the risk is silent decay rather than an outage.
• The real deadline is "block function update". After that date you cannot change code or configuration on the old runtime, so an urgent fix forces an unplanned runtime upgrade at the worst moment.
• A large batch of block dates lands in summer 2027. AWS's table currently shows 29 July 2027 (block create) and 31 August 2027 (block update) for most deprecated runtimes, including python3.9, nodejs18.x and nodejs20.x.
• Notifications under-report. Email and AWS Health list only $LATEST versions, container image functions get no deprecation notices at all, and AWS itself says the lists may be incomplete; query ListFunctions with FunctionVersion ALL in every Region and account.
• Use versions and aliases as your rollback. Once updates are blocked you cannot switch a function back to the deprecated runtime, so keep the previous published version behind an alias until the upgrade is proven.

What is changing and why

AWS's runtime policy, as published on the Lambda runtimes documentation page, is that Lambda "deprecates a runtime when any major component reaches the end of community long-term support (LTS) and security updates are no longer available." That component is usually the language (Python, Node.js, Java, .NET, Ruby), but it can be the operating system: Amazon Linux 2 (AL2) reaches end of life on 30 June 2026, and AWS is moving runtimes to Amazon Linux 2023 (AL2023). AWS says it may occasionally delay a deprecation for a limited period after the language's own end of support, patching only the runtime operating system in that window.

After deprecation AWS "may no longer apply security patches or updates to that runtime", and deprecated runtimes are provided "as-is". AWS also warns that such functions may suffer degraded performance or issues "such as a certificate expiry" that stop them working properly. The lifecycle has four phases.

The 30 and 60 day figures are minimums. For many runtimes AWS has set block dates much later, and it states it will not start blocking before the dates shown in its tables. In new Regions, AWS makes available the runtimes that are not due for deprecation within six months.

Official timeline and current status

The dates below are taken from the AWS Lambda runtimes page as checked on 8 November 2026. AWS describes future dates as forecasts for planning that may change, so re-check the page before committing a plan.

Upgrade targets with later dates, per the same table: nodejs24.x (deprecation 30 April 2028), python3.12 (31 October 2028), python3.13 and python3.14 (30 June 2029), java21, java25 and the java8.al2023, java11.al2023 and java17.al2023 variants (30 June 2029), dotnet10 (14 November 2028), ruby3.4 (31 March 2028), ruby4.0 (31 March 2029) and provided.al2023 (30 June 2029). Node.js 26 and Python 3.15 were in public preview when checked, not covered by the Lambda SLA, with general availability targeted for November 2026: do not use preview runtimes in production.

For the AL2-based runtimes still supported (Java 8, 11 and 17 on AL2, Python 3.10, Python 3.11 and provided.al2), AWS states it continues to apply critical and selected important AL2 security patches plus language patches until each runtime's deprecation date, and recommends moving to an AL2023 runtime as soon as possible. Go has no managed runtime of its own since go1.x was deprecated; Go functions run on provided.al2023.

Who and what is affected

• .zip functions on managed runtimes: the main population. AWS patches the runtime automatically while it is supported; you own the code and dependencies.
• Published versions, not only $LATEST: every published version keeps the runtime it was published with. Aliases that point to old versions keep traffic on the old runtime even after $LATEST is upgraded.
• Container image functions: AWS states deprecation notifications are not available for them and base image updates end at deprecation, so you track schedules yourself and rebuild from a current base image.
• Infrastructure as code: CloudFormation, SAM, CDK and Terraform definitions that hard-code a runtime will fail to create functions after block create, which often surfaces first as a broken environment rebuild or disaster recovery test. See the AWS CloudFormation and CDK Security Guide.
• Layers: layers declare compatible runtimes and often bundle native dependencies compiled for the old operating system or language ABI; an AL2 to AL2023 move can break them.
• Bundled AWS SDKs: Node.js, Python and Ruby runtimes include an AWS SDK, but AWS recommends packaging the SDK modules you use in the deployment package or a layer, so a runtime change does not silently change SDK behaviour.
• Edge and vendor functions: functions deployed by third-party tools or marketplace solutions in your accounts, which nobody internally thinks of as theirs.

Finding affected systems and identities

Treat the notices as a prompt, not an inventory. AWS sends notices by three routes, each with gaps.

For a complete picture, use the method AWS documents: call ListFunctions (CLI list-functions) with FunctionVersion set to ALL, filter on the Runtime field and record FunctionArn, then repeat for every Region and every account, following the NextMarker pagination token. AWS Config advanced queries, run through an aggregator, give an organisation-wide view in one query but return only $LATEST. In practice, run the ListFunctions sweep from a read-only role assumed into each member account, and keep Config and Trusted Advisor as the continuous signal. See the AWS Config Guide and the AWS Security Hub Guide.

Then prioritise. AWS suggests two signals: last activity, from CloudWatch Logs DescribeLogStreams ordered by LastEventTime on the function's log group (LoggingConfig.LogGroup), and volume, from the AWS/Lambda Invocations metric summed over 14 days. Functions with zero invocations and no owner are candidates for deletion rather than upgrade, which removes their execution roles too.

The identity angle: each function runs as an IAM execution role, a non-human identity that often outlives the team that created it. Record the role for every affected function as part of the sweep. A runtime upgrade is the moment to confirm the role is still least privilege, owned and used; deleting a dead function should also retire its role and any secrets it reads. See the AWS IAM Policies and Roles Guide.

Migration options

Decision guidance: pick the target with the latest deprecation date your libraries support. A small team with a few dozen functions should upgrade straight to the newest GA runtime in one pass. A large estate should first fix the infrastructure as code templates (so nothing new is created on old runtimes), then migrate by business criticality, using the Config allow list to stop regressions. Pin the target runtime in templates and reviews rather than relying on console defaults.

While a function is on a supported runtime, Lambda's runtime management controls decide how patch versions arrive: Auto (the default, two-phase rollout), Function update (new runtime version applied only on UpdateFunctionCode or UpdateFunctionConfiguration) or Manual (pinned to a runtime version ARN). The current runtime version ARN appears on the INIT_START line in the function's CloudWatch logs. Manual mode is for short rollbacks of a bad patch, not for avoiding upgrades.

Testing and rollback

1. Freeze the baseline: publish a version of the current function and point a production alias at it, so you have an immutable copy on the old runtime.
2. Rebuild, do not just relabel: rebuild the package and layers against the target runtime (and AL2023 where relevant), with the AWS SDK and native modules pinned in the package.
3. Test outside production: run unit and integration tests in a non-production account, including cold starts, timeouts, memory, TLS connections to dependencies and every event source mapping.
4. Shift traffic gradually: publish the upgraded version and use weighted alias routing (or the CodeDeploy canary and linear options offered through SAM) to send a small share of traffic to it, watching Errors, Throttles, Duration and application logs.
5. Promote and clean up: move the alias fully to the new version, update infrastructure as code so the next deployment does not revert, and delete published versions you no longer need.
6. Roll back by alias: if the new version misbehaves, repoint the alias to the frozen version. AWS warns that after block function update you will not be able to revert a function's runtime setting to the deprecated runtime, so do the upgrade and the rollback rehearsal before that date.

For a bad runtime patch (not a version upgrade), switch the function's runtime management mode to Manual with the earlier runtime version ARN, then return to Auto once AWS ships a fix.

Risks of doing nothing

• Unpatched code paths: after deprecation AWS may stop security patches for the runtime and OS, and the language community has already stopped them. This is NIST SP 800-53 SA-22 (Unsupported System Components) territory.
• Frozen functions: after 31 August 2027 for most deprecated runtimes, a security fix, dependency bump or even a configuration change such as an environment variable or memory setting cannot be deployed without first changing runtime.
• Broken rebuilds: after block create, any stack that creates functions on the old runtime fails, including disaster recovery and new account vending.
• Quiet failure: AWS names certificate expiry as an example of an issue that can stop a deprecated function working; the failure surfaces as an outage with no deploy path.
• No support: AWS states functions on deprecated runtimes are not eligible for technical support.
• Audit findings: Security Hub Lambda.2 and equivalent checks flag them, and frameworks expect supported software (CIS Controls v8.1 Safeguard 2.2, PCI DSS v4.0.1 requirement 12.3.4 as mapped by AWS).

Framework mapping

For language versions outside Lambda (containers, virtual machines, build images), see the End-of-Life Language Runtimes guide.

Practitioner checklist

• Subscribe the right team, not just the primary contact, to AWS Health and enable Trusted Advisor weekly email for the deprecated runtimes check.
• Run a ListFunctions sweep with FunctionVersion ALL in every Region and account, recording runtime, package type, alias targets, execution role and owner tag.
• Track container image functions separately, because AWS sends no deprecation notices for them.
• Set an approved runtime list in the Config rule LAMBDA_FUNCTION_SETTINGS_CHECK and in infrastructure as code linting, and review it each time AWS updates the table.
• Delete functions with no invocations and no owner, together with their execution roles.
• Upgrade AL2 runtimes to AL2023 equivalents, rebuilding layers and native modules.
• Use published versions, aliases and weighted routing for every upgrade, and rehearse rollback.
• Finish all upgrades well before the block update date in the runtime table (31 August 2027 for most runtimes deprecated so far) and re-check the AWS page monthly.

Standards and references

• AWS: Lambda runtimes (deprecation policy and schedule)
• AWS: Retrieve data about Lambda functions that use a deprecated runtime
• AWS: Understanding how Lambda manages runtime version updates
• AWS: Security Hub CSPM controls for Lambda
• AWS: Config managed rule lambda-function-settings-check
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: AWS Lambda Security Guide · End-of-Life Language Runtimes · Patch Management Guide · AWS Config Guide · AWS IAM Policies and Roles Guide