# Lambda における問題のトラブルシューティング
以下のトピックでは、Lambda API、コンソール、ツールの使用時に発生する可能性のあるエラーや問題のトラブルシューティングに関するアドバイスを提供します。ここに記載されていない問題が見つかった場合は、このページの [**Feedback**] ボタンを使用して報告することができます。
トラブルシューティングに関するアドバイス、およびサポートへの一般的な質問に対する回答については、[AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)にアクセスしてください。
Lambda アプリケーションのデバッグとトラブルシューティングの詳細については、Serverless Land の「[デバッグ](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops)」を参照してください。
**Topics**
+ [Lambda の設定問題のトラブルシューティング](troubleshooting-configuration.md)
+ [Lambda におけるデプロイメントに関する問題のトラブルシューティング](troubleshooting-deployment.md)
+ [Lambda での呼び出しに関する問題のトラブルシューティング](troubleshooting-invocation.md)
+ [Lambda における実行に関する問題点のトラブルシューティング](troubleshooting-execution.md)
+ [Lambda のイベントソースマッピング問題のトラブルシューティング](troubleshooting-event-source-mapping.md)
+ [Lambda でのネットワークに関する問題のトラブルシューティング](troubleshooting-networking.md)
# Lambda の設定問題のトラブルシューティング
関数の設定は、Lambda 関数の全体的なパフォーマンスおよび動作に影響を与える可能性があります。実際の関数エラーを引き起こさない場合がありますが、予期しないタイムアウトや結果を引き起こす可能性があります。
次のトピックでは、Lambda 関数の設定に関連して発生する可能性がある一般的な問題に対するトラブルシューティングのアドバイスが記載されます。
**Topics**
+ [メモリ設定](#memory-config)
+ [CPU バウンド設定](#cpu-bound-config)
+ [タイムアウト](#timeouts)
+ [呼び出し間のメモリリーク](#memory-leakage)
+ [後の呼び出しに返される非同期結果](#asynchronous-results)
## メモリ設定
Lambda 関数は、128 MB から 10,240 MB の間のメモリを使用するよう設定できます。デフォルトでは、コンソールで作成された関数には最小量のメモリが割り当てられます。多くの Lambda 関数は、この最低設定でパフォーマンスが高くなります。ただし、大きなコードライブラリをインポートしたり、メモリを大量に消費するタスクを実行したりする場合、128 MB は十分ではありません。
関数の実行速度が予想よりもはるかに遅い場合、最初のステップはメモリ設定を増やすことです。メモリバウンド関数の場合、これによりボトルネックが解決され、関数のパフォーマンスが向上することがあります。
## CPU バウンド設定
計算負荷の高いオペレーションでは、関数のパフォーマンスが予想よりも遅い場合、関数が CPU バウンドであることが原因である可能性があります。この場合、関数の計算処理能力は作業に追いつくことができません。
Lambda では CPU 設定を直接変更することができませんが、CPU はメモリ設定によって間接的に制御されます。Lambda サービスは、より多くのメモリを割り当てると、比例してより多くの仮想 CPU を割り当てます。1.8 GB のメモリでは、Lambda 関数には 1 つの vCPU 全体が割り当てられ、このレベルを超えると複数の vCPU コアにアクセスします。10,240 MB では、6 つの vCPU を利用できます。言い換えると、関数がすべてのメモリを使用しなくても、メモリ割り当てを増やすことによってパフォーマンスを向上できます。
## タイムアウト
Lambda 関数の[タイムアウト](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html)は 1 と 900 秒 (15 分) の間で設定できます。デフォルトでは、Lambda コンソールでは 3 秒に設定されます。タイムアウト値は、関数が無期限に実行されないようにする安全バルブです。タイムアウト値に達したら、Lambda は関数の呼び出しを停止します。
タイムアウト値が関数の平均期間近くに設定されている場合、このために関数が予期せずタイムアウトするリスクが高まります。関数の期間は、データ転送と処理の量、および関数が相互作用するサービスのレイテンシーによって異なる場合があります。タイムアウトの一般的な原因には、次のようなものがあります。
+ S3 バケットまたは他のデータストアからデータをダウンロードする場合、ダウンロードはサイズが大きくなったり、平均よりも時間がかかったりします。
+ 関数が別のサービスにリクエストを行う場合、応答に時間がかかります。
+ 関数に使用されるパラメータでは、関数の計算が複雑になり、呼び出しに時間がかかります。
アプリケーションをテストする際、テストがデータのサイズおよび量、ならびに実用的なパラメータ値を正確に反映していることを確認してください。重要なのは、ワークロードに合理的に予想される上限でデータセットを使用することです。
さらに、可能な限り、ワークロードに上限を実装してください。この例では、アプリケーションはファイルタイプごとに最大サイズの制限を使用できます。その後、最大の制限値を含む上限まで、予想されるファイルサイズの範囲におけるアプリケーションのパフォーマンスをテストできます。
## 呼び出し間のメモリリーク
Lambda 呼び出しの INIT フェーズに保存されているグローバル変数とオブジェクトは、ウォーム呼び出しの間も状態が保持されます。これらは、実行環境が初めて実行される場合 (「コールドスタート」とも呼ばれます) にのみ、完全にリセットされます。ハンドラーに保存されている変数は、ハンドラーが終了すると破棄されます。INIT フェーズを使用して、データベース接続の設定、ライブラリのロード、キャッシュの作成、変更不可能なアセットのロードを行うのがベストプラクティスです。
同じ実行環境で複数の呼び出しにサードパーティーライブラリを使用する場合、サーバーレスコンピューティング環境での使用に関するドキュメントを確認してください。一部のデータベース接続ライブラリとログ記録ライブラリは、中間呼び出し結果やその他のデータを保存する場合があります。そのため、これらのライブラリのメモリ使用量は、その後のウォーム呼び出しに伴って増加します。この場合、カスタムコードが変数を正しく廃棄しても、Lambda 関数のメモリ不足に直面する場合があります。
この問題は、ウォーム実行環境で発生する呼び出しに影響します。例えば、次のコードは呼び出し間でメモリリークを引き起こします。Lambda 関数は、グローバル配列のサイズを増やすことで、呼び出しごとに追加のメモリを消費します。
```
let a = []
exports.handler = async (event) => {
a.push(Array(100000).fill(1))
}
```
128 MB のメモリを設定してこの関数を 1,000 回呼び出した後、Lambda 関数の **[モニタリング]** タブには、メモリリークが発生したときの呼び出し、期間、エラー数の一般的な変化が表示されます。
![\[デバッグオペレーションの図 4\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-4.png)
1. **呼び出し** - 呼び出しの完了に時間がかかると、安定したトランザクションレートが定期的に中断されます。定常状態では、メモリリークが関数に割り当てられたメモリの全部を消費しているわけではありません。パフォーマンスが低下すると、オペレーティングシステムはローカルストレージをページングして関数に必要なメモリの増加に対応しているため、完了するトランザクションは少なくなります。
1. **期間** - 関数がメモリ不足になる前に、2 桁のミリ秒による一定の速度で呼び出しを終了します。ページングが発生すると、期間は桁違いに長くなります。
1. **エラー数** - メモリリークが割り当てられたメモリを超えると、最終的に計算がタイムアウトを超えた原因で関数がエラーを返すか、実行環境が関数を停止します。
エラーの後、Lambda は実行環境を再起動します。3 つすべてのグラフで元の状態に戻る理由が説明されます。CloudWatch メトリクスの期間を延長すると、最小、最大、平均の期間統計の詳細が表示されます。
![\[デバッグオペレーションの図 5\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-5.png)
1,000 回の呼び出しで生成されたエラーを見つけるには、CloudWatch Insights のクエリ言語を使用できます。次のクエリでは、エラーのみをレポートするため、情報ログが含まれません。
```
fields @timestamp, @message
| sort @timestamp desc
| filter @message not like 'EXTENSION'
| filter @message not like 'Lambda Insights'
| filter @message not like 'INFO'
| filter @message not like 'REPORT'
| filter @message not like 'END'
| filter @message not like 'START'
```
この関数のロググループに対して実行すると、次のように、タイムアウトが定期的なエラーの原因であったことがわかります。
![\[デバッグオペレーションの図 6\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-6.png)
## 後の呼び出しに返される非同期結果
非同期パターンを使用する関数コードの場合、1 回の呼び出しからのコールバック結果が将来の呼び出しで返される可能性があります。この例では Node.js を使用していますが、非同期パターンを使用するその他のランタイムにも同じロジックを適用できます。この関数は、JavaScript の従来のコールバック構文を使用します。呼び出し数を追跡する増分カウンターを使用して非同期関数を呼び出します。
```
let seqId = 0
exports.handler = async (event, context) => {
console.log(`Starting: sequence Id=${++seqId}`)
doWork(seqId, function(id) {
console.log(`Work done: sequence Id=${id}`)
})
}
function doWork(id, callback) {
setTimeout(() => callback(id), 3000)
}
```
連続で数回呼び出されると、コールバックの結果はその後の呼び出しで発生します。
![\[デバッグオペレーションの図 7\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-7.png)
1. このコードは `doWork` 関数を呼び出し、最後のパラメータとしてコールバック関数を提供します。
1. `doWork` 関数は、コールバックを呼び出す前に完了するまでしばらく時間がかかります。
1. 関数のログ記録は、`doWork` 関数の実行が終了する前に呼び出しが終了することを示しています。また、イテレーションを開始した後、ログに示すように、以前のイテレーションからのコールバックが処理されています。
JavaScript では、非同期コールバックは[イベントループ](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)で処理されます。他のランタイムは、同時実行を処理するために異なるメカニズムを使用します。関数の実行環境が終了すると、Lambda は次の呼び出しまで環境をフリーズします。再開後、JavaScript はイベントループの処理を続行します。この場合、以前の呼び出しの非同期コールバックが含まれます。このコンテキストがないと、関数が理由なしにコードを実行し、任意データを返しているように見えます。実際には、これはランタイムの同時実行と実行環境が相互作用する仕組みを示すアーティファクトです。
これにより、以前の呼び出しのプライベートデータが後続の呼び出しに表示される可能性が生じています。この動作を防止または検出するには、2 つの方法があります。まず、JavaScript には、非同期開発を簡素化し、非同期呼び出しが完了するまで強制的にコード実行を待機させるために、[async および await キーワード](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function)が提供されています。上記の関数は、このアプローチを使用して次のように書き直すことができます。
```
let seqId = 0
exports.handler = async (event) => {
console.log(`Starting: sequence Id=${++seqId}`)
const result = await doWork(seqId)
console.log(`Work done: sequence Id=${result}`)
}
function doWork(id) {
return new Promise(resolve => {
setTimeout(() => resolve(id), 4000)
})
}
```
この構文を使用すると、非同期関数が終了する前にハンドラーが終了しないようにすることができます。このケースで、コールバックに Lambda 関数のタイムアウトよりも長い時間がかかる場合、関数は後の呼び出しでコールバック結果を返す代わりに、エラーをスローします。
![\[デバッグオペレーションの図 8\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-8.png)
1. このコードは、ハンドラーで await キーワードを使用して非同期 `doWork` 関数を呼び出します。
1. `doWork` 関数は、約束を解決する前に完了するまでしばらく時間がかかります。
1. `doWork` はタイムアウト制限で許可されている時間よりも長くかかり、コールバック結果が後の呼び出しで返されないため、関数はタイムアウトします。
一般的に、コードのバックグラウンド処理またはコールバックは、コード終了までに完了させる必要があります。ユースケースでこれが不可能な場合は、識別子を使用して、コールバックが現在の呼び出しに属すようにすることができます。これを行うには、context オブジェクトによって提供される *awsRequestId* を使用できます。この値を非同期コールバックに渡すことで、渡された値と現在の値を比較して、コールバックが別の呼び出しから発生したのかどうかを検出することができます。
```
let currentContext
exports.handler = async (event, context) => {
console.log(`Starting: request id=$\{context.awsRequestId}`)
currentContext = context
doWork(context.awsRequestId, function(id) {
if (id != currentContext.awsRequestId) {
console.info(`This callback is from another invocation.`)
}
})
}
function doWork(id, callback) {
setTimeout(() => callback(id), 3000)
}
```
![\[デバッグオペレーションの図 9\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-9.png)
1. Lambda 関数ハンドラーは、一意の呼び出しリクエスト ID へのアクセスを提供する context パラメータを受け取ります。
1. `awsRequestId` が doWork 関数に渡されます。コールバックでは、ID が現在の呼び出しの `awsRequestId` と比較されます。これらの値が異なる場合、コードでそれに応じたアクションを実行できます。
# Lambda におけるデプロイメントに関する問題のトラブルシューティング
関数を更新すると、Lambda は、関数の新しいインスタンスを起動してコードや設定の更新を反映することで、その変更をデプロイします。デプロイエラーが発生すると、新しいバージョンは使用できなくなります。デプロイエラーは、デプロイパッケージ、コード、アクセス許可、またはツールに関する問題が原因で発生する場合があります。
Lambda API を使用するか、AWS CLI などのクライアントを使用して関数に更新を直接デプロイした場合、エラーは Lambda の出力に直接表示されます。AWS CloudFormation、AWS CodeDeploy、AWS CodePipeline などのサービスを使用した場合は、該当サービスのログまたはイベントストリームで Lambda からのレスポンスを探します。
以下のトピックでは、Lambda API、コンソール、ツールの使用時に発生する可能性のあるエラーや問題のトラブルシューティングに関するアドバイスを提供します。ここに記載されていない問題が見つかった場合は、このページの [**Feedback**] ボタンを使用して報告することができます。
トラブルシューティングに関するアドバイス、およびサポートへの一般的な質問に対する回答については、[AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)にアクセスしてください。
Lambda アプリケーションのデバッグとトラブルシューティングの詳細については、Serverless Land の「[デバッグ](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops)」を参照してください。
**Topics**
+ [一般: アクセス権限が拒否されました/該当のファイルをロードできません](#troubleshooting-deployment-denied)
+ [一般: UpdateFunctionCode を呼び出すときにエラーが発生しました](#troubleshooting-deployment-updatefunctioncode)
+ [Amazon S3: エラーコード PermanentRedirect。](#troubleshooting-deployment-PermanentRedirect)
+ [一般: 見つかりません、ロードできません、インポートできません、クラスが見つかりません、該当のファイルまたはディレクトリがありません](#troubleshooting-deployment-functionHandler1)
+ [一般: 未定義のメソッドハンドラー](#troubleshooting-deployment-functionHandler2)
+ [一般: Lambda コードストレージの制限を超えました](#troubleshooting-deployment-CodeStorageExceeded)
+ [Lambda: レイヤー変換が失敗しました](#troubleshooting-deployment-LayerConversionFailed)
+ [Lambda: InvalidParameterValueException または RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1)
+ [Lambda: InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2)
+ [Lambda: 同時実行とメモリのクォータ](#troubleshooting-deployment-quotas)
+ [Lambda: プロビジョニングされた同時実行に対する無効なエイリアス設定](#troubleshooting-deployment-provisioned-concurrency)
## 一般: アクセス権限が拒否されました/該当のファイルをロードできません
**エラー:** EACCES: アクセス許可が拒否されました。'/var/task/index.js' を開きます。
**エラー:** そのようなファイルはロードできません -- 関数
**エラー:** [Errno 13] アクセス許可が拒否されました: '/var/task/function.py'
Lambda ランタイムには、デプロイパッケージ内のファイルを読み取るアクセス許可が必要です。Linux のアクセス権限の 8 進表記では、Lambda には非実行ファイル用に 644 のアクセス権限 (rw-r--r--) が必要であり、ディレクトリと実行可能ファイル用に 755 のアクセス権限 (rwxr-xr-x) が必要です。
Linux と MacOS で、デプロイパッケージ内のファイルやディレクトリのファイルアクセス権限を変更するには、`chmod` コマンドを使用します。例えば、実行可能でないファイルに正しいアクセス許可を付与するには、次のコマンドを実行します。
```
chmod 644
```
Windows でファイルアクセス許可を変更するには、「Microsoft Windows ドキュメント」の「[Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10))」を参照してください。
**注記**
デプロイパッケージのディレクトリにアクセスするために必要なアクセス許可を Lambda に付与しない場合、Lambda はそれらのディレクトリのアクセス許可を 755 (rwxr-xr-x) に設定します。
## 一般: UpdateFunctionCode を呼び出すときにエラーが発生しました
**エラー:** UpdateFunctionCode オペレーションを呼び出すときにエラーが発生しました (RequestEntityTooLargeException)
デプロイパッケージまたはレイヤーアーカイブを Lambda に直接アップロードする場合、ZIP ファイルのサイズは 50 MB に制限されます。これよりも大きなファイルをアップロードするには、Amazon S3 に保存し、S3Bucket と S3Key のパラメータを使用します。
**注記**
AWS CLI、AWS SDK などを使用してファイルを直接アップロードすると、バイナリ ZIP ファイルは base64 に変換され、サイズが約 30％ 増加します。この点と、リクエスト内の他のパラメータのサイズを考慮して、Lambda で実際に適用されるリクエストサイズの制限はより大きくなります。このため、50 MB の制限は概算です。
## Amazon S3: エラーコード PermanentRedirect。
**エラー:** *GetObject 中にエラーが発生しました。S3 エラーコード: PermanentRedirect。S3 エラーメッセージ: バケットはリージョン us-east-2 にあります。このリージョンを使用してリクエストを再試行してください*
Amazon S3 バケットから関数のデプロイパッケージをアップロードする場合、そのバケットは関数と同じリージョンに存在する必要があります。この問題は、[UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) の呼び出しで Amazon S3 オブジェクトを指定するか、AWS CLI または AWS SAM CLI でパッケージとデプロイコマンドを使用する場合に発生する可能性があります。アプリケーションを開発するリージョンごとにデプロイアーティファクトバケットを作成してください。
## 一般: 見つかりません、ロードできません、インポートできません、クラスが見つかりません、該当のファイルまたはディレクトリがありません
**エラー:** モジュール 'function' が見つかりません
**エラー:** そのようなファイルはロードできません -- 関数
**エラー:** モジュール 'function' をインポートできません
**エラー:** *クラスが見つかりません: function.Handler*
**エラー:** fork/exec /var/task/function: そのようなファイルやディレクトリはありません
**エラー:** アセンブリ 'Function' から型 'Function.Handler' をロードできません。
関数のハンドラー設定のファイルまたはクラスの名前がコードと一致しません。詳細については、次の「」セクションを参照してください。
## 一般: 未定義のメソッドハンドラー
**エラー:** *index.handler が定義されていないか、エクスポートされていません*
**エラー:** *モジュール 'function' にハンドラー 'handler’ がありません*
**エラー:** *\$1 の未定義のメソッド 'handler'*
**エラー:** *適切なメソッドの署名の付いた handleRequest という名前のパブリックメソッドがクラス function.Handler で見つかりません*
**エラー:** *アセンブリ 'Function' に型 'Function.Handler' のメソッド 'handleRequest' が見つかりません*
関数のハンドラー設定のハンドラーメソッドの名前がコードと一致しません。各ランタイムはハンドラーの命名規則を定義します (*filename*.*methodname* など)。ハンドラーは、関数を呼び出したときにランタイムで実行される、関数のコード内のメソッドです。
一部の言語の場合、Lambda は、ハンドラーメソッドに特定の名前があることを期待するインターフェイスを持つライブラリを提供します。言語別のハンドラーの命名の詳細については、以下のトピックを参照してください。
+ [Node.js による Lambda 関数の構築](lambda-nodejs.md)
+ [Python による Lambda 関数の構築](lambda-python.md)
+ [Ruby による Lambda 関数の構築](lambda-ruby.md)
+ [Java による Lambda 関数の構築](lambda-java.md)
+ [Go による Lambda 関数の構築](lambda-golang.md)
+ [C\$1 による Lambda 関数の構築](lambda-csharp.md)
+ [PowerShell による Lambda 関数の構築](lambda-powershell.md)
## 一般: Lambda コードストレージの制限を超えました
**エラー:** *コードストレージの制限を超えました。*
Lambda は、アカウント専用の内部 S3 バケットに関数コードを保存します。各 AWS アカウントには、各リージョンに 75 GB のストレージが割り当てられます。コードストレージには、Lambda の関数とレイヤーの両方で使用されるストレージの合計が含まれます。クォータに達すると、新しい関数をデプロイしようとしたときに *CodeStorageExceededException* を受け取ります。
関数の古いバージョンのクリーンアップ、未使用のコードの削除、Lambda レイヤーの使用により、利用可能なストレージ領域を管理します。さらに、ストレージクォータの管理を実現するため、[個別のワークロードに個別の AWS アカウントを使用する](concepts-application-design.md#multiple-accounts)ことをお勧めします。
**[ダッシュボード]** サブメニューで、Lambda コンソールのストレージの合計使用量を確認できます。
![\[モニタリングとオブザーバビリティの図 26\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-26.png)
## Lambda: レイヤー変換が失敗しました
**エラー:** *Lambda レイヤー変換が失敗しました。この問題を解決するための情報については、Lambda ユーザーガイドの「Lambda でのデプロイ問題のトラブルシューティング」ページを参照してください。*
Lambda 関数をレイヤーで設定すると、Lambda はそのレイヤーを関数コードでマージします。このプロセスが完了しない場合は、Lambda はこのエラーを返します。このエラーが発生した場合は、次の手順を実行します。
+ レイヤーから未使用のファイルをすべて削除する
+ レイヤー内のシンボリックリンクをすべて削除する
+ 関数のいずれかのレイヤーにあるディレクトリと同じ名前のファイルの名前を変更する
## Lambda: InvalidParameterValueException または RequestEntityTooLargeException
**エラー:** InvalidParameterValueException: 指定した環境変数が 4 KB の上限を超えているため、Lambda は環境変数を設定できませんでした。測定された文字列: \$1"A1":"uSFeY5cyPiPn7AtnX5BsM..。
**エラー:** *RequestEntityTooLargeException: UpdateFunctionConfiguration オペレーションに対するリクエストは 5120 バイト未満にする必要があります。*
関数の設定に保存される変数オブジェクトの最大サイズが 4096 バイトを超えないようにしてください。これには、キー名、値、引用符、カンマ、括弧が含まれます。HTTP リクエストボディの合計サイズも制限されます。
```
{
"FunctionName": "my-function",
"FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
"Runtime": "nodejs24.x",
"Role": "arn:aws:iam::123456789012:role/lambda-role",
"Environment": {
"Variables": {
"BUCKET": "amzn-s3-demo-bucket",
"KEY": "file.txt"
}
},
...
}
```
この例で、オブジェクトは 39 文字です。これを文字列 `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}` として保存すると (空白を含まない)、39 バイトになります。環境変数の標準 ASCII 文字は、文字ごとに 1 バイトの値となります。拡張 ASCII 文字と Unicode 文字は、文字ごとに 2～4 バイトを使用する場合があります。
## Lambda: InvalidParameterValueException
**エラー:** *InvalidParameterValueException: 指定した環境変数に含まれている予約キーは、現在、変更がサポートされていないため、Lambda は環境変数を設定できませんでした。*
Lambda は、内部使用のためにいくつかの環境変数キーを予約します。たとえば、`AWS_REGION` は現在のリージョンを確認するためにランタイムによって使用される変数で、オーバーライドすることはできません。`PATH` などの他の変数は、ランタイムによって使用されますが、関数設定で拡張できます。詳細なリストについては、「[定義されたランタイム環境変数](configuration-envvars.md#configuration-envvars-runtime)」を参照してください
## Lambda: 同時実行とメモリのクォータ
**エラー:** 関数に指定された ConcurrentExecutions は、アカウントの UnreservedConcurrentExecution を最小値未満に減らします
**エラー:** 「メモリサイズ」 値は制約を満たすことに失敗しました: メンバーは 3008 以下の値を持つ必要があります
これらのエラーは、アカウントの同時実行数またはメモリの[クォータ](gettingstarted-limits.md)を超えると発生します。新しい AWS アカウントでは、同時実行とメモリのクォータが少なくなっています。同時実行に関連するエラーを解決するには、[クォータの引き上げをリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)できます。メモリクォータの引き上げはリクエストできません。
+ **同時実行数:** 予約済みまたはプロビジョニングされた同時実行数を使用して関数を作成、あるいは関数ごとの同時実行の要求 ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) がアカウントの同時実行クォータを超えた場合、エラーが発生します。
+ **メモリ:** 関数に割り当てられたメモリの量がアカウントのメモリクォータを超えた場合、エラーが発生します。
## Lambda: プロビジョニングされた同時実行に対する無効なエイリアス設定
**エラー:*** プロビジョニングされた同時実行に対する無効なエイリアス設定*
このエラーは、プロビジョニングされた同時実行を伴うエイリアスが問題のあるバージョンをポイントしているときに Lambda 関数のコードまたは設定の更新を試みると発生します。Lambda はプロビジョニングされた同時実行の実行環境を事前に初期化しますが、コードエラー、リソース制約、または対象のスタックやエイリアスが原因でこれらの環境を適切に初期化できない場合は、デプロイが失敗します。この問題が発生した場合は、次の手順を実行します。
1. **エイリアスをロールバックする:** これまで機能していたバージョンをポイントするように、エイリアスを一時的に更新します。
```
aws lambda update-alias \
--function-name \
--name \
--function-version
```
1. **Lambda 初期化コードを修正する:** ハンドラー外で実行される初期化コードに未検出の例外がないことを確認し、クライアントと接続を初期化します。
1. **安全に再デプロイする:** 修正されたコードをデプロイし、新しいバージョンを発行します。次に、修正されたバージョンをポイントするようにエイリアスを更新します。必要な場合は、オプションで[プロビジョニングされた同時実行](provisioned-concurrency.md)を再度有効にします。
AWS CloudFormation を使用する場合は、エイリアスが機能しているバージョンをポイントするように、スタック定義 `FunctionVersion:!GetAtt version.Version` を更新します。
```
alias:
Type: AWS::Lambda::Alias
Properties:
FunctionName: !Ref function
FunctionVersion: !GetAtt version.Version
Name: BLUE
ProvisionedConcurrencyConfig:
ProvisionedConcurrentExecutions: 1
```
# Lambda での呼び出しに関する問題のトラブルシューティング
Lambda 関数を呼び出すと、Lambda はリクエストを検証し、イベントを関数 (非同期呼び出しの場合はイベントキュー) に送信する前にスケーリングキャパシティーをチェックします。呼び出しエラーは、リクエストのパラメータ、イベント構造、関数の設定、ユーザーのアクセス許可、リソースに対するアクセス許可、または制限に関する問題が原因で発生する場合があります。
関数を直接呼び出した場合は、Lambda からのレスポンスに呼び出しエラーが表示されます。イベントソースマッピングまたは別のサービスを通じて関数を非同期的に呼び出した場合は、ログ、デッドレターキュー、または失敗イベントの送信先にエラーが表示されることがあります。エラー処理オプションと再試行の動作は、関数を呼び出した方法とエラーの種類によって異なります。
`Invoke` オペレーションが返す可能性のあるエラータイプのリストについては、[呼び出し](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) を参照してください。
**Topics**
+ [Lambda: 初期化フェーズ中に関数がタイムアウトします (Sandbox.Timedout)](#troubleshooting-timeouts)
+ [IAM: lambda:InvokeFunction は許可されていません](#troubleshooting-invocation-noauth)
+ [Lambda: 有効なブートストラップ (Runtime.InvalidEntrypoint) が見つかりませんでした](#troubleshooting-invocation-bootstrap)
+ [Lambda: オペレーションは ResourceConflictException を実行できません](#troubleshooting-invocation-ResourceConflictException)
+ [Lambda: 関数が Pending のままとなっています](#troubleshooting-invocation-pending)
+ [Lambda: 1 つの関数がすべての同時実行を使用しています](#troubleshooting-invocation-allconcurrency)
+ [一般: 他のアカウントまたはサービスで関数を呼び出すことはできません](#troubleshooting-invocation-cannotinvoke)
+ [一般: 関数の呼び出しはループしています](#troubleshooting-invocation-loop)
+ [Lambda: プロビジョニングされた同時実行によるエイリアスルーティング](#troubleshooting-invocation-alias)
+ [Lambda: プロビジョニングされた同時実行によるコールドスタートします](#troubleshooting-invocation-coldstart)
+ [Lambda: 新しいバージョンによるコールドスタート](#troubleshooting-invocation-newversion)
+ [Lambda: ランタイムでの予期しない Node.js の終了 (Runtime.NodejsExit)](#troubleshooting-invocation-nodejs-exit)
+ [EFS: 関数は EFS ファイルシステムをマウントできませんでした](#troubleshooting-invocation-efsmount)
+ [EFS: 関数は EFS ファイルシステムに接続できませんでした](#troubleshooting-invocation-efsconnect)
+ [EFS: タイムアウトのため、関数が EFS ファイルシステムをマウントできませんでした](#troubleshooting-invocation-efstimeout)
+ [Lambda: Lambda は時間がかかり過ぎている IO プロセスを検出しました](#troubleshooting-invocation-ioprocess)
+ [コンテナ: CodeArtifactUserException エラー](#troubleshooting-deployment-container-artifact)
+ [コンテナ: InvalidEntrypoint エラー](#troubleshooting-deployment-container-entrypoint)
## Lambda: 初期化フェーズ中に関数がタイムアウトします (Sandbox.Timedout)
**エラー:** *Task timed out after 3.00 seconds*
[初期化](lambda-runtime-environment.md#runtimes-lifecycle-ib)フェーズがタイムアウトすると、Lambda は、次の呼び出しリクエストが到着したときに `Init` フェーズを再実行することで、実行環境を再度初期化します。これは、[抑制された初期化](lambda-runtime-environment.md#suppressed-init)と呼ばれます。ただし、関数に短い[タイムアウト時間](configuration-timeout.md) (通常は 3 秒程度) が設定されている場合、割り当てられたタイムアウト時間中に抑制された初期化が完了せず、`Init` フェーズが再びタイムアウトすることがあります。また、抑制された初期化は完了しても、[呼び出し](lambda-runtime-environment.md#runtimes-lifecycle-invoke)フェーズが完了するまでの十分な時間が残らないために、`Invoke` フェーズがタイムアウトします。
タイムアウトエラーを減らすには、以下のうち 1 つ以上の方法を使用します。
+ **関数のタイムアウト時間を延長する**: [タイムアウト](configuration-timeout.md)を延長して、`Init` フェーズと `Invoke` フェーズが正常に完了する時間を与えます。
+ **関数メモリ割り当てを増やす**: [メモリ](configuration-memory.md)を増やすと、比例して CPU 割り当ても増加するため、`Init` フェーズと `Invoke` フェーズの両方を高速化できます。
+ **関数の初期化コードを最適化する**: 初期化に必要な時間を短縮して、設定されたタイムアウト時間内に `Init` フェーズと `Invoke` フェーズを完了できるようにします。
## IAM: lambda:InvokeFunction は許可されていません
**エラー:** *ユーザー (arn:aws:iam::123456789012:user/developer) によるリソース (my-function) に対する lambda:InvokeFunction の実行は許可されていません*
ユーザー、または引き受けるロールには、関数を呼び出すための許可が必要です。この要件は、Lambda 関数、および関数を呼び出す他のコンピューティングリソースにも適用されます。AWS マネージドポリシーである **AWSLambdaRole** をユーザーに追加するか、ターゲット関数での `lambda:InvokeFunction` アクションを許可するカスタムポリシーを追加します。
**注記**
IAM アクションの名前 (`lambda:InvokeFunction`) は、`Invoke` Lambda API オペレーションを示しています。
詳細については、「[AWS Lambda アクセス許可の管理](lambda-permissions.md)」を参照してください。
## Lambda: 有効なブートストラップ (Runtime.InvalidEntrypoint) が見つかりませんでした
**エラー:** *有効なブートストラップが見つかりませんでした: [/var/task/bootstrap /opt/bootstrap]*
このエラーは通常、デプロイパッケージのルートに `bootstrap` という名前の実行ファイルが含まれていない場合に発生します。例えば、.zip ファイルを使用して `provided.al2023` 関数をデプロイする場合、`bootstrap` ファイルは .zip ファイルのディレクトリ内ではなく、ルートにある必要があります。
## Lambda: オペレーションは ResourceConflictException を実行できません
**エラー**: *ResourceConflictException: 今回はオペレーションを実行できません。現在、この関数は次の状態にあります: 保留中*
関数の作成時に Virtual Private Cloud (VPC) に接続すると、Lambda が Elastic Network Interface を作成するまでの間、関数は `Pending` 状態になります。この間は、関数を呼び出したり変更したりすることはできません。関数の作成後に VPC に接続すると、更新が保留中である間に関数を呼び出すことができます。ただし、そのコードや設定を変更することはできません。
詳細については、「[Lambda 関数の状態](functions-states.md)」を参照してください。
## Lambda: 関数が Pending のままとなっています
**エラー:** *関数が数分間 `Pending` 状態で止まっている。*
関数が 6 分を超えて `Pending` 状態で止まっている場合は、以下のいずれかの API オペレーションを呼び出して、ブロックを解除します。
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)
Lambda は保留中のオペレーションをキャンセルし、関数を `Failed` 状態に移します。その後、再度更新を試みることができます。
## Lambda: 1 つの関数がすべての同時実行を使用しています
**問題:** *1 つの関数がすべての利用可能な同時実行を使用しているため、他の関数がスロットリングされる。*
AWS リージョンで AWS アカウントで使用可能な同時実行をプールに分割するには、[予約済みの同時実行](configuration-concurrency.md)を使用します。予約同時実行により、関数は常に割り当てられた同時実行にスケールでき、割り当てられた同時実行を超えることはありません。
## 一般: 他のアカウントまたはサービスで関数を呼び出すことはできません
**問題:** *関数を直接呼び出すことはできるが、別のサービスやアカウントから呼び出すと関数が実行されない。*
[他のサービス](lambda-services.md)やアカウントから関数を呼び出すためのアクセス許可を、関数の[リソースベースのポリシー](access-control-resource-based.md)で付与します。別のアカウントから呼び出す場合、そのアカウントのユーザーにも[関数を呼び出すためのアクセス権限](access-control-identity-based.md)が必要です。
## 一般: 関数の呼び出しはループしています
**問題:** *関数がループ内で連続して呼び出される。*
これは、通常、関数が管理するリソースが、この関数をトリガーするのと同じ AWS のサービス内にある場合に発生します。例えば、Amazon Simple Storage Service (Amazon S3)バケットにオブジェクトを保存する関数を作成した場合、このバケットに[この関数を再度呼び出す通知](with-s3.md)が設定されていることがあります。関数の実行を停止するには、使用可能な[同時実行数](lambda-concurrency.md)を 0 に設定することで、以降の呼び出しがすべてスロットリングされます。その後、再帰呼び出しの原因となったコードパスまたは設定エラーを特定します。Lambda は、一部の AWS サービスおよび SDK の再帰ループを自動的に検出して停止します。詳細については、「[Lambda 再帰ループ検出を使用した無限ループの防止](invocation-recursion.md)」を参照してください。
## Lambda: プロビジョニングされた同時実行によるエイリアスルーティング
**問題:** *エイリアスのルーティング中の、プロビジョニングされた同時実行の Spillover Invocations。*
Lambda は、単純な確率モデルを使用して 2 つの関数バージョン間でトラフィックを分散します。低いトラフィックレベルでは、各バージョンで設定されたトラフィックの割合と実際の割合の間に大きな差異が生じる場合があります。関数がプロビジョニングされた同時実行を使用する場合、エイリアスルーティングがアクティブである間に、プロビジョニングされた同時実行インスタンスの数を高く設定することで、[過剰呼び出し](monitoring-metrics-types.md#invocation-metrics)を防ぐことができます。
## Lambda: プロビジョニングされた同時実行によるコールドスタートします
**問題:** *プロビジョニングされた同時実行を有効した後に、コールドスタートが発生します。*
関数での同時実行の数が、[プロビジョニングされた同時実行の設定済みレベル](provisioned-concurrency.md)以下の場合、コールドスタートは発生しないはずです。プロビジョニングされた同時実行が正常に動作しているかどうかを確認するには、次の手順を実行します。
+ 関数バージョンまたはエイリアスで[プロビジョニングされた同時実行が有効になっていること](provisioned-concurrency.md)を確認してください。
**注記**
プロビジョニング済み同時実行数は、未公開[バージョンの関数](configuration-versions.md) (\$1LATEST) では設定可能ではありません。
+ トリガーで正しい関数バージョンまたはエイリアスが呼び出されることを確認します。例えば、Amazon API Gateway を使用している場合は、API Gateway が、\$1LATEST ではなく、プロビジョニングされた同時実行で関数バージョンまたはエイリアスを呼び出すことを確認します。プロビジョニングされた同時実行が使用されていることを確認するには、[ProvisionedConcurrencyInvocations Amazon CloudWatch メトリクス](monitoring-concurrency.md#provisioned-concurrency-metrics)を確認します。ゼロ以外の値は、関数が初期化された実行環境で呼び出しを処理していることを示します。
+ [ProvisionedConcurrencySpilloverInvocations CloudWatch メトリクス](monitoring-concurrency.md#provisioned-concurrency-metrics)をチェックして、関数の同時実行がプロビジョニングされた同時実行の設定済みレベルを超えているかどうかを判別します。ゼロ以外の値は、プロビジョニングされたすべての同時実行が使用中であり、いくつかの呼び出しがコールドスタートで発生したことを示します。
+ [呼び出し頻度](gettingstarted-limits.md#api-requests) (1 秒あたりのリクエスト数) をご確認ください。プロビジョニングされた同時実行を持つ関数の最大レートは、プロビジョニングされた同時実行ごとに 1 秒あたり 10 件のリクエストです。例えば、100 のプロビジョニングされた同時実行で設定された関数は、1 秒あたり 1,000 件のリクエストを処理できます。呼び出し速度が 1 秒あたり 1,000 件のリクエストを超えると、コールドスタートがいくつか発生する可能性があります。
## Lambda: 新しいバージョンによるコールドスタート
**問題:** *関数の新しいバージョンのデプロイ中にコールドスタートが発生します。*
関数エイリアスを更新すると、Lambda は、エイリアスで設定された重みに基づいて、プロビジョニングされた同時実行を新しいバージョンに自動的にシフトします。
**エラー:** *KMSDisabledException: 使用されている KMS キーが無効になっているため、Lambda は環境変数を復号できませんでした。関数の KMS キー設定を確認してください。*
このエラーは、AWS Key Management Service (AWS KMS) キーが無効になっている場合、またはキーの使用を Lambda に許可する付与が取り消された場合に発生します。許可がない場合は、別のキーを使用するように関数を設定します。その後、カスタムキーを再割り当てして許可を再作成します。
## Lambda: ランタイムでの予期しない Node.js の終了 (Runtime.NodejsExit)
**問題:** *Lambda ランタイムクライアントが予期しない Node.js 終了コードを検出しました。*
このエラーは、コードのバグなどにより、すべての Promise が解決される前に関数が終了した場合に発生します。また、Node.js が Promise の解決を妨げるデッドロックを検出したときにも発生する可能性があります。このエラーは、コールバックスタイルのハンドラーではなく、非同期スタイルのハンドラーのみに影響します。
**影響を受けるランタイム:** Node.js 18 以降。
**この問題を解決するには:**
1. 関数コードで、非同期ハンドラーの未解決の promise を確認します。
1. 関数が完了する前に、すべての promise が適切に解決 (解決または拒否) されていることを確認します。
1. 非同期オペレーションで潜在的な競合状態がないかコードを確認します。
Node.js の終了コードとプロセスの終了の詳細については、「[Node.js ドキュメント](https://nodejs.org/docs/latest/api/process.html#exit-codes)」を参照してください。
## EFS: 関数は EFS ファイルシステムをマウントできませんでした
**エラー:** *EFSMountFailureException: この関数は、アクセスポイント arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd に EFS ファイルシステムをマウントできませんでした。*
関数の[ファイルシステム](configuration-filesystem.md)へのマウントリクエストが拒否されました。関数のアクセス許可を確認し、そのファイルシステムとアクセスポイントが存在していて使用できる状態であることを確認します。
## EFS: 関数は EFS ファイルシステムに接続できませんでした
**エラー:** *EFSMountConnectivityException: この関数は、アクセスポイント arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd で Amazon EFS ファイルポイントに接続できませんでした。ネットワーク設定を確認して、もう一度試してください。*
関数は、NFS プロトコル (TCP ポート 2049) を使用して関数の[ファイルシステム](configuration-filesystem.md)への接続を確立できませんでした。VPC のサブネットの[セキュリティグループとルーティング設定](https://docs.aws.amazon.com/efs/latest/ug/network-access.html)を確認します。
関数の VPC 設定を更新した後にこれらのエラーが発生した場合は、ファイルシステムのアンマウントと再マウントを試してください。
## EFS: タイムアウトのため、関数が EFS ファイルシステムをマウントできませんでした
**エラー:** *EFSMountTimeoutException: この関数は、マウントのタイムアウトのため、アクセスポイント \$1arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd\$1 に EFS ファイルシステムをマウントできませんでした。*
関数は、その[ファイルシステム](configuration-filesystem.md)に接続できましたが、マウントオペレーションがタイムアウトしました。しばらくしてから再試行し、関数の[同時実行数](configuration-concurrency.md)を制限して、ファイルシステムの負荷を軽減することを検討してください。
## Lambda: Lambda は時間がかかり過ぎている IO プロセスを検出しました
EFSIOException: 時間がかかりすぎている IO プロセスを Lambda が検出したため、この関数インスタンスは停止されました。
以前の呼び出しがタイムアウトし、Lambda が関数ハンドラーを終了できませんでした。この問題は、接続されたファイルシステムがバーストクレジットを使い果たし、ベースラインスループットが不十分な場合に発生することがあります。スループットを高めるには、ファイルシステムのサイズを増やすか、プロビジョニングされたスループットを使用します。
## コンテナ: CodeArtifactUserException エラー
**エラー:** *CodeArtifactUserPendingException エラーメッセージ*
CodeArtifact は最適化を保留しています。Lambda が最適化を完了すると、この関数は[アクティブ状態](functions-states.md)に移行します。HTTP レスポンスコード 409。
**エラー:** *CodeArtifactUserDeletedException エラーメッセージ*
CodeArtifact は削除されるようスケジュールされています。HTTP レスポンスコード 409。
**エラー:** *CodeArtifactUserFailedException エラーメッセージ*
Lambda はコードの最適化に失敗しました。コードを修正してもう一度アップロードする必要があります。HTTP レスポンスコード 409。
## コンテナ: InvalidEntrypoint エラー
**エラー:** *Runtime.ExitError または "errorType": "Runtime.InvalidEntrypoint"*
コンテナーイメージの ENTRYPOINT に、位置として絶対パスが含まれていることを確認します。また、イメージに ENTRYPOINT としてシンボリックリンクが含まれていないことを確認します。
**エラー: ** * CloudFormationテンプレートを使用していて、コンテナ ENTRYPOINT が NULL または空の値でオーバーライドされています。*
CloudFormation テンプレートの [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html) リソースを確認します。テンプレートで`ImageConfig`リソースを宣言する場合は、3 つのプロパティすべてに空でない値を指定する必要があります。
# Lambda における実行に関する問題点のトラブルシューティング
Lambda ランタイムが関数コードを実行すると、このイベントは、すでに他のイベントを処理中の関数のインスタンスで処理されるか、必要に応じて新しいインスタンスが初期化されます。関数が初期化されている間に、ハンドラーコードでイベントが処理されているときに、または関数からレスポンスが返される (または返されない) ときに、エラーが発生する場合があります。
関数の実行エラーは、コード、関数の設定、ダウンストリームのリソース、またはアクセス許可の問題に起因する場合があります。関数を直接呼び出した場合は、Lambda からのレスポンスに関数エラーが表示されます。イベントソースマッピングまたは別のサービスを通じて関数を非同期的に呼び出した場合は、ログ、配信不能キュー、または障害発生時の送信先にエラーが表示されることがあります。エラー処理オプションと再試行の動作は、関数を呼び出した方法とエラーの種類によって異なります。
関数コードまたは Lambda ランタイムからエラーが返された場合、Lambda からのレスポンスのステータスコードは 200 OK です。レスポンス内にエラーが存在することは、`X-Amz-Function-Error` という名前のヘッダーで示されます。400 および 500 シリーズのステータスコードは、[呼び出しエラー](troubleshooting-invocation.md)用に予約されています。
**Topics**
+ [Lambda: Visual Studio Code でのリモートデバッグ](#troubleshooting-execution-remote-debugging)
+ [Lambda: 実行に時間がかかり過ぎています](#troubleshooting-execution-toolong)
+ [Lambda: 予想しないイベントペイロード](#troubleshooting-execution-unexpected-payload)
+ [Lambda: 予想外に大きなペイロードサイズ](#troubleshooting-execution-large-payload)
+ [Lambda: JSON エンコードとデコードエラー](#troubleshooting-execution-json-encoding)
+ [Lambda: ログやトレースが表示されません](#troubleshooting-execution-logstraces)
+ [Lambda: 関数のログの一部が表示されない](#troubleshooting-execution-missinglogs)
+ [Lambda: 関数は実行が終了する前に返します](#troubleshooting-execution-unfinished)
+ [Lambda: 意図しない関数バージョンまたはエイリアスの実行](#unintended-function)
+ [Lambda: 無限ループの検出](#infinite-loops)
+ [一般: ダウンストリームサービスの不可用性](#downstream-unavailability)
+ [AWS SDK: バージョンと更新](#troubleshooting-execution-versions)
+ [Python: ライブラリが正しくロードされません](#troubleshooting-execution-libraries)
+ [Java: Java 11 から Java 17 への更新後、関数によるイベントの処理に時間がかかる](#troubleshooting-execution-java-perf)
+ [Kafka: エラー処理と再試行設定の問題](#troubleshooting-kafka-error-handling)
## Lambda: Visual Studio Code でのリモートデバッグ
**問題:** *実際の AWS 環境での複雑な Lambda 関数動作のトラブルシューティングが困難*
Lambda は、AWS Toolkit for Visual Studio Code 経由でリモートデバッグ機能を提供します。設定と一般的な手順については、「[Visual Studio Code での Lambda 関数のリモートデバッグ](debugging.md)」を参照してください。
詳しいトラブルシューティング手順、高度なユースケース、利用可能なリージョンについては、「AWS Toolkit for Visual Studio Code User Guide」の「[Remote debugging Lambda functions](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html)」を参照してください。
## Lambda: 実行に時間がかかり過ぎています
**問題:** *関数の実行に時間がかかり過ぎる。*
Lambda でコードを実行すると、ローカルマシンよりもはるかに長い時間がかかる場合は、その関数で使用できるメモリまたは処理能力が制限されている可能性があります。メモリと CPU の両方を増やすには、[メモリを追加して関数を設定](configuration-memory.md)します。
## Lambda: 予想しないイベントペイロード
**問題:** *不正な形式の JSON または不適切なデータ検証に関連する関数エラー。*
すべての Lambda 関数は、ハンドラーの最初のパラメータでイベントペイロードを受け取ります。イベントペイロードは、配列とネストされた要素を含む可能性のある JSON 構造です。
不正な形式の JSON は、JSON 構造のチェックに堅牢なプロセスを使用していないアップストリームサービスによって提供されるときに発生する可能性があります。これは、サービスがテキスト文字列を連結する場合や、サニタイズされていないユーザー入力を埋め込む場合に発生します。また、JSON は、サービス間で渡すために頻繁にシリアル化されます。JSON のプロデューサーとコンシューマーとして両方の JSON 構造を常に解析し、構造が有効であることを確認してください。
同様に、イベントペイロードの値の範囲をチェックしないと、エラーが発生する恐れがあります。次の例は、源泉徴収額を計算する関数を示しています。
```
exports.handler = async (event) => {
let pct = event.taxPct
let salary = event.salary
// Calculate % of paycheck for taxes
return (salary * pct)
}
```
この関数は、イベントペイロードの給与と税率を使用して計算を実行します。ただし、このコードは属性が存在するかどうかをチェックすることはできません。また、データ型をチェックすることや、境界を確認する (税率が 0 から 1 の間であることを確認するなど) こともできません。その結果、これらの範囲外の値は、無意味な結果を生成します。型が正しくない場合や、属性がない場合には、ランタイムエラーが発生します。
テストを作成して、関数でより大きなペイロードサイズが処理されることを確認します。Lambda イベントペイロードの最大サイズは 1 MB です。コンテンツによっては、ペイロードが大きいほど、関数に渡される項目が増えたり、JSON 属性に埋め込まれるバイナリデータが増えたりする可能性があります。どちらの場合も、これによって Lambda 関数の処理が増える可能性があります。
ペイロードが大きいと、タイムアウトが発生することもあります。例えば、ある Lambda 関数は 100 ミリ秒ごとに 1 つのレコードを処理し、タイムアウトは 3 秒です。ペイロード内の 0～29 個の項目の処理は成功します。しかし、ペイロードに 30 個を超える項目が含まれていると、関数はタイムアウトし、エラーをスローします。これを回避するには、予想される最大項目数に対して追加の処理時間を処理するようにタイムアウトが設定されるようにします。
## Lambda: 予想外に大きなペイロードサイズ
**問題:** *関数がタイムアウトしているか、大きなペイロードが原因で関数がエラーを引き起こしています。*
大きいペイロードはタイムアウトやエラーを発生する可能性があります。関数が予想される最大ペイロードを処理し、関数のタイムアウトが適切に設定されていることを確認するテストの作成をお勧めします。
さらに、特定のイベントペイロードには、他のリソースへのポインタを含めることができます。例えば、128 MB のメモリを使用する Lambda 関数は、S3 にオブジェクトとして保存されている JPG ファイルで画像処理を実行できます。この関数は、小さな画像ファイルでは期待どおりに動作します。しかし、より大きな JPG ファイルが入力として提供されると、この Lambda 関数はメモリ不足によるエラーをスローします。これを回避するには、テストケースに想定されるデータサイズの上限の例を含める必要があります。コードはペイロードサイズも検証する必要があります。
## Lambda: JSON エンコードとデコードエラー
**問題:** *JSON 入力を解析する際の NoSuchKey の例外。*
JSON 属性が正しく処理されていることを確認してください。例えば、S3 によって生成されたイベントの場合、`s3.object.key` 属性には URL エンコードされたオブジェクトキー名が含まれます。多くの関数は、この属性をテキストとして処理して、参照されている S3 オブジェクトをロードします。
**Example**
```
const originalText = await s3.getObject({
Bucket: event.Records[0].s3.bucket.name,
Key: event.Records[0].s3.object.key
}).promise()
```
このコードはキー名 `james.jpg` で機能しますが、名前が `NoSuchKey` の場合は `james beswick.jpg` エラーをスローします。URL エンコーディングはキー名のスペースやその他の文字を変換するため、このデータを使用する前に関数でキーをデコードするようにする必要があります。
**Example**
```
const originalText = await s3.getObject({
Bucket: event.Records[0].s3.bucket.name,
Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " "))
}).promise()
```
## Lambda: ログやトレースが表示されません
**問題:** *ログが CloudWatch Logs に表示されない。*
**問題:** *トレースが AWS X-Ray に表示されない。*
関数には、CloudWatch Logs および X-Ray を呼び出すためのアクセス許可が必要です。その[実行ロール](lambda-intro-execution-role.md)を更新してアクセス許可を付与します。ログと追跡を有効にするには、以下の管理ポリシーを追加します。
+ **AWSLambdaBasicExecutionRole**
+ **AWSXRayDaemonWriteAccess**
関数にアクセス許可を追加する場合は、そのコードや設定にも些細な更新を行います。これにより、(古い認証情報により実行中の) 関数のインスタンスが、強制的に停止され置き換えられます。
**注記**
関数の呼び出し後にログが表示されるまで、5～10 分かかることがあります。
## Lambda: 関数のログの一部が表示されない
**問題:** 適切な権限があっても、CloudWatch Logs に関数ログが見つからない
AWS アカウント が [CloudWatch Logs のクォータ制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html)に達すると、CloudWatch は関数のロギングを抑制します。この場合、関数によって出力されたログの一部が CloudWatch Logs に表示されない場合があります。
関数がログを出力する頻度が高すぎて Lambda で処理できない場合、ログ出力が CloudWatch Logs に表示されない可能性もあります。Lambda は、関数がログを生成する速度でログを CloudWatch に送信できない場合、関数の実行が遅くなるのを防ぐためにログをドロップします。ログ スループットが 1 つのログ ストリームで 2 MB/秒を超えると、ログ記録が正常に行われない可能性があります。
関数が [JSON 形式のログ](monitoring-cloudwatchlogs-logformat.md)を使用するように設定されている場合、Lambda はログを削除するとき CloudWatch Logs に [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped) イベントを送信しようとします。ただし、CloudWatch は、関数のログから受け入れることができるデータ量を調整していると、ログを受け取れない場合があります。そのため、Lambda がログを削除したときにレコードが常に表示されるとは限りません。
AWS アカウント が CloudWatch Logs のクォータ制限に達しているかどうかを確認するには、次の手順を実行します。
1. [Service Quotas コンソール](https://console.aws.amazon.com/servicequotas) を開きます。
1. ナビゲーションペインで、**[AWSサービス**] を選択します。
1. **[AWS サービス]** リストから、Amazon CloudWatch Logs を検索します。
1. **[Service Quotas]** リストで、`CreateLogGroup throttle limit in transactions per second`、`CreateLogStream throttle limit in transactions per second` および `PutLogEvents throttle limit in transactions per second` クォータを選択して使用状況を表示します。
また、アカウントの使用率がこれらのクォータに指定した制限を超えたときに警告するように CloudWatch アラームを設定することもできます。詳しくは、「[Create a CloudWatch alarm based on a static threshold](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)」をご覧ください。
CloudWatch Logs のデフォルトのクォータ制限がユースケースに十分ではない場合は、[クォータの引き上げをリクエストできます](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)。
## Lambda: 関数は実行が終了する前に返します
**問題: (Node.js)** *コードの実行が終了する前に関数が戻る*
AWS SDK を含む多くのライブラリは、非同期的に動作します。レスポンスを待つ必要があるネットワーク呼び出しや別のオペレーションを実行すると、ライブラリは、オペレーションの進行状況をバックグラウンドで追跡するプロミスと呼ばれるオブジェクトを返します。
プロミスがレスポンスに解決されるまで待つには、`await` キーワードを使用します。これにより、プロミスがレスポンスを含むオブジェクトに解決されるまで、ハンドラーコードの実行がブロックされます。レスポンス内のデータをコードで使用する必要がない場合は、プロミスをランタイムに直接返すことができます。
一部のライブラリはプロミスを返しませんが、これらはプロミスを返すコードでラップできます。詳細については、「[Node.js の Lambda 関数ハンドラーの定義](nodejs-handler.md)」を参照してください。
## Lambda: 意図しない関数バージョンまたはエイリアスの実行
**問題:** *関数のバージョンまたはエイリアスが呼び出されない*
コンソール内または AWS SAM を使用して新しい Lambda 関数を発行するとき、最新のコードバージョンは `$LATEST` で表されます。デフォルトでは、バージョンまたはエイリアスを指定しない呼び出しは、関数コードの `$LATEST` バージョンを自動的にターゲットにします。
特定の関数バージョンまたはエイリアスを使用する場合、これらは `$LATEST` に加えて変更不可能な関数の公開バージョンです。これらの関数をトラブルシューティングする際、発信者が意図したバージョンまたはエイリアスを呼び出したことを最初に確認します。これを行うには、関数ログを確認します。呼び出された関数のバージョンは、常に START ログ行に表示されます。
![\[デバッグオペレーションの図 1\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-1.png)
## Lambda: 無限ループの検出
**問題:** *Lambda 関数に関連する無限ループパターン*
Lambda 関数には 2 タイプの無限ループがあります。1 つ目は関数自体に存在し、終了しないループによって発生します。呼び出しは、関数がタイムアウトしたときにのみ終了します。タイムアウトをモニタリングし、ループ動作を修正することにより、特定できます。
2 つ目のタイプは、Lambda 関数と他の AWS リソース間のループです。これらは、S3 バケットなどのリソースからのイベントが Lambda 関数を呼び出し、同じソースリソースとやり取りして別のイベントをトリガーする場合に発生します。関数が再度呼び出され、同じ S3 バケットで別の相互作用が作成されるという動作が続きます。これらのタイプのループは、Amazon SQS キューや DynamoDB テーブルなど、多数のさまざまな AWS イベントソースによって発生する可能性があります。[再帰ループ検出](invocation-recursion.md)を使用してこれらのパターンを特定できます。
![\[デバッグオペレーションの図 2\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-2.png)
Lambda 関数が消費するリソースとは別のリソースに書き込むことを確認することにより、これらのループを回避できます。消費するリソースにデータを発行し返す必要がある場合、新しいデータが同じイベントをトリガーしないことを確認してください。または、[イベントフィルタリング](invocation-eventfiltering.md)を使用します。例えば、S3 リソースおよび DynamoDB リソースを使用して無限ループに対する 2 つの提案ソリューションは次のとおりです。
+ 同じ S3 バケットに書き戻す場合、イベントトリガーとは異なるプレフィックスまたはサフィックスを使用します。
+ 同じ DynamoDB テーブルに項目を書き込む場合、消費する Lambda 関数がフィルタリングできる属性を含めてください。Lambda が 属性を検出した場合、別の呼び出しは行われません。
## 一般: ダウンストリームサービスの不可用性
**問題:** *Lambda 関数が依存するダウンストリームサービスが利用できない*
サードパーティーのエンドポイントやその他のダウンストリームリソースを呼び出す Lambda 関数では、サービスエラーやタイムアウトを処理できることを確認してください。これらのダウンストリームリソースは応答時間が異なったり、サービス中断によって利用できなくなったりする場合があります。実装状況によっては、サービスのエラーレスポンスが関数コード内で処理されない場合、これらのダウンストリームエラーが Lambda のタイムアウトまたは例外として表示されることがあります。
関数が API コールなどのダウンストリームサービスに依存する際、適切なエラー処理および再試行ロジックを実装してください。重大なサービスの場合、Lambda 関数はメトリクスまたはログを CloudWatch に発行する必要があります。例えば、サードパーティーの支払い API が利用できなくなった場合、Lambda 関数はこの情報をログ記録できます。その後、これらのエラーに関連する通知を送信するように CloudWatch アラームを設定できます。
Lambda は迅速にスケールできるため、サーバーレス以外のダウンストリームサービスがトラフィックの急増の処理に苦戦する場合があります。これを処理するには、一般的に次の 3 つのアプローチがあります。
+ **キャッシュ** — 頻繁に変更されない場合、サードパーティーのサービスによって返される値の結果をキャッシュすることを検討してください。これらの値は、関数のグローバル変数または別のサービスに保存できます。例えば、Amazon RDS インスタンスからの製品リストクエリの結果を関数内に一定期間保存して、冗長クエリを防ぐことができます。
+ **キューイング** - データを保存または更新する際、Lambda 関数とリソースの間に Amazon SQS キューを追加します。キューは、ダウンストリームサービスがメッセージを処理する間、データを永続的に保持します。
+ **プロキシ** - Amazon RDS インスタンスなど、存続期間の長い接続が一般的に使用される場合、プロキシレイヤーを使用してそれらの接続をプールして再利用します。リレーショナルデータベースの場合、[Amazon RDS Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) は Lambda ベースのアプリケーションのスケーラビリティおよび回復性を向上させるために設計されたサービスです。
## AWS SDK: バージョンと更新
**問題:** *ランタイムに含まれている AWS SDK が最新バージョンではない*
**問題:** *ランタイムに含まれている AWS SDK が自動的に更新される*
インタープリタ言語のランタイムには、 AWS SDK のバージョンが含まれます。Lambda は、最新の SDK バージョンを使用するようにこれらのランタイムを定期的に更新しています。ランタイムに含まれる SDK のバージョンを調べるには、下記のセクションをご覧ください。
+ [ランタイムに含まれる SDK バージョン(Node.js)](lambda-nodejs.md#nodejs-sdk-included)
+ [ランタイムに含まれる SDK バージョン(Python)](lambda-python.md#python-sdk-included)
+ [ランタイムに含まれる SDK バージョン (Ruby)](lambda-ruby.md#ruby-sdk-included)
より新しいバージョンの AWS SDK を使用したり、関数を特定のバージョンにロックしたりするには、ライブラリを関数コードでバンドルするか、[Lambda レイヤーを作成します](chapter-layers.md)。依存関係を持つデプロイパッケージの作成の詳細については、以下のトピックを参照してください。
------
#### [ Node.js ]
[.zip ファイルアーカイブで Node.js Lambda 関数をデプロイする](nodejs-package.md)
------
#### [ Python ]
[Python Lambda 関数で .zip ファイルアーカイブを使用する](python-package.md)
------
#### [ Ruby ]
[.zip ファイルアーカイブで Ruby Lambda 関数をデプロイする](ruby-package.md)
------
#### [ Java ]
[.zip または JAR ファイルアーカイブで Java Lambda 関数をデプロイする](java-package.md)
------
#### [ Go ]
[.zip ファイルアーカイブを使用して Go Lambda 関数をデプロイする](golang-package.md)
------
#### [ C\$1 ]
[.zip ファイルアーカイブを使用して C\$1 Lambda 関数を構築し、デプロイする](csharp-package.md)
------
#### [ PowerShell ]
[.zip ファイルアーカイブを使用した PowerShell Lambda 関数のデプロイする](powershell-package.md)
------
## Python: ライブラリが正しくロードされません
**問題:** (Python) *一部のライブラリがデプロイパッケージから正しくロードされない*
C または C\$1\$1 で記述された拡張モジュールを持つライブラリは、Lambda (Amazon Linux) と同じプロセッサアーキテクチャの環境でコンパイルする必要があります。詳細については、「[Python Lambda 関数で .zip ファイルアーカイブを使用する](python-package.md)」を参照してください。
## Java: Java 11 から Java 17 への更新後、関数によるイベントの処理に時間がかかる
**問題:** (Java) Java 11 から Java 17 への更新後、関数によるイベントの処理に時間がかかる
`JAVA_TOOL_OPTIONS` パラメータを使用して、コンパイラを調整します。Java 17 以降の Java バージョンの Lambda ランタイムによって、デフォルトのコンパイラオプションが変更されます。この変更により、実行時間の短い関数のコールドスタートに要する時間は短縮されますが、計算負荷が高く、実行時間が長い関数については、変更前の動作のほうが適しています。Java 11 の動作に戻すには、`-XX:-TieredCompilation` に `JAVA_TOOL_OPTIONS` を設定します。`JAVA_TOOL_OPTIONS` パラメータの詳細については、「[`JAVA_TOOL_OPTIONS` 環境変数について](java-customization.md#java-tool-options)」をご参照ください。
## Kafka: エラー処理と再試行設定の問題
**問題:** *Kafka イベントソースマッピングが再試行設定または障害発生時の送信先の設定に失敗する*
Kafka の再試行設定と障害発生時の送信先は、プロビジョニングモードが有効になっているイベントソースマッピングでのみ使用できます。再試行設定を設定する前に、`ProvisionedPollerConfig` で `MinimumPollers` が設定されていることを確認してください。
一般的な設定エラー:
+ **二等分割バッチによる無限再試行** – `MaximumRetryAttempts`が -1 (無限) に設定されている場合、`BisectBatchOnFunctionError` を有効にすることはできません。有限の再試行制限を設定するか、二等分割バッチを無効にします。
+ **同じトピックの再帰** – Kafka 障害発生時の送信先トピックをソーストピックと同じにすることはできません。デッドレタートピックに別のトピック名を選択します。
+ **無効な Kafka 送信先形式** – Kafka トピックを障害発生時の送信先として指定するときは、`kafka://` 形式を使用します。
+ **kafka:WriteData アクセス許可の問題** – 実行ロールに宛先トピックに対する `kafka-cluster:WriteData` アクセス許可があることを確認します。トピックが存在しないタイムアウト問題や書き込み API スロットリングの問題により、アカウント制限の引き上げが必要になる場合があります。
# Lambda のイベントソースマッピング問題のトラブルシューティング
[イベントソースマッピング](invocation-eventsourcemapping.md)に関連する Lambda の問題は複数のサービス間でデバッグを伴うため、より複雑になる可能性があります。さらに、イベントソースの動作は、使用される正確なイベントソースによって異なる場合があります。このセクションではイベントソースマッピングに関連する一般的な問題が一覧表示され、問題を特定してトラブルシューティングする方法に関するガイダンスが記載されます。
**注記**
このセクションでは、Amazon SQS イベントソースを例として使用しますが、Lambda 関数用にメッセージをキューに入れるその他のイベントソースマッピングに原則が適用されます。
## スロットリングの特定と管理
Lambda では、関数またはアカウントの同時実行制限に達するとスロットリングが発生します。Amazon SQS キューからメッセージを読み取る Lambda 関数がある次の例を検討してください。この Lambda 関数は 30 秒の呼び出しをシミュレートし、バッチサイズは 1 です。関数は 30 秒ごとに 1 つのメッセージのみを処理することを意味します。
```
const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))
exports.handler = async (event) => {
await doWork(30000)
}
```
このように呼び出し時間が長くなると、メッセージは処理される速度よりも速くキューに到着し始めます。アカウントの予約されていない同時実行数が 100 の場合、Lambda は 100 に同時実行数をスケールアップし、スロットリングが発生します。このパターンは、関数の CloudWatch メトリクスで確認できます。
![\[デバッグオペレーションの図 10\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-10.png)
関数の CloudWatch メトリクスにはエラーが表示されませんが、**[同時実行数]** のグラフには 100 の最大同時実行数に達したことが示されています。その結果、**[スロットル]** グラフにはスロットリングの実施が示されます。
CloudWatch アラームでスロットリングを検出し、関数のスロットリングメトリクスが 0 より大きいときはいつでもアラームを設定できます。スロットリング問題を特定したら、いくつかの解決方法があります。
+ このリージョンの AWS サポートに同時実行数の増加をリクエストします。
+ 関数内のパフォーマンスの問題を特定して処理速度を向上させ、それによってスループットを向上させます。
+ 呼び出しごとに多くのメッセージが処理されるように、関数のバッチサイズを増やします。
## 処理関数のエラー
処理関数がエラーをスローした場合、Lambda はメッセージを SQS キューに返します。大量のエラーを防ぐため、Lambda は関数のスケーリングを防止します。CloudWatch の次の SQS メトリクスは、キュー処理の問題を示します。
![\[デバッグオペレーションの図 11\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-11.png)
特に、最も古いメッセージの経過時間および表示されるメッセージ数の両方が増加していますが、メッセージは削除されません。キューは増加し続けていますが、メッセージは処理されていません。処理 Lambda 関数の CloudWatch メトリクスもまた、問題があることを示しています。
![\[デバッグオペレーションの図 12\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-12.png)
**エラー数**のメトリクスはゼロではなく増加していますが、**同時実行**は減少し、スロットリングは停止しています。エラーによって Lambda が関数のスケールアップを停止したことを示しています。関数の CloudWatch ログには、エラーのタイプの詳細が示されます。
エラーの原因となっている関数を特定し、エラーを見つけて解決すると、この問題を解決することができます。エラーを修正して新しい関数コードをデプロイすると、CloudWatch メトリクスに処理が復旧したことが示されます。
![\[デバッグオペレーションの図 13\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-13.png)
こちらでは、**[エラー数]** メトリクスがゼロに低下し、**[成功率]** メトリクスが 100% に戻ります。**[同時実行数]** グラフで示されるように、Lambda は関数のスケールアップを再開しています。
## バックプレッシャーの特定と処理
イベントプロデューサーが SQS キューのメッセージを Lambda 関数が処理できる速度よりも速く常時生成する場合、バックプレッシャーが発生します。この場合、表示されるメッセージのおよその数と一緒に、SQS モニタリングでは最も古いメッセージの経過時間が直線的に増加していることが示されます。CloudWatch アラームを使用し、キューのバックプレッシャーを検出できます。
バックプレッシャーを解決する手順は、ワークロードによって異なります。主な目的が Lambda 関数による処理能力およびスループットの向上の場合、次のような方法がいくつかあります。
+ AWS サポートから特定のリージョンの同時実行数の増加をリクエストします。
+ 呼び出しごとに多くのメッセージが処理されるように、関数のバッチサイズを増やします。
# Lambda でのネットワークに関する問題のトラブルシューティング
デフォルトでは、Lambda は AWS のサービスとインターネットに接続された内部の Virtual Private Cloud (VPC) で関数を実行します。ローカルネットワークのリソースにアクセスするには、[アカウントで VPC に接続するように関数を設定](configuration-vpc.md)できます。この機能を使用するときは、ユーザーが関数のインターネットアクセスと Amazon Virtual Private Cloud (Amazon VPC) リソースとのネットワーク接続を管理します。
ネットワーク接続エラーは、VPC のルーティング設定、セキュリティグループルール、AWS Identity and Access Management (IAM) ロールの許可、NAT、または IP アドレスやネットワークインターフェイスなどのリソースの可用性に関する問題が原因で発生する場合があります。問題によっては、リクエストが送信先に到達できない場合に、特定のエラーやタイムアウトが表示されることがあります。
**Topics**
+ [VPC: 関数がインターネットアクセスを失う、またはタイムアウトする](#troubleshooting-networking-cfn)
+ [VPC: TCP または UDP 接続が断続的に失敗する](#troubleshooting-networking-tcp-udp)
+ [VPC: 関数がインターネットを使用せずに AWS のサービスにアクセスする必要がある](#troubleshooting-networking-access)
+ [VPC: Elastic Network Interface の制限に到達した](#troubleshooting-networking-limit)
+ [EC2:「lambda」タイプの Elastic Network Interface](#troubleshooting-networking-eni)
+ [DNS: UNKNOWNHOSTEXCEPTION エラーのためホストに接続できません](#troubleshooting-networking-dns-tcp)
## VPC: 関数がインターネットアクセスを失う、またはタイムアウトする
**問題:** *Lambda 関数が VPC に接続した後でインターネットにアクセスできなくなります。*
**エラー:** *エラー: 接続 ETIMEDOUT 176.32.98.189:443*
**エラー:** *エラー: タスクが 10.00 秒後にタイムアウトしました*
**エラー:***ReadTimeoutError: Read timed out. (read timeout=15)* (ReadTimeoutError: 読み取りがタイムアウトしました。(読み取りタイムアウト=15))
関数を VPC に接続すると、すべてのアウトバウンドリクエストが VPC を通過します。インターネットに接続するには、関数のサブネットからパブリックサブネットの NAT ゲートウェイにアウトバウンドトラフィックを送信するように VPC を設定します。VPC 設定の詳細と例については、「[VPC に接続された Lambda 関数にインターネットアクセスを有効にする](configuration-vpc-internet.md)」を参照してください。
一部の TCP 接続がタイムアウトする場合は、[VPC: TCP または UDP 接続が断続的に失敗する](#troubleshooting-networking-tcp-udp) をチェックして、サブネットがネットワークアクセスコントロールリスト (NACL) を使用しているかを確認してください。それ以外の場合は、パケットの断片化が原因として考えられます。Lambda は TCP または ICMP の IP フラグメンテーションをサポートしないため、Lambda 関数は受信するフラグメント化された TCP リクエストを処理できません。
## VPC: TCP または UDP 接続が断続的に失敗する
**注記**
この問題は、サブネットが[ネットワークアクセスコントロールリスト (ACL)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics) を使用している場合にのみ該当します。Lambda からサブネットへの接続にネットワーク ACL は必要ありません。
**問題:** *ネットワークアクセスコントロールリスト (ACL) を設定している VPC サブネットへの Lambda の接続が断続的に失われます。*
VPC 対応の Lambda 関数の場合、AWS は顧客アカウント内に[ハイパープレーン ENI](configuration-vpc.md#configuration-vpc-enis) を作成し、`1024` から `65535` までのエフェメラルポートを使用して Lambda を顧客の VPC に接続します。ターゲットサブネットでネットワーク ACL を使用する場合、TCP および UDP の両方に `1024` から `65535` までのポート範囲を許可する必要があります。このポート範囲全体を許可しないと、断続的な接続障害が発生する可能性があります。
## VPC: 関数がインターネットを使用せずに AWS のサービスにアクセスする必要がある
**問題:** *Lambda 関数がインターネットを使用せずに AWS のサービスにアクセスする必要があります。*
インターネットアクセスがないプライベートサブネットを介して関数が AWS のサービスに接続するには、VPC エンドポイントを使用します。
## VPC: Elastic Network Interface の制限に到達した
**エラー:** *ENILimitReachedException: 関数の VPC で Elastic Network Interface の上限数に達しました。*
Lambda 関数を VPC に接続すると、Lambda が、その関数にアタッチされたサブネットとセキュリティグループの組み合わせごとに Elastic Network Interface を作成します。デフォルトのサービスクォータは、VPC あたり 250 個のネットワークインターフェイスです。クォータの引き上げをリクエストするには、[Service Quotas コンソール](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26)を使用してください。
## EC2:「lambda」タイプの Elastic Network Interface
**エラーコード:** *Client.OperationNotPermitted*
**エラーメッセージ:** *このタイプのインターフェイスではセキュリティグループを変更できません*
Lambda によって管理されている Elastic network interface (ENI) を変更しようとすると、このエラーが表示されます。`ModifyNetworkInterfaceAttribute` は、Lambda が作成した Elastic network interface で更新オペレーションを行うための Lambda API には含まれていません。
## DNS: UNKNOWNHOSTEXCEPTION エラーのためホストに接続できません
**エラーメッセージ:** *UNKNOWNHOSTEXCEPTION*
Lambda 関数は、DNS 解決のために最大 20 の同時 TCP 接続をサポートします。この制限に達すると、エラーが発生する可能性があります。最も一般的な DNS リクエストは UDP 経由で行われます。関数が UDP DNS 接続のみを行う場合、問題になる可能性は高くありません。このエラーは、一般に設定の誤りやインフラストラクチャの劣化が原因で発生します。DNS トラフィックを詳細に調べる前に、DNS インフラストラクチャが正しく設定されており正常であること、および Lambda 関数が DNS で指定されたホストを参照していることを確認してください。
問題が TCP 接続数の制限に関連するものとして診断された場合、この制限の引き上げはリクエストできないことに注意してください。DNS ペイロードが大きいために Lambda 関数が TCP DNS にフォールバックする場合は、ソリューションが EDNS をサポートするライブラリを使用していることを確認してください。EDNS の詳細については、[RFC 6891 標準](https://datatracker.ietf.org/doc/html/rfc6891)を参照してください。DNS ペイロードが常に EDNS 最大サイズを超える場合でも、ソリューションは引き続き TCP DNS 制限に達する可能性があります。