# 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
```