# Lambda マネージドインスタンス
Lambda マネージドインスタンスを使用すると、インスタンスのライフサイクル、オペレーティングシステムおよび言語のランタイムのパッチ適用、ルーティング、負荷分散、スケーリングポリシーを管理することなく、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションなど、現行世代の Amazon EC2 インスタンス上で Lambda 関数を実行できます。Lambda マネージドインスタンスでは、EC2 Savings Plans やリザーブドインスタンスなど、EC2 の料金の利点を活用できます。
サポートされているインスタンスタイプのリストについては、「[AWS Lambda 料金](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)」ページに移動し、AWS リージョン を選択します。
## 主な機能
Lambda マネージドインスタンスは次の機能を提供します。
+ **適切なインスタンスを選択する** – Graviton4 などの最新の CPU へのアクセス、設定可能なメモリと CPU の比率、高帯域幅ネットワークなど、パフォーマンスとコストの要件に基づいて[適切なインスタンス](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)を選択します。
+ **自動プロビジョニング** – AWS は、適切なインスタンスを自動的にプロビジョニングし、関数実行環境を起動します。
+ **動的スケーリング** – インスタンスは、関数のトラフィックパターンに基づいて動的にスケーリングされます。
+ **フルマネージドエクスペリエンス** – AWS がインフラストラクチャの管理、スケーリング、パッチ適用、ルーティングを処理し、これまで使い慣れた広範なイベントソース統合を引き続き利用できます。
## Lambda マネージドインスタンスを使用するタイミング
以下のユースケースでは、Lambda マネージドインスタンスを検討してください。
+ **大量の予測可能なワークロード** – 予期せぬトラフィックスパイクが発生しない定常状態のワークロードに最適です。Lambda マネージドインスタンスは、デフォルトでトラフィックが 5 分以内に 2 倍へ増加する状況に対応できるようにスケーリングを行います。
+ **パフォーマンスが重要なアプリケーション** – 最新の CPU へのアクセス、さまざまなメモリと CPU の比率、高いネットワークスループット
+ **規制要件** – VPC とインスタンスの配置を制御できるきめ細かなガバナンスのニーズ
+ **多種多様なアプリケーション** – イベント駆動型アプリケーション、メディア/データ処理、ウェブアプリケーション、サーバーレスに移行するレガシーワークロード
## 仕組み
Lambda マネージドインスタンスは、関数を実行するための基盤としてキャパシティープロバイダーを使用します。
1. **キャパシティープロバイダーを作成する** – VPC 設定、オプションでインスタンス要件、スケーリング設定を指定して、関数が実行される場所を定義します。
1. **関数を作成する** – Lambda 関数を通常どおりに作成し、キャパシティープロバイダーにアタッチします。
1. **関数バージョンを公開する** – 関数バージョンは、公開されるとキャパシティープロバイダーインスタンスでアクティブになります
キャパシティープロバイダーで関数バージョンを発行すると、Lambda はユーザーのアカウントでマネージドインスタンスを起動します。AZ の耐障害性を確保するため、デフォルトで 3 つのインスタンスを起動し、3 つの実行環境を開始すると、関数バージョンが ACTIVE にマークされます。既に他の関数を実行している既存のキャパシティープロバイダーに関数をアタッチすると、使用可能なインスタンスに新しい関数の実行環境に対応する容量が既にある場合、Lambda は新しいインスタンスをスピンアップしない可能性があります。
## 同時実行モデル
Lambda マネージドインスタンスは、1 つの実行環境が複数の呼び出しを同時に処理できる複数同時呼び出しをサポートします。これは、Lambda (デフォルト) コンピューティングタイプとは異なり、1 つの実行環境が一度に最大 1 回だけ呼び出しを実行できる単一の同時実行モデルを提供します。複数同時実行は、基本的な EC2 インスタンスの使用率を向上させ、ウェブサービスやバッチジョブなどの IO 負荷の高いアプリケーションに特に役立ちます。この実行モデルの変更は、スレッドセーフ、状態管理、コンテキストの分離をランタイムに応じて異なる方法で処理する必要があることを意味します。
## テナンシーと分離
Lambda (デフォルト) コンピューティングタイプはマルチテナントであり、Firecracker microVM テクノロジーを使用して、共有された Lambda フリートで実行されている実行環境を分離します。Lambda マネージドインスタンスはユーザーのアカウントで実行され、最新の EC2 ハードウェアと料金オプションを提供します。マネージドインスタンスは、Firecracker ではなく、EC2 Nitro インスタンスで実行されているコンテナを使用して分離を実現します。キャパシティープロバイダーは、Lambda 関数のセキュリティ境界として機能します。関数はインスタンス内のコンテナで実行されます。
### マネージドインスタンスの概要
Lambda マネージドインスタンス関数は、ユーザーのアカウントの EC2 マネージドインスタンスで実行されます。これらのインスタンスは Lambda によって完全に管理されるため、標準の EC2 インスタンスと比較してアクセス許可が制限されます。アカウント内の Lambda マネージドインスタンスは、次の方法で識別できます。
+ EC2 `DescribeInstances` 出力内の `Operator` フィールドの存在
+ インスタンスの `aws:lambda:capacity-provider` タグ
これらのインスタンスでは、手動による終了など、標準の EC2 オペレーションを直接実行することはできません。マネージドインスタンスを破棄するには、関連するキャパシティープロバイダーを削除します。その後、Lambda はキャパシティープロバイダーの削除プロセスの一環としてインスタンスを終了します。
## 料金
Lambda マネージドインスタンスは、EC2 ベースの料金を採用しており、EC2 インスタンスのコストに加えて 15% の管理手数料がかかります。この料金モデルは、EC2 Savings Plans、リザーブドインスタンス、および EC2 の使用量に適用されるその他の料金割引を対応しています。詳細については、料金ページを参照してください: [https://aws.amazon.com/lambda/pricing/](https://aws.amazon.com/lambda/pricing/)
**重要:** EC2 料金の割引は、基本的な EC2 コンピューティングにのみ適用され、管理料金には適用されません。
## Lambda マネージドインスタンスと Lambda (デフォルト) コンピューティングタイプの違い
Lambda マネージドインスタンスは、Lambda がリクエストを処理する方法を Lambda (デフォルト) と比較して変更します。
**主な相違点:**
| | Lambda (デフォルト) | Lambda マネージドインスタンス |
| --- | --- | --- |
| 同時実行モデル | 1 つの実行環境が一度に最大 1 回の呼び出しをサポートできる単一同時実行モデル | 1 つの実行環境が複数の呼び出しを同時に処理できる複数同時呼び出し。特に IO 負荷の高いアプリケーションではスループットが向上させる |
| テナンシーと分離 | マルチテナント。共有された Lambda フリートで実行されている実行環境間の分離を実現するために Firecracker microVM テクノロジーを使用している | ユーザーのアカウント内で実行され、EC2 Nitro を使用して実行環境の分離が提供されます。キャパシティープロバイダーはセキュリティ境界として機能し、関数はインスタンス内のコンテナで実行されます。 |
| 料金モデル | リクエストごとの期間料金 | オンデマンドインスタンスやリザーブドインスタンスなどの EC2 料金モデルを利用したインスタンスベースの料金、および Compute Savings Plans などの割引オプション |
| スケーリングの動作 | 着信呼び出しを処理するための空き実行環境がない場合にスケールします (コールドスタート)。トラフィックなしでゼロにスケールする | コールドスタートなしで、CPU リソース使用率のみに基づいて非同期的にスケールします。トラフィックなしで設定された最小限の実行環境にスケールする |
| 以下に最適: | バースト性のトラフィックがあり、一定のコールドスタート時間を許容できる関数、または持続的な負荷がなく、ゼロまでスケールダウンすることによる利点を享受できるアプリケーション | EC2 の柔軟性、料金プラン、ハードウェアオプションが必要な場合の大量の予測可能なトラフィック関数 |
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」を理解する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ 「[Lambda マネージドインスタンスのセキュリティとアクセス許可](lambda-managed-instances-security.md)」を理解する
# Lambda マネージドインスタンスの開始方法
## Lambda マネージドインスタンス関数の作成 (コンソール)
Lambda コンソールを使用して、キャパシティープロバイダー管理の Amazon EC2 インスタンスで実行するマネージドインスタンス関数を作成できます。
**重要:** マネージドインスタンス関数を作成する前に、まずキャパシティープロバイダーを作成する必要があります。これらの関数には、関数を実行する Amazon EC2 インフラストラクチャを定義するためのキャパシティープロバイダーが必要です。
**Lambda マネージドインスタンス関数を作成するには (コンソール)**
1. Lambda のコンソールを開きます。
1. 左側のナビゲーションペインで **[キャパシティープロバイダー]** を選択します。
1. **[キャパシティープロバイダーを作成]** を選択します。
1. **[キャパシティープロバイダー設定]** セクションに、キャパシティープロバイダーの名前を入力します。
1. キャパシティープロバイダーの VPC とアクセス許可を選択します。既存の VPC を使用するか、新しい VPC を作成できます。必要なオペレーターロールの作成については、「[Lambda マネージドインスタンス用の Lambda オペレーターロール](lambda-managed-instances-operator-role.md)」を参照してください。
1. **[詳細設定]** を展開します。
1. プロセッサアーキテクチャとインスタンスタイプを選択して、**[インスタンスの要件]** を定義します。
1. **[自動スケーリング]** で、キャパシティープロバイダーの EC2 vCPU の最大数を指定します。**[手動インスタンススケーリングモード]** を選択して、独自のスケーリング値を設定し、正確にコントロールすることもできます。
1. **[キャパシティープロバイダーを作成]** を選択して、新しいプロバイダーを作成します。
1. 次に、[**Create function**] を選択します。
1. **[一から作成]** を選択します。
1. **[基本的な情報]** ペインで、**[関数名]** を入力します。
1. **[ランタイム]** で、サポートされている任意のランタイムを選択します。
1. 関数の **[アーキテクチャ]** (キャパシティープロバイダーに選択したアーキテクチャと同じもの) を選択します。デフォルトは **x86\$164** です。
1. **[アクセス許可]** で、選択した **[実行ロール]** に対するアクセス許可があることを確認します。それ以外の場合は、ロールを作成します。
1. **[追加設定]** で、**[コンピューティングタイプ]** を **[Lambda マネージドインスタンス]** として選択します。
1. 前のステップで作成したキャパシティープロバイダーのキャパシティープロバイダー ARN を事前に選択する必要があります。
1. **[メモリサイズ]** と **[vCPU 比率あたりの実行環境メモリ (GiB)]** を選択します。
1. [**関数の作成**] を選択してください。
これで Lambda マネージドインスタンス関数が作成され、指定したキャパシティープロバイダーにキャパシティーがプロビジョニングされます。通常、関数の作成には数分かかります。完了したら、関数コードを編集し、最初のテストが実行可能になります。
## Lambda マネージドインスタンス関数の作成 (AWS CLI)
### 前提条件
作業を開始する前に、次の項目があることを確認します。
+ **AWS CLI** – AWS CLI をインストールして設定します。詳細については、「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
+ **IAM アクセス許可** – Lambda 関数とキャパシティープロバイダーを作成し、IAM ロールを渡すには、IAM ユーザーまたはロールへのアクセス許可が必要です。また、アカウントでキャパシティープロバイダーを初めて作成する場合や、サービスにリンクされたロール (SLR) が削除された場合にも、`iam:CreateServiceLinkedRole` が必要になります。
### ステップ 1: 必要な IAM ロールを作成する
Lambda マネージドインスタンスには、関数の実行ロールとキャパシティープロバイダーのオペレーターロールの 2 つの IAM ロールが必要です。オペレーターロールは、Lambda でユーザーに代わって Amazon EC2 インスタンスを起動、終了、モニタリングできます。関数の実行ロールは、他の AWS サービスとリソースに対するアクセス許可をその関数に付与します。
**Lambda 実行ロールを作成するには**
1. 以下の方法で、Lambda がロールを引き受けることを許可する信頼ポリシードキュメントを作成します。
```
cat > lambda-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. 以下の方法で、実行ロールを作成します
```
aws iam create-role \
--role-name MyLambdaExecutionRole \
--assume-role-policy-document file://lambda-trust-policy.json
```
1. 以下のように基本的な実行ポリシーを添付します。
```
aws iam attach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
**キャパシティープロバイダーのオペレーターロールを作成するには**
1. 以下の方法で、Lambda がオペレーターロールを引き受けることを許可する信頼ポリシードキュメントを作成します。
```
cat > operator-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. 以下の方法で、オペレーターロールを作成します。
```
aws iam create-role \
--role-name MyCapacityProviderOperatorRole \
--assume-role-policy-document file://operator-trust-policy.json
```
1. 以下のように、必要な EC2 アクセス許可ポリシーを添付します。
```
aws iam attach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
```
### ステップ 2: VPC リソースを設定する
Lambda マネージドインスタンスは VPC で実行されるため、サブネットとセキュリティグループが必要です。
**VPC リソースを作成するには**
1. 以下のように VPC を作成します。
```
VPC_ID=$(aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query 'Vpc.VpcId' \
--output text)
```
1. 次の方法でサブネットを作成します。
```
SUBNET_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--query 'Subnet.SubnetId' \
--output text)
```
1. 以下の方法でセキュリティグループを作成します。
```
SECURITY_GROUP_ID=$(aws ec2 create-security-group \
--group-name my-capacity-provider-sg \
--description "Security group for Lambda Managed Instances" \
--vpc-id $VPC_ID \
--query 'GroupId' \
--output text)
```
**注:** Lambda マネージドインスタンス関数では、VPC 外のリソースにアクセスしたり、テレメトリデータを CloudWatch Logs や X-Ray に送信したりするには VPC 設定が必要です。設定の詳細については、「[Lambda マネージドインスタンスのネットワーキング](lambda-managed-instances-networking.md)」を参照してください。
### ステップ 3: キャパシティープロバイダーを作成する
キャパシティープロバイダーは、Lambda 関数を実行する EC2 インスタンスを管理します。
**キャパシティープロバイダーを作成するには**
```
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=[$SUBNET_ID],SecurityGroupIds=[$SECURITY_GROUP_ID] \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::${ACCOUNT_ID}:role/MyCapacityProviderOperatorRole \
--instance-requirements Architectures=[x86_64] \
--capacity-provider-scaling-config MaxVCpuCount=30
```
このコマンドは、次の設定のキャパシティープロバイダーを作成します。
+ **VPC 設定** – EC2 インスタンスのサブネットとセキュリティグループを指定します
+ **アクセス許可** – EC2 インスタンスの管理で Lambda が使用する IAM ロールを定義します
+ **インスタンス要件** – x86\$164 アーキテクチャを指定します
+ **スケーリング設定** – キャパシティープロバイダーに最大 30 vCPU を設定します
### ステップ 4: インラインコードを使用して Lambda 関数を作成する
**インラインコードを使用して関数を作成するには**
1. まず、以下の方法で簡単な Python 関数を作成し、インラインでパッケージ化します。
```
# Create a temporary directory for the function code
mkdir -p /tmp/my-lambda-function
cd /tmp/my-lambda-function
# Create a simple Python handler
cat > lambda_function.py << 'EOF'
import json
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': json.dumps({
'message': 'Hello from Lambda Managed Instances!',
'event': event
})
}
EOF
# Create a ZIP file
zip function.zip lambda_function.py
```
1. 次のように、インライン ZIP ファイルを使用して Lambda 関数を作成します。
```
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=$(aws configure get region)
aws lambda create-function \
--function-name my-managed-instance-function \
--package-type Zip \
--runtime python3.13 \
--handler lambda_function.lambda_handler \
--zip-file fileb:///tmp/my-lambda-function/function.zip \
--role arn:aws:iam::${ACCOUNT_ID}:role/MyLambdaExecutionRole \
--architectures x86_64 \
--memory-size 2048 \
--ephemeral-storage Size=512 \
--capacity-provider-config LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:capacity-provider:my-capacity-provider}
```
関数は以下の設定で作成されます。
+ **ランタイム** – Python 3.13
+ **ハンドラー** – `lambda_function.py` の `lambda_handler` 関数
+ **メモリ** – 2048 MB
+ **エフェメラルストレージ** – 512 MB
+ **キャパシティープロバイダー** – 作成したキャパシティープロバイダーへのリンク
### ステップ 5: 関数バージョンを発行する
Lambda マネージドインスタンスで関数を実行するには、バージョンを発行する必要があります。
**関数バージョンを発行するには**
```
aws lambda publish-version \
--function-name my-managed-instance-function
```
このコマンドは、関数のバージョン 1 を発行し、キャパシティープロバイダーにデプロイします。
### ステップ 6: 関数を呼び出す
発行したら、関数を呼び出すことができます。
**関数を呼び出すには**
```
aws lambda invoke \
--function-name my-managed-instance-function:1 \
--payload '{"name": "World"}' \
response.json
# View the response
cat response.json
```
関数は、キャパシティープロバイダーが管理する EC2 インスタンスで実行され、レスポンスを返します。
### クリーンアップ
料金が発生しないようにするには、作成したリソースを削除します。
1. 以下の方法で関数を削除します。
```
aws lambda delete-function --function-name my-managed-instance-function
```
1. 以下のようにキャパシティープロバイダーを削除します。
```
aws lambda delete-capacity-provider --capacity-provider-name my-capacity-provider
```
1. 次の方法で VPC リソースを削除します。
```
aws ec2 delete-security-group --group-id $SECURITY_GROUP_ID
aws ec2 delete-subnet --subnet-id $SUBNET_ID
aws ec2 delete-vpc --vpc-id $VPC_ID
```
1. 次の方法で IAM ロールを削除します。
```
aws iam detach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam detach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
aws iam delete-role --role-name MyLambdaExecutionRole
aws iam delete-role --role-name MyCapacityProviderOperatorRole
```
# 重要な概念
Lambda マネージドインスタンスでは、従来の Lambda 関数とは異なる主要な概念がいくつか導入されています。これらの概念を理解することは、EC2 インフラストラクチャに関数を効果的にデプロイおよび管理するうえで不可欠です。
**キャパシティープロバイダー**は、Lambda マネージドインスタンスの基盤を形成します。キャパシティープロバイダーは、VPC 設定、インスタンス要件、スケーリングポリシーなど、関数が実行されるコンピューティングインフラストラクチャを定義します。キャパシティープロバイダーは関数のセキュリティ境界としても機能します。つまり、同じキャパシティープロバイダーに割り当てられたすべての関数は相互に信頼されている必要があります。
**スケーリングの動作**は、従来の Lambda 関数とは大きく異なります。マネージドインスタンスは、呼び出しが届いたときにオンデマンドでスケーリングするのではなく、CPU リソース使用率に基づいて非同期的にスケーリングします。このアプローチはコールドスタートを排除しますが、トラフィックの増加を見越した計画が必要になります。トラフィックが 5 分以内に 2 倍を超えると、Lambda が需要に合わせて容量をスケールアップするするため、スロットリングが発生する可能性があります。
**セキュリティとアクセス許可**は慎重に検討する必要があります。Lambda がキャパシティープロバイダーの EC2 リソースを管理できるようにするには、オペレーターロールのアクセス許可が必要です。さらに、ユーザーはキャパシティープロバイダーに関数を割り当てる `lambda:PassCapacityProvider` アクセス許可を必要とし、特定のインフラストラクチャで実行可能な関数を制御するためのセキュリティゲートとして機能します。
**マルチ同時実行**は、マネージドインスタンスの主要な特性です。各実行環境は複数の呼び出しを同時に処理できるため、IO 負荷の高いアプリケーションのリソース使用率を最大化できます。これは、各環境が一度に 1 つのリクエストしか処理しない従来の Lambda とは異なります。この実行モデルでは、ランタイムに応じてスレッドセーフ、状態管理、コンテキストの分離に注意する必要があります。
以下のセクションでは、それぞれの概念に関する詳細情報を提供します。
# キャパシティープロバイダー
キャパシティープロバイダーは、Lambda マネージドインスタンスを実行するための基盤です。これは関数のセキュリティ境界として機能し、Lambda がユーザーに代わってプロビジョニングおよび管理するコンピューティングリソースを定義します。
キャパシティープロバイダーを作成するときは、以下を指定します。
+ **VPC 設定** – インスタンスが実行されるサブネットとセキュリティグループ
+ **アクセス許可** – Lambda が EC2 リソースを管理するための IAM ロール
+ **インスタンス要件** (オプション) – アーキテクチャと[インスタンスタイプ](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)の設定
+ **スケーリング設定** (オプション) – Lambda がインスタンスをスケーリングする方法
## セキュリティ境界としてのキャパシティープロバイダーについて理解する
キャパシティープロバイダーは、VPC 内の Lambda 関数のセキュリティ境界として機能し、Firecracker ベースの分離を置き換えます。関数はインスタンス内のコンテナで実行されますが、Firecracker microVM とは異なり、コンテナは関数間の強力なセキュリティ分離を提供しません。
**主要なセキュリティの概念**
+ **キャパシティープロバイダー:** Lambda 関数の信頼レベルを定義するセキュリティ境界
+ **コンテナの分離:** コンテナはセキュリティプロバイダーではありません。信頼できないワークロード間のセキュリティ対策としてコンテナに依存してはいけない
+ **信頼の分離**: 異なるキャパシティープロバイダーを使用して、相互に信頼されていないワークロードを分離する
## キャパシティープロバイダーの作成
キャパシティープロバイダーは、AWS CLI、AWS マネジメントコンソール、または AWS SDK を使用して作成できます。
**AWS CLI を使用する:**
```
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=subnet-12345,subnet-67890,subnet-11111,SecurityGroupIds=sg-12345 \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::123456789012:role/MyOperatorRole \
--instance-requirements Architectures=x86_64 \
--capacity-provider-scaling-config ScalingMode=Auto
```
### 必須パラメータ
**CapacityProviderName**
+ キャパシティープロバイダーの一意の名前
+ AWS アカウント内で一意にしなければならない
**VpcConfig**
+ **SubnetIds** (必須): サブネットは最低 1 つ、最大 16 個。耐障害性を高めるため、複数のアベイラビリティーゾーンにまたがるサブネットを使用する
+ **SecurityGroupIds** (オプション): インスタンスのセキュリティグループ。指定しない場合、デフォルトは VPC デフォルトセキュリティグループになる
**PermissionsConfig**
+ **CapacityProviderOperatorRoleArn** (必須): Lambda がキャパシティプロバイダーの EC2 リソースを管理できるようにする IAM ロール
### 任意指定のパラメータ
**InstanceRequirements**
キャパシティープロバイダーのアーキテクチャと[インスタンスタイプ](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)を指定します。
+ **アーキテクチャ**: `x86_64` または `arm64` を選択します。デフォルトは `x86_64` です。
+ **AllowedInstanceTypes**: 許可されたインスタンスタイプを指定します。例:`m5.8xlarge`
+ **ExcludedInstanceTypes**: ワイルドカードを使用して除外されたインスタンスタイプを指定します。AllowedInstanceTypes または ExcludedInstanceTypes のいずれかのみを指定できます
デフォルトでは、Lambda はワークロードに最適なインスタンスタイプを選択します。利用可能なインスタンスタイプの数を制限すると可用性が低下する可能性があるため、Lambda マネージドインスタンスが選択したインスタンスタイプを使用することをお勧めします。
**CapacityProviderScalingConfig**
Lambda がインスタンスをスケールする方法を設定します。
+ **ScalingMode**: 自動スケーリングの場合は `Auto` に設定し、手動制御の場合は `Manual` に設定します。デフォルトは `Auto` です。
+ **MaxVCpuCount**: キャパシティープロバイダーの vCPU の最大数。デフォルトは 400 です。
+ **ScalingPolicies**: CPU とメモリ使用率のターゲット追跡スケーリングポリシーを定義する
**KmsKeyArn**
EBS 暗号化の AWS KMS キーを指定します。指定しない場合は、デフォルトで AWS マネージドキーになります。
**タグ**
タグを追加して、キャパシティープロバイダーを整理および管理します。
## キャパシティープロバイダーの管理
### キャパシティープロバイダーを更新する
`UpdateCapacityProvider` API を使用して、キャパシティープロバイダーの特定のプロパティを更新できます。
```
aws lambda update-capacity-provider \
--capacity-provider-name my-capacity-provider \
--capacity-provider-scaling-config ScalingMode=Auto
```
### キャパシティープロバイダーを削除する
`DeleteCapacityProvider` API を使用して不要になったキャパシティープロバイダーを削除できます。
```
aws lambda delete-capacity-provider \
--capacity-provider-name my-capacity-provider
```
**注:** 関数バージョンが紐付いているキャパシティープロバイダーは削除できません。
### キャパシティープロバイダーの詳細の確認
`GetCapacityProvider` API を使用してキャパシティープロバイダーに関する情報を取得します。
```
aws lambda get-capacity-provider \
--capacity-provider-name my-capacity-provider
```
## キャパシティープロバイダーの状態
キャパシティープロバイダーは、以下のいずれかの状態になります。
+ **保留中**: キャパシティープロバイダーは作成中
+ **アクティブ**: キャパシティープロバイダーは使用できる状態
+ **失敗**: キャパシティープロバイダーの作成が失敗した
+ **削除**中: キャパシティープロバイダーは削除中
## クォータ
+ **アカウントあたりの最大キャパシティープロバイダー**: 1,000
+ **キャパシティープロバイダーあたりの最大関数バージョン**: 100 (増やすことはできません)
## ベストプラクティス
1. **信頼レベル別で分ける**: セキュリティ要件が異なるワークロードごとに別々のキャパシティープロバイダーを作成する
1. **わかりやすい名前を使用する**: 使用目的と信頼レベルを明確に示すために、キャパシティープロバイダーに名前を付ける (例: `production-trusted`、`dev-sandbox`)
1. **複数のアベイラビリティーゾーンを使用する**: 可用性を高めるために複数のアベイラビリティーゾーンにまたがるサブネットを指定する
1. **Lambda がインスタンスタイプを選択できるようにする**: 特定のハードウェア要件がない限り、Lambda が最適なインスタンスタイプを選択して可用性を維持できるようにする
1. **使用状況をモニタリングする**: AWS CloudTrail を使用してキャパシティープロバイダーの割り当てとアクセスパターンをモニタリングする
## 次のステップ
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」について説明する
+ 「[Lambda マネージドインスタンスのセキュリティとアクセス許可](lambda-managed-instances-security.md)」を理解する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
# Lambda マネージドインスタンスのスケーリング
Lambda マネージドインスタンスは、呼び出しの到着時はスケーリングされず、コールドスタートをサポートしません。代わりに、リソース消費シグナルを使用して非同期的にスケーリングします。マネージドインスタンスは現在、CPU リソースの使用率と同時実行数の飽和度に基づいてスケーリングされます。
**主な相違点:**
+ **Lambda (デフォルト):** 着信呼び出しを処理する空き実行環境がない場合にスケーリングする (コールドスタート)
+ **Lambda マネージドインスタンス:** CPU リソース使用率と実行環境の同時実行数の飽和に基づいて非同期的にスケーリングする
トラフィックが 5 分以内に 2 倍を超えると、Lambda が需要に合わせてインスタンスと実行環境をスケールアップするため、スロットリングが表示されることがあります。
## スケーリングライフサイクル
Lambda マネージドインスタンスは、分散アーキテクチャを使用してスケーリングを管理します。
**コンポーネント:**
+ **マネージドインスタンス** – 指定したサブネットのアカウントで実行されます
+ **ルーターおよびスケーラー** – 呼び出しをルーティングし、スケーリングを管理する共有 Lambda コンポーネント
+ **Lambda エージェント** – 各マネージドインスタンスで実行され、実行環境のライフサイクルを管理し、リソースの消費量をモニタリングします
**仕組み:**
1. キャパシティープロバイダーで関数バージョンを発行すると、Lambda はユーザーのアカウントでマネージドインスタンスを起動します。AZ の回復性のためにデフォルトで 3 つ起動され、実行環境が 3 つ開始されると関数バージョンが「ACTIVE」にマークされます。
1. 各マネージドインスタンスは、同じキャパシティープロバイダーにマッピングされた複数の関数の実行環境を実行できます。
1. トラフィックがアプリケーションに流れると、実行環境はリソースを消費します。Lambda エージェントはスケーラーに通知し、新しい実行環境とマネージドインスタンスのどちらをスケーリングするかを決定します。
1. ルーターがリソース消費量の多い実行環境に呼び出しを送信しようとすると、そのインスタンスの Lambda エージェントが別のインスタンスで再試行するよう通知します。
1. トラフィックが減少すると、Lambda エージェントはスケーラーに通知し、実行環境のスケールダウンとマネージドインスタンスのスケールインを決定します。
## スケーリング動作の調整
マネージドインスタンスのスケーリング動作は、次の 4 つのコントロールでカスタマイズできます。
### 関数レベルのコントロール
#### 1. 関数メモリと vCPU
関数のメモリサイズと vCPU 割り当てを選択します。サポートされる関数の最小サイズは 2GB と 1vCPU です。
**考慮事項:**
+ 関数の複数同時実行をサポートするメモリと vCPU 設定を選択してください
+ マネージドインスタンスで実行される関数は複数同時ワークロードをサポートしている必要があるため、1 vCPU 未満の関数を設定することはできません
+ 2GB 未満を選択することはできません。これは、c インスタンスのメモリと vCPU のメモリ比率 (2 対 1) と一致するためであり、c インスタンスの比率は最も低くなっています
+ Python アプリケーションの場合、Python は複数同時実行を処理するため、メモリと vCPU の比率は 4 対 1 または 8 対 1 などの高比率を選択する必要がある場合があります。
+ CPU 負荷が高いオペレーションを実行している場合、またはほとんど IO を実行していない場合は、複数の vCPU を選択する必要があります。
#### 2. 最大同時実行数
実行環境あたりの最大同時実行数を設定します。
**デフォルトの動作:** Lambda では、さまざまなアプリケーションで動作するリソースの消費とスループットとのバランスをとる適切なデフォルトが選択されます。
**調整ガイドライン:**
+ **同時実行数を増やす:** 関数呼び出しで使用する CPU が非常に少ない場合は、vCPU あたり最大 64 まで同時実行数を増やすことができます
+ **同時実行数を減らす:** アプリケーションが大量のメモリを消費し、CPU が非常に少ない場合は、最大同時実行数を減らすことができます
**重要:** Lambda マネージドインスタンスは複数同時実行アプリケーションを対象としているため、同時実行が非常に低い実行環境では、スケーリング時にスロットリングが発生する可能性があります。
### キャパシティープロバイダーレベルのコントロール
#### 3. ターゲットのリソース使用率
CPU 使用率消費の独自のターゲットを選択します。
**デフォルトの動作:** Lambda では、スロットリングなしで 5 分以内にトラフィックを倍増させるのに十分なヘッドルームが。保持されます。
**最適化オプション:**
+ ワークロードが非常に安定している場合、またはアプリケーションがスロットリングの影響を受けにくい場合は、ターゲットを高レベルに設定して使用率を高め、コストを削減できます
+ トラフィックのバーストに備えてヘッドルームを維持する場合は、リソースターゲットを低レベルに設定できますが、より多くの容量が必要になります
#### 4. インスタンスタイプの選択
許可または除外されたインスタンスタイプを設定します。
**デフォルトの動作:** Lambda ではワークロードに最適なインスタンスタイプが選択されます。利用可能なインスタンスタイプの数を制限すると可用性が低下する可能性があるため、Lambda マネージドインスタンスが選択したインスタンスタイプを使用することをお勧めします。
**カスタム設定:**
+ **特定のハードウェア要件:** 許可されたインスタンスタイプを互換性のあるインスタンスのリストに設定します。たとえば、高いネットワーク帯域幅を必要とするアプリケーションがある場合、複数の n インスタンスタイプを選択できます
+ **コストの最適化:** テスト環境または開発環境では、m7a.large インスタンスタイプなど、より小さなインスタンスタイプを選択できます
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 複数同時実行を処理するためのランタイム固有のガイドを確認する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ スケーリングメトリクスをモニタリングしてスケーリング動作を最適化する
# セキュリティおよびアクセス許可
Lambda マネージドインスタンスは**、キャパシティープロバイダー**を信頼境界として使用します。関数はこれらのインスタンス内のコンテナで実行されますが、コンテナはワークロード間のセキュリティ分離を提供しません。同じキャパシティープロバイダーに割り当てられたすべての関数は相互に信頼されている必要があります。
## 主要なセキュリティの概念
+ **キャパシティープロバイダー**: Lambda 関数の信頼レベルを定義するセキュリティ境界
+ **コンテナの分離**: コンテナはセキュリティ境界ではないため、信頼できないワークロード間のセキュリティ対策としてコンテナに依存しない
+ **信頼の分離**: 異なるキャパシティープロバイダーを使用して、相互に信頼されていないワークロードを分離する
## 必要な許可
### PassCapacityProvider アクション
ユーザーには、キャパシティープロバイダーに関数を割り当てるための`lambda:PassCapacityProvider`アクセス許可が必要です。このアクセス許可はセキュリティゲートとして機能し、承認されたユーザーのみが特定のキャパシティープロバイダーに関数を配置できるようにします。
アカウント管理者は、`lambda:PassCapacityProvider` IAM アクションを通じて特定のキャパシティープロバイダーを使用できる関数を制御します。このアクションは、次の場合に必要です。
+ Lambda マネージドインスタンスを使用する関数の作成
+ キャパシティープロバイダーを使用するように関数設定を更新する
+ Infrastructure as Code による関数のデプロイ
**IAM ポリシーの例**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:PassCapacityProvider",
"Resource": "arn:aws:lambda:*:*:capacity-provider:trusted-workloads-*"
}
]
}
```
### サービスにリンクされたロール
AWS Lambda は、`AWSServiceRoleForLambda` サービスリンクロールを使用して、キャパシティープロバイダー内の Lambda マネージドインスタンス ec2 リソースを管理します。
## ベストプラクティス
1. **信頼レベル別で分ける**: セキュリティ要件が異なるワークロードごとに別々のキャパシティープロバイダーを作成する
1. **わかりやすい名前を使用する**: 使用目的と信頼レベルを明確に示すために、キャパシティープロバイダーに名前を付ける (例: `production-trusted`、`dev-sandbox`)
1. **最小特権を適用する**: 必要なキャパシティプロバイダーにのみ `PassCapacityProvider` アクセス許可を付与する
1. **使用状況をモニタリングする**: AWS CloudTrail を使用してキャパシティープロバイダーの割り当てとアクセスパターンをモニタリングする
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」を理解する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
# Lambda マネージドインスタンス用の Lambda オペレーターロール
Lambda マネージドインスタンスを使用する場合、Lambda にはアカウントのコンピューティングキャパシティを管理するための権限が必要になります。オペレーターロールは、Lambda がキャパシティープロバイダー内の EC2 インスタンスを管理できるようにする IAM ポリシーを通じてこれらの権限を付与します。
関数の実行時に Lambda が実行ロールを引き受ける方法と同様に、Lambda はこれらの管理オペレーションを実行する際にオペレーターロールを引き受けます。
## オペレーターロールの作成
オペレーターロールは、IAM コンソールまたは AWS CLI で作成できます。ロールには以下を含める必要があります。
+ **アクセス許可ポリシー** – キャパシティプロバイダーと関連リソースを管理するアクセス許可を付与します
+ **信頼ポリシー** – Lambda サービス (`lambda.amazonaws.com`) がロールを引き受けられるようにします
### アクセス許可ポリシー
オペレーターロールがキャパシティープロバイダーと基盤となるコンピューティングリソースを管理するには、アクセス許可が必要です。少なくとも、現在ロールには以下のような [AWSLambdaManagedEC2ResourceOperator](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSLambdaManagedEC2ResourceOperator) 管理ポリシーのアクセス許可が必要です。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateTags",
"ec2:AttachNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"ec2:ManagedResourceOperator": "scaler.lambda.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeCapacityReservations",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
}
]
}
```
### 信頼ポリシー
以下の信頼ポリシーにより、Lambda はオペレーターロールを引き受けることができます。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Lambda マネージドインスタンスのサービスにリンクされたロール
Lambda マネージドインスタンスのライフサイクルを責任を持って管理するため、Lambda にはユーザーのアカウント内のマネージドインスタンスを終了させる永続的なアクセス権が必要になります。Lambda は、AWS Identity and Access Management (IAM) のサービスにリンクされたロール (SLR) を使用してこれらのオペレーションを実行します。
**自動作成**: サービスにリンクされたロールは、キャパシティープロバイダーを初めて作成するときに自動的に作成されます。最初のキャパシティープロバイダーを作成するユーザーは、`lambda.amazonaws.com` プリンシパルに対する `iam:CreateServiceLinkedRole` 権限が必要です。
**アクセス許可**: サービスにリンクされたロールは、マネージドインスタンスに対する次のアクセス許可を Lambda に付与します。
+ `ec2:TerminateInstances` – ライフサイクルの終了時にインスタンスを終了します
+ `ec2:DescribeInstances` – マネージドインスタンスを列挙します
**削除**: このサービスにリンクされたロールは、アカウント内のすべての Lambda マネージドインスタンスキャパシティープロバイダーを削除した後にのみ削除できます。
サービスにリンクされたロールの詳細については、「[Lambda 用のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
# Lambda マネージドインスタンスの実行環境について理解する
Lambda マネージドインスタンスでは、Lambda が運用面を管理している間に、ユーザー所有の Amazon EC2 インスタンスで関数コードを実行する代替デプロイモデルを利用できます。マネージドインスタンスの実行環境には、Lambda (デフォルト) 関数との重要な違いがいくつかあります。特に違うのは、同時呼び出しの処理方法とコンテナライフサイクルの管理方法です。
**注:** Lambda (デフォルト) 実行環境の詳細については、「Lambda 実行環境のライフサイクルの概要」を参照してください。
## 実行環境のライフサイクル
Lambda マネージドインスタンス関数の実行環境のライフサイクルは、Lambda (デフォルト) とは異なる主要な点がいくつかあります。
### 初期化フェーズ
初期化フェーズでは、Lambda は次のステップを実行します。
+ すべての拡張機能を初期化して登録する
+ ランタイムエントリポイントをブートストラップする。ランタイムは、設定された数のランタイムワーカーを生成します (実装はランタイムによって異なります)
+ 関数の初期化コードを実行する (ハンドラー外のコード)
+ `/runtime/invocation/next` を呼び出して、1 つ以上のランタイムワーカーが準備状況を通知するまで待機する
拡張機能が初期化され、少なくとも 1 つのランタイムワーカーが `/runtime/invocation/next` を呼び出すと、初期化フェーズは完了したと見なされます。その後、関数の呼び出しを処理する準備が整います。
**注記**
Lambda マネージドインスタンス関数の場合、初期化には最大 15 分かかることがあります。制限時間は 130 秒、または設定されている関数のタイムアウト (最大 900 秒) のいずれかです。
### 呼び出しフェーズ
Lambda マネージドインスタンス関数の呼び出しフェーズには、固有の特性がいくつかあります。
**オペレーションの継続。**Lambda (デフォルト) とは異なり、実行環境は継続的にアクティブのままで、呼び出し間でフリーズすることなく到着時に呼び出しを処理します。
**並列処理。**同じ実行環境内で複数の呼び出しを同時に実行でき、それぞれ異なるランタイムワーカーによって処理されます。
**タイムアウトの独立。**関数で設定されたタイムアウトは、それぞれの呼び出しに適用されます。呼び出しがタイムアウトすると、Lambda はその特定の呼び出しを失敗としてマークしますが、実行中の他の呼び出しを中断したり、実行環境を終了したりしません。
**バックプレッシャー処理。**すべてのランタイムワーカーが呼び出しの処理中である場合、ワーカーが利用可能になるまで新しい呼び出しリクエストは拒否されます。
## エラー処理と復旧
Lambda マネージドインスタンス関数の実行環境でのエラー処理は、Lambda (デフォルト) とは異なります。
**タイムアウトの呼び出し。**それぞれの呼び出しがタイムアウトすると、Lambda はその呼び出しに対してタイムアウトエラーを返します。ただし、Lambda マネージドインスタンスではタイムアウトが適用されないため、コードは実行を継続します。関数の開発者は、タイムアウトの検出と処理を適切に実装する必要があります。コンテキストオブジェクトは呼び出しの残り時間を公開します (ゼロまたは負の値はタイムアウトを示しています)。実行環境での他の同時呼び出しは、正常に処理を続行します。
**ランタイムワーカーのエラー。**ランタイムワーカーのプロセスがクラッシュした場合、実行環境は残りの正常なワーカーで動作し続けます。
**拡張機能のクラッシュ。**初期化またはオペレーション中に拡張機能プロセスがクラッシュすると、実行環境全体が異常としてマークされ、終了します。Lambda は、新しい実行環境を作成して置き換えます。
**リセット/修復なし。**Lambda (デフォルト) とは異なり、マネージドインスタンスではエラー後に実行環境のリセットと再初期化は試行されません。その代わり異常なコンテナは終了され、新しいコンテナに置き換えられます。
# Lambda マネージドインスタンスの \$1LATEST.PUBLISHED バージョン
Lambda マネージドインスタンス関数は、Lambda (デフォルト) と同じ番号付きのバージョニングワークフローをサポートしています。番号付きバージョンを維持しない場合は、Lambda マネージドインスタンスに新しいバージョンタイプ `$LATEST.PUBLISHED` が導入されます。このバージョンでは、番号付きバージョンを管理することなく、必要に応じて更新されたコードまたは設定を使用して、最新の公開バージョンを作成または再公開できます。
**\$1LATEST との主な違い:** 非修飾 ARN を使用して Lambda マネージドインスタンス関数を呼び出すと、Lambda は非公開の \$1LATEST バージョンではなく `$LATEST.PUBLISHED` バージョンを暗黙的に呼び出します。
次の AWS CLI コマンドは、`$LATEST.PUBLISHED` バージョンを作成または再発行します。
```
aws lambda publish-version --function-name my-function --publish-to LATEST_PUBLISHED
```
以下の出力が表示されます。
```
{
"FunctionName": "my-function",
"FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function:$LATEST.PUBLISHED",
"Version": "$LATEST.PUBLISHED",
"Role": "arn:aws:iam::123456789012:role/lambda-role",
"Handler": "function.handler",
"Runtime": "nodejs24.x",
...
}
```
**注記**
AWS CloudFormation または Lambda コンソールを使用して Lambda マネージドインスタンス関数を作成すると、Lambda は自動的に `$LATEST.PUBLISHED` バージョンを作成します。
# Lambda マネージドインスタンスのランタイム
Lambda マネージドインスタンスを使用する場合、Lambda はリクエストを異なる方法で処理します。Lambda マネージドインスタンスは、各実行環境でリクエストを順次処理する代わりに、各実行環境内で複数のリクエストを同時に処理します。この実行モデルの変更により、Lambda マネージドインスタンスを使用する関数は、スレッドセーフ、状態管理、コンテキストの分離、および Lambda (デフォルト) の単一同時実行モデルでは発生しない懸念を考慮する必要があります。さらに、複数同時実行の実装はランタイムによって異なります。
## サポートされている言語
Lambda マネージドインスタンスは、次のプログラミング言語とランタイムで使用できます。
+ **Java:** Java 21 以降。
+ **Python:** Python 3.13 以降。
+ **Node.js:** Node.js 22 以降。
+ **.NET:** .NET 8 以降。
+ **Rust:** OS 専用ランタイム `provided.al2023` 以降でサポートされています。
## 言語固有の考慮事項
プログラミング言語によって、複数同時実行の実装方法はそれぞれ異なります。適切な同時実行のベストプラクティスを適用するには、選択したプログラミング言語で複数同時実行がどのように実装されるかを理解する必要があります。
**Java**
OS スレッドで単一のプロセスを使用して同時実行を行います。複数のスレッドがハンドラーメソッドを同時に実行するため、状態と共有リソースをスレッドセーフに処理する必要があります。
**Python**
各同時リクエストが個別のプロセスで実行される複数の Python プロセスが使用されます。これにより、ほとんどの同時実行の問題から保護できますが、`/tmp` ディレクトリなどの共有リソースに注意が必要です。
**Node.js**
非同期実行で[ワーカースレッド](https://nodejs.org/api/worker_threads.html)を使用します。同時リクエストはワーカースレッド全体に分散され、さらに各ワーカースレッドは同時リクエストを非同期で処理できるため、状態と共有リソースを安全に処理する必要があります。
**.NET**
複数同時リクエストの非同期処理で .NET タスクを使用します。状態と共有リソースを安全に処理する必要があります。
**Rust**
[Tokio](https://tokio.rs/) を搭載した非同期タスクで単一のプロセスを使用します。ハンドラー値は、`Clone` \$1 `Send` である必要があります。
## 次のステップ
各ランタイムの詳細については、次のトピックを参照してください。
+ [Lambda マネージドインスタンスの Java ランタイム](lambda-managed-instances-java-runtime.md)
+ [Lambda マネージドインスタンスの Node.js ランタイム](lambda-managed-instances-nodejs-runtime.md)
+ [Lambda マネージドインスタンスの Python ランタイム](lambda-managed-instances-python-runtime.md)
+ [Lambda マネージドインスタンスの .NET ランタイム](lambda-managed-instances-dotnet-runtime.md)
+ [Lambda マネージドインスタンスの Rust サポート](lambda-managed-instances-rust.md)
# Lambda マネージドインスタンスの Java ランタイム
Java ランタイムの場合、Lambda マネージドインスタンスは同時実行に OS スレッドを使用します。Lambda は初期化中、実行環境ごとにハンドラーオブジェクトを 1 回ロードし、複数のスレッドを作成します。これらのスレッドは並行して実行されるため、状態と共有リソースをスレッドセーフに処理する必要があります。各スレッドは、同じハンドラーオブジェクトと静的フィールドを共有します。
## 同時実行数の設定
Lambda が各実行環境に送信する同時リクエストの最大数は、関数設定の `PerExecutionEnvironmentMaxConcurrency` 設定で制御できます。これはオプションの設定となっており、デフォルト値はランタイムによって異なります。Java ランタイムの場合の同時リクエスト数は、vCPU あたり 32 件がデフォルト値になっていますが、独自の値を設定することもできます。この値により、Java ランタイムで使用されるスレッドの数も決まります。Lambda は、各実行環境の容量に応じて、設定された最大数までの同時リクエストの数を自動的に調整し、それらのリクエストを取得します。
## 同時実行のための関数の構築
Lambda マネージドインスタンスを使用する場合は、他のマルチスレッド環境と同じスレッドセーフな環境を適用する必要があります。ハンドラーオブジェクトはすべてのランタイムワーカースレッドで共有されるため、ミュータブルな状態はスレッドセーフである必要があります。これには、コレクション、データベース接続、およびリクエスト処理中に変更される静的オブジェクトが含まれます。
AWS SDK クライアントはスレッドセーフなため、特別な処理は必要ありません。
**例: データベース接続プール**
次のコードでは、スレッド間で共有される静的データベース接続オブジェクトを使用します。使用する接続ライブラリによっては、スレッドセーフではない場合があります。
```
public class DBQueryHandler implements RequestHandler {
// Single connection shared across all threads - NOT SAFE
private static Connection connection;
public DBQueryHandler() {
this.connection = DriverManager.getConnection(jdbcUrl, username, password);
}
@Override
public String handleRequest(Object input, Context context) {
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery();
// Multiple threads using same connection causes issues
return result.toString();
}
}
```
接続プールを使用することで、スレッドセーフにアプローチできます。次の例では、関数ハンドラーはプールから接続を取得します。接続は 1 つのリクエストのコンテキストでのみ使用されます。
```
public class DBQueryHandler implements RequestHandler {
private static HikariDataSource dataSource;
public DBQueryHandler() {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database");
dataSource = new HikariDataSource(config); // Create pool once per Lambda container
}
@Override
public String handleRequest(Object input, Context context) {
String query = "SELECT column_name FROM your_table LIMIT 10";
StringBuilder result = new StringBuilder("Data:\n");
// try-with-resources automatically calls close() on the connection,
// which returns it to the HikariCP pool (does NOT close the physical DB connection)
try (Connection connection = dataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
result.append(rs.getString("column_name")).append("\n");
}
} catch (Exception e) {
context.getLogger().log("Error: " + e.getMessage());
return "Error";
}
return result.toString();
}
}
```
**例: コレクション**
以下の標準 Java コレクションはスレッドセーフではありません。
```
public class Handler implements RequestHandler {
private static List items = new ArrayList<>();
private static Map cache = new HashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Not thread-safe
cache.put("key", input); // Not thread-safe
return "Success";
}
}
```
代わりに、以下のスレッドセーフコレクションを使用します。
```
public class Handler implements RequestHandler {
private static final List items =
Collections.synchronizedList(new ArrayList<>());
private static final ConcurrentHashMap cache =
new ConcurrentHashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Thread-safe
cache.put("key", input); // Thread-safe
return "Success";
}
}
```
## 共有の /tmp ディレクトリ
`/tmp` ディレクトリは、実行環境内のすべての同時リクエスト間で共有されます。同じファイルに同時に書き込むと、別のプロセスによってファイルが上書きされるなど、データの破損が発生する可能性があります。これに対処するには、共有ファイルのファイルロックを実装するか、スレッドごとまたはリクエストごとに一意のファイル名を使用して競合を回避します。空き容量を占有しないよう、不要なファイルはクリーンアップしてください。
## ログ記録
ログインターリービング (ログでインターリーブされるさまざまなリクエストからのログエントリ) は、複数同時実行システムでは正常です。
Lambda マネージドインスタンスを使用する関数は常に、[高度なログ記録コントロール](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)で導入した構造化された JSON ログ形式を使用します。この形式には `requestId` が含まれ、ログエントリを 1 つのリクエストに関連付けることができます。`context.getLogger()` から `LambdaLogger` オブジェクトを使用すると、`requestId` は各ログエントリに自動的に含まれます。詳細については、「[Java での Lambda の高度なログ記録コントロールの使用](java-logging.md#java-logging-advanced)」を参照してください。
## リクエストコンテキスト
`context` オブジェクトはリクエストスレッドにバインドされます。`context.getAwsRequestId()` を使用すると、現在のリクエストのリクエスト ID にスレッドセーフにアクセスできます。
`context.getXrayTraceId()` を使用して X-Ray トレース ID にアクセスします。これにより、現在のリクエストのトレース ID にスレッドセーフにアクセスできます。Lambda は、Lambda マネージドインスタンスの `_X_AMZN_TRACE_ID` 環境変数をサポートしていません。AWS SDK を使用すると、X-Ray トレース ID が自動的に伝播されます。
`com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()` を使用してタイムアウトを検出します。詳細については「[エラー処理と復旧](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)」を参照してください。
プログラムで仮想スレッドを使用する場合、または初期化中にスレッドを作成する場合は、必要なリクエストコンテキストをこれらのスレッドに渡す必要があります。
## 初期化とシャットダウン
関数の初期化は、実行環境ごとに 1 回行われます。初期化中に作成されたオブジェクトは、スレッド間で共有されます。
拡張機能を持つ Lambda 関数の場合、実行環境はシャットダウン中に SIGTERM シグナルを出力します。このシグナルは拡張機能によって使用され、バッファのフラッシュなどのクリーンアップタスクをトリガーします。SIGTERM イベントにサブスクライブすることで、データベース接続を閉じるなどの関数のクリーンアップタスクを実行できます。実行環境のライフサイクルの詳細については、「[Lambda 実行環境のライフサイクルの概要](lambda-runtime-environment.md)」を参照してください。
## 依存関係バージョン
Lambda マネージドインスタンスには、以下のパッケージバージョンの最小要件が必要です。
+ AWS SDK for Java 2.0: バージョン 2.34.0 以降
+ AWS X-Ray SDK for Java: バージョン 2.20.0 以降
+ AWS Distro for OpenTelemetry – Instrumentation for Java: バージョン 2.20.0 以降
+ Powertools for AWS Lambda (Java): バージョン 2.8.0 以降
## Powertools for AWS Lambda (Java)
Powertools for AWS Lambda (Java) は Lambda マネージドインスタンスと互換性があり、ログ記録、トレース、メトリクスなどのユーティリティを利用できます。詳細については、「[Powertools for AWS Lambda (Java)](https://github.com/aws-powertools/powertools-lambda-java)」を参照してください。
## 次のステップ
+ 「[Lambda マネージドインスタンスの Node.js ランタイム](lambda-managed-instances-nodejs-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの Python ランタイム](lambda-managed-instances-python-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの .NET ランタイム](lambda-managed-instances-dotnet-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」について説明する
# Lambda マネージドインスタンスの Node.js ランタイム
Node.js ランタイムの場合、Lambda マネージドインスタンスは `async` / `await` ベースの実行でワーカースレッドを使用して同時リクエストを処理します。関数の初期化はワーカースレッドごとに 1 回行われます。同時呼び出しは 2 つのディメンションにわたって処理され、ワーカースレッドは vCPU 間で並列処理を行い、非同期実行は各スレッド内で同時実行を行います。同じワーカースレッドで処理される各同時リクエストは、同じハンドラーオブジェクトとグローバル状態を共有するため、複数同時リクエストで安全に処理する必要があります。
## 最大同時実行数
Lambda が各実行環境に送信する同時リクエストの最大数は、関数設定の `PerExecutionEnvironmentMaxConcurrency` 設定で制御できます。これはオプションの設定となっており、デフォルト値はランタイムによって異なります。Node.js ランタイムの場合の同時リクエスト数は、vCPU あたり 64 件がデフォルト値になっていますが、独自の値を設定することもできます。Lambda は、各実行環境の容量に応じて、設定された最大数までの同時リクエストの数を自動的に調整し、それらのリクエストを取得します。
Node.js の場合、各実行環境が処理できる同時リクエストの数は、同時リクエストを非同期で処理するワーカースレッドの数と各ワーカースレッドの容量によって決まります。ワーカースレッドのデフォルトの数は、使用可能な vCPU の数によって決まります。または、`AWS_LAMBDA_NODEJS_WORKER_COUNT` 環境変数を設定してワーカースレッドの数を設定できます。各ワーカースレッドで数のリクエストを処理できるため、非同期関数ハンドラーを使用することをお勧めします。関数ハンドラーが同期の場合、各ワーカースレッドは一度に 1 つのリクエストのみを処理できます。
## 同時実行のための関数の構築
非同期関数ハンドラーを使用すると、各ランタイムワーカーは複数のリクエストを同時に処理します。グローバルオブジェクトは、複数の同時リクエスト間で共有されます。ミュータブルなオブジェクトの場合は、グローバル状態を使用しないか、`AsyncLocalStorage` を使用します。
AWS SDK クライアントは非同期に対応しているため、特別な処理は必要ありません。
**例: グローバル状態**
次のコードでは、関数ハンドラー内で変更されるグローバルオブジェクトが使用されています。そのため、非同期に対応しません。
```
let state = {
currentUser: null,
requestData: null
};
export const handler = async (event, context) => {
state.currentUser = event.userId;
state.requestData = event.data;
await processData(state.requestData);
// state.currentUser might now belong to a different request
return { user: state.currentUser };
};
```
以下のように関数ハンドラー内で `state` オブジェクトを初期化すると、共有グローバル状態を避けられます。
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**例: データベース接続**
次のコードは、複数の呼び出し間で共有される共有クライアントオブジェクトが使用されています。使用する接続ライブラリによっては、同時実行に対応しない場合があります。
```
const { Client } = require('pg');
// Single connection created at init time
const client = new Client({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
// Connect once during cold start
client.connect();
exports.handler = async (event) => {
// Multiple parallel invocations share this single connection = BAD
// With multi-concurrent Lambda, queries will collide
const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
同時実行に対応させるには、以下のように接続プールを使用します。プールは、同時データベースクエリごとに個別の接続を使用します。
```
const { Pool } = require('pg');
// Connection pool created at init time
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
max: 20, // Max connections in pool
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000
});
exports.handler = async (event) => {
// Pool gives each parallel invocation its own connection
const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
## Node.js 22 コールバックベースのハンドラー
Node.js 22 を使用する場合、Lambda マネージドインスタンスでコールバックベースの関数ハンドラーを使用することはできません。コールバックベースのハンドラーは、Lambda (デフォルト) 関数でのみサポートされています。Node.js 24 以降のランタイムの場合、コールバックベースの関数ハンドラーは Lambda (デフォルト) と Lambda マネージドインスタンスの両方で廃止されています。
代わりに、Lambda マネージドインスタンスを使用する際には `async` 関数ハンドラーを使用します。詳細については、「[Node.js の Lambda 関数ハンドラーの定義](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html)」をご覧ください。
## 共有の /tmp ディレクトリ
`/tmp` ディレクトリは、実行環境内のすべての同時リクエスト間で共有されます。同じファイルに同時に書き込むと、別のプロセスによってファイルが上書きされるなど、データの破損が発生する可能性があります。これに対処するには、共有ファイルのファイルロックを実装するか、リクエストごとに一意のファイル名を使用して競合を回避します。空き容量を占有しないよう、不要なファイルはクリーンアップしてください。
## ログ記録
ログインターリービング (ログでインターリーブされるさまざまなリクエストからのログエントリ) は、複数同時実行システムでは正常です。Lambda マネージドインスタンスを使用する関数は常に、[高度なログ記録コントロール](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)で導入した構造化された JSON ログ形式を使用します。この形式には `requestId` が含まれ、ログエントリを 1 つのリクエストに関連付けることができます。`console` ロガーを使用すると、`requestId` が各ログエントリに自動的に含まれます。詳細については、「[Node.js での Lambda の高度なログ記録コントロールの使用](nodejs-logging.md#node-js-logging-advanced)」を参照してください。
[Winston](https://github.com/winstonjs/winston) などの一般的なサードパーティーのログ記録ライブラリには、通常、ログ出力にコンソールを使用できるサポートが含まれています。
## リクエストコンテキスト
`context.awsRequestId` を使用すると、現在のリクエストのリクエスト ID に非同期対応でアクセスできます。
`context.xRayTraceId` を使用して X-Ray トレース ID にアクセスします。これにより、現在のリクエストのトレース ID への同時実行に対応したアクセスが可能になります。Lambda は、Lambda マネージドインスタンスの `_X_AMZN_TRACE_ID` 環境変数をサポートしていません。AWS SDK を使用すると、X-Ray トレース ID が自動的に伝播されます。
`context.getRemainingTimeInMillis()` を使用してタイムアウトを検出します。詳細については「[エラー処理と復旧](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)」を参照してください。
## 初期化とシャットダウン
関数の初期化はワーカースレッドごとに 1 回行われます。関数が初期化中にログを発行すると、繰り返しログエントリが表示されることがあります。
拡張機能を持つ Lambda 関数の場合、実行環境はシャットダウン中に SIGTERM シグナルを出力します。このシグナルは拡張機能によって使用され、バッファのフラッシュなどのクリーンアップタスクをトリガーします。拡張機能を持つ Lambda (デフォルト) 関数は、`process.on()` を使用して SIGTERM シグナルにサブスクライブすることもできます。これは、ワーカースレッドでは `process.on()` を使用できないため、Lambda マネージドインスタンスを使用する関数ではサポートされていません。実行環境のライフサイクルの詳細については、「[Lambda 実行環境のライフサイクルの概要](lambda-runtime-environment.md)」を参照してください。
## 依存関係バージョン
Lambda マネージドインスタンスには、以下のパッケージバージョンの最小要件が必要です。
+ AWS SDK for JavaScript v3: バージョン 3.933.0 以降
+ AWS X-Ray SDK for Node.js: バージョン 3.12.0 以降
+ AWS Distro for OpenTelemetry – Instrumentation for JavaScript: バージョン 0.8.0 以降
+ Powertools for AWS Lambda (TypeScript): バージョン 2.29.0 以降
## Powertools for AWS Lambda (TypeScript)
Powertools for AWS Lambda (TypeScript) は Lambda マネージドインスタンスと互換性があり、ログ記録、トレース、メトリクスなどのユーティリティを利用できます。詳細については、「[Powertools for AWS Lambda (TypeScript)](https://github.com/aws-powertools/powertools-lambda-typescript)」を参照してください。
## 次のステップ
+ 「[Lambda マネージドインスタンスの Java ランタイム](lambda-managed-instances-java-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの Python ランタイム](lambda-managed-instances-python-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの .NET ランタイム](lambda-managed-instances-dotnet-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」について説明する
# Lambda マネージドインスタンスの Python ランタイム
Lambda ランタイムは、複数の Python プロセスを使用して同時リクエストを処理します。各同時リクエストは、独自のメモリ容量と初期化を備えた個別のプロセスで実行されます。各プロセスは、一度に 1 つのリクエストを同期的に処理します。プロセスのメモリは直接共有されないため、グローバル変数、モジュールレベルのキャッシュ、およびシングルトンオブジェクトは同時リクエスト間で分離されます。
## 同時実行数の設定
Lambda が各実行環境に送信する同時リクエストの最大数は、関数設定の `PerExecutionEnvironmentMaxConcurrency` 設定で制御できます。これはオプションの設定となっており、デフォルト値はランタイムによって異なります。Python ランタイムの場合の同時リクエスト数は、vCPU あたり 16 件がデフォルト値になっていますが、独自の値を設定することもできます。この値により、Python ランタイムで使用されるプロセスの数も決まります。Lambda は、各実行環境の容量に応じて、設定された最大数までの同時リクエストの数を自動的に調整し、それらのリクエストを取得します。
**重要**
プロセスベースの同時実行を使用すると、各ランタイムワーカープロセスが独自に初期化を実行します。合計メモリ使用量は、プロセスごとのメモリに同時プロセス数を乗じたものと等しくなります。大きなライブラリまたはデータセットをロードしていて、同時実行性が高い場合は、メモリフットプリントが大きくなります。ワークロードによっては、CPU 対メモリの比率を調整するか、同時実行を低く設定して、利用可能なメモリを超過しないようにする必要があります。CloudWatch の `MemoryUtilization` メトリクスを使用して、メモリ消費量を追跡できます。
## 同時実行のための関数の構築
プロセスベースの複数同時実行モデルにより、Python ランタイムを使用する Lambda マネージドインスタンス関数は、複数の呼び出しからメモリ内リソースに同時にアクセスしません。メモリ内同時実行の安全性のためにコーディングプラクティスを適用する必要はありません。
## 共有の /tmp ディレクトリ
`/tmp` ディレクトリは、実行環境内のすべての同時リクエスト間で共有されます。同じファイルに同時に書き込むと、別のプロセスによってファイルが上書きされるなど、データの破損が発生する可能性があります。これに対処するには、共有ファイルのファイルロックを実装するか、プロセスごとまたはリクエストごとに一意のファイル名を使用して競合を回避します。空き容量を占有しないよう、不要なファイルはクリーンアップしてください。
## ログ記録
ログインターリービング (ログでインターリーブされるさまざまなリクエストからのログエントリ) は、複数同時実行システムでは正常です。
Lambda マネージドインスタンスを使用する関数は常に、[高度なログ記録コントロール](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)で導入した構造化された JSON ログ形式を使用します。この形式には `requestId` が含まれ、ログエントリを 1 つのリクエストに関連付けることができます。Lambda の Python 標準ライブラリの `logging` モジュールを使用すると、`requestId` が各ログエントリに自動的に含まれます。詳細については、「[Python での Lambda の高度なログ記録コントロールの使用](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced)」を参照してください。
## リクエストコンテキスト
`context.aws_request_id` を使用して、現在のリクエストのリクエスト ID にアクセスします。
Python ランタイムでは、`_X_AMZN_TRACE_ID` 環境変数を使用して、Lambda マネージドインスタンスで X-Ray トレース ID にアクセスできます。AWS SDK を使用すると、X-Ray トレース ID が自動的に伝播されます。
`context.get_remaining_time_in_millis()` を使用してタイムアウトを検出します。詳細については「[エラー処理と復旧](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)」を参照してください。
## 初期化とシャットダウン
関数の初期化はプロセスごとに 1 回行われます。関数が初期化中にログを発行すると、繰り返しログエントリが表示されることがあります。
拡張機能を持つ Lambda 関数の場合、実行環境はシャットダウン中に SIGTERM シグナルを出力します。このシグナルは拡張機能によって使用され、バッファのフラッシュなどのクリーンアップタスクをトリガーします。SIGTERM イベントにサブスクライブすることで、データベース接続を閉じるなどの関数のクリーンアップタスクを実行できます。実行環境のライフサイクルの詳細については、「[Lambda 実行環境のライフサイクルの概要](lambda-runtime-environment.md)」を参照してください。
## 依存関係バージョン
Lambda マネージドインスタンスには、以下のパッケージバージョンの最小要件が必要です。
+ Powertools for AWS Lambda (Python): バージョン 3.23.0 以降
## Powertools for AWS Lambda (Python)
Powertools for AWS Lambda (Python) は Lambda マネージドインスタンスと互換性があり、ログ記録、トレース、メトリクスなどのユーティリティを利用できます。詳細については、「[Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python)」を参照してください。
## 次のステップ
+ 「[Lambda マネージドインスタンスの Java ランタイム](lambda-managed-instances-java-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの Node.js ランタイム](lambda-managed-instances-nodejs-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの .NET ランタイム](lambda-managed-instances-dotnet-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」について説明する
# Lambda マネージドインスタンスの .NET ランタイム
.NET ランタイムの場合、Lambda マネージドインスタンスは実行環境ごとに 1 つの .NET プロセスを使用します。複数の同時リクエストは、.NET タスクを使用して処理されます。
## 同時実行数の設定
Lambda が各実行環境に送信する同時リクエストの最大数は、関数設定の `PerExecutionEnvironmentMaxConcurrency` 設定で制御できます。これはオプションの設定となっており、デフォルト値はランタイムによって異なります。.NET ランタイムの場合、デフォルト値は vCPU あたり 32 件の同時リクエスト数になります。または、独自の値を設定できます。Lambda は、各実行環境の容量に応じて、設定された最大数までの同時リクエストの数を自動的に調整し、それらのリクエストを取得します。
## 同時実行のための関数の構築
Lambda マネージドインスタンスを使用する場合は、他の複数同時実行環境と同じ同時実行のセーフなプラクティスを適用する必要があります。ハンドラーオブジェクトはすべてのタスクで共有されるため、変更可能な状態はスレッドセーフである必要があります。これには、コレクション、データベース接続、およびリクエスト処理中に変更されるあらゆる静的オブジェクトが含まれます。
AWS SDK クライアントはスレッドセーフなため、特別な処理は必要ありません。
**例: データベース接続プール**
次のコードは、同時リクエスト間で共有される静的データベース接続オブジェクトを使用します。`SqlConnection` オブジェクトはスレッドセーフではありません。
```
public class DBQueryHandler
{
// Single connection shared across threads - NOT SAFE
private SqlConnection connection;
public DBQueryHandler()
{
connection = new SqlConnection("your-connection-string-here");
connection.Open();
}
public string Handle(object input, ILambdaContext context)
{
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
これに対処するには、接続プールから取得したリクエストごとに個別の接続を使用します。`Microsoft.Data.SqlClient` などの ADO.NET プロバイダーは、接続オブジェクトが開かれると、接続プーリングを自動的にサポートします。
```
public class DBQueryHandler
{
public DBQueryHandler()
{
}
public string Handle(object input, ILambdaContext context)
{
using var connection = new SqlConnection("your-connection-string-here");
connection.Open();
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
**例: コレクション**
標準の .NET コレクションはスレッドセーフではありません。
```
public class Handler
{
private static List items = new List();
private static Dictionary cache = new Dictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
同時実行がセーフになるように、`System.Collections.Concurrent` 名前空間のコレクションを使用します。
```
public class Handler
{
private static ConcurrentBag items = new ConcurrentBag();
private static ConcurrentDictionary cache = new ConcurrentDictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
## 共有の /tmp ディレクトリ
`/tmp` ディレクトリは、実行環境内のすべての同時リクエスト間で共有されます。同じファイルに同時に書き込むと、別のリクエストによってファイルが上書きされるなど、データの破損が発生する可能性があります。これに対処するには、共有ファイルのファイルロックを実装するか、リクエストごとに一意のファイル名を使用して競合を回避します。空き容量を占有しないよう、不要なファイルはクリーンアップしてください。
## ログ記録
ログインターリービング (ログでインターリーブされるさまざまなリクエストからのログエントリ) は、複数同時実行システムでは正常です。Lambda マネージドインスタンスを使用する関数は常に、[高度なログ記録コントロール](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)で導入した構造化された JSON ログ形式を使用します。この形式には `requestId` が含まれ、ログエントリを 1 つのリクエストに関連付けることができます。`context.Logger` オブジェクトを使用してログを生成すると、`requestId` は各ログエントリに自動的に含まれます。詳細については、「[.NET での Lambda の高度なログ記録コントロールの使用](csharp-logging.md#csharp-logging-advanced)」を参照してください。
## リクエストコンテキスト
`context.AwsRequestId` プロパティを使用して、現在のリクエストのリクエスト ID にアクセスします。
`context.TraceId` プロパティを使用して、X-Ray トレース ID にアクセスします。これにより、現在のリクエストのトレース ID への同時実行に対応したアクセスが可能になります。Lambda は、Lambda マネージドインスタンスの `_X_AMZN_TRACE_ID` 環境変数をサポートしていません。AWS SDK を使用すると、X-Ray トレース ID が自動的に伝播されます。
`ILambdaContext.RemainingTime` を使用してタイムアウトを検出します。詳細については「[エラー処理と復旧](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)」を参照してください。
## 初期化とシャットダウン
関数の初期化は、実行環境ごとに 1 回行われます。初期化中に作成されたオブジェクトは、リクエスト間で共有されます。
拡張機能を持つ Lambda 関数の場合、実行環境はシャットダウン中に SIGTERM シグナルを出力します。このシグナルは拡張機能によって使用され、バッファのフラッシュなどのクリーンアップタスクをトリガーします。SIGTERM イベントにサブスクライブすることで、データベース接続を閉じるなどの関数のクリーンアップタスクを実行できます。実行環境のライフサイクルの詳細については、「[Lambda 実行環境のライフサイクルの概要](lambda-runtime-environment.md)」を参照してください。
## 依存関係バージョン
Lambda マネージドインスタンスには、以下のパッケージバージョンの最小要件が必要です。
+ Amazon.Lambda.Core: バージョン 2.7.1 以降
+ Amazon.Lambda.RuntimeSupport: バージョン 1.14.1 以降
+ OpenTelemetry.Instrumentation.AWSLambda: バージョン 1.14.0 以降
+ AWSXRayRecorder.Core: バージョン 2.16.0 以降
+ AWSSDK.Core: バージョン 4.0.0.32 以降
## Powertools for AWS Lambda (.NET)
[Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) および [AWS Distro for OpenTelemetry – Instrumentation for DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) は現在、Lambda マネージドインスタンスをサポートしていません。
## 次のステップ
+ 「[Lambda マネージドインスタンスの Java ランタイム](lambda-managed-instances-java-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの Node.js ランタイム](lambda-managed-instances-nodejs-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスの Python ランタイム](lambda-managed-instances-python-runtime.md)」を確認する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」について説明する
# Lambda マネージドインスタンスの Rust サポート
## 同時実行数の設定
Lambda が各実行環境に送信する同時リクエストの最大数は、関数設定の `PerExecutionEnvironmentMaxConcurrency` 設定で制御できます。これはオプション設定です。Rust のデフォルト値は vCPU ごとに 8 つの同時リクエストですが、独自の値を設定することも可能です。この値は、ランタイムによってスポーンされた Tokio タスクの数を決定するもので、実行環境の存続期間中は固定 (静的) となります。各ワーカーは実行中のリクエストを 1 つだけ処理し、多重処理することはありません。Lambda は、各実行環境の容量に応じて、設定された最大数までの同時リクエストの数を自動的に調整し、それらのリクエストを取得します。
## 同時実行のための関数の構築
Lambda マネージドインスタンスを使用する場合は、他のマルチスレッド環境と同じスレッドセーフな環境を適用する必要があります。ハンドラーオブジェクトはすべてのワーカースレッドで共有されるため、ミュータブルな状態はスレッドセーフである必要があります。これには、コレクション、データベース接続、およびリクエスト処理中に変更される静的オブジェクトが含まれます。
同時リクエスト処理を有効にするには、 `concurrency-tokio` 機能フラグを `Cargo.toml` ファイルに追加します。
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
`lambda_runtime::run_concurrent(…)` エントリポイントは、通常メイン関数の `#[tokio::main]` 属性によって提供される Tokio ランタイム内から呼び出す必要があります。ハンドラークロージャは [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html) \$1 [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html) を実装する必要があります。これにより、フレームワークは複数の非同期タスク間でハンドラーを安全に共有できます。これらの境界が満たされない場合、コードはコンパイルエラーになります。
呼び出し間で共有される状態 (データベース接続プールや設定構造体など) が必要な場合は、それを [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) で包み、各呼び出しごとにその `Arc` をクローンします。
すべての AWS SDK for Rust クライアントは同時実行セーフであり、特別な処理は必要ありません。
### 例: AWS SDK クライアント
次の例では、S3 クライアントを使用して、呼び出しごとにオブジェクトをアップロードします。クライアントは、`Arc` を介さず、直接クロージャ内へクローンされます。
```
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let s3_client = aws_sdk_s3::Client::new(&config);
run_concurrent(service_fn(move |event: LambdaEvent| {
let s3_client = s3_client.clone(); // cheap clone, no Arc needed
async move {
s3_client.put_object()
.bucket(&event.payload.bucket)
.key(&event.payload.key)
.body(event.payload.body.into_bytes().into())
.send()
.await?;
Ok(Response { message: "uploaded".into() })
}
}))
.await
```
### 例: データベース接続プール
クライアントや設定などの共有状態にハンドラからアクセスする必要がある場合は、それらを [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) で包み、各呼び出しごとにその `Arc` をクローンします。
```
#[derive(Debug)]
struct AppState {
dynamodb_client: DynamoDbClient,
table_name: String,
cache_ttl: Duration,
}
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let state = Arc::new(AppState {
dynamodb_client: DynamoDbClient::new(&config),
table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),
cache_ttl: Duration::from_secs(300),
});
run_concurrent(service_fn(move |event: LambdaEvent| {
let state = state.clone();
async move { handle(event, state).await }
}))
.await
```
## 共有の /tmp ディレクトリ
`/tmp` ディレクトリは、実行環境内のすべての同時呼び出し間で共有されます。呼び出しごとに一意のファイル名 (例えばリクエスト ID を含める) を使用するか、明示的なファイルロックを実装してデータの破損を回避します。
## ログ記録
ログインターリービング (ログでインターリーブされるさまざまなリクエストからのログエントリ) は、複数同時実行システムでは正常です。Lambda マネージドインスタンスを使用する関数は、Lambda の[高度なログ記録コントロール](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)を通じて、構造化された JSON ログ形式をサポートします。この形式には `requestId` が含まれ、ログエントリを 1 つのリクエストに関連付けることができます。詳細については、「[トレーシングクレートによる高度なログ記録機能の実装](rust-logging.md#rust-logging-tracing)」を参照してください。
## リクエストコンテキスト
`Context` オブジェクトは各ハンドラー呼び出しに直接渡されます。`event.context.request_id` を使用して、現在のリクエストのリクエスト ID にアクセスします。
`event.context.xray_trace_id` を使用して X-Ray トレース ID にアクセスします。Lambda は、Lambda マネージドインスタンスの `_X_AMZN_TRACE_ID` 環境変数をサポートしていません。AWS SDK for Rust を使用すると、X-Ray トレース ID が自動的に伝播されます。
`event.context.deadline` を使用してタイムアウトを検出します。これには、呼び出しの期限がミリ秒単位で含まれます。
## 初期化とシャットダウン
関数の初期化は、実行環境ごとに 1 回行われます。初期化中に作成されたオブジェクトは、リクエスト間で共有されます。
拡張機能を持つ Lambda 関数の場合、実行環境はシャットダウン中に SIGTERM シグナルを出力します。このシグナルは、バッファのフラッシュなどのクリーンアップタスクをトリガーするために拡張機能で使用されます。 `lambda_runtime` は、グレースフルシャットダウンのシグナル処理の設定を簡略化するヘルパー関数 [https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html) を提供しています。実行環境のライフサイクルの詳細については、「[Lambda 実行環境のライフサイクルの概要](lambda-runtime-environment.md)」を参照してください。
## 依存関係バージョン
Lambda マネージドインスタンスには、以下のパッケージバージョンの最小要件が必要です。
+ `lambda_runtime`: バージョン 1.1.1 以降 (`concurrency-tokio` 機能が有効であること)
+ 最小サポート Rust バージョン (MSRV) は 1.84.0 です。
# Lambda マネージドインスタンスのネットワーク
Lambda マネージドインスタンス関数を実行する際には、関数が VPC 外のリソースにアクセスできるようにネットワーク接続を設定する必要があります。これには、Amazon S3、Amazon DynamoDB などの AWS サービスが含まれます。また、テレメトリデータを CloudWatch Logs や X-Ray に送信する際にも接続が必要になります。
## 接続オプション
VPC 接続の設定には主に 3 つの方法があり、それぞれにコスト、セキュリティ、複雑さの面でトレードオフがあります。
## インターネットゲートウェイを持つパブリックサブネット
このオプションでは、インターネットゲートウェイを介してインターネットに直接アクセスできるパブリックサブネットを使用します。IPv4 設定と IPv6 設定のいずれかを選択できます。
### IPv4 のインターネットゲートウェイ
**インターネットゲートウェイで IPv4 接続を設定するには**
1. IPv4 CIDR ブロックを使用して既存のパブリックサブネットを作成または使用する。
1. VPC にインターネットゲートウェイをアタッチする。
1. ルートテーブルを更新して、`0.0.0.0/0` トラフィックをインターネットゲートウェイにルーティングする。
1. リソースにパブリック IPv4 アドレスまたは Elastic IP アドレスが割り当てられていることを確認する。
1. セキュリティグループを設定して、必要なポートでアウトバウンドトラフィックを許可する。
この設定により双方向接続が可能になり、関数からのアウトバウンド接続とインターネットからのインバウンド接続の両方を実行できます。
### IPv6 のインターネットゲートウェイ
**インターネットゲートウェイで IPv6 接続を設定するには**
1. VPC で IPv6 を有効にする。
1. IPv6 CIDR ブロックが割り当てられた既存のパブリックサブネットを作成または使用する。
1. インターネットゲートウェイを VPC にアタッチする (同じインターネットゲートウェイで IPv4 と IPv6 の両方を処理可能)。
1. ルートテーブルを更新して、`::/0` トラフィックをインターネットゲートウェイにルーティングする。
1. アクセスする必要がある AWS サービスが、ユーザーのリージョンで IPv6 をサポートしていることを確認します。
1. セキュリティグループを設定して、必要なポートでアウトバウンドトラフィックを許可する。
この設定により、IPv6 アドレス指定を使用した双方向接続が可能になります。
### Egress-Only インターネットゲートウェイが指定された IPv6
**Egress-Only インターネットゲートウェイが指定された IPv6 接続を設定するには**
1. VPC で IPv6 を有効にする。
1. IPv6 CIDR ブロックが割り当てられた既存のパブリックサブネットを作成または使用する。
1. Egress-Only インターネットゲートウェイを VPC にアタッチする。
1. ルートテーブルを更新して、Egress-Only インターネットゲートウェイに `::/0` トラフィックをルーティングする。
1. アクセスする必要がある AWS サービスが、ユーザーのリージョンで IPv6 をサポートしていることを確認します。
1. セキュリティグループを設定して、必要なポートでアウトバウンドトラフィックを許可する。
この設定によりアウトバウンドのみの接続が可能になり、関数にアウトバウンド接続の開始を許可しながら、インターネットからのインバウンド接続を防止します。
## VPC エンドポイント
VPC エンドポイントを使用することで、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続なしで、サポートされている AWS サービスに VPC をプライベートに接続できます。VPC と AWS サービス間のトラフィックは、Amazon ネットワークを離れません。
**VPC エンドポイントを設定するには**
1. Amazon VPC コンソールを [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) で開きます。
1. ナビゲーションペインで、**[エンドポイント]** を選択します。
1. **[エンドポイントの作成]** を選択します。
1. **[Service category]** (サービスカテゴリ) で、**[AWS services]** (のサービス) を選択します。
1. **[サービス名]** で、使用するサービスエンドポイント (Amazon S3 の `com.amazonaws.region.s3` など) を選択します。
1. [**VPC**] で、自分の VPC を選択します。
1. **[サブネット]** には、エンドポイントネットワークインターフェイスの作成先となるサブネットを選択します。可用性を高めるには、複数のアベイラビリティーゾーンにサブネットを選択します。
1. **[Security groups]** (セキュリティグループ) で、エンドポイントネットワークインターフェイスに関連付けるセキュリティグループを選択します。セキュリティグループは、必要なポートで関数のセキュリティグループから発信されるインバウンドトラフィックを許可する必要があります。
1. **[エンドポイントの作成]** を選択します。
関数がアクセスする必要がある AWS サービスごとに、これらのステップを繰り返します。
## NAT ゲートウェイを使用するプライベートサブネット
このオプションは、NAT ゲートウェイを使用して、リソースをプライベートに保ちながらプライベートサブネット内のリソースにインターネットアクセスを提供します。
**NAT ゲートウェイを使用したプライベートサブネットを設定するには**
1. CIDR ブロックを使用してパブリックサブネットを作成する (まだ作成していない場合)。
1. VPC にインターネットゲートウェイをアタッチする。
1. パブリックサブネットに NAT ゲートウェイを作成し、Elastic IP アドレスを割り当てる。
1. ルートを追加して、パブリックサブネットのルートテーブルを更新する: `0.0.0.0/0` → インターネットゲートウェイ
1. CIDR ブロックを使用してプライベートサブネットを作成または既存のものを使用する。
1. ルートを追加して、プライベートサブネットのルートテーブルを更新する: `0.0.0.0/0` → NAT ゲートウェイ
1. セキュリティグループを設定して、必要なポートでアウトバウンドトラフィックを許可する。
高可用性を実現するには、各アベイラビリティーゾーンに NAT ゲートウェイを 1 つデプロイし、ローカル NAT ゲートウェイを使用するように各アベイラビリティーゾーンにルートテーブルを設定します。これにより、クロス AZ のデータ転送料金がかかるのを防ぎ、レジリエンスが向上します。
## 接続オプションの選択
接続オプションを選択する際には、次の要素を考慮してください。
**インターネットゲートウェイを使用したパブリックサブネット**
+ 最もシンプルな設定かつ最小限のコスト
+ 開発環境とテスト環境に最適
+ リソースがインターネットからインバウンド接続を受信できる (セキュリティ上の考慮事項)
+ IPv4 と IPv6 の両方をサポートしている
**VPC エンドポイント**
+ 最高のセキュリティが確保され、トラフィックが AWS ネットワーク内に維持される
+ インターネットルーティングと比較してレイテンシーが低い
+ セキュリティ要件が厳しい本番環境に最適
+ エンドポイント、アベイラビリティーゾーン、処理される GB あたりのコストが最も高い
+ 高可用性を実現するには、各アベイラビリティーゾーンにエンドポイントが必要
**NAT ゲートウェイを使用するプライベートサブネット**
+ リソースはプライベートのままで、インバウンドのインターネットアクセスがない
+ 標準のエンタープライズアーキテクチャ
+ すべての IPv4 インターネットトラフィックをサポート
+ NAT ゲートウェイの時間単位およびデータ処理料金のコストは中程度
+ IPv4 のみをサポート
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」を理解する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
+ 「[Lambda マネージドインスタンスのセキュリティとアクセス許可](lambda-managed-instances-security.md)」を理解する
# Lambda マネージドインスタンスのモニタリング
CloudWatch メトリクスを使用して、Lambda マネージドインスタンスをモニタリングできます。Lambda では CloudWatch にメトリクスが自動的に発行さるため、リソース使用率のモニタリング、コストの追跡、パフォーマンスの最適化を簡単に行えます。
## 使用可能なメトリクス
Lambda マネージドインスタンスでは、キャパシティープロバイダーレベルと実行環境レベルの 2 つのレベルでメトリクスが提供されます。
### キャパシティープロバイダーレベルのメトリクス
キャパシティープロバイダーレベルのメトリクスは、インスタンス全体のリソース使用率を可視化します。これらのメトリクスは、次のディメンションを使用します。
+ **CapacityProviderName** – キャパシティープロバイダーの名前
+ **InstanceType** – EC2 インスタンスのタイプ
**リソース使用率メトリクス:**
+ **CPUUtilization** – キャパシティープロバイダー内のインスタンス全体の CPU 使用率
+ **MemoryUtilization** – キャパシティープロバイダー内のインスタンス全体のメモリ使用率
**キャパシティメトリクス:**
+ **vCPUAvailable** – インスタンスで割り当て可能な vCPU 数 (カウント)
+ **MemoryAvailable** – インスタンスで割り当て可能なメモリ数 (バイト単位)
+ **vCPUAllocated** – 実行環境のインスタンスに割り当てられた vCPU 数 (カウント)
+ **MemoryAllocated** – 実行環境のインスタンスに割り当てられたメモリ数 (バイト単位)
### 実行環境レベルのメトリクス
実行環境レベルのメトリクスは、各関数のリソース使用率と同時実行性を可視化します。これらのメトリクスは、次のディメンションを使用します。
+ **CapacityProviderName** – キャパシティープロバイダーの名前
+ **FunctionName** – Lambda 関数の名前
+ **リソース** - リソースごとに、関数の特定バージョンのメトリクスを表示します。
**注記**
Lambda マネージドインスタンス (LMI) の場合、`Resource` ディメンションは関数バージョンのみをサポートします。形式は `:` です。
**使用可能な実行環境メトリクス:**
+ **ExecutionEnvironmentConcurrency** – 5 分間のサンプル期間中の最大同時実行数
+ **ExecutionEnvironmentConcurrencyLimit** – 実行環境あたりの最大同時実行数の制限
+ **ExecutionEnvironmentCPUUtilization** – 関数の実行環境の CPU 使用率の割合
+ **ExecutionEnvironmentMemoryUtilization** – 関数の実行環境のメモリ使用率の割合
## メトリクスの頻度と保持
Lambda マネージドインスタンスメトリクスは 5 分間隔で発行され、15 か月間保持されます。
## CloudWatch でのメトリクスの表示
**CloudWatch コンソールで Lambda マネージドインスタンスのメトリクスを表示する**
1. CloudWatch コンソールの [console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開きます。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. **[すべてのメトリクス]** タブで、**[AWS/Lambda]** を選択します。
1. 表示するメトリクスのディメンションを選択します。
+ キャパシティープロバイダーレベルのメトリクスの場合は、**CapacityProviderName** と **InstanceType** でフィルタリングします。
+ 実行環境レベルのメトリクスの場合は、**CapacityProviderName**、**FunctionName**、および **Resource** でフィルタリングします。
1. モニタリングするメトリクスを選択します。
## メトリクスを使用してパフォーマンスを最適化する
CPU とメモリの使用率をモニタリングして、関数のサイズが適切かどうかを把握します。使用率が高い場合は、インスタンスタイプを大きくしたり、関数のメモリ割り当てを増やしたりする必要がある可能性があります。同時実行メトリクスを追跡してスケーリング動作を把握し、潜在的なスロットリングを特定します。
キャパシティメトリクスをモニタリングし、ワークロードに対して十分なリソースが確保されている状態か確認します。**vCPUAvailable** メトリクスと **MemoryAvailable** メトリクスは、インスタンスの残りの容量を把握するのに役立ちます。
## 次のステップ
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」について説明する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ 「[Lambda マネージドインスタンスのセキュリティとアクセス許可](lambda-managed-instances-security.md)」を理解する
# Lambda マネージドインスタンスのクォータ
このページでは、AWS Lambda マネージドインスタンスのサービスクォータについて説明します。これらのクォータは AWS Lambda (デフォルト) クォータとは異なります。一部のクォータは、リクエストで増やすことができます。
## Lambda API リクエストのクォータ
これらのクォータは API コールを実行できるレートを制御し、Lambda マネージドインスタンスのキャパシティープロバイダーを管理します。読み取りおよび書き込みの API レート制限は、キャパシティープロバイダーの作成、更新、説明、削除など、合計されたすべてのキャパシティープロバイダーオペレーションに適用されます。
| リソース | クォータ |
| --- | --- |
| すべてのキャパシティプロバイダーの読み取り API の最大合計レート (1 秒あたりのリクエスト数) | 1 秒あたり 15 リクエスト。増やすことはできません。 |
| すべてのキャパシティープロバイダーの書き込み API の最大合計レート (1 秒あたりのリクエスト数) | 1 秒あたり 1 リクエスト。増やすことはできません。 |
## Lambda マネージドインスタンスのリソースクォータ
これらのクォータは、AWS アカウント内における Lambda マネージドインスタンスのコアリソースの制限を定義します。また、作成できるキャパシティープロバイダーの数と、各キャパシティープロバイダーに関連付けることができる関数のバージョンの数を制御します。
| リソース | クォータ |
| --- | --- |
| キャパシティープロバイダー | 1,000。1 つのアカウントに作成できるキャパシティープロバイダーの最大数。 |
| キャパシティープロバイダーあたりの関数バージョン | 100。キャパシティープロバイダーあたりの関数バージョンの最大数。増やすことはできません。 |
## イベントソースマッピングクォータ
これらのクォータは、Lambda マネージドインスタンスのさまざまな AWS サービスからのイベントを処理するためのスループットと設定制限を制御します。スループット制限は予測可能なパフォーマンスを確保し、マッピングカウント制限はサービスの安定性を維持するのに役立ちます。Lambda マネージドインスタンスのイベントソースマッピングは、イベントソースとして Amazon SQS、DynamoDB Streams、Amazon Kinesis Data Streams、Amazon MSK、セルフマネージド Apache Kafka をサポートしています。
| リソース | クォータ |
| --- | --- |
| Lambda マネージドインスタンスでの標準 SQS イベントソースマッピングのスループット | 秒あたり 5 MB。増やすことはできません。 |
| Lambda マネージドインスタンスでの標準 Kafka イベントソースマッピングのスループット | 秒あたり 1 MB。増やすことはできません。 |
| Lambda マネージドインスタンスでの標準 Kafka イベントソースマッピング | イベントソースマッピング数 100。増やすことはできません。 |
| Lambda マネージドインスタンスでの Kinesis イベントソースマッピングのスループット | 秒あたり 25 MB。引き上げ可能です。 |
| Lambda マネージドインスタンスでの DynamoDB イベントソースマッピングのスループット | 秒あたり 10 MB。引き上げ可能です。 |
| Lambda マネージドインスタンスでの非同期呼び出しにおける呼び出しリクエストのスループット | 秒あたり 5 MB。引き上げ可能です。 |
## クォータ引き上げのリクエスト
引き上げることができるクォータについては、Service Quotas コンソールから引き上げをリクエストできます。
**クォータの引き上げをリクエストするには**
1. [console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) で Service Quotas コンソールを開きます。
1. ナビゲーションペインで、**AWS[サービス]** を選択します。
1. **[AWS Lambda]** を選択します。
1. 引き上げたいクォータを選択します。
1. **[Request quota increase]** (クォータの引き上げのリクエスト) を選択します。
1. 新しいクォータ値を入力し、引き上げの理由を入力します。
1. **[リクエスト]** を選択します。
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」を理解する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
# Lambda マネージドインスタンスのベストプラクティス
## キャパシティープロバイダーの設定
**キャパシティープロバイダーを信頼レベル別に分けます。**セキュリティ要件が異なるワークロード用ごとに、別々のキャパシティープロバイダーを作成します。キャパシティープロバイダーはセキュリティ境界として機能するため、同じキャパシティープロバイダーに割り当てられたすべての関数は相互に信頼されている必要があります。
**わかりやすい名前を使用します。**キャパシティープロバイダーに名前を付け、使用目的と信頼レベルを明確に示します (例: `production-trusted`、`dev-sandbox`)。これにより、チームは各キャパシティープロバイダーの目的とセキュリティ体制を理解できます。
**複数のアベイラビリティーゾーンを使用します。**キャパシティープロバイダーを作成するときに、複数のアベイラビリティーゾーンにまたがるサブネットを指定します。Lambda は AZ の耐障害性を確保するため、デフォルトで 3 つのインスタンスを起動し、関数の高可用性を実現します。
## インスタンスタイプの選択
**Lambda にインスタンスタイプを選択させます。**デフォルトでは、Lambda はワークロードに最適なインスタンスタイプを選択します。利用可能なインスタンスタイプの数を制限すると可用性が低下する可能性があるため、Lambda マネージドインスタンスが選択したインスタンスタイプを使用することをお勧めします。
**特定の要件に応じてインスタンスタイプを指定します。**特定のハードウェア要件がある場合は、互換性のあるインスタンスのリストに許可されたインスタンスタイプを設定します。例えば、次のようになります。
+ 高いネットワーク帯域幅を必要とするアプリケーションの場合は、いくつかのインスタンスタイプを選択します。
+ コスト制約のあるテスト環境または開発環境の場合は、m7a.large などの小さいインスタンスタイプを選択します。
## 関数の設定
**適切なメモリと vCPU 設定を選択します。**関数の複数同時実行をサポートしているメモリと vCPU 設定を選択します。サポートされている関数の最小サイズは 2GB と 1 vCPU です。
+ Python アプリケーションでは、Python が複数同時実行を処理する方法のため、メモリと vCPU の比率 (4 対 1 または 8 対 1 など) が高い方を選択します。
+ IO をほとんど実行しない CPU 集約型のオペレーションまたは関数の場合は、複数の vCPU を選択します。
+ ウェブサービスやバッチジョブなどの IO 負荷の高いアプリケーションでは、複数同時実行が最適です。
**最大同時実行数を適切に設定します。**Lambda は、リソースの消費とスループットのバランスをとる最大同時実行数の適切なデフォルトを選択します。関数のリソース使用量に基づいてこの設定を調整します。
+ 関数呼び出しで使用する CPU が非常に少ない場合、最大同時実行数を増やす (vCPU あたり最大 64 個)
+ アプリケーションが大量のメモリを消費し、CPU が非常に少ない場合、最大同時実行数を減らす
同時実行数が非常に少ない実行環境では、スロットリングが発生したり、スケーリングが困難になる可能性があることに注意してください。
## スケーリング設定
**適切なターゲットリソース使用率を設定します。**デフォルトでは、Lambda はスロットルが発生しないよう、トラフィックが 5 分以内に 2 倍へ増加しても処理可能なヘッドルームを保持しています。ワークロードの特性に基づいてこれを調整します。
+ スロットルの影響を受けにくい非常に安定したワークロードやアプリケーションの場合は、使用率を高めてコストを削減するために、ターゲットを高レベルに設定します。
+ トラフィックがバーストする可能性があるワークロードの場合、リソースターゲットを低レベルに設定して追加のヘッドルームを維持します。
**トラフィックの増加を計画します。**トラフィックが 5 分以内に 2 倍以上になると、Lambda がインスタンスと実行環境をスケールアップするため、スロットリングが表示されることがあります。迅速なスケールアップ期間中に可能性のあるスロットリングを処理するようにアプリケーションを設計します。
## セキュリティ
**PassCapacityProvider アクセス許可に最小特権を適用します。**必要なキャパシティープロバイダーにのみ `lambda:PassCapacityProvider` アクセス許可を付与します。リソースレベルのアクセス許可を使用して、ユーザーが関数に割り当てることができるキャパシティープロバイダーを制限します。
**キャパシティープロバイダーの使用状況をモニタリングします。**AWS CloudTrail を使用して、キャパシティープロバイダーの割り当てとアクセスパターンをモニタリングします。これにより、不正アクセス試行の検知が可能となり、セキュリティポリシーへの準拠が保証されます。
**信頼できないワークロードを分離します。**信頼できないワークロード間のセキュリティ分離を行う上でコンテナに依存するべきではありません。相互に信頼されていないワークロードを分離するには、別個のキャパシティープロバイダーを使用します。
## コスト最適化
**EC2 料金オプションを活用します。**EC2 Savings Plans とリザーブドインスタンスを活用してコストを削減します。これらの料金オプションは、基本的な EC2 コンピューティングに適用されます (15% の管理料金は割引されません)。
**定常状態のワークロード向けに最適化します。**Lambda マネージドインスタンスは、大量のトラフィックが予測できる定常状態の関数に最適です。バーストトラフィックパターンでは、Lambda (デフォルト) の方が費用対効果が高い場合があります。
**リソース使用率をモニタリングします。**CloudWatch メトリクスを追跡して、CPU とメモリの使用率を把握します。実際の使用パターンに基づいて関数のメモリ割り当てとインスタンスタイプの選択を調整し、コストを最適化します。
## モニタリングとオブザーバビリティ
**キャパシティープロバイダーのメトリクスをモニタリングします。**CPUUtilization、MemoryUtilization、vCPUAvailable、MemoryAvailable などのキャパシティプロバイダーレベルのメトリクスを追跡し、ワークロードに対して十分なリソースが確保されている状態か確認します。
**実行環境メトリクスをモニタリングします。**ExecutionEnvironmentConcurrency や ExecutionEnvironmentConcurrencyLimit などの実行環境レベルのメトリクスを追跡して、スケーリング動作を理解し、発生可能性のあるスロットリングを特定します。
**CloudWatch アラームを設定します。**主要なメトリクスの CloudWatch アラームを作成して、問題を事前に特定します。
+ CPU またはメモリの使用率が高い
+ 使用可能な容量
+ 同時実行数の上限に近づいている状態
## 言語固有の考慮事項
**言語固有のベストプラクティスに従います。**並行処理の扱い方は、プログラミング言語によって異なります。詳細な推奨事項については、各言語別のガイドを参照:
+ **Java**: リクエスト固有の状態に対してスレッドセーフコレクション、`AtomicInteger`、および `ThreadLocal` を使用する
+ **Node.js**: すべてのリクエスト固有の状態に対して InvokeStore を使用し、グローバル変数を回避する
+ **Python**: リクエスト ID を使用して、`/tmp` で一意のファイル名を使用し、プロセスベースのメモリ分離を検討する
+ **Rust:** `concurrency-tokio` 機能を有効にして `run` の代わりに `run_concurrent` を使用します。ハンドラー値は、`Clone` \$1 `Send` である必要があります。
**スレッドセーフと同時実行に問題がないかテストします。**本番環境にデプロイする前に、スレッドセーフの問題、競合状態、同時ロード時の適切な状態分離について、関数を徹底的にテストします。
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」を理解する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
+ [キャパシティープロバイダーの VPC 接続](lambda-managed-instances-networking.md)を設定する
+ [CloudWatch メトリクス](lambda-managed-instances-monitoring.md)を使用して Lambda マネージドインスタンスをモニタリングする
# Lambda マネージドインスタンスのトラブルシューティング
## スロットリングとスケーリングの問題
### スケールアップ中のエラー率が高い
**問題:** トラフィックが急速に増加すると、スロットリングエラー (HTTP 429) が発生する。
**原因:** Lambda マネージドインスタンスは、CPU リソース使用率と同時実行数の飽和度に基づいて非同期的にスケーリングされます。トラフィックが 5 分以内に 2 倍を超えると、Lambda が需要に合わせてインスタンスと実行環境をスケールアップするため、スロットリングが表示されることがあります。
**解決策:**
+ **ターゲットリソース使用率の調整:** ワークロードに予測可能なトラフィックパターンがある場合は、ターゲットリソース使用率を低く設定して、トラフィックバーストのヘッドルームを増やします。
+ **事前ウォーミングキャパシティ:** 計画的なトラフィックの増加については、スケーリングが遅れないように、より長い期間にわたってトラフィックを徐々に増やします。
+ **スケーリングメトリクスのモニタリング:** スロットルエラーメトリクスを追跡して、スロットルとキャパシティスケーリングの問題の理由を理解します。
+ **関数設定の確認:** 関数メモリと vCPU 設定が複数同時実行をサポートしていることを確認します。必要に応じて、関数メモリまたは vCPU 割り当てを増やします。
### スケールダウンが遅い
**問題:** トラフィックが減少した後、インスタンスのスケールダウンに時間がかかる。
**原因:** Lambda マネージドインスタンスは、可用性を維持し、パフォーマンスに影響を与える可能性のある急速な容量変更を回避するために、徐々にスケールダウンします。
**解決策:**
これは想定される動作です。Lambda は、安定性を確保するためにインスタンスを控えめにスケールダウンします。CloudWatch メトリクスをモニタリングして、実行中のインスタンスの数を追跡します。
## 同時実行の問題
### 同時実行が低い実行環境でスロットリングが発生する
**問題:** 使用可能な容量があるにもかかわらず、関数にスロットリングが発生する。
**原因:** 最大同時実行数が非常に低い実行環境では、効果的なスケーリングが困難な場合があります。Lambda マネージドインスタンスは、複数同時実行アプリケーション用に設計されています。
**解決策:**
+ **最大同時実行数を増やす:** 関数呼び出しで使用する CPU が非常に少ない場合は、vCPU あたりの最大同時実行数設定を最大 64 まで増やします。
+ **関数コードを最適化する:** 関数コードを確認して、呼び出しあたりの CPU 消費量を減らし、同時実行数を増やします。
+ **関数のメモリと vCPU を調整する:** 関数に複数の同時呼び出しを処理するのに十分なリソースがあることを確認します。
### スレッドの安全性の問題 (Java ランタイム)
**問題:** 負荷がかかると、Java 関数が誤った結果を生成したり、競合状態が発生したりする。
**原因:** 複数のスレッドがハンドラーメソッドを同時に実行し、共有状態はスレッドセーフではありません。
**解決策:**
+ プリミティブ型の代わりにカウンターに `AtomicInteger` または `AtomicLong` を使用する
+ `HashMap` を `ConcurrentHashMap` に置き換える
+ `Collections.synchronizedList()` を使用して `ArrayList` をラップする
+ リクエスト固有の状態に `ThreadLocal` を使用する
+ 環境変数ではなく Lambda Context オブジェクトからトレース ID にアクセスする
詳細なガイダンスについては、「[Lambda マネージドインスタンスの Java ランタイム](lambda-managed-instances-java-runtime.md)」ドキュメントを参照してください。
### 状態分離の問題 (Node.js ランタイム)
**問題:** Node.js 関数がさまざまなリクエストからのデータを返すか、データ破損が発生する。
**原因:** グローバル変数が、同じワーカースレッド上の同時呼び出し間で共有されています。非同期オペレーションが制御する場合、他の呼び出しは共有状態を変更できます。
**解決策:**
+ すべてのリクエスト固有の状態に `@aws/lambda-invoke-store` をインストールして使用する
+ グローバル変数を `InvokeStore.set()` および `InvokeStore.get()` に置き換える
+ `/tmp` でリクエスト ID を含む一意のファイル名を使用する
+ 環境変数の代わりに `InvokeStore.getXRayTraceId()` を使用してトレース ID にアクセスする
詳細なガイダンスについては、「[Lambda マネージドインスタンスの Node.js ランタイム](lambda-managed-instances-nodejs-runtime.md)」ドキュメントを参照してください。
### ファイル競合 (Python ランタイム)
**問題:** Python 関数が `/tmp` のファイルから誤ったデータを読み取る。
**原因:** 複数のプロセスが `/tmp` ディレクトリを共有しています。同じファイルに同時に書き込むと、データが破損する可能性があります。
**解決策:**
+ リクエスト ID を含む一意のファイル名を使用する: `/tmp/request_{context.request_id}.txt`
+ `fcntl.flock()` で共有ファイルにファイルロックを使用する
+ 使用後に `os.remove()` で一時ファイルをクリーンアップする
詳細なガイダンスについては、「[Lambda マネージドインスタンスの Python ランタイム](lambda-managed-instances-python-runtime.md)」ドキュメントを参照してください。
## パフォーマンスの問題
### メモリ使用率が高い
**問題:** 関数でメモリ使用率が高いかメモリー不足のエラーが発生する。
**原因:** Python の同時リクエストは、それぞれ独自のメモリ容量を持つ個別のプロセスで実行されています。合計メモリ使用量は、プロセスあたりのメモリに同時処理を乗じたものと等しくなります。
**解決策:**
+ CloudWatch で `MemoryUtilization` メトリクスをモニタリングする
+ メモリ使用量が関数のメモリ制限に近づいた場合は、`MaxConcurrency` 設定を減らす
+ 関数のメモリ割り当てを増やして同時実行数を増やす
+ 初期化中ではなくオンデマンドでデータをロードしてメモリ使用量を最適化する
### パフォーマンスの不整合
**問題:** 関数のパフォーマンスが呼び出し間で大きく異なる。
**原因:** Lambda が可用性に基づいて異なるインスタンスタイプを選択しているか、リソースの可用性が異なるインスタンスで関数が実行されている可能性があります。
**解決策:**
+ **許可されるインスタンスタイプを指定する:** 特定のパフォーマンス要件がある場合は、Lambda が選択できるインスタンスタイプを制限するようにキャパシティープロバイダーで許可されるインスタンスタイプを設定します。
+ **インスタンスレベルのメトリクスをモニタリングする:** キャパシティープロバイダーレベルで `CPUUtilization` と `MemoryUtilization` を追跡して、リソースの制約を特定します。
+ **キャパシティメトリクスを確認する:** `vCPUAvailable` と `MemoryAvailable` を確認して、インスタンスで十分なリソースが使用可能であることを確認します。
## キャパシティープロバイダーの問題
### 関数バージョンが ACTIVE にならない
**問題:** 関数のバージョンが公開後も保留状態のままです。
**原因:** Lambda がマネージドインスタンスを起動し、実行環境を開始しています。このプロセスは時間がかかります。特に新しいキャパシティープロバイダーの最初の関数バージョンの場合はなおさらです。
**解決策:**
Lambda が初期化プロセスを完了するまで待ちます。Lambda は、AZ の回復性のためにデフォルトで 3 つのインスタンスを起動し、実行環境を 3 つ開始すると、関数バージョンが ACTIVE にマークされます。これには通常数分かかります。
### キャパシティープロバイダーを削除できない
**問題:** キャパシティープロバイダーを削除しようとするとエラーが発生する。
**原因:** 関数バージョンがアタッチされているキャパシティープロバイダーは削除できません。
**解決策:**
1. `ListFunctionVersionsByCapacityProvider` API でキャパシティープロバイダーを使用して、すべての関数バージョンを特定します。
1. これらの関数バージョンを削除または更新して、キャパシティープロバイダーの関連付けを削除します。
1. キャパシティープロバイダーの削除を再試行します。
### 関数の公開中の一般的なエラーメッセージ
**問題:** 関数の公開時に「公開中に内部エラーが発生しました」などの一般的なエラーメッセージが表示される。
**解決策:**
+ **IAM アクセス許可を確認する:** 使用しようとしているキャパシティープロバイダーの `lambda:PassCapacityProvider` アクセス許可があることを確認します。
+ **キャパシティープロバイダーの設定を確認する:** `GetCapacityProvider` API を使用して、キャパシティープロバイダーが ACTIVE 状態であることを確認します。
+ **VPC 設定を確認する:** キャパシティープロバイダーで指定されたサブネットとセキュリティグループが正しく設定され、アクセス可能であることを確認します。
+ **AWS CloudTrail ログを確認する:** CloudTrail ログで、失敗したオペレーションに関する詳細なエラー情報を確認します。
## モニタリングとオブザーバビリティの問題
### CloudWatch メトリクスがない
**問題:** キャパシティープロバイダーまたは関数について、予想されるメトリクスが CloudWatch に表示されない。
**原因:** メトリクスは 5 分間隔で発行されます。新しいキャパシティープロバイダーまたは関数では、メトリクスがすぐに利用できない場合があります。
**解決策:**
メトリクスが CloudWatch に表示されるまで、関数バージョンを公開してから少なくとも 5～10 分待ちます。正しい名前空間 (`AWS/Lambda`) とディメンション (`CapacityProviderName`、`FunctionName`、または `InstanceType`) を表示していることを確認します。
### CloudWatch ログが見つからない
**問題:** 関数は正常に実行されますが、CloudWatch Logs でログを見つけることができない。
**原因:** Lambda マネージドインスタンスは VPC で実行され、CloudWatch Logs にログを送信するためにネットワーク接続が必要です。適切な VPC 接続設定がないと、関数は CloudWatch Logs サービスエンドポイントに到達できません。
**解決策:**
関数が CloudWatch Logs にログを送信できるように VPC 接続を設定します。次の 3 つの選択肢があります。
**オプション 1: CloudWatch Logs の VPC エンドポイント (本番環境に推奨)**
1. Amazon VPC コンソールを [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) で開きます。
1. ナビゲーションペインで、**[エンドポイント]** を選択します。
1. **[エンドポイントの作成]** を選択します。
1. **[Service category]** (サービスカテゴリ) で、**[AWS services]** (のサービス) を選択します。
1. **[サービス名]** には、`com.amazonaws.region.logs` を選択します (`region` を AWS リージョンに置き換えます)。
1. **[VPC]** には、キャパシティープロバイダーが使用する VPC を選択します。
1. **[サブネット]** には、エンドポイントネットワークインターフェイスの作成先となるサブネットを選択します。可用性を高めるには、複数のアベイラビリティーゾーンにサブネットを選択します。
1. **[セキュリティグループ]** には、関数のセキュリティグループからのインバウンド HTTPS トラフィック (ポート 443) を許可するセキュリティグループを選択します。
1. エンドポイントで **[プライベート DNS]** を有効にします。
1. **エンドポイントの作成** を選択します。
**オプション 2: インターネットゲートウェイを備えたパブリックサブネット**
キャパシティープロバイダーがパブリックサブネットを使用している場合は、以下を確認してください。
1. インターネットゲートウェイが VPC にアタッチされている
1. ルートテーブルが `0.0.0.0/0` トラフィックをインターネットゲートウェイにルーティングしている
1. セキュリティグループがポート 443 でアウトバウンド HTTPS トラフィックを許可している
**オプション 3: NAT ゲートウェイを使用するプライベートサブネット**
キャパシティープロバイダーがプライベートサブネットを使用している場合は、以下を確認してください。
1. NAT ゲートウェイがパブリックサブネット内に存在している
1. プライベートサブネットのルートテーブルが `0.0.0.0/0` トラフィックを NAT ゲートウェイにルーティングしている
1. パブリックサブネットのルートテーブルが `0.0.0.0/0` トラフィックをインターネットゲートウェイにルーティングしている
1. セキュリティグループがポート 443 でアウトバウンド HTTPS トラフィックを許可している
VPC 接続オプションの詳細については、「[VPC connectivity for Lambda Managed Instances](lambda-managed-instances-networking.md)」を参照してください。
### 同時リクエストからのログの相関付けが困難
**問題:** さまざまなリクエストからのログがインターリーブされるため、個々のリクエストを追跡するのが困難である。
**原因:** ログインターリーブは、複数同時実行システムで想定される標準的な動作です。
**解決策:**
+ **JSON 形式で構造化ログ記録を使用する:** すべてのログステートメントにリクエスト ID を含める
+ **Java:** `ThreadContext` で Log4j を使用してリクエスト ID を自動的に含める
+ **Node.js:** JSON フォーマットで `console.log()` を使用して、`InvokeStore.getRequestId()` を含める
+ **Python:** JSON フォーマットで標準ログ記録モジュールを使用して、`context.request_id` を含める
詳細なガイダンスについては、ランタイム固有のドキュメントページを参照してください。
## 追加のヘルプの取得
これらのソリューションを試した後も問題が続く場合:
1. **CloudWatch メトリクスを確認する:** キャパシティープロバイダーと実行環境メトリクスをチェックして、リソースの制約やスケーリングの問題を特定します。
1. **AWS CloudTrail ログを確認する:** API コールとエラーに関する詳細情報については、CloudTrail ログを確認します。
1. **AWS サポートに問い合わせる:** 問題を解決できない場合は、キャパシティープロバイダーの設定、関数の設定、発生した特定のエラーメッセージの詳細について AWS サポートにお問い合わせください。
## 次のステップ
+ 「[Lambda マネージドインスタンスのキャパシティプロバイダー](lambda-managed-instances-capacity-providers.md)」について説明する
+ 「[Lambda マネージドインスタンスのスケーリング](lambda-managed-instances-scaling.md)」を理解する
+ [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md)、[Python](lambda-managed-instances-python-runtime.md) のランタイム固有のガイドを確認する
+ [CloudWatch メトリクス](lambda-managed-instances-monitoring.md)を使用して Lambda マネージドインスタンスをモニタリングする
+ 「[Lambda マネージドインスタンスのベストプラクティス](lambda-managed-instances-best-practices.md)」を確認する