Cet article est le premier volet d’une série en trois articles traitant des sujets suivants : réseau, stockage et compute.
Ce qui change côté réseau : le Virtual Private Cloud (VPC)
Après l’annonce de la disponibilité générale de VMware Cloud Foundation 9.0 le 17 juin 2025 et des évolutions apportées par VCF 9.1 en mai 2026, une brique change la donne pour les équipes réseau et applicatives : le Virtual Private Cloud (VPC).
Jusqu’ici, connecter une nouvelle application au réseau sous VCF exigeait de maîtriser NSX en profondeur (Tier-0, Tier-1, Edge VM) et de mobiliser l’équipe réseau à chaque déploiement. Le VPC change cette mécanique. Il apporte en effet une consommation réseau en libre-service, à la manière d’un cloud public. En outre, celle-ci est directement accessible aux équipes applicatives depuis vCenter et non plus uniquement depuis la console NSX.
Le VPC constitue un outil supplémentaire dans la boîte à outils réseau de VCF et non un remplacement. Cela signifie que les VLAN classiques, les Tier-0/Tier-1 NSX en mode « traditionnel », ainsi que les mécanismes de pare-feu habituels (DFW, Gateway Firewall) restent pleinement disponibles et peuvent coexister avec les VPC selon les besoins.
Ce premier volet de notre série sur les nouveautés de VCF 9 (que nous avions commencé par un TLDR ici) se concentre sur le réseau. Les prochains articles couvriront le stockage, puis le compute.
Qu’est-ce qu’un VPC ?
Un Virtual Private Cloud (VPC) est un environnement réseau isolé et multi-tenant, hébergé à l’intérieur d’un cloud privé VCF plus large.
Il permet à une équipe applicative de définir et gérer son propre réseau logiquement isolé : adressage IP, routage, règles de sécurité. Le tout, sans dépendre d’une intervention réseau à chaque changement. Ce concept ne perdra pas les architectes pratiquant déjà le cloud public. Il reprend en effet la logique d’un VPC existant chez tous les grands fournisseurs de cloud, transposée à un cloud privé VCF.
Pour en découvrir davantage, consultez cet article du blog VMware à ce sujet.
Deux briques structurent un VPC.
- Les sous-réseaux : des réseaux virtuels de couche 3 (L3) du modèle OSI, publics ou privés. Un sous-réseau privé utilise un bloc IP qui n’est jamais annoncé en dehors du VPC. Un sous-réseau public reçoit quant à lui ses adresses directement dans le pool IP externe. Chez OVHcloud, il s’agit généralement de blocs d’adresses IP.
- Les passerelles : chaque VPC possède sa propre passerelle qui route les paquets entre ses sous-réseaux. Au sein d’un même projet, une Transit Gateway peut relier entre elles tous les VPC.
Un VPC peut rester rattaché à un seul domaine de gestion, ou s’étendre sur plusieurs via le span, si ceux-ci partagent la même instance NSX. Dans la version 9.1, un projet peut compter plusieurs Transit Gateways, quel que soit le nombre de VPC qu’il regroupe. Chaque VPC connecté à une Transit Gateway peut aussi se voir appliquer une politique de connectivité (Community, Promiscuous, Isolated) contrôlant ses échanges avec les autres VPC, sans recourir à la mise en place d’un pare-feu. Les limites de dimensionnement (nombre de VPC, de sous-réseau) restent, elles, définies par les valeurs maximales de configuration NSX documentées par VMware.
La répartition des rôles reste claire. C’est elle qui rend le modèle réellement self-service sans sacrifier le contrôle centralisé. Lors du déploiement d’un domaine de gestion, l’administrateur réseau définit les blocs d’adresses IP qui alimenteront les futurs VPC. Les administrateurs vCenter créent ensuite les VPC et leurs sous-réseaux en toute autonomie. Ils ne choisissent jamais les plages IP des réseaux publics ou de transit : celles-ci sont prélevées sur les blocs prédéfinis. Seules les IP des sous-réseaux purement privés, qui ne sont jamais annoncées à l’extérieur, sont librement gérées par l’équipe applicative.
Dans la pratique, une équipe applicative qui a besoin d’un nouvel environnement isolé peut créer son propre VPC en quelques clics, sans ouvrir de ticket auprès de l’équipe réseau ni attendre une fenêtre de maintenance.
Ainsi, tout se pilote depuis l’onglet réseau de vCenter (création de VPC, de sous-réseau, configuration de la connectivité) ou via l’API/PowerCLI. Il est ainsi possible d’en intégrer la création directement dans des pipelines d’Infrastructure as Code, au même titre qu’un déploiement de machine virtuelle. Aucune intervention sur les switchs ou routeurs physiques n’est nécessaire : NSX installe et gère automatiquement les composants virtuels sous-jacents.
Pour celles et ceux d’entre vous familiers avec le vSphere Client, voici comment sont représentés les sous-réseaux au sein d’un VPC, sous VCF 9.x.
Cette logique n’est pas totalement nouvelle : VCF 5.2.1 en avait déjà introduit un premier aperçu dans vCenter. VCF 9.0 généralise le modèle. VCF 9.1 vient l’enrichir avec de nouvelles capacités de connectivité, ce qui sera l’objet du chapitre suivant.
Fonctionnalités et composants du VPC
Connectivité centralisée versus distribuée
Un VPC peut relier ses workloads au réseau physique de deux façons. En connectivité centralisée, la Transit Gateway achemine le trafic vers une passerelle Tier-0 instanciée sur des machines virtuelles Edge NSX : tout le trafic entrant et sortant transite par ces dernières. En connectivité distribuée, introduite avec VCF 9.0, la Transit Gateway repose directement sur un VLAN partagé par tous les hôtes ESX, sans aucune machine virtuelle Edge ni gateway Tier-0. VCF 9.1 vient combler la principale limite historique de ce second mode : l’absence de services réseau avancés. Le choix entre ces deux modes dépend davantage du niveau de service réseau requis, plus que de la seule performance réseau.
VPC et Distributed Transit Gateway (DTGW)
Le modèle distribué gagnait en simplicité et en performance, mais restait cantonné aux services réseau de base (NAT statique, DHCP distribué). Avec VCF 9.1, une nouvelle brique logicielle comble ce manque : la Virtual Network Appliance (VNA). Il s’agit d’une appliance légère, déployée depuis vCenter, qui vient se rattacher à un environnement VPC distribué pour y apporter des services centralisés à la demande : NAT avancé, DHCP et surtout la répartition de charge via Avi Load Balancer. Résultat : une Transit Gateway distribuée peut désormais s’appuyer sur Avi pour exposer un load balancer, sans réintroduire de machine virtuelle Edge classique ni renoncer aux gains de performance du modèle distribué.
À noter : suite à la lecture de ce billet de blog, vous pouvez suivre notre feuille de route pour le VMware Avi Load Balancer. N’hésitez pas à ajouter vos avis en commentaires et/ou voter pour sa priorisation.L’Avi Load Balancer est le moteur de répartition de charge L4-L7 intégré à VCF : jusqu’à la version VCF 9.1, il restait réservé aux déploiements en connectivité centralisée, car le modèle distribué n’offrait aucun moyen d’intégration. La Virtual Network Appliance (VNA) vient combler ce vide : un administrateur réseau la déploie une fois au niveau du projet ou du VPC, puis l’associe au contrôleur Avi. Les équipes applicatives peuvent ensuite créer leurs propres Virtual Services Avi, pour exposer une API, un site web ou un ingress Kubernetes. Et ce, sans jamais toucher à la configuration réseau sous-jacente. Cette combinaison rend le modèle distribué viable pour la quasi-totalité des cas d’usage applicatifs, là où il ne couvrait auparavant que les scénarios les plus simples.
Connexion VLAN distribuée pour vSphere Supervisor
La VNA ouvre aussi la connectivité distribuée à de nouveaux cas d’usage : le vSphere Supervisor et VCF Automation peuvent désormais se raccorder au datacenter via un simple VLAN, plutôt que par une architecture de connectivité centralisée, plus lourde. Pour les équipes déployant Kubernetes (vSphere Supervisor) ou orchestrant des environnements applicatifs (VCF Automation), cela réduit sensiblement les prérequis réseau à mettre en place en amont. Plus besoin en effet de préparer une topologie Edge/Tier-0 dédiée pour obtenir une connectivité fonctionnelle.
Conclusion
Le Virtual Private Cloud transforme la façon dont les équipes réseau et applicatives collaborent sous VCF 9. Cela signifie moins d’allers-retours, une consommation réseau en self-service et désormais, grâce à la VNA, des services avancés (Avi Load Balancer, connectivité VLAN simplifiée pour Supervisor) accessibles sans sacrifier la simplicité du modèle distribué.
Pour les architectes, le message est simple : moins de tickets échangés avec l’équipe réseau et une infrastructure qui reste sous contrôle grâce aux quotas définis en amont. Cette évolution s’inscrit dans une tendance plus large de VCF 9 : rapprocher l’expérience du cloud privé de celle du cloud public, sans renoncer à la maîtrise de l’infrastructure.
Le prochain volet de cette série s’intéressera aux nouveautés côté stockage.
Découvrez l’offre VMware Cloud Foundation chez OVHcloud pour construire votre cloud privé sur cette même base.