AWSのLambdaランタイム更新に対応する
はじめに
AWSのサーバーレスアーキテクチャを使ったシステム開発をしていると、時々AWSの仕様変更に対応する必要が出てきます。今回は、Lambdaのランタイムサポート終了に伴う対応について共有します。
私が関わっているプロジェクトでは、AWSのAppSyncを構築していました。AppSyncではDynamoDBから直接データを取得する方法と、Lambda関数を使ってデータを入出力する方法を併用しています。
ある日、新しくLambda関数を追加する必要が出てきたのですが、デプロイ時に思わぬエラーに遭遇しました。その対応方法について紹介します。
背景
既存の環境
プロジェクトのserverlessフレームワークの設定では、package.jsonにNode.js 14を使用するという定義がされていました。これまではこの設定で問題なく動作していました。
問題発生
新しいLambda関数の追加
今回、新たな機能追加のために新しいLambda関数を実装する必要が出てきました。ローカル環境では問題なく動作することを確認し、いざデプロイしようとしたところ、以下のエラーが発生しました:
Resource handler returned message: "The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use a supported runtime while creating or updating functions. (Service: Lambda, Status Code: 400, Request ID: xxxx)" (RequestToken: xxxx, HandlerErrorCode: InvalidRequest)
原因
エラーメッセージを見ると、「nodejs14.xのランタイムはもうサポートされていない」と書かれています。AWSの公式ドキュメントを確認したところ、2025年3月時点では、Lambdaのランタイムは18以上が必要とのことでした。
解決方法
個別のLambda関数にランタイムを指定
今回実装したLambda関数は、Node.js 20のランタイムでも動作することをローカルで確認していました。そこで、serverless.ymlファイル内の各Lambda関数の定義に、明示的にランタイムを指定することで対応しました。
変更前:
functions:
getXXXXXXXX:
handler: src/handler.getXXXXXXXX
変更後:
functions:
getXXXXXXXX:
handler: src/handler.getXXXXXXXX
runtime: nodejs20.x
この変更により、新しく追加するLambda関数だけ、サポートされているNode.js 20.xのランタイムを使用するように指定しました。
Node.js 14のモジュールでもNode.js 20のランタイムで動作する理由
「package.jsonではNode.js 14を指定しているのに、なぜNode.js 20のランタイムで動作するのか?」という点について考えます。
Node.jsの下位互換性
Node.js 14から20への主な変更点は、セキュリティ強化、パフォーマンス向上、新機能の追加が中心であり、既存のAPIの多くは互換性を保っています。
今回利用した機能は、バージョン間で問題なく動作するものでした。
すべてのケースでこれが当てはまるわけではなく、特に以下のような場合は注意が必要です:
- 非推奨になったAPIや削除されたAPIを使用している場合
- Node.jsの内部実装に依存するコードを書いている場合
- 特定のバージョンでのみ利用可能な実験的機能を使用している場合
検証結果
この変更を加えた後、再度デプロイを試みたところ、無事成功しました。また、実際の動作検証も問題なく完了し、期待通りの動作を確認できました。
まとめ
今回は、AWSのLambdaランタイムのサポート終了に伴う対応について紹介しました。
本来であれば、プロジェクト全体のNode.jsバージョンを上げることが望ましいですが、既存の多くの関数に影響を与える可能性があるため、今回は新規追加の関数のみに対して個別にランタイムを指定するという対応を取りました。
この方法は一時的な対応策ですが、以下のメリットがあります:
- 既存の関数に影響を与えずに新機能を追加できる
- 段階的にランタイムの移行を進められる
- 緊急時の対応として比較的簡単に実装できる
最終的には、プロジェクト全体のNode.jsバージョンを上げることを検討すべきですが、短期的な解決策としてこのアプローチも有効であることがわかりました。
今回のような部分的な対応も選択肢の一つとして検討してもよいかも知れません。
Discussion