Peering Azure - 3 modèles pour un réseau optimal

Le peering Azure n’est pas qu’une option de connectivité parmi d’autres. C’est souvent la différence entre un réseau simple à exploiter et une architecture qui devient vite coûteuse, fragile ou difficile à faire évoluer. Ici, je clarifie les modèles vraiment utiles, les cas où chacun s’impose et les points techniques que je vérifie avant de valider un design.

Comprendre les trois modèles d’interconnexion

Quand on parle de peering dans l’écosystème Microsoft, on mélange souvent des besoins très différents. Je préfère les séparer immédiatement en trois familles, parce qu’un mauvais cadrage au départ conduit presque toujours à un surdimensionnement, ou au contraire à une solution qui ne couvre pas le vrai besoin.

Dans la documentation Microsoft, le peering de réseaux virtuels est donné pour 500 réseaux au maximum par défaut, avec une montée possible à 1 000 via Azure Virtual Network Manager. Ce détail compte, parce qu’il montre bien que l’architecture doit être pensée pour grandir, pas seulement pour fonctionner au premier jour. Une fois ce cadre posé, la vraie question devient simple: quel type de trafic dois-je relier, et avec quel niveau de contrôle ?

Quand le peering de réseaux virtuels suffit

Le peering entre réseaux virtuels est la solution que je recommande le plus souvent pour les communications internes à Azure. Il connecte deux VNets sans passer par Internet, en gardant le trafic sur l’infrastructure privée de Microsoft. En pratique, cela donne une connexion à faible latence, à haut débit, et très adaptée aux architectures distribuées.

Je le choisis en priorité dans ces cas-là:

• des microservices ou des applications doivent échanger entre plusieurs VNets;
• un hub central héberge les services partagés et des spokes hébergent les workloads;
• des environnements de dev, de test et de préproduction doivent rester isolés tout en communiquant;
• plusieurs régions Azure doivent rester synchronisées avec un chemin privé et direct.

Il y a cependant deux limites que je vérifie toujours. D’abord, le peering n’est pas transitif: si VNet A est pairé avec VNet B, puis VNet B avec VNet C, cela ne crée pas automatiquement un chemin entre A et C. Ensuite, certaines décisions de routage ne se devinent pas toutes seules; il faut parfois ajouter des routes définies par l’utilisateur pour forcer le passage par une appliance, un firewall ou une passerelle.

Le peering global, c’est-à-dire entre régions différentes, élargit le champ d’usage, mais il faut rester attentif aux contraintes de certains services, notamment autour des load balancers Basic. Je conseille aussi de valider les routes effectives et de tester la connectivité avec Azure Network Watcher avant la mise en production. Cela évite les découvertes tardives, au moment où l’on pense que “tout est bien pairé” alors que le trafic ne suit pas le chemin attendu.

Une fois qu’on sort du pur Azure-vers-Azure, il faut regarder un autre registre: la connectivité hybride et l’accès privé aux services Microsoft.

Pourquoi ExpressRoute devient le bon choix en hybride

ExpressRoute sert à étendre un réseau local vers Microsoft Cloud via un fournisseur de connectivité, sans faire transiter le trafic par l’Internet public. C’est la bonne réponse quand on cherche de la stabilité, des latences plus constantes et une séparation plus nette entre le trafic métier et le trafic grand public.

Je distingue toujours deux domaines dans un circuit ExpressRoute:

• Azure Private peering pour accéder aux ressources Azure exposées en IP privée, comme des machines virtuelles ou certains services déployés dans un VNet;
• Microsoft peering pour atteindre des services Microsoft publics, avec un usage très fréquent autour de Microsoft 365 et de certains services SaaS.

Chaque peering repose sur deux sessions BGP indépendantes, configurées de manière redondante. C’est un détail technique important: BGP, le Border Gateway Protocol, est le protocole qui échange les préfixes de routage entre réseaux. Autrement dit, ce n’est pas juste un “tunnel”, c’est une relation de routage qui doit être propre des deux côtés.

La documentation ExpressRoute rappelle aussi des plafonds utiles à connaître en amont: jusqu’à 4 000 préfixes IPv4 et 100 préfixes IPv6 via Azure Private peering, et jusqu’à 200 préfixes par session BGP pour Azure public et Microsoft peering. Avec l’add-on Premium, la limite IPv4 peut monter à 10 000. Ce genre de chiffre ne sert pas qu’aux architectes réseaux; il sert surtout à éviter de construire une topologie qui explose en route tables dès la première phase d’extension.

