Um serviço de monitoramento baseado em ML está configurado como um destino de API do EventBridge para consumir eventos do Auto Scaling. O CloudWatch indica que a regra do EventBridge está sendo acionada, mas o serviço de monitoramento não está recebendo os eventos. O administrador SysOps deseja capturar detalhes de erros do cliente com o mínimo esforço operacional. Qual solução deve ser implementada?

Anexar uma fila padrão do Amazon SQS como uma dead-letter queue (DLQ) para o destino do EventBridge é a solução mais eficiente e de menor esforço operacional para capturar detalhes de erros. Quando o EventBridge não consegue entregar um evento a um destino (neste caso, o serviço de monitoramento baseado em ML), ele envia o evento para a DLQ, juntamente com informações sobre o erro de entrega. Isso permite inspecionar as mensagens na fila para entender por que o serviço de monitoramento não está recebendo os eventos, sem a necessidade de modificar a lógica de negócios existente ou adicionar componentes complexos. As outras opções são menos ideais: Criar um arquivo do EventBridge e reproduzir eventos exige esforço manual e não captura os erros de entrega originais em tempo real. Criar uma segunda regra do EventBridge com uma função Lambda adiciona complexidade e custo, e a função Lambda teria que ser configurada para lidar com a lógica de reenvio e registro de erros, o que é mais complexo do que usar uma DLQ. Configurar a regra para publicar mensagens de erro em um tópico do Amazon SNS notificaria sobre erros, mas não forneceria os detalhes completos dos eventos falhos para depuração, como faria uma DLQ.