LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AWS Lambdaのランタイムサポート終了とは — 廃止ポリシーの全体像

AWS Lambdaのランタイムサポート終了とは、使用中の言語ランタイムがAWSのセキュリティパッチ提供・技術サポートの対象から外れることを指します^*1。対象となるのはNode.js・Python・Javaなど、Lambdaが提供する複数の言語ランタイムです。

各ランタイムを構成する言語本体やOS（Amazon Linux）は、開発コミュニティの長期サポート（LTS）を終える時期を迎えます^*1。AWSはその時期に合わせてランタイムを廃止すると公式に定めています^*1。

ランタイムが廃止された後も、既存のLambda関数の呼び出し自体は無期限に続く仕組みです^*1。しかし廃止後はAWSによるセキュリティパッチの適用が止まり、関数は技術サポートの対象外になります^*1。さらに一定期間が過ぎると、新規関数の作成、続いて既存関数の更新が順にブロックされる仕組みです^*1。

この廃止プロセスは、EC2やRDSのようなインフラ寄りのEOL（End of Life、サポート終了）対応とは性質が異なります。Lambdaはマネージドサービスであり、AWS側が用意した期限までに、利用者側がコードとデプロイ設定を能動的に更新することが前提になっている点が特徴です^*1。

廃止から更新不可までの3段階：通知・廃止・作成禁止・更新禁止

AWS Lambdaのランタイム廃止は、単発のイベントではなく複数の段階を経て進みます。公式ドキュメントでは、この流れを4つのフェーズに整理しています^*1。

第一段階は「廃止通知期間」です。AWSは廃止予定日の少なくとも180日前に通知を送ります^*1。

対象ランタイムを使用する関数がある場合、メール・AWS Health Dashboard・AWS Trusted Advisorを通じて知らされる仕組みです^*1。この通知には、廃止対象となる関数の$LATESTバージョン一覧が含まれます^*1。

第二段階が「廃止日」です。この時点でAWSはそのランタイムへのセキュリティパッチ提供と技術サポートを終了します^*1。ただし関数の実行自体は継続でき、すぐに利用できなくなるわけではありません^*1。

第三段階は「新規関数の作成禁止」で、廃止日から少なくとも30日後に発生します^*1。第四段階は「既存関数の更新禁止」で、廃止日から少なくとも60日後という設定です^*1。

更新禁止の期限を過ぎると、コードの再デプロイや設定変更ができなくなり、廃止ランタイムに戻すこともできなくなります^*1。この期限は実際にはランタイムごとに30日・60日より延長される場合があるため、公式ページの一覧表で個々の日付を確認しておきましょう^*1。

AWSはこの仕組みについて、Lambda関数のバージョンとエイリアス機能を使い、切り戻しが可能な形で段階的に更新することを推奨しています^*1。更新禁止の期限を過ぎてから慌てて対応すると、切り戻しの選択肢がない状態で本番環境の変更を迫られることになります。

Node.js・Python・Javaなど、主要ランタイムの廃止時期の考え方

Lambdaがサポートするランタイムには、Node.js・Python・Java・Ruby・.NETなど複数の言語があります。各言語で複数のメジャーバージョンが並行して提供されており、それぞれに個別の廃止日・作成禁止日・更新禁止日が設定されています^*1。

以下は2026年7月時点でAWS公式ページに掲載されている情報をもとにした一部の例です。個別の日付は変更される可能性があるため、対応計画を立てる際は事前に公式ページの最新表を確認してください^*1。

この一覧からわかるとおり、廃止時期は言語バージョンごとにばらつきがあり、複数のランタイムを併用している組織ほど管理対象が増えます。加えて見落としやすいのが、ランタイムの土台となるOS「Amazon Linux 2」自体が2026年6月30日にEOL（End of Life）を迎える点です^*1。