Sur le plan de la facturation, ExpressRoute introduit une logique différente du peering VNet: le circuit et, souvent, la passerelle sont facturés à part, le trafic entrant est inclus dans la plupart des SKUs, alors que le trafic sortant dépend du modèle choisi. En pratique, je demande toujours: ai-je besoin d’un lien privé durable, ou ai-je seulement besoin d’un meilleur chemin d’accès vers certains services Microsoft ? Cette distinction change tout.

Et lorsqu’un réseau d’entreprise reste principalement sur Internet, mais veut mieux contrôler le chemin vers Microsoft, Azure Peering Service peut être plus cohérent qu’un gros investissement en connectivité privée.

Ce qu’Azure Peering Service apporte quand internet suffit

Azure Peering Service améliore la connectivité publique vers Microsoft Cloud, Microsoft 365, Dynamics 365 et d’autres services Microsoft accessibles via Internet. Ce n’est pas une solution privée comme ExpressRoute. En revanche, c’est une réponse intelligente quand l’entreprise veut de la performance, une meilleure proximité avec le réseau Microsoft et un routage plus fiable sans changer complètement de modèle de transport.

J’apprécie particulièrement ce modèle dans trois situations:

• l’entreprise adopte une stratégie internet-first;
• le trafic Microsoft SaaS est élevé et sensible à la qualité du chemin;
• l’architecture SD-WAN existe déjà et l’on veut renforcer la sortie vers Microsoft sans ajouter une couche privée complète.

Le point de vigilance est simple: Peering Service optimise le chemin, mais il ne remplace ni la maîtrise d’un circuit privé, ni le cloisonnement qu’apporte ExpressRoute. Je le vois comme une solution de qualité de transport, pas comme une refonte du réseau d’entreprise.

À ce stade, le choix paraît plus clair, mais la vraie différence entre un déploiement propre et un déploiement pénible tient souvent aux détails d’architecture et de routage.

Les étapes que je verrouille avant de passer en production

Quand je prépare une interconnexion Azure, je ne commence jamais par le portail. Je commence par le plan de routage, parce que c’est là que les problèmes se créent ou se préviennent. Une implémentation correcte suit presque toujours la même logique.

1. Je cartographie les flux réels: Azure vers Azure, Azure vers le datacenter, et Azure vers les services Microsoft publics.
2. Je vérifie les espaces d’adressage et j’élimine les chevauchements avant toute mise en relation.
3. Je décide si la topologie doit être en hub-and-spoke, en maillage partiel ou en simple paire de VNets.
4. Je définis le point de transit: gateway partagée, route server, appliance NVA ou chemin direct.
5. Je prépare les règles BGP, les filtres de routes et les UDR, puis je teste les routes effectives.
6. Je documente les dépendances de suppression, parce qu’un circuit ou une passerelle laissée en place peut continuer à générer des coûts.

Le hub-and-spoke reste, à mon sens, le schéma le plus rentable dès qu’il faut centraliser des services communs comme un firewall, une passerelle VPN ou un point d’observation réseau. Il évite de multiplier les pairings inutiles et limite les coûts de trafic entre réseaux. En revanche, il faut accepter une discipline plus stricte sur le routage, surtout si plusieurs équipes gèrent les spokes.

Je fais aussi attention à deux pièges fréquents. Le premier, c’est d’oublier que certaines modifications d’espace d’adressage exigent une synchronisation des peerings. Le second, c’est de croire qu’un simple peering résout automatiquement le besoin de transit vers l’on-premises; si le chemin passe par une passerelle, le design doit le dire explicitement. Dans les architectures sérieuses, ce sont ces détails-là qui font gagner du temps, pas les grands principes affichés dans les slides.

Le schéma que je retiendrais selon le cas d’usage

Si je devais simplifier au maximum la décision, je la résumerais ainsi. Le bon modèle n’est pas celui qui semble le plus moderne, mais celui qui colle exactement au trajet du trafic.

• Tout reste dans Azure, avec besoin de faible latence entre workloads: je choisis le peering de réseaux virtuels.
• Plusieurs régions Azure doivent coopérer, avec une architecture claire: je pars sur du peering global, souvent dans un hub-and-spoke.
• Le réseau local doit accéder à Azure en privé, avec des exigences fortes de stabilité: je prends ExpressRoute.
• Le besoin principal concerne Microsoft 365 ou d’autres services Microsoft via Internet, sans lien privé complet: je regarde Azure Peering Service.
• Le circuit ExpressRoute existe déjà et il faut consommer des services Microsoft publics de manière sélective: j’ajoute Microsoft peering avec filtre de routes.

Le réflexe que je conseille en 2026 est simple: commencer par la topologie la plus sobre qui répond au besoin, puis ajouter seulement le niveau de connectivité nécessaire. C’est presque toujours moins cher, plus lisible et plus facile à maintenir qu’un design surchargé dès le départ.