Aplicativos híbridos usam recursos tanto on-premises quanto na AWS. Os usuários às vezes relatam que os aplicativos estão indisponíveis. Um alarme do CloudWatch já monitora o status do túnel da VPN Site-to-Site. A equipe de operações precisa que tickets de alta prioridade sejam criados automaticamente em um sistema de tickets interno quando o túnel VPN cair. Qual design atende a essa necessidade?

A opção correta é criar um tópico do Amazon SNS e assinar o endpoint do sistema de tickets a ele. O Amazon CloudWatch pode enviar notificações para um tópico SNS quando o alarme de status do túnel VPN for acionado. O SNS, por sua vez, pode entregar essa notificação para um endpoint HTTP/HTTPS, que é como muitos sistemas de tickets internos recebem eventos. As outras opções são menos eficientes ou não são a melhor prática: Configurar uma fila SQS como destino do alarme do CloudWatch exigiria um componente adicional (como uma função Lambda) para processar as mensagens da fila e criar os tickets, adicionando complexidade desnecessária. Anexar uma função Lambda diretamente ao alarme do CloudWatch é uma solução viável, mas o SNS é a forma mais direta e gerenciada de enviar notificações para endpoints externos, especialmente quando o sistema de tickets já suporta a integração via HTTP/HTTPS. Criar uma regra do EventBridge para monitorar a integridade do túnel VPN diretamente não é a abordagem ideal, pois o CloudWatch já está monitorando o status do túnel e pode acionar ações diretamente. O EventBridge é mais adequado para eventos de serviços AWS ou eventos personalizados, enquanto o CloudWatch é o serviço primário para monitoramento e alarmes.