Obtener información sobre cómo configurar un redireccionamiento de cola de mensajes fallidos en Amazon SQS - Amazon Simple Queue Service

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.

Obtener información sobre cómo configurar un redireccionamiento de cola de mensajes fallidos en Amazon SQS

Utilice el redireccionamiento de la cola de cartas sin procesar para mover los mensajes no consumidos de una cola de cartas sin salida a otro destino para su procesamiento. De forma predeterminada, el redireccionamiento de cola de mensajes fallidos mueve los mensajes de una cola de mensajes fallidos a una cola de origen. No obstante, también puede configurar cualquier otra cola estándar como destino de redireccionamiento si las colas son del mismo tipo. Por ejemplo, si la cola de mensajes fallidos es una cola FIFO, la cola de destino de redireccionamiento también debe ser una cola FIFO. Además, puede configurar la velocidad de redireccionamiento para establecer a qué velocidad Amazon SQS mueve los mensajes.

nota

Cuando un mensaje pasa de una cola FIFO a una DLQ FIFO, el ID de desduplicación del mensaje original se reemplazará por el ID del mensaje original. Esto es para asegurarse de que la desduplicación de DLQ no impedirá el almacenamiento de dos mensajes independientes que casualmente comparten un ID de desduplicación.

Las colas de mensajes fallidos redirigen los mensajes en el orden en que se reciben, empezando por el mensaje más antiguo. Sin embargo, la cola de destino ingiere los mensajes redirigidos, así como los mensajes nuevos de otros productores, según el orden en que los recibe. Por ejemplo, si un productor envía mensajes a una cola FIFO de origen cuando de forma simultánea recibe mensajes redirigidos de una cola de mensajes fallidos, los mensajes redirigidos se entrelazarán con los nuevos mensajes del productor.

nota

La tarea de redireccionamiento restablece el periodo de retención. Todos los mensajes redirigidos se consideran mensajes nuevos con un messageID y un enqueueTime nuevos y se asignan a mensajes redirigidos.

Configuración de un redireccionamiento de cola de mensajes fallidos para una cola estándar existente mediante la API de Amazon SQS

Puede configurar un redireccionamiento cola de mensajes fallidos con las acciones de la API StartMessageMoveTask, ListMessageMoveTasks y CancelMessageMoveTask:

Acción de la API Descripción

StartMessageMoveTask

Inicia una tarea asincrónica para mover mensajes de una cola de origen especificada a una cola de destino especificada.

ListMessageMoveTasks

Obtiene las tareas de movimiento de mensajes más recientes (hasta diez) en una cola de origen específica.

CancelMessageMoveTask

Cancela una tarea de movimiento de mensajes especificada. Un movimiento de mensajes solo puede cancelarse cuando el estado actual es EN EJECUCIÓN.

Configuración de un redireccionamiento de cola de mensajes fallidos para una cola estándar mediante la consola de Amazon SQS

  1. Abra la consola Amazon SQS en. https://console.aws.amazon.com/sqs/

  2. En el panel de navegación, elija Colas.

  3. Elija el nombre de la cola que haya configurado como una cola de mensajes fallidos.

  4. Seleccione Iniciar el redireccionamiento de la DLQ.

  5. En Redireccionar configuración, para Destino del mensaje, realice una de las siguientes acciones:

    • Para redireccionar mensajes a su cola de origen, seleccione Redireccionar a las colas de origen.

    • Para redireccionar mensajes a otra cola, elija Redireccionar a un destino personalizado. A continuación, escriba el nombre de recurso de Amazon (ARN) de una cola de destino existente.

  6. En Configuración de control de velocidad, elija una de las siguientes opciones:

    • Sistema optimizado: redireccionar la cola de mensajes fallidos al número máximo de mensajes por segundo.

    • Velocidad máxima personalizada: redireccionar mensajes de la cola de mensajes fallidos con una velocidad máxima personalizada de mensajes por segundo. La velocidad máxima permitida es de 500 mensajes por segundo.

      • Se recomienda empezar con un valor pequeño para la velocidad máxima personalizada y comprobar que la cola de origen no se satura de mensajes. A partir de ahí, aumente gradualmente el valor de la velocidad máxima personalizada, sin dejar de monitorear el estado de la cola de origen.

  7. Cuando termine de configurar el redireccionamiento de la cola de mensajes fallidos, elija Redireccionar mensajes.

    importante

    Amazon SQS no admite el filtrado y la modificación de mensajes mientras los redirecciona desde la cola de mensajes fallidos.

    Una tarea de redireccionamiento de cola de mensajes fallidos puede ejecutarse un máximo de 36 horas. Amazon SQS admite un máximo de 100 tareas de redireccionamiento activas por cuenta.

  8. Si desea cancelar la tarea de redireccionamiento de mensajes, en la página Detalles de la cola, elija Cancelar redireccionamiento de DLQ. Al cancelar un redireccionamiento de mensajes en curso, los mensajes que ya se hayan movido correctamente a su cola de destino de movimiento permanecerán en ella.

