

# Lambda 関数を非同期的に呼び出す
<a name="invocation-async"></a>

Amazon Simple Storage Service (Amazon S3) や Amazon Simple Notification Service (Amazon SNS) などの複数の AWS のサービス では、関数を非同期的に呼び出してイベントを処理します。AWS Command Line Interface (AWS CLI) または AWS SDK のいずれかを使用して、Lambda 関数を非同期的に呼び出すこともできます。関数を非同期的に呼び出す場合は、関数コードからのレスポンスを待機しません。イベントを Lambda に渡すと、Lambda が残りを処理します。Lambda がエラーを処理する方法を設定し、Amazon Simple Queue Service (Amazon SQS) または Amazon EventBridge (EventBridge) などのダウンストリームリソースに呼び出しレコードを送信して、アプリケーションのコンポーネントをつなぎ合わせることができます。

次の図は、クライアントによる Lambda 関数の非同期的呼び出しを示しています。Lambda は、イベントを関数に送信する前にキューに入れます。

![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/features-async.png)


非同期呼び出しの場合、Lambda はリクエストをキューに入れ、追加情報のない成功のレスポンスを返します。別のプロセスがキューからイベントを読み取って関数に送信します。

 AWS Command Line Interface (AWS CLI) または AWS SDK のいずれかを使用して Lambda 関数を非同期的に呼び出すには、[呼び出しタイプ](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-InvocationType)パラメータを `Event` に設定します。次のコード例は、関数を呼び出す AWS CLI コマンドを示しています。

```
aws lambda invoke \
  --function-name my-function  \
  --invocation-type Event \
  --cli-binary-format raw-in-base64-out \
  --payload '{ "key": "value" }' response.json
```

以下の出力が表示されます。

```
{
    "StatusCode": 202
}
```

AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、バージョン 2 の AWS Command Line Interface ユーザーガイドの「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。

出力ファイル (`response.json`) には情報は含まれないものの、このコマンドを実行すると作成されます。Lambda がイベントをキューに追加することができない場合、エラーメッセージがコマンド出力に表示されます。

# Lambda がエラーを処理し、非同期呼び出しで再試行する方法
<a name="invocation-async-error-handling"></a>

Lambda は関数の非同期イベントキューを管理し、エラー発生時に再試行を行います。関数からエラーが返された場合、Lambda はデフォルトでその関数をさらに 2 回再試行します。その際、最初の 2 回の試行の間に 1 分間、2 回目と 3 回目の間に 2 分間の待機時間があります。関数エラーには、関数のコードによって返されるエラーと、タイムアウトなど関数のランタイムによって返されるエラーが含まれます。

関数にすべてのイベントを処理するために十分な同時実行数がない場合は、追加のリクエストはスロットリングされます。スロットルエラー (429) およびシステムエラー (500 番台) の場合、Lambda はイベントをキューに返し、デフォルトで最大 6 時間関数の再実行を試行します。再試行間隔は、最初の試行後 1 秒から最大 5 分まで指数関数的に増加します。キューに多くのエントリが含まれている場合、Lambda は再試行の間隔を長くして、キューからイベントを読み取る速度を低下させます。

関数がエラーを返さない場合でも、キュー自体は最終的に一貫しているため、同じイベントを Lambda から複数回受信する可能性があります。関数が受信するイベントに対応できない場合、イベントは関数に送信されずにキューから削除される場合があります。関数コードが重複イベントを適切に処理し、すべての呼び出しを処理するのに十分な同時実行数があることを確認してください。