AL2をベースとするJava 8・11・17、Python 3.10・3.11、provided.al2には猶予があります^*1。この期日以降も一定範囲のセキュリティ更新を継続する措置がとられているのが実情です^*1。

ただしAWSは、Amazon Linux 2023ベースのランタイムへの早期移行を推奨しています^*1。言語バージョンの廃止スケジュールとOSのEOLという2つの時間軸を、同時に把握しておくことが欠かせません。

対応を放置すると生じる3つのリスク

ランタイム更新への対応を先送りすると、段階的に深刻さが増す3つのリスクに直面します。それぞれ発生するタイミングが異なるため、区別して理解することが大切です。

リスク1：セキュリティパッチが止まる

廃止日を迎えると、AWSはそのランタイムへのセキュリティパッチ適用を停止します^*1。廃止後のランタイムは「現状有姿（as-is）」で提供され、バグ・エラー・脆弱性を含む可能性があると公式に明記されています^*1。攻撃者に狙われやすい既知の脆弱性が、パッチなしのまま放置される状態です。

リスク2：技術サポートの対象から外れる

廃止済みランタイムを使う関数は、AWSの技術サポートを受けられなくなります^*1。本番障害が発生した際に、ランタイム起因の不具合であってもAWS側の支援を仰げない状況になり、自社もしくは委託先の技術力だけで解決する必要が生じます。

リスク3：更新禁止後は変更もロールバックもできなくなる

更新禁止の期限を過ぎると、関数のコードや設定を一切変更できなくなります^*1。この状態になってから初めて「新しいランタイムに切り替えたい」と考えても、その関数自体を作り直すほかありません。

加えて、廃止後の関数は証明書の期限切れなど別の要因で動作が不安定になる可能性があるとも案内されています^*1。更新期限内に手を打つかどうかで、後々の対応コストが大きく変わってきます。

コンテナイメージ運用は廃止通知が届かない落とし穴

Lambda関数には、zipファイルでデプロイする方式に加えて、コンテナイメージでデプロイする方式があります。この2つは、ランタイム廃止への向き合い方が根本的に異なるので注意が必要です。

zipファイル方式の関数は、廃止が近づくとメール・Health Dashboard・Trusted Advisorで通知が届きます^*1。ところがコンテナイメージ方式の関数には、こうした廃止通知の仕組みが用意されていません^*1。

AWSの責任分担モデルでも、この点は明記されています^*1。「コンテナイメージ利用者は自らベースイメージの廃止スケジュールを把握し、最新のベースイメージで再ビルド・再デプロイする責任を負う」という内容です^*1。

つまりコンテナイメージ運用の組織は、能動的に公式ドキュメントを定期チェックしなければ、廃止に気づかないまま古いベースイメージを使い続けるリスクを抱えています。運用担当者が異動・退職した場合や、複数のAWSアカウントに関数が分散している場合は、この見落としがさらに起こりやすくなります。

ランタイム更新作業の具体的な流れ

ランタイム更新は、単にコンソール上でランタイムのプルダウンを切り替えるだけの作業ではありません。実務では次のような工程を踏む必要があります。

1. 対象関数の棚卸し：AWSアカウント全体で、どの関数がどのランタイムを使用しているかを洗い出します。
2. 依存関係の影響確認：使用しているSDK・ライブラリが新しい言語バージョンに対応しているかを確認します。
3. コードの改修：言語仕様の変更や非推奨APIの置き換えなど、新バージョンで動作するようにコードを修正します。
4. IaC（Infrastructure as Code）定義の更新：CloudFormation・Terraform利用時は、定義ファイル側の修正も必要です。
5. テスト環境での検証：単体テスト・結合テストで、新ランタイム上での挙動を確認します。
6. バージョン・エイリアスを使った段階移行：本番環境ではエイリアスの切り替えで段階的にトラフィックを移し、問題があれば旧バージョンに戻せる状態を保ちます^*2。