Configuración de los permisos del redireccionamiento de cola de mensajes fallidos

Puede conceder al usuario acceso a acciones específicas de la cola de mensajes fallidos si agrega permisos a la política. Los permisos mínimos necesarios para un redireccionamiento de cola de mensajes fallidos son los siguientes:

Permisos mínimos Métodos de API necesarios
Inicio de un redireccionamiento de mensajes
  • Agregue sqs:StartMessageMoveTask, sqs:ReceiveMessage, sqs:DeleteMessage y sqs:GetQueueAttributes de la cola de mensajes fallidos. Si la cola de mensajes fallidos o la cola de origen están cifradas (conocida como cola SSE), también se necesita kms:Decrypt para cualquier clave de KMS que se haya utilizado para cifrar los mensajes.

  • Agregue sqs:SendMessage de la cola de destino. Si la cola de destino está cifrada, también se requieren kms:GenerateDataKey y kms:Decrypt.

Cancelación de un redireccionamiento de mensajes en curso
  • Agregue sqs:CancelMessageMoveTask, sqs:ReceiveMessage, sqs:DeleteMessage y sqs:GetQueueAttributes de la cola de mensajes fallidos. Si la cola de mensajes fallidos está cifrada (conocida como cola SSE), también se requiere kms:Decrypt.

Visualización del estado de movimiento de mensajes
  • Agregue sqs:ListMessageMoveTasks y sqs:GetQueueAttributes de la cola de mensajes fallidos.

Configuración de los permisos de un par de colas cifradas (una cola de origen con una cola de mensajes fallidos)

