Conectividad híbrida: VPN, enlaces dedicados y peering
Unir la nube con una oficina, un centro de datos propio u otra nube es un problema de tres decisiones: por dónde viaja el tráfico, con qué rangos de direcciones y quién puede iniciar la conexión. Lo demás es elegir entre una VPN barata y un enlace dedicado caro.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
Casi ninguna empresa está sólo en la nube. Hay un sistema viejo en un centro de datos, una oficina con impresoras y servidores de archivos, una base que no se puede mover por una licencia, o directamente otra nube.
Conectar todo eso parece un tema de proveedores y cables, y en el fondo es un problema de diseño que se decide antes: qué rangos de direcciones usa cada lado. Todo lo demás se puede cambiar después; eso no.
Las tres formas de unir dos redes
| VPN sobre internet | Enlace dedicado | Peering entre redes de la nube | |
|---|---|---|---|
| Por dónde viaja | Internet, cifrado | Una conexión física privada | La red interna del proveedor |
| Latencia | Variable: depende de internet | Estable y baja | Muy baja |
| Ancho de banda | Del orden de un gigabit por túnel | De cientos de megabits a decenas de gigabits | Alto |
| Tiempo de puesta en marcha | Una tarde | Semanas o meses | Minutos |
| Costo | Bajo | Alto y fijo, más el tráfico | Sólo el tráfico |
| Cuándo | Oficinas, respaldo, volúmenes chicos | Volumen alto, latencia estable, requisito regulatorio | Unir redes de la misma nube o de nubes distintas |
El plan de direcciones es la decisión que no se puede deshacer
Dos redes que se conectan no pueden tener rangos superpuestos: una dirección como 10.0.1.5
existiría de los dos lados y no habría forma de decidir a cuál mandar el paquete.
Antes de seguir, predecí
Reglas de un plan que aguanta
- Un bloque grande reservado por entorno y por región, con huecos para crecer.
- Nada de rangos que use el resto del mundo corporativo:
10.0.0.0/16y192.168.1.0/24son los primeros que aparecen en cualquier fusión. - Un registro central de qué rango es de quién, aunque sea el propio código de infraestructura.
- Contemplar a los socios: las conexiones con terceros también necesitan rangos que no se pisen, y ahí la traducción sí suele ser la respuesta correcta.
De malla a concentrador
Con dos redes alcanza el peering directo. Con diez, conectarlas de a pares son 45 conexiones y ninguna organización sostiene eso.
| Topología | Cómo es | Cuándo |
|---|---|---|
| Peering de a pares | Cada red conectada con cada otra | Pocas redes y sin crecimiento previsto |
| Concentrador y radios | Todas las redes se conectan a una central que rutea | Lo normal a partir de unas pocas redes |
| Servicio de tránsito gestionado | El proveedor hace de concentrador | La forma actual: menos piezas propias que operar |
| Punto de acceso privado a un servicio | Se expone un servicio puntual, sin unir las redes | Cuando sólo hace falta llegar a una cosa |
La alternativa que muchas veces hace innecesaria toda esta discusión: si lo único que hace falta es que una aplicación llegue a un servicio del otro lado, un punto de acceso privado expone ese servicio sin unir las redes. Menos superficie, menos ruteo y ningún problema de direcciones.
Unir dos redes es unir dos superficies
Lo que hay que decidir explícitamente
- Quién puede iniciar la conexión, y en qué dirección. Casi siempre hace falta un solo sentido, y casi siempre se configuran los dos.
- Qué se anuncia por ruteo: anunciar toda la red corporativa hacia la nube expone mucho más de lo necesario.
- Dónde se inspecciona el tráfico, si hay requisito de auditarlo.
- Cómo se resuelve el DNS de los dos lados, que es la parte que siempre falta: el enlace queda perfecto y los nombres internos no resuelven.
- Que el cifrado siga existiendo sobre el enlace dedicado, que es privado pero no cifrado por sí mismo.
Más a fondo · nivel seniorMulti-nube: el caso donde todo esto se paga dos veces
Conectar dos nubes entre sí tiene las mismas piezas y dos costos extra que se subestiman.
El primero es el tráfico de salida: mover datos de una nube a otra se cobra del lado que sale, y una arquitectura conversadora entre nubes puede generar una factura mensual mayor que el servicio que la justificaba. La regla práctica es cruzar la frontera con eventos o con lotes, no con llamadas sincrónicas por request.
El segundo es la identidad: cada nube tiene su propio modelo, y el sistema que vive de un lado necesita credenciales del otro. La solución correcta es la federación entre los dos proveedores de identidad —credenciales temporales en ambos sentidos— y no una clave de larga duración copiada, que es lo que se termina haciendo cuando la decisión se toma con apuro.
Y una advertencia de diseño: la latencia entre nubes se parece a la que hay entre regiones. Una base de un lado y su aplicación del otro es un diseño que funciona en la demo y no en producción.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica