Este artículo es el primer capítulo de una serie de tres artículos que tratan los siguientes temas: red, almacenamiento y compute.
Lo que cambia en la red: la Virtual Private Cloud ( VPC )
Tras el anuncio de la disponibilidad general de VMware Cloud Foundation 9.0 el 17 de junio de 2025 y los cambios de VCF 9.1 en mayo de 2026, un bloque cambia las reglas del juego para los equipos de red y aplicaciones: la Virtual Private Cloud (VPC).
Hasta ahora, conectar una nueva aplicación a la red en VCF requería un conocimiento profundo de NSX (Tier-0, Tier-1, Edge VM) y la participación del equipo de red en cada despliegue. La VPC cambia esta mecánica. En efecto, ofrece un consumo de red en autoservicio, al estilo de una nube pública. Además, los equipos de aplicaciones pueden acceder a ella directamente desde vCenter y ya no solo desde la consola NSX.
La VPC es una herramienta adicional en el conjunto de herramientas de la red VCF y no una sustitución. Esto significa que las VLAN tradicionales, las Tier-0/Tier-1 NSX en modo «tradicional» y los mecanismos de cortafuegos habituales (DFW, Gateway Firewall) siguen estando totalmente disponibles y pueden coexistir con las VPC según sea necesario.
Esta primera parte de nuestra serie sobre las novedades de VCF 9 (que comenzamos con un TLDR aquí) se centra en la red. Los próximos artículos tratarán sobre el almacenamiento y luego sobre el compute.
¿Qué es una VPC?
Una Virtual Private Cloud (VPC) es un entorno de red aislado y multiinquilino, alojado dentro de una nube privada VCF más amplia.
Permite a un equipo de aplicaciones definir y gestionar su propia red lógicamente aislada: direccionamiento IP, enrutamiento, reglas de seguridad. Todo esto sin depender de una intervención de red en cada cambio. Este concepto no perderá a los arquitectos que ya trabajan con la nube pública. De hecho, sigue la lógica de una VPC existente en todos los grandes proveedores de cloud, trasladada a un cloud privado VCF.
Para obtener más información, consulte este artículo del blog de VMware.
Una VPC se estructura en dos bloques.
- Subredes: redes virtuales de capa 3 (L3) del modelo OSI, públicas o privadas. Una subred privada utiliza un bloque IP que nunca se anuncia fuera de la VPC. Una subred pública recibe sus direcciones directamente del pool IP externo. En OVHcloud, se trata generalmente de bloques de direcciones IP.
- Pasarelas: cada VPC tiene su propia pasarela que enruta los paquetes entre sus subredes. Dentro de un mismo proyecto, una Transit Gateway puede conectar todos las VPC entre sí.
Una VPC puede permanecer asociada a un único dominio de gestión o extenderse a varios a través del span, si estos comparten la misma instancia de NSX. En la versión 9.1, un proyecto puede tener varias Transit Gateways, independientemente del número de VPC que contenga. Cada VPC conectada a una Transit Gateway también puede tener una política de conectividad (Community, Promiscuous, Isolated) que controla su intercambio con otras VPC sin necesidad de configurar un cortafuegos. Los límites de dimensionamiento (número de VPC, de subred) siguen estando definidos por los valores máximos de configuración NSX documentados por VMware.
La distribución de roles sigue siendo clara. Es lo que hace que el modelo sea realmente de autoservicio sin sacrificar el control centralizado. Al desplegar un dominio de gestión, el administrador de red define los bloques de direcciones IP que alimentarán las futuras VPC. Los administradores de vCenter crean después las VPC y sus subredes de forma autónoma. Nunca eligen las direcciones IP de las redes públicas o de tránsito: estas se extraen de los bloques predefinidos. Solo las IP de las subredes puramente privadas, que nunca se anuncian en el exterior, son gestionadas libremente por el equipo de aplicaciones.
En la práctica, un equipo de aplicaciones que necesita un nuevo entorno aislado puede crear su propia VPC en unos pocos clics, sin abrir un ticket al equipo de red ni esperar a una ventana de mantenimiento.
Así, todo se gestiona desde la pestaña red de vCenter (creación de VPC, subred, configuración de la conectividad) o a través de la API/PowerCLI. Esto permite integrar la creación directamente en los pipelines de Infrastructure as Code, al igual que un despliegue de máquina virtual. No es necesario realizar ninguna intervención en los switchs o routers físicos: NSX instala y gestiona automáticamente los componentes virtuales subyacentes.
Para aquellos que están familiarizados con el vSphere Client, aquí se muestra cómo se representan las subredes dentro de una VPC, en VCF 9.x.
Esta lógica no es totalmente nueva: VCF 5.2.1 ya había presentado una primera vista previa en vCenter. VCF 9.0 generaliza el modelo. VCF 9.1 lo ha enriquecido con nuevas capacidades de conectividad, que serán objeto del siguiente capítulo.
Funcionalidades y componentes de la VPC
Conectividad centralizada frente a distribuida
Una VPC puede conectar sus cargas de trabajo a la red física de dos maneras. En la conectividad centralizada, la Transit Gateway dirige el tráfico a una pasarela Tier-0 implementada en máquinas virtuales Edge NSX: todo el tráfico entrante y saliente pasa por estas. En la conectividad distribuida, introducida con VCF 9.0, la Transit Gateway se basa directamente en una VLAN compartida por todos los hosts ESX, sin ninguna máquina virtual Edge ni gateway Tier-0. VCF 9.1 elimina la principal limitación histórica de este segundo modo: la falta de servicios de red avanzados. La elección entre estos dos modos depende más del nivel de servicio de red requerido que del solo rendimiento de la red.
VPC y Distributed Transit Gateway (DTGW)
El modelo distribuido era más sencillo y eficiente, pero se limitaba a los servicios básicos de red (NAT estático, DHCP distribuido). Con VCF 9.1, un nuevo componente de software cubre esta laguna: la Virtual Network Appliance ( VNA ). Se trata de una aplicación ligera, desplegada desde vCenter, que se conecta a un entorno VPC distribuido para aportar servicios centralizados bajo demanda: NAT avanzado, DHCP y sobre todo el balanceo de carga a través de Avi Load Balancer. El resultado es que una Transit Gateway distribuida puede ahora usar Avi para exponer un load balancer sin volver a introducir una máquina virtual Edge tradicional ni renunciar a las ventajas de rendimiento del modelo distribuido.
Nota: después de leer este artículo, puede seguir nuestra hoja de ruta para VMware Avi Load Balancer. No dude en añadir sus comentarios y/o votar para darle prioridad.El Avi Load Balancer es el motor de balanceo de carga L4-L7 integrado en VCF: hasta la versión VCF 9.1, estaba reservado a los despliegues con conectividad centralizada, ya que el modelo distribuido no ofrecía ningún medio de integración. La Virtual Network Appliance ( VNA ) cubre esta laguna: un administrador de red la despliega una vez a nivel de proyecto o del VPC y luego la asocia al controlador Avi. Los equipos de aplicaciones pueden luego crear sus propios Virtual Services Avi para exponer una API, un sitio web o un ingress de Kubernetes. Y todo esto sin tocar la configuración de red subyacente. Esta combinación hace que el modelo distribuido sea viable para casi todos los casos de uso de aplicaciones, donde antes solo cubría los escenarios más simples.
Conexión VLAN distribuida para vSphere Supervisor
La VNA también abre la conectividad distribuida a nuevos casos de uso: vSphere Supervisor y VCF Automation ahora pueden conectarse al datacenter a través de una VLAN simple, en lugar de una arquitectura de conectividad centralizada más compleja. Para los equipos que despliegan Kubernetes (vSphere Supervisor) o orquestan entornos de aplicaciones (VCF Automation), esto reduce significativamente los requisitos previos de red que deben configurarse con antelación. No es necesario preparar una topología Edge/Tier-0 dedicada para obtener una conectividad funcional.
Conclusión
Virtual Private Cloud transforma la forma en que los equipos de red y de aplicaciones colaboran en VCF 9. Esto significa menos viajes, un consumo de red en autoservicio y ahora, gracias a la VNA, servicios avanzados (Avi Load Balancer, conectividad VLAN simplificada para Supervisor) accesibles sin sacrificar la simplicidad del modelo distribuido.
Para los arquitectos, el mensaje es simple: menos tickets enviados al equipo de red y una infraestructura que se mantiene bajo control gracias a las cuotas definidas con antelación. Este cambio se inscribe en una tendencia más amplia de VCF 9: acercar la experiencia del cloud privado a la del cloud público, sin renunciar al control de la infraestructura.
El próximo capítulo de esta serie se centrará en las novedades en el ámbito del almacenamiento.
Descubra la oferta VMware Cloud Foundation de OVHcloud para construir su cloud privado sobre la misma base.