Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Políticas de reintentos y colas de mensajes muertos

Cuando se produce un error en RetryPolicy una llamada de destino, EventBridge vuelve a intentarlo hasta alcanzar uno de los dos límites establecidos (5 intentos o 300 segundos de forma predeterminada) y, a continuación, escribe un registro en la cola de Amazon SQS. OnFailureConfiguration.Arn Configure ambos al crear el suscriptor: si no hay una cola de mensajes muertos, se descarta un evento que agote sus reintentos y el único seguimiento es la métrica. EventsDropped

Límites de reintentos

La entrega se detiene en el límite que se alcance primero.

Los valores predeterminados son más cortos que los de un bus de eventos personalizado: el objetivo clásico es de 24 horas y 185 intentos. Un diseño migrado que dependiera de un día de reintentos debe establecerse MaxEventAgeInSeconds en 86.400 de forma explícita; de lo contrario, los eventos que fallan durante una interrupción prevista de más de 5 minutos pasan a la cola de correo muerto en lugar de entregarse tarde. En el caso de un suscriptor de FIFO, un evento fallido bloquea los eventos posteriores de su grupo mientras se vuelva a intentar, por lo que un período de reintento prolongado cambia el orden por la latencia.

El récord de cartas muertas

El registro es un documento JSON, no el evento. El siguiente ejemplo muestra un registro para dos eventos que fallaron juntos en un lote.

{
    "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": "..." }
    ]
}

Todos los errores que llegaban a la cola se volvían a intentar primero: no hay ningún error de entrega que se salte. RetryPolicy Los errores internos EventBridge se vuelven a intentar EventBridge sin límite y nunca producen un registro. En la siguiente tabla se enumeran los códigos que puede contener un registro. errorMessagese trunca a 1.024 caracteres.

El mensaje genérico es Se ha producido un error en la entrega. Utilice el código de error y el identificador de solicitud de este registro al investigar y póngase en contacto con el servicio de AWS asistencia si el error persiste. EventBridge lo utiliza siempre que la transmisión del mensaje subyacente pueda poner al descubierto los aspectos internos de otro servicio, por lo que esos códigos targetRequestId son los datos con los que trabajar, junto con los EVENT_DELIVERY_ATTEMPT registros que contienen la solicitud que se ha enviado. errorCode Llegan los mismos valores que los atributos de los mensajes de Amazon SQS (ERROR_CODEERROR_MESSAGE,,SUBSCRIBER_ARN,TARGET_ARN,BUS_ARN,RETRY_ATTEMPTS)EXHAUSTED_RETRY_CONDITION, por lo que un consumidor puede direccionarlos sin necesidad de analizar el cuerpo. Para un suscriptor de FIFO, utilice una cola FIFO como cola de mensajes muertos; EventBridge establece cada registro a MessageGroupId partir de los eventosEventGroupId, de modo que los registros de un grupo se mantengan en orden.

El rol de entrega debe estar en la lista de espera. sqs:SendMessage Sin ella, la OnFailureDestinationFailed métrica cuenta cada registro que no se pudo escribir y esos eventos se pierden.

Redirigir los eventos de la cola de mensajes muertos

La cola contiene registros, no eventos, por lo que puedes reconducir reproduciendo los eventos del autobús. Los eventos deben seguir dentro del período de retención del autobús.

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" }'

Los eventos reproducidos llegan con ellos aws:DeliveryTypeREPLAY, por lo que el consumidor puede distinguirlos a partir del tráfico en vivo.