# Lambda ランタイム
Lambda は、*ランタイム*の使用により複数の言語をサポートします。ランタイムは、Lambda と関数の間の呼び出しイベント、コンテキスト情報、レスポンスを中継する言語固有の環境を提供します。Lambda が提供するランタイムを使用することも、独自に構築することもできます。
Lambda はランタイムの選択に依存しません。シンプルな関数の場合、Python や Node.js などのインタープリター言語が最速のパフォーマンスを提供します。より複雑な計算を使用する関数の場合、Java などのコンパイル済み言語は初期化に時間がかかることがありますが、Lambda ハンドラーでは迅速に実行されます。ランタイムの選択は、開発者の好みや言語の精通度にも影響されます。
主なプログラミング言語の各リリースには別個のランタイムがあり、*一意のランタイム識別子* (`nodejs24.x` または `python3.14` など) を持っています。新しいメジャー言語バージョンを使用するように関数を設定するには、ランタイム識別子を変更する必要があります。AWS Lambda はメジャーバージョン間の下位互換性を保証できないため、これは顧客が主導権を持つ操作です。
[コンテナーイメージとして定義された関数](images-create.md)の場合は、そのコンテナーイメージを作成する際に、ランタイムと Linux ディストリビューションを選択します。ランタイムを変更するには、新しいコンテナーイメージを作成します。
デプロイパッケージに .zip ファイルアーカイブを使用する場合は、関数の作成時にランタイムを選択します。このランタイムは、[関数の設定を更新](configuration-function-zip.md)することで変更できます。ランタイムは、Amazon Linux ディストリビューションの 1 つとペアを構成しています。基盤となる実行環境は、関数コードからアクセスできる追加のライブラリと[環境変数](configuration-envvars.md)を提供します。
Lambda は、[実行環境](lambda-runtime-environment.md)で関数を呼び出します。実行環境では、関数の実行に必要なリソースを管理するセキュアで分離されたランタイム環境が提供されます。Lambda は以前の呼び出し (使用可能な場合) から実行環境を再利用しますが、新しい実行環境を作成することもできます。
Lambda で [Go](lambda-golang.md) や [Rust](lambda-rust.md) などの他の言語を使用するには、[OS](runtimes-provided.md) 専用ランタイムを使用してください。Lambda 実行環境には、呼び出しイベントの取得とレスポンスの送信を行うための[ランタイムインターフェイス](runtimes-api.md)が搭載されています。[カスタムランタイム](runtimes-custom.md)を関数コードと共に実装するか、[レイヤー](chapter-layers.md)に実装することで、他の言語をデプロイできます。
## ランタイムのサポート
サポートされている Lambda ランタイムと廃止予定日リストを以下の表に示します。ランタイムが廃止された後も、一定期間中は関数の作成と更新が可能です。詳細については、「[非推奨化後のランタイムの使用について](#runtime-deprecation-levels)」を参照してください。この表は、[ランタイムの非推奨化に関するポリシー](#runtime-support-policy) に基づき現在予定されているランタイム廃止予定日を示しています。これらの日付は計画上の目的で提供されており、変更されることがあります。
**重要**
Amazon Linux 2 は 2026 年 6 月 30 日にサポート終了を予定しています。Java 8 (AL2)、Java 11、Java 17、Python 3.10、Python 3.11、および provided.al2 用の Lambda ランタイムとコンテナベースイメージは、以下の表に示す廃止日まで、言語ランタイムパッチに加えて、Amazon Linux 2 セキュリティの[重大な問題および選択された重要な問題](https://alas.aws.amazon.com/faqs.html)のパッチを引き続き受け取ります。
できるだけ早く Amazon Linux 2023 ベースのランタイムにアップグレードすることをお勧めします。Java 21 または Java 25 にアップグレードする顧客に対しては、[AWS Transform カスタム](https://docs.aws.amazon.com/transform/latest/userguide/custom.html)を使用してこれらのアップグレードをサポートできます。Java バージョンをアップグレードできない顧客に対しては、2026 年第 2 四半期末までに Java 8、Java 11、および Java 17 用の Amazon Linux 2023 ベースのランタイムをリリースする予定です。
| 名前 | 識別子 | オペレーティングシステム | 廃止日 | 関数の作成をブロックする | 関数の更新をブロックする |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 2028 年 4 月 30 日 | 2028 年 6 月 1 日 | 2028 年 7 月 1 日 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 2027 年 4 月 30 日 | 2027 年 6 月 1 日 | 2027 年 7 月 1 日 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 2026 年 4 月 30 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 2028 年 10 月 31 日 | 2028 年 11 月 30 日 | 2029 年 1 月 10 日 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 2026 年 10 月 31 日 | 2026 年 11 月 30 日 | 2027 年 1 月 15 日 |
| Java 25 | `java25` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 |
| Java 21 | `java21` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 |
| Java 17 | `java17` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 |
| Java 11 | `java11` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 |
| Java 8 | `java8.al2` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 2028 年 11 月 14 日 | 2028 年 12 月 14 日 | 2029 年 1 月 15 日 |
| .NET 9 (コンテナのみ) | `dotnet9` | Amazon Linux 2023 | 2026 年 11 月 10 日 | スケジュールされていません | スケジュールされていません |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 2026 年 11 月 10 日 | 2026 年 12 月 10 日 | 2027 年 1 月 11 日 |
| Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 2028 年 3 月 31 日 | 2028 年 4 月 30 日 | 2028 年 5 月 31 日 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 2027 年 3 月 31 日 | 2027 年 4 月 30 日 | 2027 年 5 月 31 日 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 2026 年 3 月 31 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| OS 専用ランタイム | `provided.al2023` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 |
| OS 専用ランタイム | `provided.al2` | Amazon Linux 2 | 2026 年 7 月 31 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
**注記**
新しいリージョンでは、Lambda は今後 6 か月以内に廃止される予定のランタイムをサポートしません。
Lambda は、パッチの適用とマイナーバージョンリリースのサポートにより、マネージドランタイムと対応するコンテナベースイメージを最新の状態に保ちます。詳細については、「[Lambda ランタイムの更新](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html)」を参照してください。
Lambda 関数から他の AWS のサービス やリソースとプログラムでやり取りするには、 AWS SDK のいずれかを使用できます。Node.js、Python、Ruby ランタイムには、 AWS SDK のバージョンが含まれています。ただし、依存関係を完全に制御し、ランタイムの自動更新中に[下位互換性](runtimes-update.md#runtime-update-compatibility)を最大化するには、コードが使用する SDK モジュール (および依存関係) を関数のデプロイ パッケージまたは [Lambda レイヤー](chapter-layers.md)に常に含めておくことをお勧めします。
デプロイメントに追加のパッケージを含めることができない場合にのみ、ランタイムが含まれる SDK バージョンを使用することをお勧めします。例えば、Lambda コンソールコードエディタを使用して関数を作成する場合や、 CloudFormation テンプレートでインライン関数コードを使用する場合などです。
Lambda は、Node.js、Python、Ruby ランタイムに含まれる AWS SDK のバージョンを定期的に更新します。使用しているランタイムに含まれる AWS SDK のバージョンを確認するには、以下のセクションを参照してください。
+ [ランタイムに含まれる SDK バージョン(Node.js)](lambda-nodejs.md#nodejs-sdk-included)
+ [ランタイムに含まれる SDK バージョン (Python)](lambda-python.md#python-sdk-included)
+ [ランタイムに含まれる SDK バージョン (Ruby)](lambda-ruby.md#ruby-sdk-included)
Lambda は Go 1.x ランタイムが廃止された後も Go プログラミング言語を引き続きサポートします。詳細については、「*AWS コンピュートブログ*」の「[AWS Lambda 関数を Go1.x ランタイムから Amazon Linux 2 のカスタムラインタイムに移行](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/)」を参照してください。
サポートされているすべての Lambda ランタイムは、x86\$164 アーキテクチャと arm64 アーキテクチャの両方をサポートします。
## 新しいランタイムリリース
リリースが、言語のリリースサイクルの長期サポート (LTS) フェーズに達したときにのみ Lambda でその言語の新バージョン用マネージドランタイムが提供されます。例えば、[Node.js のリリースサイクル](https://nodejs.org/en/about/previous-releases)では、リリースが Active LTS フェーズに達したときです。
リリースは長期サポート段階に達するまでは開発段階にあり、重大な変更が加えられる可能性があります。Lambda はデフォルトでランタイム更新を自動的に適用するため、ランタイムバージョンに重大な変更があった場合、関数が期待どおりに動作しなくなる可能性があります。
Lambda は、LTS リリースが予定されていない言語バージョン用のマネージドランタイムを提供していません。
次のリストは、今後の Lambda ランタイムのリリース開始予定月を示しています。リストの日程は参考であり、変更される可能性があります。
+ **Ruby 3.5** - 2026 年 3 月
+ **AL2023 での Java 8、11、17** - 2026 年第 2 四半期
+ **Node.js 26** - 2026 年 11 月
+ **Python 3.15** - 2026 年 11 月
## ランタイムの非推奨化に関するポリシー
.zip ファイルアーカイブの Lambda ランタイムは、メンテナンスとセキュリティ更新の対象となるオペレーティングシステム、プログラミング言語、およびソフトウェアライブラリの組み合わせを中心に構築されています。Lambda の標準的な非推奨化に関するポリシーは、ランタイムの主要コンポーネントのいずれかに対するコミュニティ長期サポート (LTS) 期間が満了し、セキュリティアップデートが利用できなくなった時点でランタイムを非推奨にするというものです。たいていの場合、これは言語ランタイムが対象ですが、オペレーティングシステム (OS) で LTS の満了を迎えることでランタイムが非推奨化される場合もあります。
ランタイムが非推奨になると、AWS はご使用のランタイムにセキュリティパッチを適用しなくなります。これにより、そのランタイムを使用する関数はテクニカルサポートの対象ではなくなります。このような非推奨のランタイムは、「現状のまま」の保証なしで提供されるため、バグ、エラー、欠陥、またはその他の脆弱性が含まれている可能性があります。
ランタイムのアップグレードと廃止の管理について詳しくは、以下のセクションおよび、「*AWS コンピュートブログ*」の「[Managing AWS Lambda runtime upgrades](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/)」を参照してください。
**重要**
Lambda では、ランタイムがサポートする言語バージョンのサポート期間満了後も Lambda ランタイムの非推奨化を一定期間延長することがあります。この期間中、Lambda ではランタイム OS にのみセキュリティパッチを適用します。Lambda では、サポート期間を満了したプログラミング言語ランタイムにセキュリティパッチを適用しません。
## 責任共有モデル
Lambda は、サポートされているすべてのマネージドランタイムとコンテナベースイメージに関するセキュリティ更新のキュレーションと発行に対する責任を担います。デフォルトでは、Lambda はマネージドランタイムを使用してこれらの更新を関数に自動的に適用します。デフォルトの自動ランタイム更新設定が変更されている場合は、[「責任共有モデル](runtime-management-shared.md)」を参照してください。コンテナー イメージを使用してデプロイされた関数の場合、最新のベースイメージから関数のコンテナイメージを再構築し、コンテナイメージを再デプロイする責任はお客様が担います。
ランタイムが非推奨になると、 Lambda のマネージドランタイムとコンテナベースイメージの更新はサポートされなくなります。サポートされているランタイムまたはベースイメージの使用における関数のアップグレードは、お客様の責任で行ってください。
いずれの場合も、依存関係を含め、関数コードへの更新の適用について、お客様が責任を持ちます。責任共有モデルに基づくお客様の責任は、次の表にまとめられています。
| ランタイムライフサイクルフェーズ | Lambda の責任 | お客様の責任 |
| --- | --- | --- |
| サポートされているマネージドランタイム | セキュリティパッチやその他の更新プログラムを使用して、ランタイムを定期的に更新します。 ランタイム更新をデフォルトで自動的に適用します (デフォルト以外の動作については、「[ランタイム更新モード](runtimes-update.md#runtime-management-controls)」を参照してください）。 | 依存関係を含む関数コードを更新して、セキュリティの脆弱性に対処します。 |
| サポートされているコンテナイメージ | セキュリティパッチやその他の更新プログラムを使用して、コンテナベースイメージを定期的に更新します。 | 依存関係を含む関数コードを更新して、セキュリティの脆弱性に対処します。 最新のベースイメージを使用して、コンテナイメージを定期的に再構築して再デプロイします。 |
| マネージドランタイムが非推奨になる予定日に近づいています | ドキュメント、Health Dashboard、E メール、および Trusted Advisor を使用して、ランタイムが非推奨になる前にお客様に通知します。 非推奨になると、弊社はランタイムを更新する責任を負いません。 | ランタイムの非推奨情報に関する Lambda ドキュメント、Health Dashboard、E メール、または Trusted Advisor をモニタリングします。 以前のランタイムが非奨励になる前に、サポートされているランタイムバージョンに関数をアップグレードします。 |
| コンテナイメージが非推奨になる予定日に近づいています | コンテナイメージを使用する関数では、非推奨に関する通知はありません。 コンテナベースイメージの更新は、非推奨時に終了します。 | イメージの非推奨に伴い、非推奨に関するスケジュールの確認と、ベースイメージのサポートされるバージョンへのアップグレードを行ってください。 |
## 非推奨化後のランタイムの使用について
ランタイムが非推奨になると、AWS はご使用のランタイムにセキュリティパッチを適用しなくなります。これにより、そのランタイムを使用する関数はテクニカルサポートの対象ではなくなります。関数を無期限に呼び出すことはできますが、AWS ではサポートされているランタイムへの移行を強くお勧めします。非推奨のランタイムは、「現状のまま」の保証なしで提供されるため、バグ、エラー、欠陥、またはその他の脆弱性が含まれている可能性があります。非推奨のランタイムを使用する関数は、パフォーマンスが低下したり、証明書の有効期限切れなどの問題が発生したりして、正しく動作しなくなる可能性があります。
ランタイムが非奨励になった後はいつでも、関数を更新すると、サポートされている新しいランタイムバージョンを使用できます。本番環境に変更を適用する前に、新しいランタイムで関数をテストすることをお勧めします。関数の更新がブロックされると、非推奨になったランタイムに戻すことはできません。ロールバックによる安全なデプロイを有効にするには、関数の[バージョン](configuration-versions.md)と[エイリアス](configuration-aliases.md)を使用することをお勧めします。
次のタイムラインは、ランタイムが非推奨になったときにどうなるかを示しています。
| ランタイムライフサイクルフェーズ | メトリック | 何 |
| --- | --- | --- |
| 非推奨通知期間 | 非推奨になる少なくとも 180 日前 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html) |
| 非推奨 | 廃止日 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html) |
| 関数の作成をブロックする | 非推奨になってから少なくとも 30 日後 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html) |
| 関数の更新をブロックする | 非推奨になってから少なくとも 60 日後 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html) |
**注記**
一部のランタイムでは、AWS は block-function-create および block-function-update の日付が非推奨になってから通常の 30 日および 60 日を超えて延期しています。AWS は顧客のフィードバックに応えてこの変更を行い、関数をアップグレードする時間を増やしました。[ランタイムのサポート](#runtimes-supported) および [非推奨のランタイム](#runtimes-deprecated) の表を参照し、ランタイムの日付を確認してください。Lambda は、これらの表に記載されている日付より前に関数の作成や更新のブロックを行うことはありません。
## ランタイムの廃止通知を受け取る
ランタイムが廃止日に近づくと、AWS アカウント 内にそのランタイムを使用している関数があると、Lambda からメールアラートが送信されます。通知は Health Dashboard と AWS Trusted Advisor にも表示されます。
+ メール通知の受信:
Lambda は、ランタイムが廃止される少なくとも **180 日**前にメールアラートを送信します。メールには、そのランタイムを使用するすべての関数の \$1LATEST バージョンが記載されています。影響を受ける関数バージョンの全リストを確認するには、Trusted Advisor を使用するか、[非推奨のランタイムを使用する Lambda 関数に関するデータを取得する](runtimes-list-deprecated.md) をご覧ください。
Lambda は、AWS アカウント の主要アカウント連絡先にメール通知を送信します。アカウントのメールアドレスの表示や更新の詳細については、「*AWS の全般リファレンス*」の「[連絡先情報の更新](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)」を参照してください。
+ Health Dashboard で通知を受信する:
Health Dashboard は、ランタイムが廃止される少なくとも **180 日**前に通知を表示します。通知は **[アカウントの状態]** ページの [[その他の通知]](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications) に表示されます。通知の **[影響を受けるリソース]** タブには、ランタイムを使用するすべての関数の \$1LATEST バージョンが一覧表示されます。
**注記**
影響を受ける関数バージョンの、最新の全リストを確認するには、Trusted Advisor を使用するか、[非推奨のランタイムを使用する Lambda 関数に関するデータを取得する](runtimes-list-deprecated.md) をご覧ください。
Health Dashboard 通知は、影響を受けるランタイムが廃止されてから 90 日後に表示されなくなります。
+ AWS Trusted Advisorの使用
Trusted Advisor は、ランタイムが廃止される少なくとも **180 日**前に通知を表示します。通知は [[セキュリティ]](https://console.aws.amazon.com/trustedadvisor/home#/category/security) ページに表示されます。影響を受ける関数のリストは、**[非推奨のランタイムを使用する AWS Lambda 関数]** に表示されます。この関数リストには \$1LATEST バージョンと公開済みバージョンの両方が表示され、関数の現在の状態を反映して自動的に更新されます。
Trusted Advisor コンソールの [[設定]](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) ページから、Trusted Advisor の毎週のメール通知を有効にできます。
## 非推奨のランタイム
次のランタイムは、サポート終了に達しています。
| 名前 | 識別子 | オペレーティングシステム | 廃止日 | 関数の作成をブロックする | 関数の更新をブロックする |
| --- | --- | --- | --- | --- | --- |
| Python 3.9 | python3.9 | Amazon Linux 2 | 2025 年 12 月 15 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| Node.js 18 | nodejs18.x | Amazon Linux 2 | 2025 年 9 月 1 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| .NET 6 | dotnet6 | Amazon Linux 2 | 2024 年 12 月 20 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| Python 3.8 | python3.8 | Amazon Linux 2 | 2024 年 10 月 14 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| Node.js 16 | nodejs16.x | Amazon Linux 2 | 2024 年 6 月 12 日 | 2026 年 8 月 31 日 | 2026 年 9 月 30 日 |
| .NET 7 (コンテナのみ) | dotnet7 | Amazon Linux 2 | 2024 年 5 月 14 日 | 該当なし | 該当なし |
| Java 8 | java8 | Amazon Linux | 2024 年 1 月 8 日 | 2024 年 2 月 8 日 | 2026 年 9 月 30 日 |
| Go 1.x | go1.x | Amazon Linux | 2024 年 1 月 8 日 | 2024 年 2 月 8 日 | 2026 年 9 月 30 日 |
| OS 専用ランタイム | provided | Amazon Linux | 2024 年 1 月 8 日 | 2024 年 2 月 8 日 | 2026 年 9 月 30 日 |
| Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 2023 年 12 月 7 日 | 2024 年 1 月 9 日 | 2026 年 9 月 30 日 |
| Node.js 14 | nodejs14.x | Amazon Linux 2 | 2023 年 12 月 4 日 | 2024 年 1 月 9 日 | 2026 年 9 月 30 日 |
| Python 3.7 | python3.7 | Amazon Linux | 2023 年 12 月 4 日 | 2024 年 1 月 9 日 | 2026 年 9 月 30 日 |
| .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 2023 年 4 月 3 日 | 2023 年 4 月 3 日 | 2023 年 5 月 3 日 |
| Node.js 12 | nodejs12.x | Amazon Linux 2 | 2023 年 3 月 31 日 | 2023 年 3 月 31 日 | 2023 年 4 月 30 日 |
| Python 3.6 | python3.6 | Amazon Linux | 2022 年 7 月 18 日 | 2022 年 7 月 18 日 | 2022 年 8 月 29 日 |
| .NET 5 (コンテナのみ) | dotnet5.0 | Amazon Linux 2 | 2022 年 5 月 10 日 | 該当なし | 該当なし |
| .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 2022 年 1 月 5 日 | 2022 年 1 月 5 日 | 2022 年 4 月 13 日 |
| Node.js 10 | nodejs10.x | Amazon Linux 2 | 2021 年 7 月 30 日 | 2021 年 7 月 30 日 | 2022 年 2 月 14 日 |
| Ruby 2.5 | ruby2.5 | Amazon Linux | 2021 年 7 月 30 日 | 2021 年 7 月 30 日 | 2022 年 3 月 31 日 |
| Python 2.7 | python2.7 | Amazon Linux | 2021 年 7 月 15 日 | 2021 年 7 月 15 日 | 2022 年 5 月 30 日 |
| Node.js 8.10 | nodejs8.10 | Amazon Linux | 2020 年 3 月 6 日 | 2020 年 2 月 4 日 | 2020 年 3 月 6 日 |
| Node.js 4.3 | nodejs4.3 | Amazon Linux | 2020 年 3 月 5 日 | 2020 年 2 月 3 日 | 2020 年 3 月 5 日 |
| Node.js 4.3 Edge | nodejs4.3-edge | Amazon Linux | 2020 年 3 月 5 日 | 2019 年 3 月 31 日 | 2019 年 4 月 30 日 |
| Node.js 6.10 | nodejs6.10 | Amazon Linux | 2019 年 8 月 12 日 | 2019 年 7 月 12 日 | 2019 年 8 月 12 日 |
| .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 2019 年 6 月 27 日 | 2019 年 6 月 30 日 | 2019 年 7 月 30 日 |
| .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 2019 年 5 月 30 日 | 2019 年 4 月 30 日 | 2019 年 5 月 30 日 |
| Node.js 0.10 | nodejs | Amazon Linux | 2016 年 8 月 30 日 | 2016 年 9 月 30 日 | 2016 年 10 月 31 日 |
ほとんどの場合、言語バージョンまたはオペレーティングシステムのサポート終了日は事前に通知されます。以下のリンク先には、Lambda がマネージドランタイムとしてサポートする各言語のサポート終了スケジュールが記載されています。
**言語およびフレームワークのサポートポリシー**
+ **Node.js** – [github.com](https://github.com/nodejs/Release#release-schedule)
+ **Python** – [devguide.python.org](https://devguide.python.org/versions/#versions)
+ **Ruby** – [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/)
+ **Java** – [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) と [Corretto のよくある質問](https://aws.amazon.com/corretto/faqs/)
+ **Go** – [golang.org](https://golang.org/doc/devel/release.html)
+ **.NET** — [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core)
# 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) を使用することで組織全体に適用できます。関数を以前のランタイムバージョンにロールバックする必要がある場合は、ケースバイケースでポリシー例外を付与することができます。
# 非推奨のランタイムを使用する Lambda 関数に関するデータを取得する
Lambda ランタイムが非推奨に近づくと、Lambda は E メールでアラートを送信し、 Health Dashboard と Trusted Advisor で通知を提供します。これらの E メールと通知には、 ランタイムを使用する関数の \$1LATEST バージョンが一覧で記載されます。特定のランタイムを使用するすべての関数バージョンを一覧にするには、 AWS Command Line Interface (AWS CLI) またはいずれかの AWS SDK を使用できます。
非推奨になるランタイムを使用している関が多数ある場合は、 AWS CLIまたは AWS SDK を使用して、最も頻繁に使用される関数の更新を優先することもできます。
AWS CLI および AWS SDK を使用して、特定のランタイムを使用する関数に関するデータを収集する方法については、以下のセクションを参照してください。
## 特定のランタイムを使用する関数バージョンの一覧表示
AWS CLI を使用して、特定のランタイムを使用するすべての関数バージョンを一覧表示するには、次のコマンドを実行します。`RUNTIME_IDENTIFIER` を廃止予定のランタイムの名前に置き換えて、お使いの AWS リージョン を選択してください。関数の \$1LATEST バージョンだけを一覧表示するには、`--function-version ALL` をコマンドから省略します。
```
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn"
```
**ヒント**
コマンド例では、特定の AWS アカウント の `us-east-1` リージョン内の関数を一覧表示します。このコマンドを、アカウントが機能している各リージョンと各 AWS アカウント で繰り返す必要があります。
AWS SDK のいずれかを使用して、特定のランタイムを使用する関数を一覧表示することもできます。次のサンプルコードでは、V3 AWS SDK for JavaScript と AWS SDK for Python (Boto3) を使用して、特定のランタイムを使用する関数として関数 ARN のリストを返します。このサンプルコードは、リストされた各関数の CloudWatch ロググループも返します。このロググループを使用して、関数の最後の呼び出し日を確認できます。詳細については、次のセクション [最も頻繁に使用される関数と、最近呼び出された関数の特定](#runtimes-list-deprecated-statistics) を参照してください。
------
#### [ Node.js ]
**Example 特定のランタイムを使用して関数を一覧表示する JavaScript コード**
```
import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda";
const lambdaClient = new LambdaClient();
const command = new ListFunctionsCommand({
FunctionVersion: "ALL",
MaxItems: 50
});
const response = await lambdaClient.send(command);
for (const f of response.Functions){
if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14'
console.log(f.FunctionArn);
// get the CloudWatch log group of the function to
// use later for finding the last invocation date
console.log(f.LoggingConfig.LogGroup);
}
}
// If your account has more functions than the specified
// MaxItems, use the returned pagination token in the
// next request with the 'Marker' parameter
if ('NextMarker' in response){
let paginationToken = response.NextMarker;
}
```
------
#### [ Python ]
**Example 特定のランタイムを使用して関数を一覧表示する Python コード**
```
import boto3
from botocore.exceptions import ClientError
def list_lambda_functions(target_runtime):
lambda_client = boto3.client('lambda')
response = lambda_client.list_functions(
FunctionVersion='ALL',
MaxItems=50
)
if not response['Functions']:
print("No Lambda functions found")
else:
for function in response['Functions']:
if function['PackageType']=='Zip' and function['Runtime'] == target_runtime:
print(function['FunctionArn'])
# Print the CloudWatch log group of the function
# to use later for finding last invocation date
print(function['LoggingConfig']['LogGroup'])
if 'NextMarker' in response:
pagination_token = response['NextMarker']
if __name__ == "__main__":
# Replace python3.12 with the appropriate runtime ID for your Lambda functions
list_lambda_functions('python3.12')
```
------
AWS SDK で [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html) アクションを使用して関数をリストする方法の詳細については、目的のプログラミング言語の [SDK ドキュメント](https://aws.amazon.com/developer/tools/)を参照してください。
AWS Config の高度なクエリ機能を使用して、影響を受けるランタイムを使用するすべての関数を一覧表示することもできます。このクエリは関数の \$1LATEST バージョンのみを返しますが、1 つのコマンドでクエリを集約して、すべてのリージョンの複数の AWS アカウント にある関数を一覧表示できます。詳細については、「*AWS Config デベロッパーガイド*」の「[Querying the Current Configuration State of AWS Auto Scaling Resources](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html)」を参照してください。
## 最も頻繁に使用される関数と、最近呼び出された関数の特定
AWS アカウント に、非推奨になる予定のランタイムを使用する関数が含まれている場合は、頻繁に呼び出される関数や最近呼び出された関数の更新を優先できます。
関数が少ない場合は、CloudWatch Logs コンソールを使用して関数のログストリームを確認することで、この情報を収集できます。詳細については、「[CloudWatch Logs に送信されたログデータを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)」を参照してください。
最近の関数呼び出し数を確認するには、Lambda コンソールに表示される CloudWatch メトリクス情報を使用することもできます。この情報を表示するには、次の手順を実行します。
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 呼び出し統計を表示する関数を選択します。
1. [**Monitor**] (モニタリング) タブを選択します。
1. 日付範囲ピッカーを使用して、統計を表示する期間を設定します。最近の呼び出しは、**[呼び出し]** ペインに表示されます。
多くの関数を持つアカウントの場合は、AWS CLI または AWS SDK のいずれかを使用して、[DescribeLogStreams](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html) および [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html) API アクションを使用してプログラムでこのデータを収集する方が効率的です。
次の例では、V3 AWS SDK for JavaScript と AWS SDK for Python (Boto3) を使用して、特定の関数の最後の呼び出し日を確認し、過去 14 日間の特定の関数の呼び出し回数を特定するコードスニペットを示します。
------
#### [ Node.js ]
**Example 関数の最後の呼び出し時間を特定する JavaScript コード**
```
import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs";
const cloudWatchLogsClient = new CloudWatchLogsClient();
const command = new DescribeLogStreamsCommand({
logGroupName: '',
orderBy: 'LastEventTime',
descending: true,
limit: 1
});
try {
const response = await cloudWatchLogsClient.send(command);
const lastEventTimestamp = response.logStreams.length > 0 ?
response.logStreams[0].lastEventTimestamp : null;
// Convert the UNIX timestamp to a human-readable format for display
const date = new Date(lastEventTimestamp).toLocaleDateString();
const time = new Date(lastEventTimestamp).toLocaleTimeString();
console.log(`${date} ${time}`);
} catch (e){
console.error('Log group not found.')
}
```
------
#### [ Python ]
**Example 関数の最後の呼び出し時間を特定する Python コード**
```
import boto3
from datetime import datetime
cloudwatch_logs_client = boto3.client('logs')
response = cloudwatch_logs_client.describe_log_streams(
logGroupName='',
orderBy='LastEventTime',
descending=True,
limit=1
)
try:
if len(response['logStreams']) > 0:
last_event_timestamp = response['logStreams'][0]['lastEventTimestamp']
print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds
else:
last_event_timestamp = None
except:
print('Log group not found')
```
------
**ヒント**
[ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html) API オペレーションを使用して、関数のロググループ名を見つけることができます。[特定のランタイムを使用する関数バージョンの一覧表示](#runtimes-list-deprecated-versions) のコードを参照して、このオペレーションを実行する方法の例を確認できます。
------
#### [ Node.js ]
**Example 過去 14 日間の呼び出し数を検索する JavaScript コード**
```
import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch";
const cloudWatchClient = new CloudWatchClient();
const command = new GetMetricStatisticsCommand({
Namespace: 'AWS/Lambda',
MetricName: 'Invocations',
StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago
EndTime: new Date(Date.now()),
Period: 86400 * 14, // 14 days.
Statistics: ['Sum'],
Dimensions: [{
Name: 'FunctionName',
Value: ''
}]
});
const response = await cloudWatchClient.send(command);
const invokesInLast14Days = response.Datapoints.length > 0 ?
response.Datapoints[0].Sum : 0;
console.log('Number of invocations: ' + invokesInLast14Days);
```
------
#### [ Python ]
**Example 過去 14 日間の呼び出し数を検索する Python コード**
```
import boto3
from datetime import datetime, timedelta
cloudwatch_client = boto3.client('cloudwatch')
response = cloudwatch_client.get_metric_statistics(
Namespace='AWS/Lambda',
MetricName='Invocations',
Dimensions=[
{
'Name': 'FunctionName',
'Value': ''
},
],
StartTime=datetime.now() - timedelta(days=14),
EndTime=datetime.now(),
Period=86400 * 14, # 14 days
Statistics=[
'Sum'
]
)
if len(response['Datapoints']) > 0:
invokes_in_last_14_days = int(response['Datapoints'][0]['Sum'])
else:
invokes_in_last_14_days = 0
print(f'Number of invocations: {invokes_in_last_14_days}')
```
------
# ランタイム環境の変更
[内部拡張機能](lambda-extensions.md)を使用して、ランタイムプロセスを変更できます。内部拡張機能は、個別のプロセスではありません。ランタイムプロセスの一部として実行されます。
Lambda は、ランタイムにオプションとツールを追加するように設定することが可能な、言語固有の[環境変数](configuration-envvars.md)を提供します。Lambda さらに[ラッパースクリプト](#runtime-wrapper)を呼び出します。これにより、Lambda はランタイム起動をスクリプトに委任できます。ラッパースクリプトを作成して、ランタイムの起動動作をカスタマイズできます。
## 言語固有の環境変数
Lambda は、次の言語固有の環境変数を通じて、関数の初期化中にコードをプリロードできるように設定専用の方法をサポートしています。
+ `JAVA_TOOL_OPTIONS` – Java を使用する場合、Lambda は追加のコマンドライン変数を設定するために、この環境変数をサポートします。この環境変数では、ツールの初期化を指定できます。具体的には、`agentlib` または `javaagent` オプションを使用して、ネイティブまたは Java プログラミング言語エージェントの起動を指定できます。詳細については、「[`JAVA_TOOL_OPTIONS` 環境変数](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options)」を参照してください。
+ `NODE_OPTIONS` — [Node.js ランタイム](lambda-nodejs.md)で使用できます。
+ `DOTNET_STARTUP_HOOKS` -.NET Core 3.1 以降では、この環境変数が、Lambda が使用できるアセンブリ (dll) へのパスを指定します。
起動プロパティを設定するには、言語固有の環境変数を使用することを推奨します。
## ラッパースクリプト
*ラッパースクリプト*を作成することで、Lambda 関数のランタイム起動動作をカスタマイズできます。ラッパースクリプトを使用すると、言語固有の環境変数を通じて、設定できない設定パラメーターを設定できます。
**注記**
ラッパースクリプトがランタイムプロセスを正常に開始しない場合、呼び出しが失敗することがあります。
ラッパースクリプトは、すべてのネイティブ [Lambda ランタイム](lambda-runtimes.md)でサポートされています。ラッパースクリプトは [OS 専用ランタイム](runtimes-provided.md) (`provided` ランタイムファミリー) ではサポートされていません。
関数にラッパースクリプトを使用すると、Lambda はユーザーのスクリプトを使ってランタイムを開始します。Lambda は、インタープリターへのパスと、標準ランタイムを起動するための元の引数のすべてをスクリプトに送信します。スクリプトは、プログラムの起動動作を拡張または変換できます。例えば、スクリプトは、引数の挿入と変更、環境変数の設定、またはメトリクス/エラー/その他の診断情報の取得を行うことができます。
スクリプトを指定するには、実行可能バイナリまたはスクリプトのファイルシステムパスとして `AWS_LAMBDA_EXEC_WRAPPER` 環境変数の値を設定します。
### 例: ラッパースクリプトを作成して Lambda レイヤーとして使用する
次の例では、`-X importtime` オプションを指定して Python インタプリタを起動するラッパースクリプトを作成します。関数を実行すると、Lambda は、各インポートのインポートに要した時間を示すログエントリを生成します。
**ラッパースクリプトを作成してレイヤーとして使用するには**
1. レイヤーのディレクトリを作成します。
```
mkdir -p python-wrapper-layer/bin
cd python-wrapper-layer/bin
```
1. `bin` ディレクトリで、次のコードを `importtime_wrapper` という名前の新しいファイルに貼り付けます。これはラッパースクリプトです。
```
#!/bin/bash
# the path to the interpreter and all of the originally intended arguments
args=("$@")
# the extra options to pass to the interpreter
extra_args=("-X" "importtime")
# insert the extra options
args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")
# start the runtime with the extra options
exec "${args[@]}"
```
1. スクリプトに実行可能権限を付与します。
```
chmod +x importtime_wrapper
```
1. レイヤーの .zip ファイルを作成します。
```
cd ..
zip -r ../python-wrapper-layer.zip .
```
1. .zip ファイルに次のディレクトリ構造があることを確認します。
```
python-wrapper-layer.zip
└ bin
└ importtime_wrapper
```
1. .zip パッケージを使用して[レイヤーを作成します](creating-deleting-layers.md#layers-create)。
1. Lambda コンソールを使用して関数を作成します。
1. [Lambda コンソール](https://console.aws.amazon.com/lambda)を開きます。
1. [**Create function**] (関数の作成) をクリックします。
1. **[Function name]** (関数名) を入力します。
1. **[ランタイム]** で、**サポートされている最新**の Python ランタイムを選択します。
1. [**Create function** (関数の作成)] を選択します。
1. レイヤーを関数に追加します。
1. 関数を選択し、次に **[コード]** タブを選択します。
1. **[レイヤー]** セクションまで下にスクロールし、**[レイヤーの追加]** を選択します。
1. **[レイヤーソース]** で、**[カスタムレイヤー]** を選択し、**[カスタムレイヤー]** ドロップダウンリストからレイヤーを選択します。
1. [**Version (バージョン)**] で、[**1**] を選択します。
1. **[追加]** を選択します。
1. ラッパー環境変数を追加します。
1. **[設定]** タブを選択してから、**[環境変数]** を選択します。
1. [**環境変数**] で、[**編集**] を選択します。
1. [**環境変数の追加**] を選択します
1. [**キー**] に「`AWS_LAMBDA_EXEC_WRAPPER`」と入力します。
1. **[値]** に「`/opt/bin/importtime_wrapper`」(`/opt/` \$1 .zip レイヤーのフォルダ構造) と入力します。
1. [**Save**] を選択します。
1. ラッパースクリプトをテストします。
1. **[テスト]** タブを選択します。
1. **[テストイベント]** で、**[テスト]** を選択します。テストイベントを作成する必要はありません。デフォルトのイベントが機能します。
1. **[ログ出力]** まで下にスクロールします。ラッパースクリプトが `-X importtime` オプションで Python インタプリタを起動したため、ログには各インポートにかかった時間が示されます。以下に例を示します。
```
532 | collections
import time: 63 | 63 | _functools
import time: 1053 | 3646 | functools
import time: 2163 | 7499 | enum
import time: 100 | 100 | _sre
import time: 446 | 446 | re._constants
import time: 691 | 1136 | re._parser
import time: 378 | 378 | re._casefix
import time: 670 | 2283 | re._compiler
import time: 416 | 416 | copyreg
```
# カスタムランタイムに Lambda ランタイム API を使用する
AWS Lambda では、[カスタムランタイム](runtimes-custom.md)の HTTP API を使用して Lambda の呼び出しイベントを受け取り、レスポンスデータを Lambda の[実行環境](lambda-runtimes.md)に送り返します。このセクションでは、Lambda ランタイム API の API リファレンスについて説明します。
**Lambda マネージドインスタンスが同時リクエストをサポートする**
Lambda マネージドインスタンスは、Lambda (デフォルト) 関数と同じランタイム API を使用します。主な違いは、マネージドインスタンスは、設定された `AWS_LAMBDA_MAX_CONCURRENCY` 制限まで同時 `/next` および `/response` リクエストを受け入れることができることです。これにより、1 つの実行環境内で複数の呼び出しを同時に処理できます。マネージドインスタンスの詳細については、「[Lambda マネージドインスタンスの実行環境について理解する](lambda-managed-instances-execution-environment.md)」を参照してください。
![\[実行環境のアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
ランタイム API バージョン **2018-06-01** の OpenAPI 仕様は、[runtime-api.zip](samples/runtime-api.zip) から入手できます。
API リクエスト URL を作成するには、ランタイムは `AWS_LAMBDA_RUNTIME_API` 環境変数から API エンドポイントを取得し、API バージョンを追加し、目的のリソースパスを追加します。
**Example リクエスト**
```
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
```
**Topics**
+ [
## 次の呼び出し
](#runtimes-api-next)
+ [
## 呼び出しレスポンス
](#runtimes-api-response)
+ [
## 初期化エラー
](#runtimes-api-initerror)
+ [
## 呼び出しエラー
](#runtimes-api-invokeerror)
## 次の呼び出し
**パス** – `/runtime/invocation/next`
**メソッド** - **GET**
ランタイムは、このメッセージを Lambda に送信して、呼び出しイベントをリクエストします。レスポンス本文には、呼び出しのペイロードが含まれます。これは、関数トリガーのイベントデータを含む JSON ドキュメントです。レスポンスヘッダーには、呼び出しに関する追加データが含まれます。
**レスポンスヘッダー**
+ `Lambda-Runtime-Aws-Request-Id` - リクエスト ID。関数の呼び出しをトリガーしたリクエストを識別します。
例えば、`8476a536-e9f4-11e8-9739-2dfe598c3fcd`。
+ `Lambda-Runtime-Deadline-Ms` - 関数がタイムアウトした日付 (Unix 時間のミリ秒)。
例えば、`1542409706888`。
+ `Lambda-Runtime-Invoked-Function-Arn` - 呼び出しで指定されている Lambda 関数、バージョン、またはエイリアスの ARN。
例えば、`arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`。
+ `Lambda-Runtime-Trace-Id` - [AWS X-Ray トレースヘッダー](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader)。
例えば、`Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`。
+ `Lambda-Runtime-Client-Context` - AWS Mobile SDK の呼び出しにおいて、クライアントアプリケーションおよびデバイスに関するデータ。
+ `Lambda-Runtime-Cognito-Identity` - AWS Mobile SDK からの呼び出しの場合は、Amazon Cognito ID プロバイダーに関するデータ。
応答が遅れる可能性があるため、`GET` リクエストにタイムアウトを設定しないでください。Lambda がランタイムをブートストラップするときと、返すイベントがランタイムにあるときとの間に、ランタイムプロセスが数秒間停止する可能性があります。
リクエスト ID は、Lambda 内の呼び出しを追跡します。レスポンス送信時に呼び出しを指定する場合に使用します。
トレースヘッダーには、トレース ID、親 ID、サンプリングデシジョンが含まれます。リクエストがサンプリングされている場合、リクエストが Lambda、またはアップストリームサービスによってサンプリングされた場合。ランタイムは、`_X_AMZN_TRACE_ID` をヘッダーの値に設定します。X-Ray SDK はこの値を読み込んで ID を取得し、リクエストを追跡するかどうかを判断します。
## 呼び出しレスポンス
**パス** – `/runtime/invocation/AwsRequestId/response`
**メソッド** - **POST**
関数が実行されて完了すると、ランタイムは呼び出し応答を Lambda に送信します。同期呼び出しの場合、Lambda はそのレスポンスをクライアントに送ります。
**Example 成功リクエスト**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS"
```
## 初期化エラー
関数がエラーを返すか、初期化中にランタイムでエラーが発生した場合、ランタイムはこのメソッドを使用してエラーを Lambda に報告します。
**パス** – `/runtime/init/error`
**メソッド** - **POST**
**ヘッダー**
`Lambda-Runtime-Function-Error-Type` – ランタイムで発生したエラータイプ。必須: いいえ。
このヘッダーは、文字列値で構成されています。Lambda はどのような文字列でも受け入れますが、形式は にすることが推奨されます。以下に例を示します。
+ Runtime.NoSuchHandler
+ Runtime.APIKeyNotFound
+ Runtime.ConfigInvalid
+ Runtime.UnknownReason
**Body パラメータ**
`ErrorRequest` - エラーに関する情報。必須: いいえ。
このフィールドは、次の構造を持つ JSON オブジェクトです。
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Lambda は、`errorType` として任意の値を受け入れることに注意してください。
次の例は、呼び出しで指定されたイベントデータを関数で解析できなかった Lambda 関数のエラーメッセージを示しています。
**Example 関数エラー**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**レスポンス本文のパラメータ**
+ `StatusResponse` – 文字列。202 応答コードとともに送信されるステータス情報。
+ `ErrorResponse` - エラー応答コードとともに送信される追加のエラー情報。ErrorResponse には、エラータイプとエラーメッセージが含まれています。
**レスポンスコード**
+ 202 - Accepted
+ 403 – Forbidden
+ 500 – Container error 回復不能な状態。ランタイムはすぐに終了することが望ましいです。
**Example 初期化エラーリクエスト**
```
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
## 呼び出しエラー
関数がエラーを返すか、ランタイムでエラーが発生した場合、ランタイムはこのメソッドを使用してエラーを Lambda に報告します。
**パス** – `/runtime/invocation/AwsRequestId/error`
**メソッド** - **POST**
**ヘッダー**
`Lambda-Runtime-Function-Error-Type` – ランタイムで発生したエラータイプ。必須: いいえ。
このヘッダーは、文字列値で構成されています。Lambda はどのような文字列でも受け入れますが、形式は にすることが推奨されます。以下に例を示します。
+ Runtime.NoSuchHandler
+ Runtime.APIKeyNotFound
+ Runtime.ConfigInvalid
+ Runtime.UnknownReason
**Body パラメータ**
`ErrorRequest` - エラーに関する情報。必須: いいえ。
このフィールドは、次の構造を持つ JSON オブジェクトです。
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Lambda は、`errorType` として任意の値を受け入れることに注意してください。
次の例は、呼び出しで指定されたイベントデータを関数で解析できなかった Lambda 関数のエラーメッセージを示しています。
**Example 関数エラー**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**レスポンス本文のパラメータ**
+ `StatusResponse` – 文字列。202 応答コードとともに送信されるステータス情報。
+ `ErrorResponse` - エラー応答コードとともに送信される追加のエラー情報。ErrorResponse には、エラータイプとエラーメッセージが含まれています。
**レスポンスコード**
+ 202 - Accepted
+ 400 – Bad Request
+ 403 – Forbidden
+ 500 – Container error 回復不能な状態。ランタイムはすぐに終了することが望ましいです。
**Example エラーリクエスト**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
# Lambda の OS 専用ランタイムを使用する状況
Lambda は Java、Python、Node.js、.NET、Ruby の[マネージドランタイム](lambda-runtimes.md)を提供しています。マネージドランタイムとして使用できないプログラミング言語で Lambda 関数を作成するには、OS 専用ランタイム (`provided` ランタイムファミリー) を使用します。OS 専用ランタイムの主な使用例は次の 3 つです。
+ **ネイティブアヘッドオブタイム (AOT) コンパイル**: Go、Rust、Swift、C\$1\$1 などの言語は、実行可能なバイナリにネイティブにコンパイルされるため、専用の言語ランタイムは必要ありません。これらの言語に必要なのは、コンパイルされたバイナリを実行できる OS 環境だけです。Lambda OS 専用ランタイムを使用して、.NET ネイティブ AOT と Java GraalVM Native Image でコンパイルされたバイナリをデプロイすることもできます。
バイナリには、ランタイムインターフェイスクライアントを含める必要があります。ランタイムインターフェイスクライアントは [カスタムランタイムに Lambda ランタイム API を使用する](runtimes-api.md) を呼び出して関数呼び出しを取得し、次に関数ハンドラーを呼び出します。Lambda は [Rust](lambda-rust.md)、[Go](golang-package.md#golang-package-mac-linux)、[.NET Native AOT](dotnet-native-aot.md)、[Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (実験用)、[C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (実験用) のランタイムインターフェイスクライアントを提供しています。
バイナリは Linux 環境用に、関数に使用する予定のものと同じ命令セットアーキテクチャ (x86\$164 または arm64) でコンパイルする必要があります。
+ **サードパーティランタイム**: PHP 用の [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) などの既製のランタイムを使用して Lambda 関数を実行できます。
+ **カスタムランタイム**: Lambda がマネージドランタイムを提供していない言語または言語バージョン (Node.js 19 など) 用に独自のランタイムを構築できます。詳細については、「[AWS Lambda 用カスタムランタイムの構築](runtimes-custom.md)」を参照してください。これは OS 専用ランタイムでは最も稀なユースケースです。
Lambda は以下の OS 専用 ランタイムをサポートします。
| 名前 | 識別子 | オペレーティングシステム | 廃止日 | 関数の作成をブロックする | 関数の更新をブロックする |
| --- | --- | --- | --- | --- | --- |
| OS 専用ランタイム | `provided.al2023` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 |
| OS 専用ランタイム | `provided.al2` | Amazon Linux 2 | 2026 年 7 月 31 日 | 2026 年 8 月 31 日 | Sep 30, 2026 |
Amazon Linux 2023 (`provided.al2023`) ランタイムには、デプロイのフットプリントが小さいことや、`glibc` などのライブラリのバージョンが更新されていることなど、Amazon Linux 2 に比べていくつかの利点があります。
`provided.al2023` ランタイムは、Amazon Linux 2 のデフォルトのパッケージマネージャーである `yum` ではなく、`dnf` をパッケージマネージャーとして使用します。`provided.al2023` と `provided.al2` の違いの詳細については、AWS コンピューティングブログの「[Introducing the Amazon Linux 2023 runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/)」を参照してください。
# AWS Lambda 用カスタムランタイムの構築
AWS Lambda ランタイムは、どのプログラミング言語でも実装できます。ランタイムは、関数が呼び出されたときに Lambda 関数のハンドラメソッドを実行するプログラムです。ランタイムは、関数のデプロイパッケージに含めるか、または[レイヤー](chapter-layers.md)で配信することができます。Lambda 関数を作成するときは、[OS 専用ランタイム (`provided` ランタイムファミリー](runtimes-provided.md)) を選択します。
**注記**
カスタムランタイムの作成は高度なユースケースです。ネイティブバイナリへのコンパイルやサードパーティの既製のランタイムの使用に関する情報をお探しの場合は、「[Lambda の OS 専用ランタイムを使用する状況](runtimes-provided.md)」を参照してください。
カスタムランタイムデプロイの手順については、「[チュートリアル: カスタムランタイムの構築](runtimes-walkthrough.md)」を参照してください。
**Topics**
+ [
## 要件
](#runtimes-custom-build)
+ [
## カスタムランタイムでのレスポンスストリーミングの実装
](#runtimes-custom-response-streaming)
+ [
## Lambda マネージドインスタンスのカスタムランタイムの構築
](#runtimes-custom-managed-instances)
## 要件
カスタムランタイムでは、特定の初期化タスクと処理タスクを完了する必要があります。ランタイムは、関数のセットアップコードの実行、環境変数からのハンドラ名の読み取り、Lambda ランタイム API からの呼び出しイベントの読み取りを行います。ランタイムは、イベントデータを関数ハンドラに渡し、ハンドラからのレスポンスを Lambda に戻します。
### 初期化タスク
初期化タスクは、呼び出しを処理する環境を準備するために、[関数のインスタンスごとに](lambda-runtime-environment.md) 1 回実行されます。
+ **設定の取得** – 関数と環境に関する詳細を取得するには、環境変数を参照してください。
+ `_HANDLER` – 関数の設定からハンドラへの場所。標準形式は、`file.method` です。ここで、`file` は、拡張子のないファイル名、`method` は、ファイルで定義されているメソッドまたは関数の名前を表します。
+ `LAMBDA_TASK_ROOT` – 関数コードを含むディレクトリ。
+ `AWS_LAMBDA_RUNTIME_API` – ランタイム API のホストおよびポート。
使用可能な変数の完全なリストについては、「[定義されたランタイム環境変数](configuration-envvars.md#configuration-envvars-runtime)」を参照してください。
+ **関数の初期化** – ハンドラファイルをロードし、ハンドラファイルに含まれているグローバルコードまたは静的コードを実行します。関数は、SDK クライアントやデータベース接続などの静的リソースを一度作成し、複数の呼び出しに再利用します。
+ **ハンドラエラー** – エラーが発生した場合は、[初期化エラー](runtimes-api.md#runtimes-api-initerror) API を呼び出し、すぐに終了します。
初期化は請求された実行時間とタイムアウトの対象です。実行によって関数の新しいインスタンスの初期化がトリガーされると、ログと [AWS X-Ray トレース](services-xray.md)に初期化時間が表示されます。
**Example ログ**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### 処理タスク
実行されている間、ランタイムは [Lambda ランタイムインターフェイス](runtimes-api.md)を使用して、受信イベントの管理とエラーのレポートを行います。初期化タスクが完了したら、ランタイムは、受信イベントをループで処理します。ランタイムコードで、次のステップを順に実行します。
+ **イベントの取得** – [次の呼び出し](runtimes-api.md#runtimes-api-next) API を呼び出して、次のイベントを取得します。レスポンス本文には、イベントデータが含まれます。レスポンスヘッダーには、リクエスト ID などの情報が含まれます。
+ **トレースヘッダーの伝播** – X-Ray トレースヘッダーを API レスポンスの`Lambda-Runtime-Trace-Id`ヘッダーから取得します。`_X_AMZN_TRACE_ID` 環境変数をローカルで同じ値に設定します。X-Ray SDK はこの値を使用して、サービス間でトレースデータを接続します。
+ **コンテキストオブジェクトの作成** – 環境変数のコンテキスト情報および API レスポンスのヘッダーでオブジェクトを作成します。
+ **関数ハンドラの呼び出し** – イベントおよびコンテキストオブジェクトをハンドラに渡します。
+ **レスポンスの処理** – [呼び出しレスポンス](runtimes-api.md#runtimes-api-response) API を呼び出し、レスポンスをハンドラから投稿します。
+ **ハンドラエラー** – エラーが発生した場合は、[呼び出しエラー](runtimes-api.md#runtimes-api-invokeerror) API を呼び出します。
+ **クリーンアップ** – 不要なリソースの解放、他のサービスへのデータ送信、次のイベント取得前の追加タスクの実行を行います。
### エントリポイント
カスタムランタイムのエンドポイントは、`bootstrap` という名前の実行可能ファイルです。ブートストラップファイルをランタイムにするか、ランタイムを作成する別のファイルを呼び出す場合があります。デプロイパッケージのルートに `bootstrap` という名前のファイルが含まれていない場合、Lambda は関数のレイヤーでファイルを検索します。`bootstrap` ファイルが存在しないか、実行可能でない場合、関数は呼び出し時に `Runtime.InvalidEntrypoint` エラーを返します。
`bootstrap` ファイルによる例では、バンドルされた Node.js バージョンを使用して、`runtime.js` という別のファイルで JavaScript ランタイムを実行します。
**Example bootstrap**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## カスタムランタイムでのレスポンスストリーミングの実装
[レスポンスストリーミング関数](configuration-response-streaming.md)については、`response` および `error` エンドポイントは、ランタイムが部分的なレスポンスをクライアントにストリーミングし、ペイロードをチャンクで返すことができるように動作が若干変更されています。特定の動作の詳細については、以下を参照してください。
+ `/runtime/invocation/AwsRequestId/response` – ランタイムからの `Content-Type` ヘッダーを伝播して、クライアントに送信します。Lambda は、HTTP/1.1 チャンク転送エンコーディングを介して、レスポンスペイロードをチャンクで返します。Lambda にレスポンスをストリーミングするには、ランタイムが以下を実行する必要があります。
+ `Lambda-Runtime-Function-Response-Mode` HTTP ヘッダーを `streaming` に設定する。
+ `Transfer-Encoding` ヘッダーを `chunked` に設定します。
+ HTTP/1.1 チャンク転送エンコーディング仕様に従ったレスポンスを書き込む
+ レスポンスを正常に書き込んだ後、基盤となる接続を閉じます。
+ `/runtime/invocation/AwsRequestId/error` – ランタイムはこのエンドポイントを使用して、関数またはランタイムのエラーを Lambda に報告できます。Lambda は `Transfer-Encoding` ヘッダーも受け入れます。このエンドポイントを呼び出せるのは、ランタイムが呼び出しレスポンスの送信を開始する前だけです。
+ `/runtime/invocation/AwsRequestId/response` でエラー トレーラーを使用して中間エラーを報告 - ランタイムが呼び出しレスポンスの書き込みを開始した後に発生したエラーを報告するために、ランタイムはオプションで `Lambda-Runtime-Function-Error-Type` および `Lambda-Runtime-Function-Error-Body` という名前の HTTP 末尾ヘッダーをアタッチすることができます。Lambda はこれを正常なレスポンスとして扱い、ランタイムが提供するエラーメタデータをクライアントに転送します。
**注記**
末尾ヘッダーをアタッチするには、ランタイムが HTTP リクエストの先頭に `Trailer` ヘッダー値を設定する必要があります。これは、HTTP/1.1 チャンク転送エンコーディング仕様によって義務付けられています。
+ `Lambda-Runtime-Function-Error-Type` – ランタイムで発生したエラータイプ。このヘッダーは、文字列値で構成されています。Lambda はどのような文字列でも受け入れますが、形式は ** にすることが推奨されます。例えば、`Runtime.APIKeyNotFound`。
+ `Lambda-Runtime-Function-Error-Body` – Base64-encoded でのエラーに関する情報。
## Lambda マネージドインスタンスのカスタムランタイムの構築
Lambda マネージドインスタンスは、Lambda (デフォルト) 関数と同じランタイム API を使用します。ただし、マネージドインスタンスの同時実行モデルをサポートするためにカスタムランタイムを実装する方法には大きな違いがあります。
### 同時リクエスト処理
マネージドインスタンスのカスタムランタイムを構築する際の主な違いは、同時呼び出しのサポートです。ランタイムが一度に 1 つの呼び出しを処理する Lambda (デフォルト) 関数とは異なり、マネージドインスタンスは 1 つの実行環境内で複数の呼び出しを同時に処理できます。
カスタムランタイムは次の条件を満たす必要があります。
+ **同時 `/next` リクエストをサポートする** – ランタイムは、`AWS_LAMBDA_MAX_CONCURRENCY` 環境変数で指定された制限まで、[次の呼び出し](runtimes-api.md#runtimes-api-next) API を複数回同時に呼び出すことができます。
+ **同時 `/response` リクエストを処理する** – 複数の呼び出しが[呼び出しレスポンス](runtimes-api.md#runtimes-api-response) API を同時に呼び出すことができます。
+ **スレッドセーフなリクエスト処理を実装する** – 共有リソースと状態を適切に管理することで、同時呼び出しが相互に干渉しないようにします。
+ **一意のリクエスト ID を使用する** – `Lambda-Runtime-Aws-Request-Id` ヘッダーを使用して各呼び出しを個別に追跡し、レスポンスを対応するリクエストと照合します。
### 実装パターン
マネージドインスタンスランタイムの一般的な実装パターンには、同時呼び出しを処理するワーカースレッドまたはプロセスの作成が含まれます。
1. **同時実行数の制限を読み取る** – 初期化時に、`AWS_LAMBDA_MAX_CONCURRENCY` 環境変数を読み取って、サポートする同時呼び出しの数を決定します。
1. **ワーカープールを作成する** – 同時実行数の制限と等しいワーカー (スレッド、プロセス、または非同期タスク) のプールを初期化します。
1. **ワーカー処理ループ** – 各ワーカーは個別に以下を行います。
+ 呼び出しイベントを取得するために `/runtime/invocation/next` を呼び出す
+ イベントデータを使用して関数ハンドラーを呼び出す
+ レスポンスを `/runtime/invocation/AwsRequestId/response` に投稿する
+ ループを繰り返す
### その他の考慮事項
+ **ログ記録形式** – マネージドインスタンスは JSON ログ形式のみをサポートします。ランタイムが `AWS_LAMBDA_LOG_FORMAT` 環境変数を尊重し、JSON 形式のみを使用していることを確認します。詳細については、「[JSON とプレーンテキストのログフォーマットの設定](monitoring-cloudwatchlogs-logformat.md)」を参照してください。
+ **共有リソース** – `/tmp` ディレクトリなどの共有リソースを同時呼び出しで使用する場合は注意してください。競合状態を防ぐために、適切なロックメカニズムを実装します。
Lambda マネージドインスタンスの実行環境の詳細については、「[Lambda マネージドインスタンスの実行環境について理解する](lambda-managed-instances-execution-environment.md)」を参照してください。
# チュートリアル: カスタムランタイムの構築
このチュートリアルでは、カスタムランタイムで Lambda 関数を使用します。まず、ランタイムを関数のデプロイパッケージに含めます。次に、それを関数とは別に管理するレイヤーに移行します。最後に、リソースベースのアクセス許可ポリシーを更新して、ランタイムレイヤーを世界と共有します。
## 前提条件
このチュートリアルでは、基本的な Lambda オペレーションと Lambda コンソールについてある程度の知識があることを前提としています。初めての方は、[コンソールで Lambda の関数の作成](getting-started.md#getting-started-create-function) の手順に従って最初の Lambda 関数を作成してください。
以下の手順を完了するには、[AWS CLI バージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) が必要です。コマンドと予想される出力は、別々のブロックにリストされます。
```
aws --version
```
次のような出力が表示されます。
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
コマンドが長い場合、コマンドを複数行に分割するためにエスケープ文字 (`\`) が使用されます。
Linux および macOS では、任意のシェルとパッケージマネージャーを使用します。
**注記**
Windows では、Lambda でよく使用される一部の Bash CLI コマンド (`zip` など) が、オペレーティングシステムの組み込みターミナルでサポートされていません。Ubuntu および Bash の Windows 統合バージョンを取得するには、[Windows Subsystem for Linux をインストール](https://docs.microsoft.com/en-us/windows/wsl/install-win10)します。このガイドの CLI コマンドの例では、Linux フォーマットを使用しています。Windows CLI を使用している場合、インライン JSON ドキュメントを含むコマンドを再フォーマットする必要があります。
Lambda 関数を作成するには IAM ロールが必要です。ロールには、ログを CloudWatch Logs に送信し、関数で使用される AWS のサービスにアクセスするためのアクセス許可が必要です。関数開発用の実行ロールをお持ちでない場合は、ここで作成します。
**実行ロールを作成するには**
1. IAM コンソールの [[ロールページ](https://console.aws.amazon.com/iam/home#/roles)] を開きます。
1. [**ロールの作成**] を選択します。
1. 次のプロパティでロールを作成します。
+ **信頼されたエンティティ** – **Lambda**。
+ **アクセス許可** – **AWSLambdaBasicExecutionRole**。
+ **ロール名** – **lambda-role**。
**AWSLambdaBasicExecutionRole** ポリシーには、ログを CloudWatch Logs に書き込むために関数が必要とするアクセス許可があります。
## 関数の作成
カスタムランタイムで Lambda 関数を作成します。この例には、ランタイム `bootstrap` ファイルと関数ハンドラーの 2 つのファイルが含まれています。いずれのファイルも Bash で実装されています。
1. プロジェクト用のディレクトリを作成し、そのディレクトリに切り替えます。
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. `bootstrap` という名前の新しいファイルを作成します。これはカスタムランタイムです。
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
ランタイムは、デプロイパッケージから関数スクリプトを読み込みます。2 つの変数を使用して、スクリプトを見つけます。`LAMBDA_TASK_ROOT` は、パッケージが抽出された場所を変数に伝え、`_HANDLER` には、そのスクリプトの名前が含まれます。
ランタイムは関数スクリプトをロードした後、ランタイム API を使用して Lambda から呼び出しイベントを取得し、そのイベントをハンドラーに渡して、レスポンスを Lambda に戻します。リクエスト ID を取得するには、API レスポンスのヘッダーを一時ファイルに保存し、ファイルから `Lambda-Runtime-Aws-Request-Id` ヘッダーを読み込みます。
**注記**
ランタイムは、他にもエラーの処理などに使用され、コンテキスト情報をハンドラに提供します。詳細については、「[要件](runtimes-custom.md#runtimes-custom-build)」を参照してください。
1. 関数のためのスクリプトを作成します。以下のスクリプト例は、イベントデータを取得するハンドラー関数を定義し、それを `stderr` にログ記録して返します。
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
`runtime-tutorial` ディレクトリは以下のようになります。
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. ファイルを実行可能にして .zip アーカイブに追加します。これがデプロイパッケージです。
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. `bash-runtime`という名前の関数を作成します。`--role` には、Lambda [実行ロール](lambda-intro-execution-role.md)の ARN を入力します。
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. 関数を呼び出します。
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、バージョン 2 の AWS Command Line Interface ユーザーガイドの「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
次のような結果が表示されます。
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. レスポンスを確認してください。
```
cat response.txt
```
次のような結果が表示されます。
```
Echoing request: '{"text":"Hello"}'
```
## レイヤーの作成
ランタイムコードと関数コードを区別するには、ランタイムのみを含むレイヤーを作成します。レイヤーを使用すると、関数の依存関係を個別に開発することができ、複数の関数で同じレイヤーを使用する場合には、ストレージの使用量を抑えることができます。詳細については、「[レイヤーによる Lambda 依存関係の管理](chapter-layers.md)」を参照してください。
1. `bootstrap` ファイルを含む .zip ファイルを作成します。
```
zip runtime.zip bootstrap
```
1. [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x) コマンドを使用してレイヤーを作成します。
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
これにより、最初のバージョンのレイヤーが作成されます。
## 関数の更新
関数でランタイムレイヤーを使用するには、レイヤーを使用するように関数を設定し、関数からランタイムコードを削除します。
1. 関数設定を更新して、レイヤーに取り込みます。
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
これにより、ランタイムが `/opt` ディレクトリの関数に追加されます。Lambda がレイヤーのランタイムを使用するようにするには、次の 2 つのステップに示すように、関数のデプロイパッケージから `boostrap` を削除する必要があります。
1. 関数コードを含む .zip ファイルを作成します。
```
zip function-only.zip function.sh
```
1. ハンドラスクリプトのみ含まれるように関数コードを更新します。
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. 関数を呼び出し、ランタイムレイヤーで正常に動作することを確認します。
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、バージョン 2 の AWS Command Line Interface ユーザーガイドの「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
次のような結果が表示されます。
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. レスポンスを確認してください。
```
cat response.txt
```
次のような結果が表示されます。
```
Echoing request: '{"text":"Hello"}'
```
## ランタイムの更新
1. 実行環境に関する情報をログ記録するには、環境変数が出力されるようにランタイムスクリプトを更新します。
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. `bootstrap` ファイルの新しいバージョンを含む .zip ファイルを作成します。
```
zip runtime.zip bootstrap
```
1. `bash-runtime` レイヤーの新しいバージョンを作成します。
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. 新しいバージョンのレイヤーを使用するように関数を設定します。
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## レイヤーを共有する
レイヤーを別の と共有するにはAWS アカウント、レイヤーの[リソースベースのポリシー](access-control-resource-based.md) にクロスアカウントアクセス許可ステートメントを追加します。[add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) コマンドを実行し、アカウント ID を として指定します`principal`。アクセス許可は、各ステートメントで、1 つのアカウント、すべてのアカウント、または [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 内の組織に付与することができます。
以下の例では、アカウント 111122223333 に `bash-runtime` レイヤーのバージョン 2 へのアクセス許可を付与します。
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
次のような出力が表示されます。
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
アクセス許可は、単一レイヤーバージョンにのみ適用されます。新しいレイヤーバージョンを作成するたびに、このプロセスを繰り返します。
## クリーンアップ
各バージョンのレイヤーを削除します。
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
バージョン 2 のレイヤーへの参照が関数で保持されているため、現在も Lambda に存在します。関数は引き続き動作しますが、削除したバージョンが使用されるように、参照を設定することはできません。関数のレイヤーのリストを変更する場合は、新しいバージョンを指定するか、削除したレイヤーを除外する必要があります。
[delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html) コマンドを使用して関数を削除します。
```
aws lambda delete-function --function-name bash-runtime
```
# オープンソースリポジトリ
AWS Lambda には、サーバーレスアプリケーションの構築、カスタマイズ、最適化に役立つさまざまなオープンソースツール、ライブラリ、コンポーネントが用意されています。これらのリソースには、ランタイムインターフェイスクライアント、イベントライブラリ、コンテナベースイメージ、開発ツール、AWS で管理され GitHub で利用可能なサンプルプロジェクトなどがあります。これらのオープンソースリポジトリを活用することで、Lambda の機能を拡張し、カスタムランタイムを作成し、さまざまな AWS サービスからイベントを処理し、関数のパフォーマンスに関するより深いインサイトを得ることができます。このページでは、Lambda 開発をサポートする主なオープンソースプロジェクトの概要を説明します。
## ランタイムインターフェイスクライアント
Lambda Runtime Interface Clients (RICs) は、[Runtime API](runtimes-api.md) を実装し、関数コードと Lambda サービス間のやり取りを管理するオープンソースライブラリです。これらのクライアントは、呼び出しイベントの受信、コンテキスト情報の受け渡し、エラーの報告を処理します。
Lambda のマネージドランタイムとコンテナベースイメージで使用されるランタイムインターフェイスクライアントは、オープンソースとして公開されます。カスタムランタイムを構築したり、既存のランタイムを拡張したりする場合、これらのオープンソースライブラリを使用して実装を簡素化できます。以下のオープンソースの GitHub リポジトリには、Lambda の RIC のソースコードが含まれています。
+ [Node.js のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client)
+ [Python のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-python-runtime-interface-client)
+ [Java のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client)
+ [Ruby のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-ruby-runtime-interface-client)
+ [.NET のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-dotnet)
+ [Rust のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-rust-runtime)
+ [Go のランタイムインターフェイスクライアント](https://github.com/aws/aws-lambda-go)
+ [Swift のランタイムインターフェイスクライアント](https://github.com/awslabs/swift-aws-lambda-runtime) (実験用)
+ [C\$1\$1 のランタイムインターフェイスクライアント](https://github.com/awslabs/aws-lambda-cpp) (実験用)
+ [Lambdaのベースイメージ](https://github.com/aws/aws-lambda-base-images)
これらのクライアントを使用してカスタムランタイムを構築する方法の詳細については、「[AWS Lambda 用カスタムランタイムの構築](runtimes-custom.md)」を参照してください。
## イベントライブラリ
Lambda イベントライブラリは、さまざまな AWS サービスからのイベントを処理するためのタイプ定義とヘルパーユーティリティを提供します。これらのライブラリは、イベントデータをタイプセーフな方法で解析して処理するのに役立ちます。これにより、Amazon S3、Amazon DynamoDB、Amazon API Gateway などのサービスのイベントを簡単に操作できます。
コンパイルされた言語の場合、AWS は次のイベントライブラリを提供します。
+ [Java イベントライブラリ](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)
+ [.NET イベントライブラリ](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src)
+ [Go イベントライブラリ](https://github.com/aws/aws-lambda-go/tree/main/events)
+ [Rust イベントライブラリ](https://github.com/awslabs/aws-lambda-rust-runtime)
Node.js、Python、Ruby などのインタプリタ型言語の場合、イベントは別のライブラリを必要とせずに JSON オブジェクトとして直接解析できます。ただし、Node.js と Python を使用するデベロッパーは、AWS Lambda の powertools を活用できます。これにより、タイプヒント、データ検証、コンパイルされた言語ライブラリと同様の機能を提供する AWS イベント用の組み込みスキーマが提供されます。
+ [Powertools for TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas)
+ [Powertools for Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models)
## コンテナベースイメージ
AWS には、Lambda 関数のコンテナイメージを構築するための出発点として使用できるオープンソースのコンテナベースイメージが用意されています。これらのベースイメージには、ランタイムインターフェイスクライアントと、Lambda 実行環境で関数を実行するために必要なその他のコンポーネントが含まれます。
使用可能なベースイメージとその使用方法の詳細については、[AWS「Lambda ベースイメージ](https://github.com/aws/aws-lambda-base-images)リポジトリ」および[コンテナイメージを使用した Lambda 関数の作成](images-create.md)を参照してください。
## 開発ツール
AWS には、Lambda 関数の構築と最適化に役立つ追加のオープンソース開発ツールが用意されています。
### Powertools for AWS Lambda
Powertools for AWS Lambda は、重要なユーティリティを使用してサーバーレス開発を簡素化し、重複処理、マルチレコード処理、Kafka コンシューマーライブラリのバッチ処理を防止します。これらの機能により、コードの複雑さと運用上のオーバーヘッドを最小限に抑えることができます。
また、組み込みのイベントスキーマ検証、構造化ログ記録、トレース、パラメータストア統合を活用することもできます。これらは、AWS Well-Architected のベストプラクティスに従いながら、本番環境に対応した Lambda 関数の作成を加速するように設計されています。
GitHub リポジトリ:
+ [Python](https://github.com/aws-powertools/powertools-lambda-python):
+ [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript)
+ [Java](https://github.com/aws-powertools/powertools-lambda-java):
+ [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet)
### Java 開発ツール
+ [Java プロファイラー (実験用)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler) - Java Lambda 関数をプロファイリングするためのツール。
+ [Java ライブラリ](https://github.com/aws/aws-lambda-java-libs) - JUnit テストユーティリティやプロファイリングツールなどの主要なプロジェクトを含む、Lambda 開発用の Java ライブラリとツールの包括的なコレクションを提供するリポジトリ。
+ [サーバーレス Java コンテナ](https://github.com/aws/serverless-java-container) - 最小限の変更で Lambda で既存の Java アプリケーションを実行できるようにするライブラリ。
### .NET 開発ツール
[AWS Lambda.NET](https://github.com/aws/aws-lambda-dotnet)リポジトリは、Lambda 開発用の .NET ライブラリとツールを提供します。これには、.NET CLI 用の AWS Lambda ツールや、.NET Core アプリケーションをホストするための .NET Core サーバーなどの主要なプロジェクトが含まれます。
## サンプルプロジェクト
[Serverless Land リポジトリ](https://serverlessland.com/repos)で、サンプルの Lambda プロジェクトとアプリケーションの包括的なコレクションをご覧ください。これらのサンプルは、サーバーレスアプリケーションの使用開始に役立つさまざまな Lambda ユースケース、統合パターン、ベストプラクティスを示しています。