
Amazon EventBridge の新しいカスタムイベントバスで、Subscriber のターゲットへの再試行が 24 時間継続しない原因を教えてください
困っていること
Amazon EventBridge の新しいカスタムイベントバスに Subscriber を作りました。ターゲットは Amazon Simple Queue Service(Amazon SQS)のキューです。デッドレターキュー(DLQ)にも別のキューを指定しています。
配信用の AWS Identity and Access Management(IAM)ロールの権限が足りず、ターゲットへの配信が失敗していました。私の環境ではイベントを送ってから 2 分 32 秒で、DLQ に次の記録が入りました。
"errorCode": "ACCESS_DENIED",
"exhaustedRetryCondition": "MaximumRetryAttempts",
"retryAttempts": 5,
従来のイベントバスのルールのターゲットは、24 時間・185 回まで再試行されると認識していました。新しいバスでは、再試行の既定が違うのでしょうか。教えてください。
どう対応すればいいの?
新しいカスタムイベントバス(以下、新しいバス)の Subscriber は、RetryPolicy を指定しないと、再試行 5 回と 300 秒のうち、先に達した方で再試行を止めます。
1 日分の再試行が要る場合は、RetryPolicy の MaxRetryAttempts と MaxEventAgeInSeconds の両方を明示してください。
Subscriber は、新しいバス(AWS ドキュメントの表記は Custom Event Bus)で、イベントを 1 つのターゲットに届ける設定のリソースです。
When a target call fails, EventBridge retries it until one of the two limits in RetryPolicy is reached, by default 5 attempts or 300 seconds, then writes a record to the Amazon SQS queue in OnFailureConfiguration.Arn.
一方、従来のバス(AWS ドキュメントの表記は Custom Event Bus - Classic)のターゲットは、既定で 24 時間・185 回まで再試行します。従来のバスと同じだけ再試行させたい場合は、Subscriber ごとに両方の値を明示します。
A subscriber retries a failed delivery for 300 seconds and 5 attempts by default. A Custom Event Bus - Classic target retries for 24 hours and 185 attempts. If your consumers rely on a day of retries during an outage, set RetryPolicy.MaxEventAgeInSeconds to 86,400 and MaxRetryAttempts to 185 on each subscriber, and attach a dead-letter queue.
ただし、従来のバスでも、24 時間・185 回まで再試行されるのは再試行できるエラーだけです。ターゲットへの権限が無いエラーは再試行されません。
For example, for errors that result from missing permissions to a target, a target resource that no longer exists, or a target that cannot be found due to an invalid address or DNS lookup failure, no retry attempts will happen until action is taken to resolve the underlying issue.
確認してみた
東京リージョンで RetryPolicy を指定せずに Subscriber を作ると、MaxRetryAttempts が 5、MaxEventAgeInSeconds が 300 の既定の値が入り、RetryStrategy は ALL でした。

配信用のロールにターゲットへの権限が無い状態で、バスにイベントを 1 件送りました。DLQ の記録は、イベントを送ってから 2 分 32 秒後に届きました。300 秒より先に、5 回の上限で止まっています。新しいバスでは、権限のエラーも上限まで再試行されていました。

DLQ に入るのはイベント本体ではなく、失敗の記録(JSON)です。表示のため、本文を取り出して整形しています。
新しいバスでは、再試行を飛ばして DLQ に入る失敗はありません。
Every failure that reaches the queue was retried first: there is no delivery failure that skips RetryPolicy.
再試行は 2 つの上限のうち、先に達した方で止まります。MaxEventAgeInSeconds だけを 86,400 にしても、MaxRetryAttempts が既定の 5 回のままなら、回数の上限で止まります。この検証では、5 回で止まるまでが 2 分 32 秒でした。
設定方法
Subscriber を作るときに、次の 2 点を設定してください。
RetryPolicyでMaxRetryAttempts(最大 185)とMaxEventAgeInSeconds(86,400)を両方とも明示します。OnFailureConfigurationに DLQ の Amazon SQS キューを指定し、配信用のロールに DLQ へのsqs:SendMessageを許可します。DLQ が無いと、再試行を使い切ったイベントは捨てられ、残るのはEventsDroppedメトリクスだけです。
ただし、上限を大きくすると、権限の誤りのように待っても直らないエラーでも、上限まで再試行が続きます。その分、DLQ に記録が入って失敗に気付くまでの時間が延びます。







