¿Qué es VPC/VNet Peering?
Qué conecta el peering de redes cloud, cuáles son sus límites de rutas y qué revisar en CIDR, DNS, seguridad y topología.

VPC/VNet peering conecta directamente dos redes virtuales para que intercambien tráfico privado. El proveedor conserva las redes como dominios separados, pero añade una relación de conectividad entre ellas. La idea sirve para comunicar aplicaciones, servicios compartidos o entornos de desarrollo sin convertir cada red en una única red plana.
VPC es el nombre habitual en AWS y VNet el de Azure; el concepto se parece, aunque las opciones y límites concretos dependen de cada plataforma. Peering no es una función universal con parámetros idénticos. Antes de diseñar rutas hay que consultar la documentación del proveedor y distinguir lo que ofrece el servicio de lo que debe configurarse en las tablas de rutas.
Un enlace privado con límites claros
Al crear el peering, las redes aceptan una relación directa entre sus espacios de direcciones. Una instancia de una red puede alcanzar recursos de la otra si existen rutas válidas y las reglas de seguridad permiten el flujo. La conexión no sustituye a las rutas, los firewalls ni las políticas de acceso: habilita el camino, pero cada control conserva su responsabilidad.
Un ejemplo sencillo sería una VPC de aplicaciones que necesita consultar una VPC donde viven los servicios de datos. El tráfico recorre la conexión privada entre ambas, pero solo llega a las subredes y puertos permitidos por las rutas y controles configurados. Tener peering activo no convierte automáticamente todos los recursos en vecinos. Es necesario comprobar el camino en ambos sentidos, porque una ruta de ida sin retorno no completa una comunicación.
En AWS, las redes que se conectan no pueden tener bloques CIDR coincidentes o solapados; esa condición evita que un destino pertenezca a dos redes a la vez. El plan de direccionamiento debe revisarse antes de desplegar, sobre todo cuando se conectan cuentas, regiones o empresas que administran sus rangos por separado. Azure tiene sus propios requisitos y posibilidades, de modo que no conviene trasladar una receta de AWS sin verificarla.
-InfraCrew dice: Dos redes pueden saludarse sin compartir toda la libreta de direcciones.-
La palabra «directo» también significa no transitivo
El límite que más sorprende es la ausencia de transitividad. Si la red A está conectada con B y A también con C, eso no significa que B pueda hablar con C atravesando A. Cada relación de peering une los extremos que la han creado, no crea un router de tránsito general. Para interconectar muchas redes en malla, el número de enlaces y su mantenimiento pueden crecer con rapidez.
Cuando se necesita un punto central para enrutar entre varias redes, suele encajar mejor un servicio de tránsito, un hub de red o un dispositivo de encaminamiento diseñado para ese papel. El peering resuelve conexiones puntuales; una topología de tránsito resuelve conectividad compartida. Elegir entre ambos cambia dónde se controlan las rutas, cómo se inspecciona el tráfico y qué ocurre cuando falla una pieza central.
La resolución DNS también merece su propia prueba. En AWS, ciertos nombres privados del otro lado requieren activar opciones específicas de resolución en la conexión y en las VPC. Una dirección IP alcanzable no demuestra que el nombre vaya a resolverse como espera la aplicación. Prueba ambos caminos: consulta DNS y conexión al servicio, desde cada lado que realmente lo necesite.
-InfraCrew dice: La ruta de vuelta también tiene que saber dónde está la puerta.-
Qué aporta a la arquitectura y qué no
El peering puede reducir saltos y simplificar la comunicación entre pocas redes. También permite compartir servicios internos sin exponerlos a Internet, siempre que el diseño de rutas y los controles lo mantengan privado. Privado describe el recorrido de red, no equivale a cifrado extremo a extremo ni a autorización. Si el requisito incluye confidencialidad criptográfica, hay que verificar qué protección ofrece cada servicio y añadir la adecuada.
Una conexión directa puede resultar eficiente, aunque la organización termina gestionando cada pareja por separado. Al aumentar las redes, conviene inventariar conexiones, rangos, reglas, propietarios y dependencias. El coste operativo no aparece solo en la factura: también se paga en revisiones, diagnóstico, cambios coordinados y riesgo de rutas olvidadas.
El filtrado debe diseñarse a ambos lados. Revisa grupos de seguridad, reglas de red, listas de control, políticas de firewall y permisos de servicio. La segmentación sigue siendo necesaria después de conectar las redes. Una aplicación que solo precisa consultar un endpoint no debería heredar acceso amplio a cada subred del otro entorno.
Cómo comprobar un peering antes de darlo por terminado
Empieza por confirmar que la conexión figura activa en los dos lados y que no existe solapamiento entre rangos. Comprueba las rutas efectivas en la subred de origen y en la de destino, y verifica el retorno. Una tabla correctamente guardada no garantiza que la ruta efectiva sea la que creías si hay rutas más específicas o políticas adicionales.
Después prueba nombres, IP, puerto y protocolo desde los orígenes reales de la aplicación; documenta qué debe funcionar y qué debe seguir bloqueado. Registra los cambios de DNS, las reglas y la cuenta responsable de cada extremo. La prueba útil incluye el caso negativo: confirmar que un recurso no autorizado no queda accesible por el nuevo camino.
Por último, decide cómo se retirará la conexión. Identifica aplicaciones dependientes, rutas y reglas que deban eliminarse juntas. Una conexión de red también necesita un plan de salida. Así, el peering queda como una decisión trazable y reversible, en vez de convertirse en una puerta antigua que nadie recuerda quién abrió.
-InfraCrew dice: Si nadie sabe qué aplicación usa el enlace, el inventario ya forma parte del incidente.-
Diccionario de la Crew
VPC/VNet — Red virtual aislada definida dentro de una plataforma cloud.
CIDR — Notación que expresa un bloque de direcciones IP y su tamaño.
Transitividad — Capacidad de utilizar una conexión como paso intermedio hacia otra red; el peering directo normalmente no la proporciona.


