Las aplicaciones híbridas utilizan recursos tanto on-premises como en AWS. Los usuarios a veces informan que las aplicaciones no están disponibles. Una alarma de CloudWatch ya monitorea el estado del túnel de la Site-to-Site VPN. El equipo de operaciones necesita que se creen tickets de alta prioridad automáticamente en un sistema de tickets interno cuando el túnel VPN se caiga. ¿Qué diseño satisface esta necesidad?

La opción correcta es crear un tema de Amazon SNS para la alarma de CloudWatch y suscribir el endpoint del sistema de tickets a ese tema. Cuando la alarma de CloudWatch detecta que el túnel VPN está caído, publicará un mensaje en el tema de SNS. SNS puede enviar notificaciones a varios tipos de endpoints, incluyendo HTTP/S, lo que permite integrar fácilmente con un sistema de tickets interno que exponga un endpoint. Las otras opciones son menos eficientes o no son directamente aplicables: Configurar una cola SQS como objetivo de la alarma de CloudWatch requeriría un componente adicional (como una función Lambda) para procesar los mensajes de la cola y convertirlos en tickets, añadiendo complejidad innecesaria. Adjuntar una función Lambda directamente a la alarma de CloudWatch es posible, pero SNS es una solución más escalable y desacoplada para distribuir notificaciones a múltiples suscriptores, y es la forma estándar de integrar CloudWatch con sistemas externos para notificaciones. Crear una regla de EventBridge que monitoree directamente el estado del túnel VPN no es la forma más directa de reaccionar a una alarma de CloudWatch ya existente. La alarma de CloudWatch ya está configurada para detectar el estado del túnel, y SNS es el servicio diseñado para distribuir esas notificaciones.