[小ネタ]Lambda Managed Instancesでは実行環境が「フリーズ」しないことを確認してみた #AWSreInvent

[小ネタ]Lambda Managed Instancesでは実行環境が「フリーズ」しないことを確認してみた #AWSreInvent

Lambda Managed Instancesを利用した場合は通常のLambda実行環境と異なり「フリーズ」はしません。
2025.12.06

リテールアプリ共創部@大阪の岩田です。

Lambda Managed Instancesを利用する場合、実行環境のライフサイクルは通常のLambdaとは異なります。
両者の違いについては公式ドキュメントに詳細が記載されています。

通常の実行環境の場合はこちら。
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html

Lambda Managed Instancesの場合はこちらです。
https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-execution-environment.html

通常のLambda実行環境については上記ドキュメントにも記載されている通りInvoke完了後に「フリーズ」することが知られています。サーバーレスで完全従量課金のLambdaを支える仕様ですね。

Each phase starts with an event that Lambda sends to the runtime and to all registered extensions. The runtime and each extension indicate completion by sending a Next API request. Lambda freezes the execution environment when the runtime and each extension have completed and there are no pending events.

これに対してLambda Managed InstancesにおいてはInvoke完了後に「フリーズ」するという記載はどこにもありません。また、裏で実行されるEC2に対して課金が発生するという料金体系を考えると、特に「フリーズ」させる意義は薄いように思います。ということで実際にLambda Managed Instancesの実行環境は「フリーズ」するのか確認してみました。

やってみる

ランタイムにNode.js 24.xを選択し、通常のLambd実行環境とLambda Managed Instancesの実行環境それぞれで以下のコードを実行してみます。

console.log('init');
let count = 0;

setInterval(() => {
  count++;
  console.log(`${count}回目の実行 - ${new Date().toLocaleString()}`);
}, 10000);

export const handler = async (event) => {
  // TODO implement
  const response = {
    statusCode: 200,
    body: JSON.stringify('Hello from Lambda!'),
  };
  return response;
};

initフェーズでsetIntervalを仕込み、10秒に1回ログを出力するだけの処理です。

通常のLambda 実行環境の場合

まず通常のLambda実行環境の場合です。テスト実行後にしばらくしてからログを確認すると結果は以下の通りでした。

通常のLambda実行環境で試した場合のログ

xx回目の実行というログが出力されていないことが分かります。

Lambda Managed Instancesの場合

続いてLambda Managed Instancesの場合です。コードをデプロイ後にしばらくしてからログを確認すると結果は以下の通りでした。
※テスト実行は行っていません。

Lambda Managed Instances実行環境で試した場合のログ-1

Lambda Managed Instances実行環境で試した場合のログ-2

Lambda Managed Instances実行環境で試した場合のログ-3

xx回目の実行というログが継続的に出力されていることが分かります。実行環境がフリーズしていないということですね!

ちなみに"platform.initReport"のログはEC2の台数とイコールになる3件しか出力されていませんでしたが、Lambdaのコードから出力したinitというログは24件出力されていました。ランタイムによって挙動は異なりますが、Lambda Managed Instancesを利用した場合は実行環境ごとに複数のランタイムワーカーが起動するためです。

Bootstrap the runtime entrypoint. Runtime spawns the configured number of runtime workers (implementation depends on runtime)

https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-execution-environment.html#lambda-managed-instances-execution-lifecycle

Node.jsの場合はランタイムワーカー = ワーカースレッドであり、init処理はワーカースレッドごとに実行されるためです。

For Node.js runtimes, Lambda Managed Instances uses worker threads with async/await-based execution to handle concurrent requests. Function initialization occurs once per worker thread.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-nodejs-runtime.html

まとめ

Lambda Managed Instancesを利用した場合、実行環境は「フリーズ」しないことを確認してみました。initフェーズが実行されるのはランタイムワーカー毎である点なども通常のLambdaとは異なるので、利用時には注意が必要ですね。

参考

この記事をシェアする

FacebookHatena blogX

関連記事