EventBridge rule DLQs: distinguish target delivery from business completion

Event routing success is not business completion

An EventBridge rule can match an event yet fail to deliver it to a target. Even a successful target invocation may not prove that an asynchronous business operation completed. A reliable design records both the transport boundary and the application's processing outcome.

This guide specifically concerns EventBridge event-bus rule targets and their supported dead-letter queues. Other EventBridge delivery models can have different retry semantics. Verify the product path instead of copying retry defaults from a similarly named feature.

Setup: define failure retention before the first incident

Record the bus, rule, target, Region and target authorization. Configure the intended retry policy and a supported target DLQ with the required queue access policy. Confirm queue type, retention, access control and ownership. The DLQ must be able to accept events when the target cannot.

A useful design worksheet is:

Rule target and authorization owner:
Retry age and attempt budget:
DLQ identity, retention and access policy:
Business event key and reconciliation store:
Replay approval and duplicate protection:

Populate it from the actual configuration. Some failures are handled differently from retriable service errors, so inspect the recorded failure rather than assuming every event always follows an identical retry sequence.

Illustrative incident: a target permission change causes a backlog

In this fictional example, a target's resource policy is changed and matched events stop reaching it. Retained failed events appear in the target DLQ. The team restores the intended permission but does not immediately replay the entire queue at full speed.

It first checks which business operations are absent, whether any target accepted an earlier attempt and how duplicate requests are handled. The correction of transport permissions and the recovery of missing business work are tracked as two separate milestones.

Troubleshooting: inspect the failed delivery contract

Keep event payloads access-controlled; they may contain customer or operational data. Preserve event identifiers, failure metadata and timestamps in the incident record. A queue-depth chart is useful for impact estimation but does not by itself identify which business records need recovery.

Restore delivery and replay with bounded ownership

Repair the evidenced target or queue permission using the narrow intended trust relationship. Test a controlled fresh event before replaying retained work. Then choose a reviewed replay path with a rate bound, an operator, an abort condition and application-side duplicate handling.

Do not treat a DLQ as an automatic exactly-once recovery mechanism. A business operation may need reconciliation against its own completion record. Queue retention and replay tools also need to match the event path; generic redrive assumptions from another service can be wrong here.

Verification, alerting and SOP

Confirm new matched events reach the intended target and produce the expected business completion record. Reconcile retained events through the approved replay process, then verify no unexplained gaps or duplicates remain. Keep a record of events intentionally excluded from replay and the authorized reason.

Monitor invocation failures, failure-path delivery and oldest unresolved business work. An internal SLO can define reconciliation within a bounded recovery window; a customer SLA needs separate end-to-end terms. The SOP should name rule and queue owners, delivery budgets, retention, replay authority, idempotency keys, audit evidence and escalation when the failure path itself is unavailable.

See Clouvenix devops automation for a reviewed implementation and operational handover.

Technical reference

AWS EventBridge rule retry policy, AWS EventBridge target DLQs. Reviewed 19 October 2026; use documentation for the installed product and release.