developersIO
AWS Lambda 関数エイリアスの実行環境を任意のタイミングで再起動する方法を確認してみた

AWS Lambda 関数エイリアスの実行環境を任意のタイミングで再起動する方法を確認してみた

結論: $LATEST の環境変数を更新→関数バージョンを新規発行→エイリアスに新バージョンを設定→ルーティング設定の解除をポーリングで待機、で出来ました。
AWS LambdaAWS CDKAmazon API Gateway
FacebookHatena blogX
2026.01.12

こんにちは、製造ビジネステクノロジー部の若槻です。

結合テスト実施時など、AWS Lambda で実行環境を再利用したくない場合があります。その際によく知られたテクニックとして、関数の環境変数をダミーのキー値で更新して実行環境を再起動させる方法があります。これにより、Lambda 関数の実行環境が強制的に再起動され、クリーンな状態で関数を実行できます。

さて、AWS Lambda にはバージョンやエイリアスという機能があり、Lambda 関数のカナリアリリースや Provisioned Concurrency 利用時などに活用されます。


テクニカルインストラクターと学ぶ AWS Lambda 関数のバージョンとエイリアス - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS より

それではその Lambda 関数エイリアスに対しても同様に任意のタイミングで実行環境の再起動は可能なのでしょうか？ 気になったので実際に試して確認してみました。

やってみた

検証用の Lambda 関数およびエイリアスを作成し、API Gateway REST API から呼び出せるようにします。それらを利用して、エイリアスの実行環境が再起動されるかを確認してみます。

ハンドラーコード

Lambda 関数のハンドラーコードは以下の通りです。

src/handler.ts
const startTime = new Date().toISOString(); // グローバル変数で実行環境の起動時間を記録

export const handler = async (): Promise<Object> => {
  return {
    statusCode: 200,
    body: JSON.stringify({
      startTime,
      invokedTime: new Date().toISOString(),
    }),
  };
};

ハンドラー外の処理は実行環境の起動時に一度だけ実行されます。ハンドラー外でグローバル変数を設定しレスポンスで返すことにより、実行環境が再起動したのかを確認しやすくしています。

インフラ実装

インフラは AWS CDK で実装します。コードは以下の通りです。

lib/sample-stack.ts
import * as cdk from "aws-cdk-lib";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as lambda_nodejs from "aws-cdk-lib/aws-lambda-nodejs";
import { Construct } from "constructs";

export class SampleStack extends cdk.Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    /**
     * Lambda 関数
     */
    const sampleFunction = new lambda_nodejs.NodejsFunction(
      this,
      "SampleFunction",
      {
        entry: "src/handler.ts",
      },
    );

    /**
     * Lambda エイリアス
     */
    const sampleFunctionAlias = new lambda.Alias(this, "SampleFunctionAlias", {
      aliasName: "Prod",
      version: sampleFunction.currentVersion,
      provisionedConcurrentExecutions: 5, // Provisioned Concurrency が設定されたエイリアスを想定
    });

    /**
     * API Gateway Rest API Lambda プロキシ統合
     */
    new apigateway.LambdaRestApi(this, "SampleApi", {
      handler: sampleFunctionAlias, // REST API がエイリアスを呼び出すように設定
    });
  }
}

上記をデプロイすると、関数エイリアスを呼び出す API Gateway REST API が作成されます。

関数をマネジメントコンソールから確認すると、Prod エイリアスが設定され、Provisioned Concurrency も有効化されています。設定されている関数バージョンが 1 では無いのは、CDK デプロイ時に自動でバージョンがインクリメントされるためです。（今回既に何度かデプロイを行っているため、バージョン 1 以降のバージョンが設定されています。）

動作確認

通常時はエイリアスの実行環境が再利用されることを確認

まず、通常時はエイリアスの実行環境が再利用されることを確認します。

REST API を連続で呼び出すと、以下のようなレスポンスが返ってきます。invokedTime が更新されている一方で、startTime は同じ値が返ってきています。つまり実行環境は再利用されている、と言うことが確認できます。

$ curl https://${API_ID}.execute-api.ap-northeast-1.amazonaws.com/prod
{"startTime":"2026-01-12T07:07:04.239Z","invokedTime":"2026-01-12T07:45:17.637Z"}%
$ curl https://${API_ID}.execute-api.ap-northeast-1.amazonaws.com/prod
{"startTime":"2026-01-12T07:07:04.239Z","invokedTime":"2026-01-12T07:45:19.696Z"}

エイリアスの実行環境を再起動できるか確認

それでは、エイリアスの実行環境を再起動できるか試してみます。

まず現在のエイリアスの関数バージョンを取得します。後続の切り戻しで使用します。

$ EXISTING_VER=$(aws lambda get-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME} --query 'FunctionVersion' --output text)
$ echo ${EXISTING_VER}
5

関数の $LATEST バージョンの環境変数を更新します。

$ aws lambda update-function-configuration --function-name ${FUNCTION_NAME} \
  --environment "{\"Variables\":{\"TEST\":\"$(date -u +%Y-%m-%dT%H:%M:%S.000Z)\"}}"

