

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 再試行ポリシーとデッドレターキュー
<a name="eb-custom-bus-retry"></a>

ターゲット呼び出しが失敗すると、EventBridge `RetryPolicy`は、デフォルトで 5 回または 300 秒の 2 つの制限のいずれかに達するまで再試行し、 の Amazon SQS キューにレコードを書き込みます`OnFailureConfiguration.Arn`。サブスクライバーを作成するときに両方を設定します。デッドレターキューがない場合、再試行を使い果たすイベントはドロップされ、唯一のトレースは `EventsDropped`メトリクスです。

## 再試行の制限
<a name="eb-custom-bus-retry-policy"></a>

配信は、最初に到達した制限で停止します。


| 制限 | Range | デフォルト | 
| --- | --- | --- | 
| MaxRetryAttempts | 0～185 | 5 | 
| MaxEventAgeInSeconds | 60～86,400 | 300 | 

デフォルトは、カスタムイベントバス - クラシックターゲットの 24 時間および 185 回の試行よりも短くなります。1 日の再試行に依存する移行された設計は、明示的に 86,400 `MaxEventAgeInSeconds`に設定する必要があります。そうしないと、ターゲットの停止中に 5 分以上失敗するイベントは、遅延配信されるのではなく、デッドレターキューに送られます。FIFO サブスクライバーの場合、失敗したイベントは再試行されている限りグループ内の後続のイベントをブロックするため、長い再試行ウィンドウはレイテンシーの順序に置き換えられます。

## デッドレターレコード
<a name="eb-custom-bus-retry-record"></a>

レコードはイベントではなく JSON ドキュメントです。次の例は、1 つのバッチで一緒に失敗した 2 つのイベントに対して 1 つのレコードを示しています。

```
{
    "version": "1.0",
    "busArn": "arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef",
    "subscriberArn": "arn:aws:events:us-east-1:111122223333:subscriber/large-orders/EXAMPLEabcdef1234567890",
    "targetArn": "arn:aws:sqs:us-east-1:111122223333:large-orders",
    "errorCode": "ACCESS_DENIED",
    "errorMessage": "The delivery role is not authorized to perform sqs:SendMessage on the target.",
    "exhaustedRetryCondition": "MaximumEventAgeInSeconds",
    "retryAttempts": 4,
    "failedMessages": [
        { "eventId": "a1b2c3d4-...", "eventGroupId": "order-1001", "deduplicationId": null, "timestamp": "2026-09-16T18:40:12Z", "targetRequestId": "..." },
        { "eventId": "e5f6a7b8-...", "eventGroupId": "order-1001", "deduplicationId": null, "timestamp": "2026-09-16T18:40:13Z", "targetRequestId": "..." }
    ]
}
```

キューに到達するすべての障害が最初に再試行されました。 をスキップする配信障害はありません`RetryPolicy`。EventBridge 自体内の障害は、無制限に EventBridge によって再試行され、レコードは生成されません。次の表に、レコードが保持できるコードを示します。 `errorMessage`は 1,024 文字に切り捨てられます。


