Introducción
Operar una red híbrida distribuida geográficamente presenta un desafío constante cuando se requiere mantenimiento programado de la conectividad física. El objetivo habitual es retirar un enlace de AWS Direct Connect sin provocar interrupciones en el servicio ni degradar la latencia de las regiones que no están siendo intervenidas. En arquitecturas multi-región, una configuración inadecuada puede causar que todo el tráfico egress se desvíe hacia una única ubicación remota, incrementando la latencia y los costos de transferencia de datos entre regiones.
DeepL, proveedor de soluciones de IA lingüística con presencia en Europa, Norteamérica y Asia, enfrenta este escenario diariamente. Su infraestructura conecta múltiples VPCs en seis regiones de AWS con dos centros de datos europeos mediante una red MPLS resiliente. La necesidad técnica era clara: drenar el tráfico de un enlace específico en Dublín para mantenimiento, asegurando que las regiones Frankfurt (eu-central-1) y Estocolmo (eu-north-1) continuaran utilizando sus salidas locales más cercanas. Este caso ilustra cómo la comprensión profunda de la jerarquía de decisión BGP dentro de AWS Cloud WAN permite lograr esto sin desplegar políticas de ruteo complejas ni modificar atributos globales que afecten a toda la red.
Qué ocurrió
La arquitectura de conectividad de DeepL se basa en el comportamiento por defecto de «closest-exit» egress. En estado estable, el tráfico originado en una región AWS sale hacia los centros de datos on-premises a través de la ubicación Direct Connect geográficamente más cercana. Por ejemplo, el tráfico de eu-west-1 (Irlanda) sale por Dublín, mientras que el de eu-central-1 (Alemania) lo hace por Copenhague. Esta configuración minimiza la latencia y simplifica la gestión operativa al no requerir ingeniería de tráfico manual constante.
El evento crítico fue una ventana de mantenimiento programada para el router en la ubicación Direct Connect de Dublín. El equipo técnico necesitaba mover el tráfico fuera de ese enlace específico antes de apagarlo físicamente, pero sin alterar las rutas utilizadas por el resto de las regiones. Una aproximación ingenua podría haber implicado retirar las rutas BGP o modificar atributos locales globales, opciones que habrían provocado una reevaluación de rutas en todo el core network. DeepL optó por una intervención quirúrgica: aplicar un AS_PATH prepend desde los routers on-premises hacia la interfaz virtual (VIF) de Dublín, aprovechando cómo el borde del core network evalúa las longitudes de AS_PATH para seleccionar la mejor ruta localmente en cada región.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de infraestructura y SRE que gestionan redes híbridas a escala, este caso demuestra que el mantenimiento no tiene por qué ser disruptivo si se entiende el plano de control. El impacto directo fue la continuidad del servicio sin pérdida de paquetes durante la transición de rutas. Al mantener las sesiones BGP activas y modificar solo la atribución de preferencia de ruta, DeepL evitó los «convergence gaps» asociados con el retiro de rutas BGP standard, donde existen ventanas temporales de incertidumbre en la tabla de ruteo.
Desde la perspectiva de costos y performance, el impacto se concentra en el tráfico de la región afectada durante el mantenimiento. El tráfico de eu-west-1 se re-rutea hacia otra ubicación Direct Connect disponible (por ejemplo, a través de las rutas aprendidas desde pares de edges), lo que implica una transferencia de datos inter-región dentro del core network de AWS Cloud WAN. Sin embargo, este costo y latencia adicional es temporal y aislado. Las regiones eu-central-1 y eu-north-1 no experimentaron cambios en su ruta egress, preservando sus métricas de latencia locales. Esto valida que el aislamiento del blast radius del mantenimiento está correctamente implementado, un indicador clave de salud para arquitecturas resilientes.
Detalles técnicos
La selección de rutas en esta arquitectura ocurre en dos niveles distintos dentro de AWS Cloud WAN, y la solución depende de la jerarquía estricta de estos procesos. Primero, el Direct Connect Gateway (DC GW) evalúa las rutas según el atributo local preference BGP. Por defecto, AWS asigna una comunidad local preference media (7224:7200) a las ubicaciones Direct Connect asociadas con la región de origen del tráfico. Este atributo tiene prioridad sobre el AS_PATH. Si DeepL hubiera intentado modificar la preferencia globalmente mediante comunidades en el anuncio del prefijo /16, habría afectado la decisión del DC GW para todas las regiones simultáneamente, rompiendo el closest-exit para Frankfurt y Estocolmo.
La clave técnica reside en que los atributos de comunidad BGP del Direct Connect Gateway no influyen directamente en las decisiones de ruteo del Core Network Edge (CNE). Cada CNE recibe las rutas desde el DC GW con la AS_PATH preservada, pero también aprende las mismas rutas desde sus pares CNE a través del core network. Estas rutas peer tienen una longitud de AS_PATH mayor porque los edges vecinos agregan su propio ASN. El CNE evalúa la longitud de AS_PATH como desempate principal después de otras consideraciones internas. Al realizar un prepend en el anuncio on-premises hacia Dublín, DeepL incrementó artificialmente la longitud de AS_PATH para esa ruta específica. Como resultado, solo el CNE de eu-west-1 cambió su preferencia hacia una ruta alternativa (probablemente aprendida de un peer edge), mientras que los CNEs de Frankfurt y Estocolmo siguieron prefiriendo sus rutas locales directas del DC GW, ya que la modificación no alteró el orden de evaluación para ellos.
Qué deberían hacer los administradores y equipos técnicos
Para replicar este patrón de mantenimiento sin interrupciones en arquitecturas AWS Cloud WAN con Direct Connect adjunto nativamente, los administradores deben seguir estos pasos específicos:
- Validar la topología de selección de rutas: Antes de aplicar cambios, identifique que el CNE local está tomando la decisión basada en
AS_PATHlength y no solo enlocal preference. Verifique las comunidades BGP aplicadas por AWS por defecto (7224:7200) para asegurar que no haya conflictos con políticas personalizadas preexistentes. - Preparar el Prepend On-Premises: Configure los routers on-premises conectados al enlace Direct Connect objetivo (Dublín en este caso) para aplicar un
AS_PATH prependa las rutas anunciadas hacia esa VIF específica. Asegúrese de que este prepend no se aplique a la VIF del segundo data center o ubicación redundante si desea mantener el closest-exit para otras regiones. - Monitorear la convergencia BGP: Ejecute el cambio en un entorno no productivo primero. En producción, monitoree las tablas de ruteo del Core Network Edge objetivo (eu-west-1) y los pares vecinos. El tráfico debe comenzar a moverse antes de apagar físicamente el enlace, ya que las sesiones BGP permanecen activas durante todo el proceso.
- Revertir tras el mantenimiento: Una vez finalizada la tarea en el router, elimine el
AS_PATH prependdesde los routers on-premises. El CNE volverá a preferir la ruta local más corta automáticamente sin necesidad de retirar y reanunciar rutas (route withdrawal/flap), minimizando el riesgo de flapping inestable.
Conclusión
La experiencia de DeepL demuestra que la sofisticación en redes híbridas no siempre requiere políticas de ruteo complejas o herramientas SD-WAN externas. Comprender los mecanismos internos de AWS Cloud WAN, específicamente la separación entre las decisiones del Direct Connect Gateway y los Core Network Edges, permite a los ingenieros realizar intervenciones quirúrgicas. El uso de AS_PATH prepend como herramienta de drenaje local es una solución robusta que preserva el comportamiento closest-exit global mientras aísla el impacto operativo en una única región. Para equipos de plataforma que gestionan conectividad multi-región, este patrón ofrece un equilibrio óptimo entre simplicidad de configuración y precisión en la ingeniería de tráfico durante ventanas de mantenimiento programadas.
Fuentes
https://aws.amazon.com/blogs/architecture/how-deepl-keeps-closest-exit-routing-during-maintenance-with-aws-cloud-wan/