念のため再起動状況を確認すると、この時点でも startTime は変わらず同じ値が返ってきており、実行環境は再起動されていません。

$ curl https://${API_ID}.execute-api.ap-northeast-1.amazonaws.com/prod
{"startTime":"2026-01-12T07:07:04.239Z","invokedTime":"2026-01-12T07:45:50.080Z"}

テスト用の関数バージョンを発行し、発行されたバージョンを記録します。

$ TEST_VER=$(aws lambda publish-version --function-name ${FUNCTION_NAME} --query 'Version' --output text)
$ echo $TEST_VER
6

念のため再起動状況を確認すると、この時点では startTime は変わらず同じ値が返ってきており、実行環境は再起動されていません。

$ curl https://${API_ID}.execute-api.ap-northeast-1.amazonaws.com/prod
{"startTime":"2026-01-12T07:07:04.239Z","invokedTime":"2026-01-12T07:46:15.751Z"}

エイリアスに対して、先ほど発行したバージョンを設定します。

$ aws lambda update-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME} --function-version ${TEST_VER}
{
    "AliasArn": "arn:aws:lambda:ap-northeast-1:XXXXXXXXXXXX:function:Sample-SampleFunction7DB1D36A-KZtPV8JOPRdt:Prod",
    "Name": "Prod",
    "FunctionVersion": "6",
    "Description": "",
    "RevisionId": "92a3f462-7ad7-47f7-8cbc-b9aaf812945e"
}

マネジメントコンソールからエイリアスの設定を確認すると、先ほど発行したバージョンが 0%、以前のバージョンが 100% となっており、エイリアスの関数バージョンのルーティングの切り替えが開始されていることが確認できます。

ルーティングの切り替え状況は、CLI 上では次のように確認できます。メインバージョンが 6 であるにもかかわらず、RoutingConfig によってバージョン 5 に 1.0 (100%) の重みが設定されている状態です。よって切り替えはまだ完了していません。

$ aws lambda get-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME}
{
    "AliasArn": "arn:aws:lambda:ap-northeast-1:XXXXXXXXXXXX:function:Sample-SampleFunction7DB1D36A-KZtPV8JOPRdt:Prod",
    "Name": "Prod",
    "FunctionVersion": "6",
    "Description": "",
    "RoutingConfig": {
        "AdditionalVersionWeights": {
            "5": 1.0
        }
    },
    "RevisionId": "7115cb8b-dba9-4535-9c0e-fce3e8af2992"
}

ポーリングでルーティング設定の解除を待ちます。ルーティング設定が解除されると、エイリアスの関数バージョンが完全に新しいバージョンに切り替わったことになります。

while true; do
  ROUTING_CONFIG=$(aws lambda get-alias \
    --function-name ${FUNCTION_NAME} \
    --name ${ALIAS_NAME} \
    --query 'RoutingConfig' --output json)

  if [ "$ROUTING_CONFIG" = "null" ] || [ "$ROUTING_CONFIG" = "{}" ]; then
    echo "Success: RoutingConfig is cleared."
    break
  fi

  echo "Still waiting... Current RoutingConfig: ${ROUTING_CONFIG}"
  sleep 2
done

また、バージョン切り替え直後は Provisioned Concurrency がまだ新しいバージョンに割り当てられていない状態となっています。

Lambda 関数には Provisioned Concurrency という機能があり、事前に Lambda 関数の実行環境を準備しておくことでコールドスタートを調整するのに役立ちます。ただしこの機能を使用している場合でエイリアスのバージョンを新しいものに一気に切り替えると、切り替え後のバージョンの実行環境が用意される前に大量にリクエストが来てしまい、リリース直後にコールドスタートが頻発する可能性があります。

Provisioned Concurrency の割り当て状況は次のコマンドで確認できます。ステータスが READY になっていれば、Provisioned Concurrency の割り当てが完了しています。こちらも必要に応じてポーリングを行うと良いでしょう。（ただしルーティングの切り替えが完了していれば、Provisioned Concurrency の割り当ても完了している場合が多いでしょう。）

$ aws lambda get-provisioned-concurrency-config \
    --function-name ${FUNCTION_NAME} \
    --qualifier ${ALIAS_NAME}
{
    "RequestedProvisionedConcurrentExecutions": 5,
    "AvailableProvisionedConcurrentExecutions": 5,
    "AllocatedProvisionedConcurrentExecutions": 5,
    "Status": "READY",
    "LastModified": "2026-01-12T09:02:30+0000"
}

Provisioned Concurrency の割り当てが完了したらステータスが READY となります。

テスト用の切り替えが完了したので改めて API を呼び出すと、startTime が更新されており、実行環境がちゃんと再起動されていますね！

$ curl https://${API_ID}.execute-api.ap-northeast-1.amazonaws.com/prod
{"startTime":"2026-01-12T07:46:41.460Z","invokedTime":"2026-01-12T07:49:51.481Z"}

既存のバージョンへの切り戻し

テスト実施後は既存のバージョンへの切り戻しを行いましょう。

先ほど取得した既存のバージョンをエイリアスに設定します。

