AWS Lambdaでは、言語のサポートが終わったランタイムを「非推奨」にしたあと、段階的に操作を止めていきます。Node.js 20、Python 3.9・3.10、.NET 6、Amazon Linux 2ベースのカスタムランタイム（provided.al2）など、すでに非推奨になったランタイムの多くは、2027年7月29日に関数の新規作成が、8月31日に既存関数のコードと設定の更新が、そろってできなくなります。

関数そのものは8月31日を過ぎても動き続けます。困るのは障害や仕様変更のときです。コードを1行直したくてもデプロイできなくなります。2023年ごろに作ったバッチや連携処理が、Node.js 18やPython 3.9のまま残っている企業は少なくありません。本記事では、対象になるランタイムの一覧、自社の関数の洗い出し方、移行先の選び方と、上げるときに引っかかりやすい点を順に解説します。

想定読者

本記事は、次のような方を想定しています。

• AWSから「Lambda runtime deprecation」の通知メールを受け取り、何をすべきか整理したい方
• 外部に委託して作ったLambda関数が、どのランタイムで動いているか把握できていない情報システム担当者の方
• Node.js 20やPython 3.10のLambdaを抱えていて、いつまでに上げればよいか知りたい方
• Amazon Linux 2やRDSなど、AWS上のほかの期限とまとめて計画を立てたい方

---

Lambdaのランタイムは非推奨のあと3段階で止まる

ランタイムの期限は、1日で全部が止まるわけではありません。AWSの公式ドキュメントでは、次の3段階で操作が制限されます。

本来は、非推奨の30日後に作成ブロック、60日後に更新ブロックがかかる決まりです。ところが多くのランタイムでは、利用者の要望を受けてAWSがブロック日を延ばしました。その結果、時期の違うランタイムのブロック日が2027年7月29日（作成）と8月31日（更新）の2日にまとまっています。

更新ブロックのあとに困ること

更新ブロックのあとも関数は呼び出せますが、次の作業はできなくなります。

• バグの修正や、連携先APIの仕様変更に合わせたコードの修正
• 環境変数、メモリ、タイムアウトなど設定の変更
• 依存ライブラリの脆弱性への対応

AWSは、非推奨のランタイムは「現状のまま」提供するとしています。証明書の期限切れなどで、ある日突然正しく動かなくなるおそれもあると明記しています。サポート中のランタイムへの切り替えは更新ブロック後も可能です。ただ、その時点で動作確認をしていなければ、切り替えた関数がそのまま動く保証はありません。

---

2027年7月29日・8月31日に止まるランタイムの一覧

2026年11月時点のAWS公式ドキュメント（Lambda runtimes）をもとに、2027年のブロック日が決まっている主なランタイムを整理します。

すでに非推奨になっているランタイム

Node.js 14、Python 3.7、Java 8（Amazon Linux 1）、Go 1.x、Ruby 2.7などのさらに古いランタイムは、新規作成がすでにブロックされています。これらも、既存関数の更新は2027年8月31日に止まります。

これから非推奨になるランタイム

注意したいのはNode.js 22です。Node.js 20から1つ上げただけでは、2027年4月30日に再び非推奨になり、同じ8月31日に更新が止まります。今から上げるなら、Node.js 24を選ぶのが基本です。

Python 3.9〜3.11とJava（Amazon Linux 2版）は、OSであるAmazon Linux 2の終了に引きずられて期限が決まっています。Python 3.12以降とJavaの「.al2023」版は、Amazon Linux 2023ベースです。

---

自社の関数がどのランタイムで動いているかを洗い出す

移行の第一歩は、対象の関数を漏れなく数えることです。委託先が作った関数や、検証用に作ったまま残っている関数が見つかることもよくあります。

AWSからの通知を確認する

AWSは非推奨日の少なくとも180日前に、対象の関数を持つアカウントへ次の方法で知らせます。

• アカウントの主連絡先（プライマリコンタクト）へのメール
• AWS Health Dashboardの通知
• AWS Trusted Advisorの「非推奨のランタイムを使うLambda関数」チェック

