Aviso de AWS de un solo túnel: cuándo importa de verdad

Un aviso de AWS Health que dice que un túnel está caído suele llegar cuando nada parece roto. Es exactamente por eso que se descarta. El aviso no describe una caída; describe un estado de redundancia que ha persistido más allá de la ventana de observación de AWS. Que actúe o no depende de lo que su diseño pueda soportar, no de cómo se sienta el panel.

Qué midió realmente el aviso

Cada conexión Site-to-Site tiene dos túneles, terminados en puntos de conexión de AWS distintos. La documentación de monitoreo de AWS recomienda configurar ambos para la redundancia y eleva la notificación cuando uno permanece caído durante el período documentado. Ese período importa, porque un parpadeo y una pérdida permanente se ven idénticos en un solo gráfico.

Lea la telemetría por túnel en lugar del estado general de la conexión. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' devuelve un estado y un mensaje para cada túnel, y esa es la evidencia en la que se basa el aviso.

Tres condiciones que deciden su respuesta

Repase las tres antes de decidir si esto es un ticket o un encogimiento de hombros.

Primero, ¿puede el túnel superviviente llevar la carga, incluido cualquier techo de ancho de banda y los prefijos que anuncia? Segundo, ¿ocurre realmente la conmutación por error, dado que un segundo túnel caído desde su creación nunca se ha demostrado que suba? Tercero, ¿su próximo cambio planificado tumbaría ambos túneles a la vez, lo que convierte un aviso cosmético en un problema de ventana de mantenimiento. Si alguna respuesta es no o desconocida, el aviso es un hallazgo real.

Si las tres están demostrablemente bien, anote por qué es tolerable y siga adelante. Esa nota vale más que la discusión el próximo trimestre.

Lo que un par de reserva no demuestra

Una puerta de enlace de cliente con un par de reserva configurado no es prueba de que AWS vea dos túneles sanos. El lado del cliente puede mantener un par frío que necesite una negociación nueva, y eso puede ser un diseño legítimo. Aun así no es la misma observación que dos túneles vivos.

Dos routers físicos tampoco arreglan el caso opuesto. Cuando ambos túneles terminan en un solo dispositivo o salen por un solo enlace ascendente, la redundancia existe solo sobre el papel.

Ajuste el cambio a su radio de impacto

La documentación de sustitución de puntos de conexión de AWS separa los casos, y la distinción es fácil de pasar por alto. Las actualizaciones gestionadas por AWS se aplican a un túnel a la vez. Los cambios iniciados por el cliente en la puerta de enlace de destino, la puerta de enlace de cliente o las opciones de conexión dejan ambos túneles no disponibles mientras se aprovisionan puntos de conexión de reemplazo.

Cambiar opciones en un solo túnel es un tercer caso con su propio impacto declarado: ese túnel no está disponible durante su propia actualización y el otro sigue funcionando.

Demuestre la alternativa antes de necesitarla

Programe la prueba en lugar de esperar el suceso. Baje el túnel sano dentro de una ventana de mantenimiento, confirme que la alternativa negocia, y luego confirme que el tráfico real la atraviesa en ambos sentidos. Compruebe el enrutamiento de retorno además del estado del túnel, porque un desajuste de la segunda fase deja el túnel arriba y la carga de trabajo muerta. Mida la transición mientras está allí.

Guarde el aviso, la salida de telemetría y el plan de cambios en un solo registro. Ese registro convierte el aviso del próximo trimestre en una revisión de dos minutos en lugar de un debate sobre si alguien ha probado alguna vez la reserva.