Avec VMware Cloud Foundation (VCF) 9.1, Broadcom poursuit l’évolution des services réseau intégrés aux Virtual Private Clouds (VPC), notamment avec de nouvelles possibilités de Load Balancing et une intégration renforcée de VMware Avi Load Balancer.
Dans une publication officielle du 15 mai 2026, Broadcom confirme la possibilité de consommer des services de Load Balancing via Native NSX ou le produit Avi.
Mais cette coexistence soulève plusieurs questions d’architecture : quelles différences entre les deux approches ? Quels sont les impacts sur les performances, l’exploitation et l’automatisation ? Et surtout, quelle solution privilégier selon les besoins applicatifs et les contraintes d’infrastructure ?
1. NSX Load Balancing et Avi : deux approches différentes
Historiquement, VMware NSX intègre un service de Load Balancing natif permettant de répartir les connexions vers plusieurs serveurs applicatifs.
Cette approche présente l’avantage d’être directement intégrée à l’infrastructure réseau NSX, avec une gestion des services au sein de l’environnement de virtualisation.
VMware Avi Load Balancer, anciennement NSX Advanced Load Balancer, repose sur une architecture ADC (Application Delivery Controller) dédiée, conçue pour fournir des services avancés de répartition de charge, de disponibilité et de sécurité applicative.
Contrairement à une approche limitée aux services réseau d’une plateforme donnée, Avi introduit une séparation entre le plan de contrôle et le plan de données, tout en permettant une gestion centralisée des services applicatifs.
Il ne s’agit donc pas uniquement d’une différence de fonctionnalités, mais de deux modèles d’architecture et d’exploitation.
2. NSX Native Load Balancing : intégration et périmètre d’utilisation
Le Load Balancing natif NSX repose sur les composants et mécanismes réseau de NSX, offrant une intégration directe avec les services de connectivité de l’infrastructure.
Avec VCF 9.1, Broadcom étend les services disponibles dans les VPC, notamment en matière de NAT et de Load Balancing.
Ces services peuvent être consommés selon différentes architectures de connectivité :
- Centralized Transit Gateway (CTGW) : modèle reposant sur les NSX Edge Nodes pour assurer les services réseau centralisés.
- Distributed Transit Gateway (DTGW) : modèle permettant une connectivité distribuée, sans imposer des NSX Edge Nodes pour le transit, avec l’introduction de Virtual Network Appliances (VNA) pour certains services stateful.
Ces évolutions apportent davantage de flexibilité pour la consommation des services réseau.
Le choix entre ces deux modèles détermine l’architecture de connectivité des VPC et les modalités de fourniture des services réseau. Avec VCF 9.1, l’introduction des Virtual Network Appliances permet notamment d’étendre les services stateful, dont le Load Balancing, aux environnements utilisant une connectivité distribuée.
Attention aux changements de licence depuis VCF 9.0
Un point essentiel doit toutefois être pris en compte.
Depuis VCF 9.0, Broadcom a modifié les droits d’utilisation du Load Balancer intégré à NSX. Les fonctionnalités de Load Balancing généraliste ne sont plus incluses dans les droits standard de VCF.
L’utilisation du NSX Load Balancer reste notamment autorisée pour les composants d’infrastructure VCF et certains besoins de Load Balancing L4 associés à vSphere Supervisor.
La disponibilité technique d’un service natif ne doit donc pas être confondue avec son droit d’utilisation pour des applications métiers.
Pour les nouveaux besoins de Load Balancing applicatif généraliste, Broadcom oriente les clients vers VMware Avi Load Balancer.
3. VMware Avi Load Balancer : une architecture ADC dédiée
Avi adopte une architecture distribuée reposant principalement sur deux composants.
Avi Controller : le plan de contrôle
Les Avi Controllers assurent la configuration, l’orchestration, la gestion des objets ADC et la centralisation des informations opérationnelles.
Ils permettent notamment de piloter les Virtual Services, les politiques applicatives et le déploiement des instances chargées du traitement du trafic.
Service Engines : le plan de données
Les Service Engines (SE) assurent le traitement effectif du trafic applicatif.
Ils hébergent les services de Load Balancing et peuvent être déployés selon différents modèles, en fonction des environnements supportés et de l’intégration choisie.
Cette séparation permet de dissocier l’administration centralisée des services ADC de leur exécution au plus près des applications.
Avi propose notamment :
- Load Balancing L4 et L7.
- Terminaison TLS et politiques avancées de trafic.
- Global Server Load Balancing (GSLB).
- Web Application Firewall (WAF).
- Intégration Kubernetes Ingress.
- Analytics applicatives et visibilité sur les performances.
- Automatisation via API, Ansible et Terraform.
L’objectif n’est plus simplement de distribuer les connexions, mais de disposer d’une véritable plateforme de services applicatifs.
4. Ce que change VCF 9.1 pour Avi
Avec VCF 9.1, Broadcom renforce l’intégration d’Avi dans les mécanismes d’automatisation, de consommation et d’exploitation du cloud privé.
Parmi les principales évolutions annoncées le 5 mai 2026 :
Intégration Kubernetes simplifiée
Le déploiement de vSphere Kubernetes Service (VKS) peut déclencher automatiquement l’installation et la configuration d’Avi Kubernetes Operator (AKO), réduisant les opérations manuelles nécessaires à la mise à disposition des services Ingress.
Load Balancing en self-service
L’intégration avec VCF Automation permet aux équipes applicatives de consommer des services de Load Balancing à travers des workflows délégués ou des catalogues de services prédéfinis.
Mutualisation des ressources entre VPC
Avi permet de mutualiser les ressources ADC entre plusieurs tenants tout en conservant des possibilités d’isolation adaptées aux applications.
Les Service Engine Groups peuvent être dédiés aux applications critiques ou partagés pour optimiser la consommation des ressources.
Gestion du cycle de vie
L’intégration avec VCF Operations facilite le déploiement des Controllers, leur configuration et certaines opérations de gestion du cycle de vie.
Ces évolutions renforcent le positionnement d’Avi comme plateforme ADC intégrée au cloud privé, plutôt que comme simple composant de Load Balancing supplémentaire.
5. NSX Load Balancing vs Avi : comparaison architecturale
| Critère | NSX Native Load Balancing | VMware Avi Load Balancer |
|---|---|---|
| Positionnement | Service réseau intégré NSX | Plateforme ADC dédiée |
| Architecture | Intégrée au modèle de services NSX | Controllers et Service Engines |
| Fonctionnalités | LB natif, périmètre dépendant de la version | L4/L7 et fonctions ADC avancées |
| GSLB | Non disponible dans l’offre native comparable | Oui |
| WAF | Non | Oui, selon les licences |
| Kubernetes Ingress avancé | Périmètre limité selon le cas d’usage | Intégration via AKO |
| Analytics applicatives | Visibilité réseau et opérationnelle | Analytics applicatives détaillées |
| Automatisation | API et intégration NSX/VCF | API, VCF Automation, Ansible, Terraform |
| Environnements hétérogènes | Dépendance aux services NSX | Plusieurs modèles d’intégration |
| Licence dans VCF 9.x | Usages autorisés restreints | Droits Avi à vérifier séparément |
Ce tableau met en évidence un point fondamental : NSX et Avi ne répondent pas exactement aux mêmes objectifs.
Le Load Balancing natif s’inscrit dans la fourniture de services réseau intégrés, tandis qu’Avi répond à des besoins plus larges de disponibilité, de performance, de sécurité et d’exploitation applicative.
6. Avi comme service ADC transverse : un choix d’architecture à considérer
L’un des intérêts d’Avi réside dans sa capacité à dissocier le plan de contrôle de l’infrastructure qui héberge les applications.
Dans une organisation disposant de plusieurs plateformes — vSphere, environnements cloud, Kubernetes ou infrastructures physiques — la question n’est plus uniquement de savoir comment fournir une VIP à une application.
Il s’agit également de déterminer où positionner les services ADC, comment mutualiser leur exploitation et comment éviter la multiplication de solutions de Load Balancing propres à chaque environnement.
Avi peut répondre à cette problématique grâce à une architecture de gestion centralisée et à différents modèles de déploiement des Service Engines.
Cependant, cette approche ne signifie pas qu’un même déploiement est automatiquement compatible avec toutes les plateformes.
Plusieurs aspects doivent être vérifiés :
- Le support officiel de l’hyperviseur ou du mode de déploiement choisi.
- La connectivité entre les Controllers et les Service Engines.
- Le routage des VIP et l’accessibilité des serveurs applicatifs.
- Les modes de haute disponibilité et de placement des Service Engines.
- Les contraintes de licences, d’exploitation et de support.
- Les domaines de responsabilité entre les équipes réseau, infrastructure et applicatives.
Le bon positionnement des Service Engines est un choix structurant : il détermine notamment les chemins de trafic, les contraintes réseau et les domaines de panne.
Dans une infrastructure hétérogène, une architecture ADC transverse peut être pertinente, à condition de ne pas introduire une dépendance réseau ou opérationnelle supplémentaire inutile.
7. Quelle architecture choisir selon les besoins ?
Le choix doit partir des exigences applicatives, et non uniquement des fonctionnalités disponibles dans une console.
Cas 1 : services d’infrastructure VCF et besoins L4 autorisés
Le Load Balancing natif NSX peut répondre aux besoins prévus par son périmètre d’utilisation et ses droits de licence.
Il convient toutefois de vérifier précisément le cas d’usage, notamment pour les services liés à vSphere Supervisor.
Cas 2 : applications métiers et services L7
Pour des applications nécessitant terminaison TLS, politiques HTTP, analytics, WAF ou GSLB, Avi constitue une solution plus adaptée.
Son architecture offre également davantage de possibilités pour industrialiser et automatiser la fourniture des services ADC.
Cas 3 : cloud privé multi-tenant
Dans un environnement VCF comportant plusieurs VPC, Avi permet de combiner une gestion centralisée avec une consommation self-service et des modèles de Service Engine Groups partagés ou dédiés.
Le dimensionnement et l’isolation des ressources doivent néanmoins être définis en fonction des exigences des applications.
Cas 4 : infrastructures hétérogènes
Pour une organisation exploitant plusieurs plateformes, Avi mérite d’être étudié comme socle ADC transverse.
Mais cette approche doit être validée à travers les matrices de compatibilité, les modèles de déploiement supportés et une analyse des flux réseau.
L’objectif n’est pas de centraliser systématiquement tous les flux, mais de centraliser la gouvernance des services lorsque cela apporte un réel bénéfice opérationnel.
Conclusion
Avec VCF 9.1, Broadcom renforce les possibilités de Load Balancing au sein des VPC tout en poursuivant l’intégration d’Avi dans son modèle de cloud privé.
NSX Native Load Balancing et Avi ne doivent toutefois pas être considérés comme deux solutions équivalentes.
Le premier répond à des besoins de services réseau intégrés, dans un périmètre d’utilisation désormais restreint. Le second constitue une plateforme ADC capable de prendre en charge des exigences applicatives avancées et des modèles d’exploitation plus transverses.
Pour les architectes, la décision doit donc reposer sur plusieurs critères : exigences L4/L7, disponibilité, sécurité, automatisation, interopérabilité, exploitation et licences.
Le véritable enjeu n’est pas simplement de choisir un Load Balancer, mais de définir une architecture de services applicatifs cohérente avec les besoins et les contraintes de l’infrastructure.