キューが非常に長い場合、新しいイベントは Lambda によって関数に送信される前に期限切れになる場合があります。期限切れになったイベントや、すべての処理試行に失敗したイベントは Lambda によって破棄されます。関数の[エラー処理を設定](invocation-async-configuring.md)して、Lambda による再試行の回数を減らしたり、未処理のイベントをより速やかに破棄したりできます。廃棄されたイベントをキャプチャするには、関数の[デッドレターキューを設定](invocation-async-retain-records.md#invocation-dlq)します。失敗した呼び出し (タイムアウトやランタイムエラーなど) のレコードをキャプチャするには、[失敗時の送信先を作成](invocation-async-retain-records.md#invocation-async-destinations)します。

# Lambda 非同期呼び出しのエラー処理の設定
<a name="invocation-async-configuring"></a>

次の設定を使用して、Lambda で非同期の関数呼び出しのエラーと再試行をどのように処理するかを設定します。
+ [MaximumEventAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html#lambda-PutFunctionEventInvokeConfig-request-MaximumEventAgeInSeconds): Lambda が非同期イベントキューにイベントを保持する最大時間を秒単位で設定します。この時間を過ぎると、イベントは破棄されます。
+ [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html#lambda-PutFunctionEventInvokeConfig-request-MaximumRetryAttempts): 関数がエラーを返したときに Lambda がイベントを再試行する回数の上限を設定します。

Lambda コンソールまたは AWS CLI を使用して、関数、バージョン、またはエイリアスのエラー処理を設定します。

------
#### [ Console ]

**エラー処理を設定するには**

1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。

1. 関数を選択します。

1. [**設定**]、[**Asynchronous invocation (非同期呼び出し)**] の順に選択します。

1. [**Asynchronous invocation (非同期呼び出し)**] で、[**Edit (編集)**] を選択します。

1. 以下を設定します。
   + [**Maximum age of event**] (イベントの最大有効期間) － Lambda が非同期イベントキューにイベントを保持する最大時間 (最大 6 時間)。
   + [**Retry attempts**] (再試行) － 関数がエラーを返したときに Lambda が再試行する回数 (0 〜 2)。

1. [**Save**] を選択します。

------
#### [ AWS CLI ]

AWS CLI で非同期呼び出しを設定するには、[put-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-function-event-invoke-config.html) コマンドを使用します。以下の例では、最大イベント有効期間が 1 時間で再試行なしの関数を設定しています。

```
aws lambda put-function-event-invoke-config \ 
  --function-name error \
  --maximum-event-age-in-seconds 3600 \
  --maximum-retry-attempts 0
```

`put-function-event-invoke-config` コマンドは、関数、バージョン、またはエイリアスの既存の設定を上書きします。あるオプションだけを設定し、他のものはリセットしないようにするには、[update-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-event-invoke-config.html) コマンドを使用します。以下の例では、イベントを処理できない場合に、`destination` という名前の標準 SQS キューにレコードを送信するように Lambda を設定します。

```
aws lambda update-function-event-invoke-config \
  --function-name my-function \
  --destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-1:123456789012:destination"}}'
```

------

以下の出力が表示されます。

```
{
    "LastModified": 1573686021.479,
    "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
    "MaximumRetryAttempts": 0,
    "MaximumEventAgeInSeconds": 3600,
    "DestinationConfig": {
        "OnSuccess": {},
        "OnFailure": {}
    }
}
```

呼び出しイベントが最大有効期間を超えるか、すべての再試行に失敗すると、Lambda はそのイベントを破棄します。破棄されたイベントのコピーを保持するには、失敗イベントの[送信先](invocation-async-retain-records.md#invocation-async-destinations)を設定します。

# Lambda 非同期呼び出しのレコードのキャプチャ
<a name="invocation-async-retain-records"></a>

Lambda 関数は、非同期呼び出しのレコードを以下のいずれかの AWS のサービス に送信できます。
+ **Amazon SQS** — 標準 SQS キュー
+ **Amazon SNS** – 標準 SNS トピック
+ **Amazon S3** – Amazon S3 バケット (障害発生時のみ)
+ **AWS Lambda** — Lambda 関数
+ **Amazon EventBridge** － Amazon EventBridge イベントバス

呼び出しレコードには、JSON 形式のリクエストとレスポンスに関する詳細が含まれます。処理に成功したイベント用とすべての処理試行に失敗したイベント用に別々の送信先を設定できます。または、破棄されたイベント用に標準 Amazon SQS キューまたは標準 Amazon SNS トピックをデッドレターキューとして設定することもできます。デッドレターキューの場合、Lambda はイベントのコンテンツのみを送信し、レスポンスの詳細は送信しません。

設定した送信先に Lambda がレコードを送信できない場合、Lambda は Amazon CloudWatch に `DestinationDeliveryFailures` メトリクスを送信します。これは、設定に Amazon SQS FIFO キューや Amazon SNS FIFO トピックなど、サポートされていない送信先タイプが含まれている場合に発生する可能性があります。また、配信エラーはアクセス許可エラーが原因で発生する可能性があります。Lambda 呼び出しメトリクスの詳細については、「[呼び出しメトリクス](monitoring-metrics-types.md#invocation-metrics)」を参照してください。

**注記**  
関数がトリガーされないようにするには、その関数の予約済同時実行数をゼロに設定します。非同期で呼び出された関数の予約された同時実行数をゼロに設定すると、Lambda は設定した[デッドレターキュー](#invocation-dlq)または障害発生時の[イベント送信先](#invocation-async-destinations)に再試行なしで新しいイベントの送信を開始します。予約された同時実行数をゼロに設定している間に送信されたイベントを処理するには、デッドレターキューまたは障害発生時のイベント送信先からイベントを消費する必要があります。

## 送信先の追加
<a name="invocation-async-destinations"></a>

非同期呼び出しのレコードを保持するには、関数に送信先を追加します。成功した呼び出しと失敗した呼び出しのいずれかを送信先に送るように選択できます。各関数に複数の送信先を設定できるため、成功したイベントと失敗したイベントの送信先を別々に設定できます。送信先に送られる各レコードは、呼び出しに関する詳細を含む JSON ドキュメントです。エラー処理の設定と同様に、関数、関数のバージョン、またはエイリアスに対して送信先を設定できます。

**ヒント**  
次のイベントソースマッピングのタイプについて、失敗した呼び出しのレコードを保持することもできます。[Amazon Kinesis](kinesis-on-failure-destination.md#kinesis-on-failure-destination-console)、[Amazon DynamoDB](services-dynamodb-errors.md)、[Apache Kafka (Amazon MSK と セルフマネージド Apache Kafka)](kafka-on-failure.md#kafka-onfailure-destination)。<a name="destinations-permissions"></a>

以下の表は、非同期呼び出しレコードでサポートされている送信先の一覧です。Lambda が選択した送信先にレコードを正常に送信するには、関数の[実行ロール](lambda-intro-execution-role.md)にも関連するアクセス権限が含まれていることを確認してください。この表では、各送信先タイプで JSON 呼び出しレコードを受け取る方法についても説明しています。


| 送信先タイプ | 必要なアクセス許可 | 宛先固有の JSON 形式 | 
| --- | --- | --- | 
|  Amazon SQS キュー  |  [sqs:SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)  |  Lambda は呼び出しレコードを `Message` として宛先に渡します。  | 
|  Amazon SNS トピック  |  [sns:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)  |  Lambda は呼び出しレコードを `Message` として宛先に渡します。  | 
|  Amazon S3 バケット (障害発生時のみ)  |  [s3:PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) [s3:ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-async-retain-records.html)  | 
|  Lambda function  |  [lambda:InvokeFunction](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)  |  Lambda は呼び出しレコードをペイロードとして関数に渡します。  | 
|  EventBridge  |  [events:PutEvents](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-async-retain-records.html)  | 

**注記**  
Amazon S3 の送信先では、KMS キーを使用してバケットの暗号化を有効にしている場合、関数には [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) アクセス許可も必要です。

**重要**  
Amazon SNS を送信先として使用する場合、Amazon SNS の最大メッセージサイズ制限は 256 KB であることに注意してください。非同期呼び出しペイロードが 1 MB に近づくと、呼び出しレコード (元のペイロードと追加のメタデータを含む) が Amazon SNS の制限を超え、配信が失敗する可能性があります。より大きなペイロードには Amazon SQS または Amazon S3 の送信先を使用することを検討してください。

次のステップでは、Lambda コンソールと AWS CLI を使用して関数の送信先を設定する方法について説明します。

------
#### [ Console ]

1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。

1. 関数を選択します。

1. [**機能の概要 **] で、[**送信先を追加 **] を選択します。

1. [**Source (送信元)**] で、[**Asynchronous invocation (非同期呼び出し)**] を選択します。

1. [**条件**] で、以下のオプションから選択します。
   + [**On failure**] (失敗時) － イベントがすべての処理試行に失敗した場合、または最大有効期間を超えた場合に、レコードを送信します。
   + [**On success**] (正常) － 関数が非同期呼び出しを正常に処理したときに、レコードを送信します。

1. [**送信先タイプ**] で、呼び出しレコードを受信するリソースのタイプを選択します。

1. [**送信先**] で、リソースを選択します。

1. **[保存]** を選択します。

------
#### [ AWS CLI ]

AWS CLI を使用して送信先を設定するには、[update-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-event-invoke-config.html) コマンドを実行します。以下の例では、イベントを処理できない場合に、`destination` という名前の標準 SQS キューにレコードを送信するように Lambda を設定します。

```
aws lambda update-function-event-invoke-config \
  --function-name my-function \
  --destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-1:123456789012:destination"}}'
```

------

### Amazon S3 送信先のセキュリティのベストプラクティス
<a name="s3-destination-security"></a>

関数の設定から送信先を削除せずに、送信先として設定された S3 バケットを削除すると、セキュリティリスクが発生する可能性があります。別のユーザーが送信先バケットの名前を知っている場合は、その AWS アカウントでバケットを再作成できます。失敗した呼び出しのレコードがそのバケットに送信され、関数からのデータが公開される可能性があります。

**警告**  
関数からの呼び出しレコードを別の AWS アカウントの S3 バケットに送信できないようにするには、`s3:PutObject` アクセス許可を自分アカウントのバケットに制限する条件を関数の実行ロールに追加します。

次の例は、関数の `s3:PutObject` アクセス許可を自分のアカウントのバケットに制限する IAM ポリシーを示しています。このポリシーは、送信先として S3 バケットを使用するために必要な `s3:ListBucket` アクセス許可も Lambda に付与します。

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "S3BucketResourceAccountWrite",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::*/*",
                "arn:aws:s3:::*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:ResourceAccount": "111122223333"
                }
            }
        }
    ]
}
```

AWS マネジメントコンソールまたは AWS CLI を使用して、関数の実行ロールにアクセス許可ポリシーを追加する場合は、次の手順を参照してください。

------
#### [ Console ]

**関数の実行ロールにアクセス許可ポリシーを追加するには (コンソール)**

1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。

1. 実行ロールを変更する Lambda 関数を選択します。

1. **[構成]** タブで、**[アクセス許可]** を選択します。

1. **[実行ロール]** タブで、関数の **[ロール名]** を選択して、ロールの IAM コンソールページを開きます。

1. 次の手順を実行してアクセス許可ポリシーをロールに追加します。

   1. **[アクセス許可ポリシー]** ペインで、**[アクセス許可の追加]**、**[インラインポリシーを作成]** を選択します。

   1. **ポリシーエディタ**で、**[JSON]** を選択します。

   1. 追加するポリシーをエディタに貼り付け (既存の JSON を置き換える)、**[次へ]** を選択します。

   1. **[ポリシーの詳細]** で **[ポリシー名]** を入力します。

   1. [**Create policy**] (ポリシーの作成) を選択します。

------
#### [ AWS CLI ]

**関数の実行ロールにアクセス許可ポリシーを追加するには (CLI)**

1. 必要なアクセス許可を持つ JSON ポリシードキュメントを作成し、ローカルディレクトリに保存します。

1. IAM `put-role-policy` CLI コマンドを使用して、関数の実行ロールにアクセス許可を追加します。JSON ポリシードキュメントを保存したディレクトリから次のコマンドを実行して、ロール名、ポリシー名、ポリシードキュメントを独自の値に置き換えます。

   ```
   aws iam put-role-policy \
   --role-name my_lambda_role \
   --policy-name LambdaS3DestinationPolicy \
   --policy-document file://my_policy.json
   ```

------

### 呼び出しレコードの例
<a name="destination-example-record"></a>

呼び出しが条件に一致すると、Lambda は呼び出しに関する詳細を含む [JSON ドキュメント](#destinations-permissions)を送信先に送ります。次の例は、関数エラーが原因で 3 つの処理試行に失敗したイベントの呼び出しレコードを示しています。

**Example**  

```
{
    "version": "1.0",
    "timestamp": "2019-11-14T18:16:05.568Z",
    "requestContext": {
        "requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e",
        "functionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
        "condition": "RetriesExhausted",
        "approximateInvokeCount": 3
    },
    "requestPayload": {
        "ORDER_IDS": [
            "9e07af03-ce31-4ff3-xmpl-36dce652cb4f",
            "637de236-e7b2-464e-xmpl-baf57f86bb53",
            "a81ddca6-2c35-45c7-xmpl-c3a03a31ed15"
        ]
    },
    "responseContext": {
        "statusCode": 200,
        "executedVersion": "$LATEST",
        "functionError": "Unhandled"
    },
    "responsePayload": {
        "errorMessage": "RequestId: e4b46cbf-b738-xmpl-8880-a18cdf61200e Process exited before completing request"
    }
}
```

呼び出しレコードには、イベント、レスポンス、レコードが送信された理由に関する詳細が含まれます。

### 送信先へのリクエストのトレース
<a name="destinations-tracing"></a>

AWS X-Ray を使用すると、各リクエストがキューに入れられ、Lambda 関数によって処理され、送信先サービスに渡される過程の接続されたビューを確認できます。関数または関数を呼び出すサービスの X-Ray トレーシングを有効にすると、Lambda は X-Ray ヘッダーをリクエストに追加し、ヘッダーを送信先サービスに渡します。アップストリームサービスからのトレースは、ダウンストリーム Lambda 関数および宛先サービスからのトレースに自動的にリンクされ、アプリケーション全体のエンドツーエンドビューを作成します。トレースの詳細については、「[AWS X-Ray を使用した Lambda 関数呼び出しの視覚化](services-xray.md)」を参照してください。

## デッドレターキューの追加
<a name="invocation-dlq"></a>

[障害発生時の送信先](#invocation-async-destinations)に代わる方法として、配信不能キューを使用して関数を設定し、破棄されたイベントを保存してさらに処理できます。配信不能キューは、イベントがすべての処理試行に失敗した場合や処理されずに期限切れになった場合に使用されるという点で、障害発生時の送信先と同じように動作します。ただし、デッドレターキューを追加または削除できるのは、関数レベルでのみです。関数バージョンでは、未公開バージョン (\$1LATEST) と同じデッドレターキュー設定が使用されます。また、障害発生時の送信先は、追加のターゲットをサポートし、関数のレスポンスに関する詳細を呼び出しレコードに含めます。

デッドレターキュー内のイベントを再処理するには、デッドレターキューを Lambda 関数の[イベントソース](invocation-eventsourcemapping.md)として設定します。または、イベントを手動で取得することもできます。

デッドレターキューには標準 Amazon SQS キューまたは標準 Amazon SNS トピックを選択できます。FIFO キューと Amazon SNS FIFO トピックはサポートされていません。
+ [Amazon SQS キュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-create-queue.html) － キューは、失敗したイベントが取得されるまでそれらを保持します。Lambda 関数や CloudWatch アラームなどの単一のエンティティが失敗したイベントを処理することが予想される場合は、Amazon SQS 標準キューを選択します。詳細については、「[Amazon SQS での Lambda の使用](with-sqs.md)」を参照してください。
+ [Amazon SNS トピック](https://docs.aws.amazon.com/sns/latest/gsg/CreateTopic.html) － トピックは、失敗したイベントを 1 つまたは複数の送信先に中継します。複数のエンティティが失敗したイベントに対して動作することが予想される場合は、Amazon SNS 標準トピックを選択します。例えば、E メールアドレス、Lambda 関数、および/または HTTP エンドポイントにイベントを送信するようにトピックを設定できます。詳細については、「[Amazon SNS 通知を使用した Lambda 関数の呼び出し](with-sns.md)」を参照してください。

キューまたはトピックにイベントを送信するには、関数に追加のアクセス権限が必要です。[必要なアクセス許可](#destinations-permissions)を定義したポリシーを関数の[実行ロール](lambda-intro-execution-role.md)に追加します。ターゲットキューまたはトピックがカスタマーマネージド AWS KMS キーで暗号化されている場合は、関数の実行ロールとキーの[リソースベースのポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)の両方に関連するアクセス許可が含まれていることを確認してください。

ターゲットを作成し、関数の実行ロールを更新した後、デッドレターキューを関数に追加します。同じターゲットにイベントを送信するように複数の関数を設定できます。

------
#### [ Console ]

1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。

1. 関数を選択します。

1. [**設定**]、[**Asynchronous invocation (非同期呼び出し)**] の順に選択します。

1. [**Asynchronous invocation (非同期呼び出し)**] で、[**Edit (編集)**] を選択します。

1. **デッドレターキューサービス**を **Amazon SQS** または **Amazon SNS** に設定します。

1. ターゲットとなるキューまたはトピックを選択します。

1. **[保存]** を選択します。

------
#### [ AWS CLI ]

AWS CLI を使用してデッドレターキューを設定するには、[update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) コマンドを使用します。

```
aws lambda update-function-configuration \
  --function-name my-function \
  --dead-letter-config TargetArn=arn:aws:sns:us-east-1:123456789012:my-topic
```

------

Lambda は、イベントをそのまま属性の追加情報と共にデッドレターキューに送信します。この情報を使用して、関数が返したエラーを特定するか、イベントをログまたは AWS X-Ray トレースと関連付けることができます。

**デッドレターキューメッセージの属性**
+ **RequestID** (文字列) － 呼び出しリクエストの ID。リクエスト ID は関数ログに表示されます。また、X-Ray SDK を使用して、トレース内の属性のリクエスト ID を記録することもできます。その後、X-Ray コンソールで、リクエスト ID によってトレースを検索できます。
+ **ErrorCode** (数値) － HTTP ステータスコード。
+ **ErrorMessage** (文字列) － エラーメッセージの最初の 1 KB。

Lambda がデッドレターキューにメッセージを送信できない場合、イベントは削除され、[DeadLetterErrors](monitoring-metrics-types.md) メトリクスが発行されます。このような状況は、アクセス権限がない、またはメッセージの合計サイズがターゲットとなるキューやトピックの制限を超えてしまった場合に発生します。例えば、本文のサイズが 1 MB に近い Amazon SNS 通知が、エラーとなる関数をトリガーしたとします。その場合、Amazon SNS によって追加されたイベントデータと Lambda によって追加された属性の組み合わせによって、メッセージがデッドレターキューで許可されている最大サイズを超過することがあります。

Amazon SQS をイベントソースとして使用する場合、Amazon SQS キューでは Lambda 関数ではなくデッドレターキューを設定します。詳細については、「[Amazon SQS での Lambda の使用](with-sqs.md)」を参照してください。