# Lambda がランタイムバージョンの更新を管理する方法を理解する
Lambda は、セキュリティ更新、バグ修正、新機能、パフォーマンス強化、およびマイナーバージョンリリースのサポートを使用して、各マネージドランタイムを最新の状態に保ちます。これらのランタイム更新は、ランタイムバージョンとして発行されます Lambda は、関数を以前のランタイムバージョンから新しいランタイムバージョンに移行することによって、ランタイム更新を関数に適用します。
マネージドランタイムを使用する関数の場合、Lambda はデフォルトでランタイム更新を自動的に適用します。自動ランタイム更新により、Lambda はランタイムバージョンにパッチを適用する運用上の負担を取り除きます。大抵のお客様には、自動更新が最適な選択肢です。このデフォルトの動作は、[ランタイム管理設定を構成](runtime-management-configure-settings.md)することで変更できます。
Lambda は、新しい各ランタイムバージョンのコンテナイメージとしての発行も行います。コンテナベースの関数のランタイムバージョンを更新するには、更新されたベースイメージから[新しいコンテナイメージを作成](images-create.md)して、関数を再デプロイする必要があります。
各ランタイムバージョンには、バージョン番号と ARN (Amazon リソースネーム) が関連付けられています。ランタイムのバージョン番号は Lambda が定義する番号付けスキームを使用しており、これはプログラミング言語が使用するバージョン番号とは無関係の番号です。ランタイムバージョン番号は常に連続しているとは限りません。例えば、バージョン 42 の後にバージョン 45 が続く場合があります。ランタイムバージョンの ARN は、各ランタイムバージョンの一意の識別子です。関数の現在のランタイムバージョンの ARN は、または[関数ログの `INIT_START` 行](runtime-management-identify.md)で確認できます。
ランタイムバージョンとランタイム識別子は、それぞれ別個に考える必要があります。各ランタイムには、`python3.14` や `nodejs24.x` などの一意の**ランタイム識別子**があります。これらは主要プログラミング言語の各リリースに対応しています。ランタイムバージョンは、個々のランタイムのパッチバージョンを表しています。
**注記**
同じランタイムバージョン番号の ARN は、AWS リージョンと CPU アーキテクチャによって異なる場合があります。
**Topics**
+ [下位互換性](#runtime-update-compatibility)
+ [ランタイム更新モード](#runtime-management-controls)
+ [2 フェーズのランタイムバージョンロールアウト](#runtime-management-two-phase)
+ [Lambda ランタイム管理設定](runtime-management-configure-settings.md)
+ [Lambda ランタイムバージョンのロールバック](runtime-management-rollback.md)
+ [Lambda ランタイムバージョン変更の特定](runtime-management-identify.md)
+ [Lambda ランタイム管理における責任共有モデルを理解する](runtime-management-shared.md)
+ [高コンプライアンスアプリケーションの Lambda ランタイム更新アクセス許可の制御](runtime-management-hc-applications.md)
## 下位互換性
Lambda は、既存の関数との後方互換性を備えたランタイム更新を提供するように努めていますが、ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。例えば、セキュリティパッチは、以前のセキュアではない動作に依存する既存の関数に関する内在的な問題を明らかにする可能性があります。
関数を構築してデプロイするときは、今後のランタイム更新との潜在的な非互換性を回避するために、依存関係を管理する方法を理解することが重要です。例えば、関数がパッケージ A に依存していて、パッケージ A がパッケージ B に依存しているとします。両方のパッケージは Lambda ランタイムに含まれています (例えば、SDK またはその依存関係の一部、またはランタイムシステムライブラリの一部である可能性があります）。
次のシナリオを考えてみてください。
| デプロイ | パッチ互換性 | Reason |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | はい | パッケージ A と B の今後のランタイム更新では、下位互換性を維持します。 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | はい | デプロイが優先されるため、パッケージ A と B の今後のランタイム更新は影響を与えません。 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | はい\$1 | パッケージ B の今後のランタイム更新には下位互換性があります。 \$1A と B が緊密に結合されている場合、互換性の問題が発生する可能性があります。例えば、 AWS SDK for Python の `boto3` パッケージと`botocore` パッケージは一緒にデプロイする必要があります。 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-update.html) | 不可 | パッケージ A の今後のランタイム更新では、パッケージ B の更新バージョンが必要になる場合があります。ただし、デプロイ済のパッケージ B のバージョンが優先され、パッケージ A の更新バージョンとの前方互換性がない場合があります。 |
今後のランタイム更新との互換性を維持するには、次のベストプラクティスに従ってください。
+ **可能であれば、すべての依存関係をパッケージ化します。**AWS SDK とその依存関係を含む、必要なすべてのライブラリをデプロイパッケージに含めます。これにより、安定した互換性のあるコンポーネント一式が保証されます。
+ **ランタイム提供 SDK を控えめに使用する：** 追加のパッケージを含めることができない場合にのみ、ランタイム提供の SDK を使用します (例えば、Lambda コンソールコードエディタまたはインラインコードを AWS CloudFormation テンプレートで使用する場合）。
+ **システムライブラリを上書きしない：** 今後のランタイム更新と競合する可能性のあるカスタムオペレーティングシステムライブラリをデプロイしないでください。
## ランタイム更新モード
Lambda は、既存の関数との後方互換性を備えたランタイム更新を提供するように努めていますが、ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。例えば、セキュリティパッチは、以前のセキュアではない動作に依存する既存の関数に関する内在的な問題を明らかにする可能性があります。Lambda ランタイム管理コントロールは、ランタイムバージョンの非互換性というまれな状況で、ワークロードに影響が及ぶリスクを軽減するために役立ちます。[関数バージョン](configuration-versions.md) (`$LATEST` または発行済みバージョン) ごとに、以下のランタイム更新モードのいずれかを選択できます。
+ **自動 (デフォルト)** – [2 フェーズのランタイムバージョンロールアウト](#runtime-management-two-phase) を使用して、最新のセキュアなランタイムバージョンに自動的に更新します。ランタイム更新のメリットを常に得るためにも、これは大半のお客様に推奨されるモードです。
+ **関数の更新** – 関数を更新するときに、最新の安全なランタイムバージョンに更新します。関数が更新されると、Lambda が関数のランタイムを最新のセキュアなランタイムバージョンに更新します。このアプローチは、ランタイム更新を関数デプロイと同期させることから、Lambda がランタイム更新を適用するタイミングを制御できます。このモードを使用することで、まれに発生するランタイム更新の非互換性を早期に検出して緩和することができます。このモードを使用するときは、関数を定期的に更新して、それらのランタイムを最新の状態に保つ必要があります。
+ **手動** – ランタイムバージョンを手動で更新します。関数設定でランタイムバージョンを指定します。関数は、このランタイムバージョンを恒久的に使用します。新しいランタイムバージョンに既存の関数との互換性がないというまれな状況でも、このモードを使用して、関数を以前のランタイムバージョンにロールバックすることができます。デプロイ間でのランタイムの整合性を実現するためにも、**[Manual]** (手動) モードは使用しないことをお勧めします。詳細については、「[Lambda ランタイムバージョンのロールバック](runtime-management-rollback.md)」を参照してください。
ランタイム更新を関数に適用する責任は、選択するランタイム更新モードに応じて異なります。詳細については、「[Lambda ランタイム管理における責任共有モデルを理解する](runtime-management-shared.md)」を参照してください。
## 2 フェーズのランタイムバージョンロールアウト
Lambda は、次の順序で新しいランタイムバージョンを導入します。
1. 第 1 フェーズでは、関数が作成または更新されるたびに Lambda が新しいランタイムバージョンを適用します。関数は、[UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) または [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 操作が呼び出されるときに更新されます。
1. 第 2 フェーズでは、**[Auto]** (自動) ランタイム更新モードを使用する関数で、まだ新しいランタイムバージョンに更新されていない関数を Lambda が更新します。
このロールアウトプロセスの全体的な所要時間は、ランタイム更新に含まれるセキュリティパッチの重大度などの複数の要因に応じて異なります。
関数の開発とデプロイを積極的に行っている場合は、第 1 フェーズ中に新しいランタイムバージョンを取得する可能性が高くなります。これは、ランタイム更新を関数の更新に同期します。最新のランタイムバージョンがアプリケーションに悪影響を及ぼすというまれな状況でも、このアプローチによって迅速に是正措置を講じることができます。積極的な開発が行われていない関数でも、第 2 フェーズ中の自動ランタイム更新による運用上のメリットが得られます。
このアプローチは、**[Function update]** (関数の更新) または **[Manual]** (手動) モードに設定された関数には影響しません。**[Function update]** (関数の更新) モードを使用する関数が最新のランタイム更新を受け取るのは、それらの作成時または更新時のみです。**[Manual** (手動) モードを使用する関数は、ランタイム更新を受け取りません。
Lambda は、新しいランタイムバージョンを段階的なローリング形式で AWS リージョン全体に発行します。関数が **[Auto]** (自動) または **[Function update]** (関数の更新) モードに設定されている場合、異なるリージョンに同時にデプロイされた関数、または同じリージョン内で異なる時間にデプロイされた関数が、異なるランタイムバージョンを取得する可能性があります。環境全体でランタイムバージョンの整合性を確保する必要があるお客様は、[コンテナイメージを使用して Lambda 関数をデプロイ](images-create.md)する必要があります。**[手動]** モードは、ランタイムバージョンが関数と互換性がないというまれなイベントで、ランタイムバージョンのロールバックを可能にするための一時的な緩和策として設計されています。
# Lambda ランタイム管理設定
ランタイム管理は、Lambda コンソール、または AWS Command Line Interface (AWS CLI) を使用して設定できます。
**注記**
ランタイム管理は、[関数バージョン](configuration-versions.md)ごとに個別に設定できます。
**Lambda がランタイムバージョンを更新する方法を設定する (コンソール)**
1. Lambda コンソールの[関数ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 関数の名前を選択します。
1. **[Code]** (コード) タブの **[Runtime settings]** (ランタイム設定) で **[Edit runtime management configuration]** (ランタイム管理設定を編集) を選択します。
1. **[Runtime management configuration]** (ランタイム管理設定) で、以下のいずれかを選択します。
+ 関数を最新のランタイムバージョンに自動的に更新するには、**[Auto]** (自動) を選択します。
+ 関数を変更するときに関数を最新のランタイムバージョンに更新するには、**[Function update]** (関数の更新) を選択します。
+ ランタイムバージョンの ARN を変更するときにのみ関数を最新のランタイムバージョンに更新するには、**[Manual** (手動) を選択します。ランタイムバージョンの ARN は、**[Runtime management configuration]** (ランタイム管理設定) で確認できます。ARN は、関数ログの `INIT_START` 行でも確認できます。
これらのオプションの詳細については、「[ランタイム更新モード](runtimes-update.md#runtime-management-controls)」を参照してください。
1. [**Save**] を選択します。
**Lambda がランタイムバージョンを更新する方法を設定する (AWS CLI)**
関数のランタイム管理を設定するには、[put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) AWS CLI コマンドを実行します。`Manual` モードを使用するときは、ランタイムバージョンの ARN も指定する必要があります。
```
aws lambda put-runtime-management-config \
--function-name my-function \
--update-runtime-on Manual \
--runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```
次のような出力が表示されます:
```
{
"UpdateRuntimeOn": "Manual",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```
# Lambda ランタイムバージョンのロールバック
新しいランタイムバージョンに既存の関数との互換性がないというまれな状況が発生した場合は、関数のランタイムバージョンを以前のバージョンにロールバックすることができます。そうすることで、アプリケーションが引き続き機能し、中断が最小限に抑えられるので、最新のランタイムバージョンに戻る前に非互換性を修正する時間を確保できます。
Lambda は、特定のランタイムバージョンを使用できる期間を制限していませんが、最新のセキュリティパッチ、パフォーマンスの向上、および機能面でのメリットを得るためにも、可能な限り早急に最新のランタイムバージョンに更新することを強くお勧めします。Lambda は以前のランタイムバージョンにロールバックするオプションを提供してますが、これはあくまでも、まれに発生するランタイム更新の互換性問題の一時的な緩和策として使用するものです。以前のランタイムバージョンを長期間使用している関数では、最終的にパフォーマンスの低下、または証明書の有効期限切れなどの問題が発生するので、適切に動作しなくなる可能性があります。
ランタイムバージョンは、以下の方法でロールバックできます。
+ [[Manual] (手動) ランタイム更新モードの使用](#runtime-management-rollback-manual)
+ [発行済みの関数バージョンの使用](#runtime-management-rollback-published)
詳細については、AWS コンピューティングブログの「[AWS Lambda ランタイム管理コントロールの紹介](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/)」を参照してください。
## [Manual] (手動) ランタイム更新モードを使用したランタイムバージョンのロールバック
**[Auto]** (自動) ランタイムバージョン更新モードを使用している場合、または `$LATEST` ランタイムバージョンを使用している場合は、**[Manual]** (手動)モードを使用してランタイムバージョンをロールバックできます。ロールバックする[関数バージョン](configuration-versions.md)で、ランタイムバージョン更新モードを **[Manual]** (手動) に変更し、以前のランタイムバージョンの ARN を指定します。以前のランタイムバージョンの ARN を確認する方法の詳細については、「[Lambda ランタイムバージョン変更の特定](runtime-management-identify.md)」を参照してください。
**注記**
関数の `$LATEST` バージョンが **[Manual]** (手動) モードを使用するように設定されている場合は、関数が使用する CPU アーキテクチャまたはランタイムバージョンを変更できません。これらの変更を行うには、**[Auto]** (自動) モードまたは **[Function update]** (関数の更新) モードに変更する必要があります。
## 発行済みの関数バージョンを使用したランタイムバージョンのロールバック
発行済みの[関数バージョン](configuration-versions.md)は、関数が作成されたときの `$LATEST` 関数コードと設定のイミュータブルなスナップショットです。**[Auto]** (自動) モードでは、ランタイムバージョンロールアウトの第 2 フェーズ中に、Lambda が発行済みの関数バージョンのランタイムバージョンを自動的に更新します。**[Function update]** (関数の更新) モードでは、Lambda は発行済みの関数バージョンのランタイムバージョンを更新しません。
そのため、**[Function update]** (関数の更新) モードを使用する発行済みの関数バージョンは、関数コード、設定、およびランタイムバージョンの静的スナップショットを作成します。関数バージョンで **[Function update]** (関数の更新) モードを使用することによって、ランタイム更新をデプロイと同期できます。また、トラフィックを以前の発行済み関数バージョンにリダイレクトすることで、コード、設定、およびランタイムバージョンのロールバックを調整することもできます。このアプローチは、ランタイム更新に互換性がないというまれな状況での完全に自動化されたロールバックのために、継続的インテグレーションおよび継続的デリバリー (CI/CD) に統合することができます。このアプローチを使用するときは、関数を定期的に更新し、新しい関数バージョンを発行して、最新のランタイム更新を取得する必要があります。詳細については、「[Lambda ランタイム管理における責任共有モデルを理解する](runtime-management-shared.md)」を参照してください。
# Lambda ランタイムバージョン変更の特定
[ランタイムバージョン番号](runtimes-update.md)および ARN は `INIT_START` ログ行にログ記録されており、Lambda が新しい[実行環境](concepts-basics.md#gettingstarted-concepts-runtime)を作成するたびに、このログ行を CloudWatch ログに出力します。実行環境はすべての関数呼び出しに同じランタイムバージョンを使用するため、Lambda は、Lambda が init フェーズを実行するときにのみ `INIT_START` ログ行を出力します。Lambda は、関数の呼び出しごとにこのログ行を出力しません。Lambda はログ行を CloudWatch Logs に出力しますが、ログ行はコンソールに表示されません。
**注記**
ランタイムバージョン番号は常に連続しているとは限りません。例えば、バージョン 42 の後にバージョン 45 が続く場合があります。
**Example INIT\$1START ログ行の例**
```
INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```
ログを直接使用する代わりに、[Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) を使用して、ランタイムバージョン間の移行を特定できます。以下のルールは、各 `INIT_START` ログ行からの独特のランタイムバージョンの個数を数えます。このルールを使用するには、サンプルロググループ名 `/aws/lambda/*` を、関数または一連の関数の適切なプレフィックスに置き換えてください。
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "eventType",
"In": [
"INIT_START"
]
}
],
"Keys": [
"runtimeVersion",
"runtimeVersionArn"
]
},
"LogFormat": "CLF",
"LogGroupNames": [
"/aws/lambda/*"
],
"Fields": {
"1": "eventType",
"4": "runtimeVersion",
"8": "runtimeVersionArn"
}
}
```
以下の CloudWatch Contributor Insights レポートは、前述のルールによって取得されたランタイムバージョンの移行の例を示すものです。オレンジ色の線は以前のランタイムバージョン (**python:3.13.v12**) の実行環境の初期化を示し、青い線は新しいランタイムバージョン (**python:3.13.v14**) の実行環境の初期化を示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/runtime_version_graph.png)
# Lambda ランタイム管理における責任共有モデルを理解する
Lambda は、サポートされているすべてのマネージドランタイムとコンテナイメージに関するセキュリティ更新のキュレーションと発行に対する責任を担います。最新のランタイムバージョンを使用するように既存の関数を更新する責任は、お客様が使用するランタイム更新モードに応じて異なります。
Lambda は、**[Auto]** (自動) ランタイム更新モードを使用するように設定されたすべての関数にランタイム更新を適用する責任を担います。
**[Function update]** (関数の更新) ランタイム更新モードで設定された関数については、お客様が関数を定期的に更新する責任を担います。Lambda は、お客様がこれらの更新を行うときにランタイム更新を適用する責任を担います。お客様が関数を更新しない場合、Lambda はランタイムを更新しません。関数を定期的に更新しない場合は、関数を自動的なランタイム更新に設定して、継続的にセキュリティ更新を受け取るようにすることを強くお勧めします。
**[Manual]** (手動) ランタイム更新モードを使用するように設定された関数については、お客様が関数を更新して、最新のランタイムバージョンが使用されるようにする責任を担います。このモードは、ランタイム更新に互換性がないというまれな状況での一時的な緩和策として、ランタイムバージョンをロールバックするためのみに使用することを強くお勧めします。また、関数にパッチが適用されていない時間を最小限に抑えるため、可能な限り早急に **[Auto]** (自動) モードに変更することもお勧めします。
お客様が[関数のデプロイにコンテナイメージを使用](images-create.md)している場合は、Lambda が更新されたベースイメージを発行する責任を担います。この場合、最新のベースイメージから関数のコンテナイメージを再構築し、コンテナイメージを再デプロイする責任はお客様が担います。
これらは、以下の表に要約されています。
****
| デプロイモード | Lambda の責任 | お客様の責任 |
| --- | --- | --- |
| マネージドランタイム、[Auto] (自動) モード | 最新のパッチが含まれる新しいランタイムバージョンを発行します。 既存の関数にランタイムパッチを適用します。 | ランタイム更新の互換性問題が発生したまれな状況において、以前のランタイムバージョンにロールバックします。[下位互換性](runtimes-update.md#runtime-update-compatibility)を確保するためのベストプラクティスに従ってください。 |
| マネージドランタイム、[Function update] (関数の更新) モード | 最新のパッチが含まれる新しいランタイムバージョンを発行します。 | 関数を定期的に更新して、最新のランタイムバージョンを取得します。 関数を定期的に更新していないときは、関数を **[Auto]** (自動) モードに切り替えます。 ランタイム更新の互換性問題が発生したまれな状況において、以前のランタイムバージョンにロールバックします。[下位互換性](runtimes-update.md#runtime-update-compatibility)を確保するためのベストプラクティスに従ってください。 |
| マネージドランタイム、[Manual] (手動) モード | 最新のパッチが含まれる新しいランタイムバージョンを発行します。 | このモードは、ランタイム更新の互換性問題が発生したまれな状況における、一時的なランタイムロールバックのみに使用します。 可能な限り早急に、関数を **[Auto]** (自動) または **[Function update]** (関数の更新) モード、および最新のランタイムバージョンに切り替えます。 |
| コンテナイメージ | 最新のパッチが含まれる新しいコンテナイメージを発行します。 | 最新のコンテナベースイメージを使用して定期的に関数を再デプロイし、最新のパッチを取得します。 |
AWS との責任共有の詳細については、「[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)」を参照してください。
# 高コンプライアンスアプリケーションの Lambda ランタイム更新アクセス許可の制御
Lambda のお客様は通常、パッチ適用要件を満たすために自動ランタイム更新を利用しています。アプリケーションが厳しいパッチ最新性要件の対象になっている場合は、以前のランタイムバージョンの使用を制限することが推奨されます。AWS Identity and Access Management (IAM) を使用して、AWS アカウント内のユーザーによる [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html) API 操作へのアクセスを拒否することで、Lambda のランタイム管理コントロールを制限できます。この操作は、関数のランタイム更新モードを選択するために使用されます。この操作へのアクセスを拒否すると、すべての関数がデフォルトで **[Auto]** (自動) モードになります。この制限は、[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を使用することで組織全体に適用できます。関数を以前のランタイムバージョンにロールバックする必要がある場合は、ケースバイケースでポリシー例外を付与することができます。