$ aws lambda update-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME} --function-version ${EXISTING_VER}
{
    "AliasArn": "arn:aws:lambda:ap-northeast-1:XXXXXXXXXXXX:function:Sample-SampleFunction7DB1D36A-KZtPV8JOPRdt:Prod",
    "Name": "Prod",
    "FunctionVersion": "5",
    "Description": "",
    "RevisionId": "ac81ae5d-369f-4469-bc8c-e837339337b8"
}

切り替え時と同様に、ポーリングでルーティング設定の解除を待ちます。

while true; do
  ROUTING_CONFIG=$(aws lambda get-alias \
    --function-name ${FUNCTION_NAME} \
    --name ${ALIAS_NAME} \
    --query 'RoutingConfig' --output json)

  if [ "$ROUTING_CONFIG" = "null" ] || [ "$ROUTING_CONFIG" = "{}" ]; then
    echo "Success: RoutingConfig is cleared."
    break
  fi

  echo "Still waiting... Current RoutingConfig: ${ROUTING_CONFIG}"
  sleep 2
done

テストに使用した古いバージョンは残ったままとなるので、不要であれば削除します。

$ aws lambda delete-function --function-name ${FUNCTION_NAME} --qualifier ${TEST_VER}
{
    "StatusCode": 204
}

関数のバージョン一覧を取得してみると、テスト用のバージョンが削除され、既存のバージョンおよび $LATEST バージョンのみが残っていることが確認できました。

$ aws lambda list-versions-by-function --function-name ${FUNCTION_NAME} --query 'Versions[].Version' --output text
$LATEST 5

手順まとめ

今回紹介したコマンドによりエイリアスの実行環境を再起動する手順をまとめます。

切り替え手順

# 0. 事前準備: 既存のバージョンを取得
EXISTING_VER=$(aws lambda get-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME} --query 'FunctionVersion' --output text)

# 1. 関数の $LATEST バージョンの環境変数を更新
aws lambda update-function-configuration --function-name ${FUNCTION_NAME} \
  --environment "{\"Variables\":{\"TEST\":\"$(date -u +%Y-%m-%dT%H:%M:%S.000Z)\"}}"

# 2. テスト用の関数バージョンを発行
TEST_VER=$(aws lambda publish-version --function-name ${FUNCTION_NAME} --query 'Version' --output text)

# 3. エイリアスに対して、発行したバージョンを設定
aws lambda update-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME} --function-version ${TEST_VER}

# 4. ルーティング設定の解除をポーリングで待機
while true; do
  ROUTING_CONFIG=$(aws lambda get-alias \
    --function-name ${FUNCTION_NAME} \
    --name ${ALIAS_NAME} \
    --query 'RoutingConfig' --output json)

  if [ "$ROUTING_CONFIG" = "null" ] || [ "$ROUTING_CONFIG" = "{}" ]; then
    echo "Success: RoutingConfig is cleared."
    break
  fi

  echo "Still waiting... Current RoutingConfig: ${ROUTING_CONFIG}"
  sleep 2
done

切り戻し手順

# 1. 既存のバージョンをエイリアスに設定
aws lambda update-alias --function-name ${FUNCTION_NAME} --name ${ALIAS_NAME} --function-version ${EXISTING_VER}

# 2. ルーティング設定の解除をポーリングで待機
while true; do
  ROUTING_CONFIG=$(aws lambda get-alias \
    --function-name ${FUNCTION_NAME} \
    --name ${ALIAS_NAME} \
    --query 'RoutingConfig' --output json)

  if [ "$ROUTING_CONFIG" = "null" ] || [ "$ROUTING_CONFIG" = "{}" ]; then
    echo "Success: RoutingConfig is cleared."
    break
  fi

  echo "Still waiting... Current RoutingConfig: ${ROUTING_CONFIG}"
  sleep 2
done

# 3. （必要に応じて）テスト用の関数バージョンを削除
aws lambda delete-function --function-name ${FUNCTION_NAME} --qualifier ${TEST_VER}

おわりに

AWS Lambda 関数エイリアスの実行環境を任意のタイミングで再起動する方法を確認してみました。

結論として、新バージョンを発行してエイリアスに設定するだけで、エイリアスの実行環境を再起動できることが確認できました。

Provisioned Concurrency が設定されている場合でも同様に再起動でき、切り替え後のバージョンに対して自動的に Provisioned Concurrency の割り当ても行われることも確認できました。本部分がもっとも気になるポイントでしたが、問題無さそうで安心しました。

以上

この記事をシェアする

FacebookHatena blogX

関連記事

Lambda Durable Functionsを利用してRedshiftに対しクエリ実行と結果のポーリングをしてみた
k.uehara
2026.01.07
Amazon API Gateway REST API を Amazon SQS と統合して、Lambda 関数を非同期に呼び出す構成を AWS CDK で構築する
若槻龍太
2026.01.02
AWS Lambda Managed Instances でデフォルトの CPU 使用率ベースのスケーリングの挙動を確認してみた
若槻龍太
2026.01.01
API Gateway と Lambda のサーバーレス構成で Express を動かしてみた
小林翔馬
2025.12.31