Alta disponibilidad de VPN en AWS: 2 túneles, 2 VPN y Direct Connect explicados

Cuando conectas tu red on-premises a AWS con una VPN, la alta disponibilidad no es algo que tengas que inventar desde cero: una sola conexión Site-to-Site VPN ya trae HA de fábrica en forma de dos túneles. Pero esa redundancia solo cubre un tipo de fallo. En este artículo recorremos, paso a paso y con la lógica de la documentación de AWS, cómo funciona ese HA nativo, por qué vienen dos túneles si solo tienes un Customer Gateway, cómo escalas a dos VPN o a Direct Connect + VPN, qué pasa con las tablas de rutas y qué conviene en cada caso.

Los tres componentes de una Site-to-Site VPN

Según la documentación de AWS, una conexión Site-to-Site VPN se compone de tres piezas:

Virtual Private Gateway (VGW) o Transit Gateway (TGW): el concentrador VPN del lado de AWS, asociado a tu VPC.
Customer Gateway device: el dispositivo físico o software en tu red (típicamente tu firewall o router: Fortinet, Cisco, pfSense, etc.).
Customer Gateway (CGW): el recurso en AWS que representa a ese dispositivo. Aquí registras su IP pública y su ASN de BGP.

Esa distinción entre el dispositivo (tu firewall real) y el recurso CGW (su representación en AWS) es la clave para entender todo lo que sigue.

¿Por qué vienen dos túneles si solo tengo un Customer Gateway?

Esta es la pregunta más frecuente, y la respuesta está en la propia definición de AWS: cada conexión Site-to-Site VPN ofrece dos túneles IPsec, y cada túnel usa una dirección IP pública distinta. No es opcional ni configurable a uno: siempre son dos.

Una sola VPN: un único Customer Gateway, pero dos túneles hacia dos endpoints AWS en AZ distintas.

El motivo es que los dos túneles no terminan en el mismo sitio del lado de AWS:

Cada túnel termina en un endpoint de túnel distinto, y cada endpoint vive en una Availability Zone diferente.
Así, si AWS necesita hacer mantenimiento en un endpoint (o una AZ tiene un problema), el otro túnel sigue arriba. Ese es el HA que trae la VPN por naturaleza.

💡 Un CGW, dos túneles: no es contradicción

Tu lado solo tiene un Customer Gateway (un dispositivo, una IP pública), pero establece dos sesiones IPsec, una hacia cada endpoint de AWS. Tu firewall levanta los dos túneles contra las dos IP públicas que AWS te entrega en el archivo de configuración de la conexión.

Cómo se comporta el tráfico entre los dos túneles

Según la doc de AWS, el patrón de tráfico es asimétrico por diseño:

On-premises → AWS: tu equipo puede usar ambos túneles.
AWS → on-premises: el VGW prefiere uno de los túneles, pero conmuta automáticamente al otro si hay un fallo del lado de AWS.

Failover de túnel: si el túnel 1 cae, el tráfico pasa solo al túnel 2 de la misma VPN, sin intervención manual.

⚠️ Qué NO cubre el HA nativo de una sola VPN

Los dos túneles protegen contra un fallo del lado de AWS (un endpoint, una AZ). No protegen contra la caída de tu dispositivo: si tu único firewall/CGW se apaga, los dos túneles caen con él, porque ambos nacen de ese mismo dispositivo. Para cubrir ese caso necesitas un segundo dispositivo (lo vemos abajo).

Escenario: dos VPN con dos Customer Gateways

Para protegerte de la caída de tu propio dispositivo, AWS documenta el patrón de conexiones VPN redundantes: añades un segundo Customer Gateway (un segundo firewall con su propia IP pública) y creas una segunda conexión Site-to-Site VPN contra el mismo VGW.

Dos VPN, dos Customer Gateways, un mismo VGW: ahora toleras la pérdida de un firewall on-premises completo.

El patrón exacto que recomienda AWS para este caso:

Usar el mismo VGW y crear un nuevo CGW para el segundo dispositivo.
La IP pública del segundo CGW debe ser accesible desde Internet.
Ambos dispositivos deben anunciar los mismos rangos IP hacia el VGW por BGP.
Si un dispositivo falla, el VGW dirige todo el tráfico al dispositivo que sigue operativo.

Observa que ahora tienes cuatro túneles en total (dos por cada VPN). Esto combina los dos niveles de HA: redundancia de endpoint de AWS (los dos túneles de cada VPN) y redundancia de dispositivo on-premises (los dos CGW).

✅ Mantenimiento sin downtime

Con VPN redundantes puedes hacer mantenimiento en uno de tus dispositivos mientras el tráfico sigue fluyendo por el segundo. Es el argumento operativo principal para justificar el segundo CGW.

