¿Deberías activar los registros de túnel de AWS VPN en un túnel activo?

Activar los registros de actividad del túnel para una VPN de sitio a sitio es un cambio pequeño que puede tumbar el túnel que está midiendo. AWS advierte que habilitar el registro en un túnel existente puede interrumpirlo durante varios minutos, así que la pregunta interesante no es cómo girar la bandera sino en qué túnel girarla y cuándo. Tres condiciones deciden el orden: si el otro túnel transporta realmente las rutas, si necesitas eventos de servicio o eventos BGP, y si el cambio pasa por la consola o por la API de opciones del túnel. Equivócate y acabarás con una interrupción o con un grupo de registros lleno de nada.

Tres condiciones deciden el orden

Empieza por la identidad de lo que estás cambiando. Necesitas el ID de conexión VPN, la región y la dirección IP exterior del túnel concreto, porque cada ajuste de registro de esta función es por túnel y no por conexión. Un cambio aplicado a la dirección exterior equivocada es un cambio en un túnel que nadie estaba depurando.

El destino es un grupo de registros de CloudWatch en la misma región, con la retención y la política de acceso que realmente quieres. AWS recomienda el prefijo /aws/vendedlogs/ para estos grupos porque evita los límites de tamaño de política de recursos que los nombres simples pueden encontrar. Un nombre como /aws/vendedlogs/vpn/branch-a-activity es solo ilustrativo; lo que importa es que el grupo exista, que el rol de entrega pueda escribir en él y que ambos los gestione quien posee la configuración de la VPN. El nombre no concede permisos, y un grupo creado sin la política de entrega produce silencio en lugar de un error.

Condición uno: un túnel redundante que realmente lleve tráfico

Esta es la condición que los equipos se saltan. Dos túneles configurados no son prueba de que la aplicación tenga una ruta alternativa utilizable.

Antes de tocar un túnel, confirma que el otro lleva las rutas que importan: revisa la tabla de enrutamiento del lado de la puerta de enlace del cliente y confirma que la aplicación puede realmente conmutar por error. La ventana de interrupción de AWS es de minutos, no de segundos, y un túnel que solo existe sobre el papel convierte un cambio de diagnóstico en una caída. Si la ruta redundante no está probada, programa el cambio con el mismo cuidado que cualquier otro cambio de enrutamiento en lugar de tratar el registro como pasivo. Instrumenta el túnel cuyo comportamiento intentas explicar, no el que es más fácil de alcanzar.

Condición dos: registro de actividad o registro BGP

Esta decide qué vas a poder leer realmente. Los registros de actividad cubren eventos de servicio como las transiciones de estado de IKE e IPsec y los mensajes DPD, que es lo que quieres cuando el túnel no levanta o no deja de renovar claves. Los registros BGP son un flujo aparte con sus propios controles, y responden a una pregunta distinta: si las rutas se intercambiaron y retiraron como se esperaba.

Activar la bandera de actividad no es una petición para todos los flujos que el servicio puede emitir. Si la sospecha es el enrutamiento, activa ambos; si la sospecha es la negociación de la fase 1 o la fase 2, el flujo de actividad es el que lo mostrará.

Ninguno de los dos flujos es una captura de paquetes, y esa distinción resuelve más tickets de los que debería. Los registros de actividad y BGP te dicen qué hizo el servicio con el túnel y la sesión, no qué envió tu aplicación a través de él. Recurrir a los registros del túnel para depurar un tiempo de espera de la aplicación es un error de categoría, y normalmente cuesta una ventana de interrupción antes de que nadie lo note. Elige primero la pregunta, después el flujo que puede responderla.

Condición tres: cambio por consola o API de opciones del túnel

Si una persona hace un cambio puntual, el camino por la consola está bien: VPC console, Site-to-Site VPN connections, selecciona la conexión, Actions, Modify VPN tunnel options, elige la IP exterior, activa Tunnel activity log, elige el grupo y el formato de salida, guarda dentro de la ventana. Si la VPN se gestiona como código, el mismo clic es una deriva que reconciliarás más tarde.

Para la automatización, la parte de registro de actividad de las opciones del túnel tiene una forma fija: LogOptions que contiene CloudWatchLogOptions con LogEnabled, LogGroupArn y LogOutputFormat. Ese bloque es un fragmento, no una petición; modify-vpn-tunnel-options todavía necesita el ID de conexión y la IP exterior del túnel, y el resto de ajustes del túnel los debe preservar quien posee la plantilla. El registro BGP usa sus propias claves BgpLogEnabled, BgpLogGroupArn y BgpLogOutputFormat en la misma estructura. Vuelve a leer el cambio con describe-vpn-connections en lugar de confiar en que la llamada se aplicó.

Qué pueden y qué no pueden decirte los registros

Cuando el primer túnel esté hecho y la ruta prevista esté disponible, repite la misma secuencia controlada para el segundo túnel si también necesitas sus registros. Un túnel a la vez es todo el sentido.

Los registros llegan en flujos identificados por la conexión y la dirección exterior del túnel, así que correlaciona con esa identidad en lugar de esperar que el historial aparezca retroactivamente. Nada antes del cambio existe, y ninguna espera llena el hueco. Si necesitas una línea base, captura el estado actual del túnel y la tabla de enrutamiento antes del cambio para que haya algo con lo que comparar.

Mantén el grupo de registros, su retención, sus permisos de entrega y el bloque de opciones del túnel en el mismo inventario que la propia VPN, porque son una sola configuración repartida en cuatro sitios. El procedimiento de AWS para activar los registros documenta el flujo de trabajo por túnel y su aviso de interrupción, y vale la pena leerlo antes del cambio y no después. Luego verifica en orden: el túnel volvió, los registros aparecen en el flujo esperado y los registros responden a la pregunta por la que abriste el ticket. Si el tercero falla, el problema era la elección del flujo y no el registro.