ここで落とし穴があります。Health Dashboardの通知は、非推奨日の90日後に消えます。2026年4月30日に非推奨になったNode.js 20の通知は、すでに見えなくなっています。主連絡先のメールが退職者のアドレスのまま、ということもあります。通知が来ていないから対象がない、とは判断しないでください。

AWS CLIで一覧を取る

確実なのは、AWS CLIで関数の一覧を取ることです。AWSのドキュメントでは、次のコマンドが案内されています（ランタイムの識別子とリージョンは置き換えてください）。

aws lambda list-functions --function-version ALL --region ap-northeast-1 --output text --query "Functions[?Runtime=='nodejs20.x'].FunctionArn"

このコマンドはリージョンごと、アカウントごとに結果が分かれます。東京リージョンだけでなく、大阪リージョンやバージニア北部（us-east-1）にも関数がないか確認してください。CloudFrontと連携するLambda@Edgeは、us-east-1で作られています。複数のアカウントやリージョンをまとめて調べたい場合は、AWS Configの高度なクエリも使えます。

優先順位を付ける

関数が多い場合は、すべてを同時に上げる必要はありません。次の順で優先度を決めると進めやすくなります。

1. 直近14日間に呼び出されている関数（CloudWatchの呼び出し回数で確認）
2. 受発注、請求、外部連携など、止まると業務に響く関数
3. 修正の頻度が高い関数（更新ブロックの影響を最初に受ける）
4. しばらく呼び出されていない関数（使っていなければ、移行せずに削除する選択肢もある）

コンテナイメージで動かしている関数は、ランタイムの廃止通知が届きません。ベースイメージを作り直す責任も利用者側にあるため、一覧から漏れないよう別に数えておきます。

---

Lambda関数の棚卸しや移行の優先順位付けでお困りでしたら、c3index にお気軽にご相談ください。

---

移行先のランタイムを選ぶ

移行先は、次の非推奨日までの期間が長いものを選びます。2026年11月時点の主な移行先は次のとおりです。

Python 3.12（2028年10月31日まで）も選べます。ただ、3.13と3.14のほうが期限が8か月長く、移行の手間はほとんど変わりません。Javaはバージョンを上げられない事情があっても、Amazon Linux 2023ベースのjava8.al2023・java11.al2023・java17.al2023に移るだけで、期限は2029年6月30日まで延びます。

---

移行で引っかかりやすい点

ランタイムの切り替えは設定画面の1項目ですが、言語やOSの版が上がるため、そのまま動くとは限りません。よく問題になるのは次の点です。

Node.js：コールバック形式のハンドラーはNode.js 24で使えない

AWSのドキュメントでは、コールバック形式のハンドラー（引数にcallbackを取る書き方）が使えるのはNode.js 22までです。Node.js 24では、非同期処理をasync関数で書く必要があります。古い関数ほどこの書き方が残っているため、切り替え前にコードを確認してください。

// Node.js 24 で使えない書き方
exports.handler = (event, context, callback) => { callback(null, result); };

// Node.js 24 で使う書き方
exports.handler = async (event) => { return result; };

Node.js 18以前から上げる場合：証明書の読み込みが変わる

Node.js 18までのランタイムは、RDSなどAWSのCA証明書を自動で読み込んでいました。Node.js 20以降は既定では読み込みません。RDSにTLSで接続している関数は、上げた直後に接続エラーになることがあります。環境変数 NODE_EXTRA_CA_CERTS に /var/runtime/ca-cert.pem を指定すれば、従来と同じ動きにできます。

Python：OSが変わるため、ネイティブのライブラリを作り直す

Python 3.11までのランタイムはAmazon Linux 2、3.12以降はAmazon Linux 2023で動きます。C言語の拡張を含むライブラリ（画像処理、暗号、DBドライバーなど）をレイヤーに入れている場合は、新しい環境向けにビルドし直す必要が出ることがあります。また、Python 3.12では標準ライブラリからdistutilsが削除されました。古いライブラリが内部で使っていると、読み込みの時点でエラーになります。

共通：ランタイム同梱のSDKに頼らない