¿Cómo puede una VPN con un solo CGW conectar a dos firewalls?

Aquí hay que separar dos lecturas de la pregunta, porque el recurso CGW en AWS está atado a una sola IP pública:

Dos caminos para dar HA de dispositivo: una IP virtual compartida (un CGW) o dos IP distintas (dos CGW, dos VPN).

Opción A — un clúster HA que comparte una IP pública (sigue siendo un CGW)

Si tus dos firewalls forman un clúster activo/standby que expone una única IP pública virtual (VRRP/HA del fabricante), para AWS eso es un solo Customer Gateway. La conmutación entre firewall A y B ocurre dentro de tu red y es transparente para AWS: la IP y los túneles no cambian. En este sentido, «una VPN con un CGW» sí conecta a dos firewalls físicos, porque ambos se esconden detrás de la misma IP.

Opción B — dos firewalls con IP públicas distintas (dos CGW, dos VPN)

Si cada firewall tiene su propia IP pública, no caben en un solo CGW: cada uno necesita su propio recurso CGW y su propia conexión VPN. Esto es exactamente el escenario anterior de dos VPN con dos CGW. Es el camino recomendado cuando quieres que la redundancia la gestione AWS por BGP en lugar de depender del clustering de tu fabricante.

💡 Regla práctica

Un recurso CGW = una IP pública. ¿Tus dos firewalls comparten una IP virtual de clúster? → un CGW, una VPN. ¿Tienen IP públicas distintas? → dos CGW, dos VPN.

Escenario: Direct Connect + VPN de respaldo

Un patrón muy común en producción es usar Direct Connect (DX) como enlace primario (dedicado, baja latencia, ancho de banda estable) y una Site-to-Site VPN sobre Internet como respaldo para cuando el DX se caiga.

Direct Connect primario + VPN de respaldo: BGP prefiere el DX mientras esté sano y conmuta a la VPN si falla.

La gracia está en que no tienes que conmutar nada a mano: lo resuelve la prioridad de rutas del VGW. AWS prefiere las rutas aprendidas por BGP desde Direct Connect por encima de las de la VPN. Mientras el DX esté sano, el tráfico va por ahí; si cae, las rutas del DX desaparecen y el VGW empieza a usar la VPN automáticamente.

⚠️ Dimensiona el respaldo

Un DX de 10 Gbps respaldado por una VPN estándar (hasta 1,25 Gbps por túnel) no te da el mismo ancho de banda durante el failover. Si necesitas más, AWS ofrece Large Bandwidth Tunnels (hasta 5 Gbps por túnel, solo con TGW/Cloud WAN) o ECMP sobre varias VPN. El respaldo mantiene la conectividad, no necesariamente el rendimiento pleno.

Qué pasa con las tablas de rutas y la prioridad

Toda esta orquestación de «quién gana» se decide con reglas de prioridad de ruta en el VGW. Este es el orden que documenta AWS, de más a menos preferido, cuando hay prefijos que compiten:

Orden de prioridad de rutas en el VGW cuando varios caminos compiten por el mismo destino.

La ruta local de la VPC siempre gana, aunque las propagadas sean más específicas. El tráfico dentro de la VPC nunca sale por la VPN.
Primero se aplica longest prefix match: la ruta más específica (máscara más larga) gana. Puedes anunciar prefijos más específicos por BGP para forzar un camino.
Con el mismo prefijo, el orden es: BGP de Direct Connect > ruta estática de VPN > BGP de VPN.
Entre dos VPN que usan BGP con igual prefijo, gana la de AS_PATH más corto (y luego desempata el MED).
Por encima de todo: la salud del túnel tiene prioridad. Un endpoint sano se elige antes que cualquier atributo de ruta.

💡 Estática vs propagada con el mismo prefijo

Si una ruta estática de VPN y una BGP propagada tienen el mismo destino, AWS prioriza la estática. Por eso, mezclar estáticas y propagadas sobre el mismo prefijo puede «pinchar» tu failover sin que te des cuenta: revisa que no haya estáticas tapando a las propagadas.

La entrada que sí debes crear a mano: la tabla de la subred

Independiente de la prioridad interna del VGW, hay una cosa que tú configuras en la VPC: la tabla de rutas de la subred tiene que saber que el rango on-premises se alcanza por el VGW.

En la tabla de la subred, el rango on-premises apunta al VGW (como ruta propagada o estática).

Tienes dos formas de poblar esa entrada:

Propagación de rutas (route propagation): activas la propagación en la tabla y el VGW inyecta automáticamente los prefijos aprendidos por BGP. Es lo recomendado con VPN dinámica, porque el failover se refleja solo.
Ruta estática: añades a mano destino = rango on-prem, target = vgw-xxxx. Necesario con VPN de routing estático.