Siga los siguientes pasos para configurar los permisos mínimos para una reunidad de cola de cartas muertas (DLQ):

  1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.

  2. En el panel de navegación, seleccione Policies (Políticas).

  3. Cree una nueva política y añada los siguientes permisos. Adjunte la política al usuario o rol de IAM que realizará la operación de redrive.

    • Permisos para la DLQ (cola de fuentes):

      • sqs:StartMessageMoveTask

      • sqs:CancelMessageMoveTask

      • sqs:ListMessageMoveTasks

      • sqs:ReceiveMessage

      • sqs:DeleteMessage

      • sqs:GetQueueAttributes

      • sqs:ListDeadLetterSourceQueues

      • Especifique el ARN del recurso del DLQ (cola de fuentes) (por ejemplo, «arn:aws:sqs::: «). <DLQ_region> <DLQ_accountId> <DLQ_name>

    • Permisos para la cola de destino:

      • sqs:SendMessage

      • Especifique la cola Resource ARN de destino (por ejemplo, «arn:aws:sqs: «). <DestQueue_region>:<DestQueue_accountId>:<DestQueue_name>

    • Permisos para las claves KMS:

      • kms:Decrypt(Necesario para descifrar los mensajes del DLQ).

      • kms:GenerateDataKey(Necesario para cifrar los mensajes de la cola de destino).

        • Resource ARNs:

          • El ARN de la clave KMS utilizada para cifrar los mensajes de la DLQ (cola de origen) (por ejemplo, «arn:aws:kms: ::key/ «). <region> <accountId> <SourceQueueKeyId>

          • El ARN de la clave KMS utilizada para cifrar los mensajes de la cola de destino (por ejemplo, «arn:aws:kms: ::key/ «). <region> <accountId> <DestinationQueueKeyId>

    Su política de acceso debe ser similar a la siguiente:

    JSON
    { "Version": "2012-10-17" , "Statement": [ { "Effect": "Allow", "Action": [ "sqs:StartMessageMoveTask", "sqs:CancelMessageMoveTask", "sqs:ListMessageMoveTasks", "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:ListDeadLetterSourceQueues" ], "Resource": "arn:aws:sqs:us-west-1:123456789012:<DLQ_name>", "Condition": { "StringEquals": { "aws:ResourceTag/QueueRole": "source" } } }, { "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:us-west-1:123456789012:<DestQueue_name>", "Condition": { "StringEquals": { "aws:ResourceTag/QueueRole": "destination" } } }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:us-west-1:123456789012:key/<SourceQueueKeyId>", "arn:aws:kms:us-west-1:123456789012:key/<DestQueueKeyId>" ] } ] }
Configuración de los permisos mediante un par de colas no cifradas (una cola de origen con una cola de mensajes fallidos)

Siga estos pasos para configurar los permisos mínimos necesarios para gestionar una cola de cartas sin procesar (DLQ) estándar y sin cifrar. Los permisos mínimos requeridos son recibir, eliminar y obtener atributos de la cola de mensajes fallidos, y enviar atributos a la cola de origen.

  1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.

  2. En el panel de navegación, seleccione Policies (Políticas).

  3. Cree una nueva política y añada los siguientes permisos. Adjunte la política al usuario o rol de IAM que realizará la operación de redrive.

    • Permisos para la DLQ (cola de fuentes):

      • sqs:StartMessageMoveTask

      • sqs:CancelMessageMoveTask

      • sqs:ListMessageMoveTasks

      • sqs:ReceiveMessage

      • sqs:DeleteMessage

      • sqs:ListDeadLetterSourceQueues

      • Especifique el ARN del recurso del DLQ (cola de fuentes) (por ejemplo, «arn:aws:sqs::: «). <DLQ_region> <DLQ_accountId> <DLQ_name>

    • Permisos para la cola de destino:

      • sqs:SendMessage

      • Especifique la cola Resource ARN de destino (por ejemplo, «arn:aws:sqs: «). <DestQueue_region>:<DestQueue_accountId>:<DestQueue_name>

    Su política de acceso debe ser similar a la siguiente:

    JSON
    { "Version": "2012-10-17" , "Statement": [ { "Effect": "Allow", "Action": [ "sqs:StartMessageMoveTask", "sqs:CancelMessageMoveTask", "sqs:ListMessageMoveTasks", "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:ListDeadLetterSourceQueues" ], "Resource": "arn:aws:sqs:us-west-1:111122223333:<DLQ_name>", "Condition": { "StringEquals": { "aws:ResourceTag/QueueRole": "source" } } }, { "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:us-west-1:111122223333:<DestQueue_name>", "Condition": { "StringEquals": { "aws:ResourceTag/QueueRole": "destination" } } } ] }

Uso del redrive de colas de letra muerta con control de acceso a puntos finales de VPC

Si restringes el acceso a las colas a un VPCs uso específico de la aws:sourceVpc condición, debes hacer una excepción en el caso de los AWS servicios para habilitar la funcionalidad de redireccionamiento de colas con letra muerta (DLQ). Esto se debe a que el servicio Amazon SQS funciona fuera de la VPC al mover los mensajes.

Para permitir las operaciones de redrive de DLQ, añada la aws:CalledViaLast condición a su política de colas. Esto permite a Amazon SQS realizar llamadas a la API en su nombre y, al mismo tiempo, mantener las restricciones de VPC para el acceso directo.

Para permitir tanto el acceso restringido por VPC como la retransmisión de DLQ:

  1. Usa la aws:CalledViaLast condición en tu política de colas.

  2. Aplique la política tanto a la cola de origen como a la DLQ

  3. Mantenga las restricciones de VPC para el acceso directo desde otras fuentes

A continuación, se muestra un ejemplo de política que implementa estos requisitos:

{ "Version": "2012-10-17", "Id": "SQSRedriveWithVpcRestriction", "Statement": [ { "Sid": "DenyOutsideVPCUnlessAWSService_DestQueue", "Effect": "Deny", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:DestQueue", "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-1234567890abcdef0" }, "StringNotEqualsIfExists": { "aws:CalledViaLast": "sqs.amazonaws.com" } } }, { "Sid": "DenyOutsideVPCUnlessAWSService_DLQ", "Effect": "Deny", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:Dlq", "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-1234567890abcdef0" }, "StringNotEqualsIfExists": { "aws:CalledViaLast": "sqs.amazonaws.com" } } } ] }
  • Sustituya los valores de los marcadores de posición por sus valores reales

  • Esta política utiliza una declaración de «denegar» con condiciones, que es más segura que utilizar declaraciones de «permitir»

  • El StringNotEqualsIfExists operador gestiona los casos en los que la clave de condición podría no estar presente en el contexto de la solicitud.

Como alternativa, puedes usar la clave de aws:ViaAWSService condición para permitir el acceso basado en el servicio y, al mismo tiempo, mantener las restricciones de VPC. Esta clave de condición indica si la solicitud proviene de un AWS servicio. A continuación, se muestra un ejemplo de política que utiliza aws:ViaAWSService en lugar deaws:CalledViaLast:

{ "Version": "2012-10-17", "Id": "SQSRedriveWithVpcRestriction", "Statement": [ { "Sid": "DenyOutsideVPCUnlessAWSService_DestQueue", "Effect": "Deny", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:DestQueue", "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-1234567890abcdef0" }, "BoolIfExists": { "aws:ViaAWSService": "false" } } }, { "Sid": "DenyOutsideVPCUnlessAWSService_DLQ", "Effect": "Deny", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:Dlq", "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-1234567890abcdef0" }, "BoolIfExists": { "aws:ViaAWSService": "false" } } } ] }

El BoolIfExists operador con la aws:ViaAWSService condición garantiza que se permitan las solicitudes cuando provienen de servicios y, al mismo tiempo, mantiene las restricciones de VPC para el acceso directo. Esto puede ser más fácil de entender y mantener, ya que comprueba directamente si la solicitud la ha realizado un AWS servicio en lugar de comprobar qué servicio realizó la última llamada.

Para obtener más información sobre las claves de condición utilizadas en las políticas de recursos y de IAM, consulte Elementos de la política JSON de IAM: condición.