| `errorCode` | 失敗した内容 | `errorMessage` | 
| --- | --- | --- | 
| CUSTOMER\_VALIDATION | ターゲット API がリクエストを拒否しました (4xx レスポンス): 不正な値、欠落しているフィールド、不正な形式の本文 | ターゲット API の独自のメッセージ | 
| ACCESS\_DENIED | EventBridge が配信ロールを引き受けることができなかったか、ロールがターゲットを呼び出すことが許可されていないか、ターゲットの AWS KMS キーがアクセスを拒否しました | EventBridge が{{ロール}}を引き受けることができませんでした。ロールが存在し、その信頼ポリシーで EventBridge サービスプリンシパルがロールを引き受けることが許可されていることを確認します。 または EventBridge は{{リソース}}にアクセスできませんでした。存在し、そのポリシーが EventBridge サービスプリンシパルアクセスを許可していることを確認します。 | 
| RESOURCE\_NOT\_FOUND | ターゲットまたはその AWS KMS キーが存在しない | は上記のメッセージ、または汎用メッセージにアクセスできませんでした  | 
| INPUT\_TRANSFORMATION\_FAILURE | Transformer またはユニバーサルターゲットInput式が値をスローまたは生成しなかった | 式エラー | 
| THROTTLING | ターゲットが呼び出しをスロットリングしました | 汎用メッセージ | 
| EXECUTION\_TIMEOUT | ターゲットが 内で応答しませんでした InvocationTimeoutSeconds | 汎用メッセージ | 
| REQUEST\_TOO\_LARGE | リクエストがターゲットのサイズ制限を超えました。 MaxBatchSize | 汎用メッセージ | 
| PARTIAL\_BATCH\_FAILURE | ターゲットはバッチの一部を受け入れ、残りを拒否しました。レコードの には拒否されたイベントのみfailedMessagesが表示されます。 | 汎用メッセージ | 
| RESOURCE\_CONFLICT | ターゲットが競合を報告しました。たとえば、既に使用されている名前などです。 | 汎用メッセージ | 
| KMS\_INVALID\_STATE | ターゲットの AWS KMS キーが無効になっているか、削除が保留中です | 汎用メッセージ | 
| SFN\_TYPE\_NOT\_SUPPORTED | REQUEST\_RESPONSE は、同期実行をサポートしていない標準ステートマシンで使用されました | 汎用メッセージ | 
| COMPUTE\_EXECUTION\_ERROR | REQUEST\_RESPONSE 関数または実行が実行され、エラーが報告されました | 汎用メッセージ | 
| INVOCATION\_DEPENDENCY\_INTERNAL | ターゲットがサーバーエラー (5xx レスポンス) を返しました | 汎用メッセージ | 
| LOOP\_DETECTED | イベント、またはそのイベントから派生したイベントは、既にターゲットバスを通過しています。「」を参照してください。 [ループ検出](eb-custom-bus-target-bus.md#eb-custom-bus-target-bus-loops) | 汎用メッセージ | 
| INTERNAL\_SERVER\_ERROR | 再試行を使い果たした通話中の EventBridge 内の障害 | 汎用メッセージ | 

一般的なメッセージは *です。配信に失敗しました。調査時にこのレコードのエラーコードとリクエスト ID を使用し、障害が解決しない場合は AWS サポートにお問い合わせください。*EventBridge は、基盤となるメッセージを渡すと別のサービスの内部が公開される可能性がある場合にこれを使用します。そのため、これらのコードでは、 `errorCode`および `targetRequestId` は、送信されたリクエストを伝達する`EVENT_DELIVERY_ATTEMPT`ログレコードとともに、操作する事実です。同じ値が Amazon SQS メッセージ属性 (`ERROR_CODE`、`ERROR_MESSAGE`、、`SUBSCRIBER_ARN`、、`RETRY_ATTEMPTS`) として到着するため`TARGET_ARN``BUS_ARN``EXHAUSTED_RETRY_CONDITION`、コンシューマーは本文を解析せずにそれらの属性をルーティングできます。FIFO サブスクライバーの場合、FIFO キューをデッドレターキューとして使用します。EventBridge は各レコードの をイベントの `MessageGroupId`から設定するため`EventGroupId`、1 つのグループのレコードは順番に残ります。

配信ロールはキュー`sqs:SendMessage`に が必要です。これがないと、`OnFailureDestinationFailed`メトリクスは書き込めなかった各レコードをカウントし、それらのイベントは失われます。

## デッドレターキューからのイベントの配信
<a name="eb-custom-bus-retry-redrive"></a>

キューはイベントではなくレコードを保持するため、バスからイベントを再生してリドライブします。イベントはバスの保持期間内である必要があります。

1. レコードを読み取り、すべての `failedMessages[].eventId`に加えて、最も古い と最新の を収集します`timestamp`。

1. ロールのポリシー、ターゲット、または式`errorCode`の名前の原因を修正しました。

1. 同じターゲットとロール、 が最も早いタイムスタンプで `StartingPoint`が`EndPoint`最新である`POINT_IN_TIME`開始位置、識別子に対する`SYSTEM_METADATA`フィルターを持つ同じバスにサブスクライバーを作成します。

1. サブスクライバーがイベントを配信したら、イベントを削除し、キューからレコードを削除します。

```
aws eventsv2 create-subscriber \
    --name redrive-2026-09-16 \
    --event-bus-arn arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \
    --starting-position POINT_IN_TIME \
    --point-in-time-configuration '{ "PointType": "TIMESTAMP", "StartingPoint": "2026-09-16T18:40:00Z", "EndPoint": "2026-09-16T18:41:00Z" }' \
    --filter-configuration '{ "Filters": [ { "Scope": "SYSTEM_METADATA", "Pattern": "{\"aws:EventId\":[\"a1b2c3d4-...\",\"e5f6a7b8-...\"]}" } ] }' \
    --invoke-configuration '{ "TargetArn": "arn:aws:sqs:us-east-1:111122223333:large-orders", "RoleArn": "arn:aws:iam::111122223333:role/EventBusDeliveryRole" }'
```

リプレイされたイベントは `aws:DeliveryType` で到着するため`REPLAY`、コンシューマーはライブトラフィックから通知できます。