Node.jsとPythonのランタイムにはAWS SDKが同梱されています。ただし、同梱される版はランタイムによって違います。AWSは、使うSDKをデプロイパッケージに含めることを推奨しています。移行を機に、依存ライブラリをすべてパッケージに含める形に直しておくと、次の移行が楽になります。

---

2027年8月31日から逆算した進め方

2026年11月から数えると、作成ブロックまで約9か月、更新ブロックまで約10か月あります。関数が数十本ある場合、次のような流れが現実的です。

1. 2026年11〜12月：全アカウント・全リージョンの関数を洗い出し、ランタイム別・重要度別の一覧を作る
2. 2027年1〜2月：コールバック形式やネイティブライブラリなど、修正が必要な関数を特定し、工数を見積もる
3. 2027年3〜5月：検証環境でランタイムを切り替え、動作を確認する
4. 2027年6月まで：本番の切り替えを終える。7月以降は、想定外の不具合に備えた予備の期間にする

本番で切り替えるときは、関数のバージョンとエイリアスを使って、問題があればすぐ元に戻せるようにしておきます。更新ブロックのあとは、非推奨のランタイムへ戻す操作がブロックされることがあります。戻せるうちに切り替えを終え、不具合が出たら元のランタイムで直せる状態にしておきます。

同じ時期には、Amazon Linux 2023の標準サポート終了（2027年6月30日）や、Windows Server 2016のサポート終了（2027年1月12日）も控えています。EC2やRDSの更新とまとめて計画すると、検証や切り替えの手間を一度で済ませられます。

---

よくある質問

Q. 非推奨になると、関数は止まりますか？

A. 止まりません。非推奨のあとも、更新ブロックのあとも、関数は呼び出せます。ただし、セキュリティ更新と技術サポートがなくなります。更新ブロックのあとは、コードも設定も変えられなくなります。

Q. CloudFormationやSAMで管理していれば、非推奨のランタイムでも作れますか？

A. 作成ブロック日（2027年7月29日）までは、AWS CLI、AWS SAM、CloudFormationなどから作成と更新ができます。非推奨日から使えなくなるのは、Lambdaのコンソールでの操作です。作成ブロック日を過ぎると新規作成ができなくなり、更新ブロック日（2027年8月31日）を過ぎると既存関数の更新もできなくなります。

Q. Node.js 20をNode.js 22に上げれば当面大丈夫ですか？

A. おすすめしません。Node.js 22は2027年4月30日に非推奨になり、更新ブロックはNode.js 20と同じ2027年8月31日です。今から上げるなら、2028年4月30日まで使えるNode.js 24を選んでください。

Q. 委託先が作った関数で、中身が分かりません。どうすればよいですか？

A. まずAWS CLIで関数とランタイムの一覧を取り、呼び出し回数とログから実際に使われているかを確認します。使われている関数は、コードを取得してコールバック形式やネイティブライブラリの有無を調べます。委託先に連絡が付かない場合でも、AWSアカウントの管理権限があれば、関数のコードは取得できます。

---

まとめ

本記事のポイントをまとめます。

• サポートが終わったLambdaランタイムの多くは、2027年7月29日に新規作成、8月31日に既存関数の更新ができなくなる
• 関数は動き続けるが、更新ブロックのあとは障害対応や仕様変更のための修正ができなくなる
• Health Dashboardの通知は非推奨の90日後に消えるため、AWS CLIで全アカウント・全リージョンの関数を洗い出す
• Node.js 22はすぐ期限が来るため、移行先はNode.js 24、Python 3.13・3.14、Java 21・25などを選ぶ
• コールバック形式のハンドラー、証明書の読み込み、ネイティブライブラリの3点を、切り替え前に確認する

2027年8月31日までの時間は、思ったほど長くありません。関数の本数が分からない段階でも、洗い出しから始めることをおすすめします。

---

c3index に相談する

c3indexは、AWSアドバンストティアサービスパートナーとして、Lambda関数の棚卸しから、移行先ランタイムの選定、コードの修正と検証、本番の切り替え、移行後の運用代行までを一貫してご支援しています。委託先が作った関数の中身が分からない、何本あるか把握できていないといった段階のご相談も、まずはお気軽にお問い合わせください。