Recuerda: el VGW solo enruta hacia prefijos que conoce (anunciados por BGP o entrados como ruta estática) más el CIDR de su VPC. Cualquier otro destino se descarta.

¿Se necesitan segmentos de red distintos?

Sí, y es un punto donde muchos tropiezan. Para que el enrutamiento IP funcione, los rangos a ambos lados no pueden solaparse:

El CIDR de tu VPC y el de tu red on-premises deben ser disjuntos. Si ambos usan 10.0.0.0/16, el tráfico nunca sabrá cuándo cruzar la VPN (la ruta local de la VPC siempre gana para su propio CIDR).
Si conectas varias redes on-premises o varias VPC al mismo concentrador, todas deben tener rangos únicos entre sí.
Las dos VPN de un escenario redundante sí comparten los mismos rangos anunciados (ambos CGW anuncian la misma red): eso es correcto y deseado, porque representan el mismo destino por dos caminos. Lo que no puede solaparse es VPC ↔ on-prem.

🚫 El error clásico: CIDR solapados

Planifica el direccionamiento antes de crear la VPC. Cambiar el CIDR de una VPC en producción es doloroso. Reserva rangos que no choquen con ninguna red on-premises presente ni futura.

VGW vs Transit Gateway: cuándo escala uno u otro

Una limitación importante del VGW: aunque tengas varios túneles o varias VPN, el VGW usa un solo túnel de salida activo a la vez (no reparte carga). El Transit Gateway, en cambio, soporta ECMP (Equal Cost Multipath), que reparte el tráfico entre varios túneles en paralelo y suma ancho de banda.

VGW elige un túnel de salida; TGW con ECMP usa varios túneles simultáneamente para sumar capacidad.

VGW: simple, ideal para una VPC conectada a on-premises. HA por túneles, pero sin agregación de ancho de banda por ECMP.
TGW: hub central para muchas VPC + on-premises, soporta ECMP, IPv6 dentro del túnel y los Large Bandwidth Tunnels de 5 Gbps. Es el camino cuando creces.

Qué se recomienda en cada caso

Necesidad	Diseño recomendado	Qué fallo cubre
Conectividad básica	1 VPN (2 túneles) a un VGW	Fallo de un endpoint/AZ de AWS
HA del dispositivo on-prem	2 VPN + 2 CGW (BGP, mismos rangos)	Caída de un firewall completo
Enlace dedicado con respaldo	Direct Connect primario + VPN backup	Caída del DX (conmuta a VPN por BGP)
Más ancho de banda / varias VPC	TGW + varias VPN con ECMP	Escala y agrega capacidad
Máxima resiliencia	DX en dos ubicaciones + VPN backup sobre TGW	Fallo de DX, de sitio y de AWS

Checklist de configuración

1. Diseña CIDR disjuntos (VPC vs on-premises), sin solapes.
2. Crea el VGW (o TGW) y adjúntalo a la VPC.
3. Crea el/los Customer Gateway(s) con la IP pública y ASN de cada firewall.
4. Crea la/las conexión(es) Site-to-Site VPN (preferir BGP/dinámico).
5. Configura tu firewall con los DOS túneles del archivo de config de AWS.
6. En la tabla de rutas de la subred: propaga rutas o añade la estática al VGW.
7. Verifica que ambos túneles queden UP y prueba el failover (baja uno).

✅ Siempre configura los dos túneles

El error más común es dejar un solo túnel arriba «porque funciona». Si no configuras ambos, pierdes justamente el HA que la VPN te regala. AWS recomienda explícitamente configurar los dos túneles y permitir enrutamiento asimétrico.

Conclusión

El HA de una Site-to-Site VPN se construye por capas. La capa base viene gratis: dos túneles por conexión, a dos endpoints de AWS en AZ distintas, con failover automático — y por eso vienen dos túneles aunque tengas un solo Customer Gateway. La siguiente capa es tuya: un segundo CGW con una segunda VPN para sobrevivir a la caída de tu propio dispositivo. Y cuando necesitas un enlace dedicado, Direct Connect + VPN de respaldo te da lo mejor de ambos mundos, con la prioridad de rutas de AWS conmutando por ti.

Dos reglas que lo resumen todo: planifica rangos que no se solapen y configura siempre ambos túneles. Con eso, el resto —prioridad de rutas, propagación, failover— trabaja a tu favor sin intervención manual.

💡 Verifica con la doc oficial

Las reglas de prioridad de ruta y los límites de ancho de banda cambian con el tiempo y por tipo de gateway (VGW vs TGW). Antes de un diseño comprometido, contrasta con la guía de usuario de AWS Site-to-Site VPN para tu región y tipo de gateway.