AWSのコンピュートブログでも、ランタイムアップグレードは事前のテストを行ったうえで本番環境に適用することが推奨されています^*2。関数のバージョンとエイリアスを活用した、切り戻し可能な移行手順も紹介されているのが特徴です^*2。関数の数が多い組織ほど、この一連の工程を関数ごとに繰り返す必要があり、対応にかかる工数は保有する関数の規模に比例して増えていきます。

内製対応と外部委託、何が違うのか

ランタイム更新は「言語を新しいバージョンに変える」という一見シンプルな作業に見えます。しかし実際には、対象言語ごとの仕様変更・依存ライブラリの互換性・本番環境への適用手順という3つの専門性が同時に問われるでしょう。内製で対応する場合と外部委託する場合の違いを整理します。

内製対応が向いているのは、使用ランタイムが単一で関数数が少なく、社内に該当言語の担当者が明確にいる場合です。一方で、複数言語・複数アカウントにまたがる棚卸しや、通常業務と並行した計画的な移行が難しい場合は、外部委託によって専任の体制を確保する選択肢が現実的になります。

外部委託先の選び方と内製に必要なスキル・工数

内製でランタイム更新に対応する場合、AWS Lambdaのサービス仕様の理解が必要です。加えて、対象言語（Node.js・Python・Javaなど）のバージョン間差分を把握したエンジニアも欠かせません。

関数の棚卸し・依存関係の調査・コード改修・テスト・段階移行という一連の工程を、通常の開発業務と並行して進められる体制が求められます。使用ランタイムの種類が増えるほど、必要な言語知見の幅も広がるでしょう。

外部委託を検討する場合は、次の観点で委託先を評価することをお勧めします。

• 対象となる言語（Node.js・Python・Javaなど）でのLambda運用・改修実績があるか。
• 複数アカウント・複数リージョンにまたがる棚卸しに対応できるか。
• バージョン・エイリアスを使った段階移行やロールバック手順を提案できるか。
• 更新後の保守・運用まで継続して任せられる体制があるか。

特に本番環境で稼働する関数の更新は、テスト不足のまま切り替えると業務システムの停止につながる可能性があります。委託先には、改修だけでなく段階移行・ロールバック計画まで含めた提案力があるかを確認することが大切です。

LASSICのIT事業部では、をもとに、AWS環境の保守・運用を元請として受託しています。詳細はIT運用保守支援サービスページをご覧ください。

まとめ：ランタイム更新を計画的に進めるための3つの判断軸

本稿では、AWS Lambdaのランタイムサポート終了の仕組みと対応リスク、更新作業の内容、内製・外部委託それぞれの特徴を整理しました。要点を3つに集約します。

第一に、ランタイム廃止は「廃止通知（180日前）→廃止→作成禁止（30日後〜）→更新禁止（60日後〜）」という段階を踏んで進みます^*1。更新禁止の期限を過ぎると変更もロールバックもできなくなるため、期限から逆算した対応が欠かせません。

第二に、コンテナイメージ運用の関数には廃止通知が届かない点に注意が必要です^*1。定期的な棚卸しの仕組みを自組織で持つか、外部の運用パートナーに監視を任せるかを検討する必要があります。

第三に、対象言語や関数数が多く社内の対応工数を確保しづらい場合は、外部委託によって専任体制を確保する選択肢が現実的です。委託先を選ぶ際は、対象言語の実績・複数アカウント対応力・段階移行の提案力を軸に評価することをお勧めします。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS Documentation「Lambda runtimes」（Runtime deprecation policy／Supported runtimes／Runtime use after deprecation／Shared responsibility model 各節を含む）URL: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html（2026年7月時点の掲載内容に基づく。個別ランタイムの廃止日・作成禁止日・更新禁止日は変更される場合があるため最新表を要確認）
2. *2　出典：AWS Compute Blog「Managing AWS Lambda runtime upgrades」URL: https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/

Tweet