Topologie réseau hub-and-spoke : diagrammes Azure et AWS

Le premier réseau cloud est facile. Au dixième, on a une toile de connexions de peering, trois tunnels VPN vers le bureau configurés chacun un peu différemment, un pare-feu copié dans chaque réseau, et personne ne peut dire avec certitude qui peut joindre quoi. Le hub-and-spoke est la sortie standard : un réseau central pour la connectivité partagée et l'inspection, et des workloads dans des spokes isolés qui ne se connectent qu'à travers lui.

Cet article explique la topologie, puis la construit deux fois avec des diagrammes : dans Azure avec un réseau virtuel hub et du peering, et dans AWS avec Transit Gateway. Il couvre le routage et la segmentation, l'inspection du trafic, la sortie centralisée, les coûts qui surprennent les équipes, et les cas où un hub managé est le meilleur choix.

Pourquoi un maillage cesse de fonctionner

Relier directement chaque réseau à tous les autres demande n(n−1)/2 connexions. Dix réseaux en demandent 45 ; cinquante en demandent 1 225, chacune avec ses routes et ses règles de sécurité. Le peering n'est pas non plus transitif, dans aucun des deux clouds : si A est appairé à B et B à C, A ne peut toujours pas joindre C à travers B. Un design hub-and-spoke ne demande qu'une connexion par spoke, et le hub devient l'unique endroit où vivent le routage et la politique de sécurité.

Ce qui va dans le hub

Les workloads n'ont pas leur place dans le hub. Les spokes hébergent les applications, en général un par application, par équipe ou par environnement, pour qu'une erreur dans l'un ne se propage pas aux autres.

Le hub-and-spoke dans Azure

L'architecture de référence hub-spoke de Microsoft place Azure Firewall, une passerelle VPN ou ExpressRoute et Azure Bastion dans un réseau virtuel hub, chacun dans son propre sous-réseau dédié. Azure Firewall exige un sous-réseau d'au moins /26. Les spokes se connectent au hub par peering de réseaux virtuels, que Microsoft décrit comme non transitif : des réseaux appairés se parlent entre eux, pas à travers les uns des autres.

Cela a deux conséquences :

• Le partage de passerelle est explicite. Le peering du hub autorise le transit par passerelle et chaque spoke utilise la passerelle distante, pour que les spokes joignent le site via la passerelle du hub.
• Le trafic entre spokes a besoin de routes. Des routes définies par l'utilisateur dans chaque spoke envoient le trafic destiné aux autres spokes, et en général la route par défaut, vers l'IP privée du pare-feu. Le pare-feu transmet ce que la politique autorise. Sinon, Azure Virtual Network Manager peut gérer les peerings et les groupes connectés à grande échelle, et un peering direct entre deux spokes reste possible pour des cas particuliers.

Pour un hub géré par Microsoft, Azure Virtual WAN fournit des hubs avec routage intégré, passerelles et pare-feu optionnels, en échange d'un contrôle moindre sur les détails.

Le hub-and-spoke dans AWS

Dans AWS, le hub est en général un Transit Gateway, un routeur régional auquel s'attachent les VPC, les connexions VPN et les passerelles Direct Connect :

• Les spokes sont des attachements de VPC. Un Transit Gateway prend en charge 5 000 attachements par défaut, selon les quotas de Transit Gateway ; il va donc bien au-delà des maillages de peering.
• La segmentation vient des tables de routage du Transit Gateway. Les attachements de production sont associés à une table, ceux de développement à une autre, si bien que les deux n'apprennent jamais les routes l'un de l'autre, tout en pouvant joindre un VPC de services partagés.
• L'inspection se fait dans un VPC d'inspection dédié qui exécute AWS Network Firewall ou des appliances tierces derrière un Gateway Load Balancer. Les tables de routage des spokes pointent vers le Transit Gateway, et ses routes font passer le trafic par le VPC d'inspection.
• Le mode appliance, sur l'attachement du VPC d'inspection, garde les deux sens d'un flux dans la même zone de disponibilité, ce qu'exigent les pare-feu avec état.
• La sortie centralisée : un VPC de sortie avec des passerelles NAT sert tous les spokes, au lieu de passerelles NAT dans chaque VPC.

Pour les réseaux mondiaux couvrant de nombreuses régions, AWS Cloud WAN joue le rôle que Virtual WAN joue dans Azure : un réseau central managé avec des segments définis par politique.

Les deux clouds côte à côte

Routage, segmentation et symétrie

Trois règles rendent un réseau hub-and-spoke prévisible :

1. Les routes par défaut pointent vers le hub. Les spokes envoient au hub tout ce qui n'est pas local, pour que rien ne contourne l'inspection par accident.
2. Les segments sont explicites. Décidez quels spokes peuvent parler à quels autres : production et développement en général non, les services partagés en général joignables depuis partout, et l'accès au site passe par le pare-feu.
3. Le trafic de retour doit prendre le même chemin. Un pare-feu avec état rejette les réponses dont il n'a pas vu l'aller. Les routes asymétriques sont la cause la plus fréquente du « la règle de pare-feu existe, mais rien ne marche ».

Écrivez le plan d'adressage avant que le premier spoke n'existe. Des plages CIDR qui se chevauchent entre spokes, ou avec le site, ne peuvent pas être routées à travers un hub et sont pénibles à corriger plus tard.

Ce que ça coûte

Chaque octet qui traverse le hub est facturé quelque part. Dans AWS, au moment de la rédaction (novembre 2026), la tarification de Transit Gateway dans US East (N. Virginia) est de 0,05 USD par attachement et par heure et de 0,02 USD par Go de données traitées. Dix attachements de spokes coûtent environ 10 × 0,05 USD × 730 heures, soit à peu près 365 USD par mois, avant tout trafic. Dix To de trafic entre spokes ajoutent environ 10 240 Go × 0,02 USD, soit à peu près 205 USD de traitement, plus les frais de traitement du pare-feu. Dans Azure, le trafic appairé est facturé au Go aux deux extrémités du peering, et Azure Firewall ajoute ses propres frais de traitement.

L'optimisation habituelle est ciblée : gardez le hub pour la politique, et ajoutez un peering direct pour une paire précise de spokes qui échangent de très gros volumes et n'ont pas besoin d'inspection.

Quand ne pas utiliser le hub-and-spoke

• Deux ou trois réseaux n'ont pas besoin de hub ; le peering direct est plus simple.
• Le trafic est-ouest sensible à la latence paie un saut supplémentaire et un pare-feu à chaque paquet. Mesurez avant de faire passer une paire de services bavards par l'inspection.
• D'énormes volumes internes peuvent faire du traitement au Go le premier poste de coût réseau. Un peering direct pour ces flux est souvent justifié.
• Les très grands parcs multirégions sont souvent mieux servis par un hub managé, Virtual WAN ou Cloud WAN, que par des tables de routage construites à la main.

Le diagramme hub-and-spoke

Comment le lire :

• Le site, en haut, se connecte une fois à chaque cloud : à la passerelle du hub Azure et au Transit Gateway AWS.
• Le cadre Azure montre le réseau virtuel hub avec son pare-feu et sa passerelle VPN, et deux spokes appairés. Le trafic entre spokes passe par le pare-feu.
• Le cadre AWS montre le Transit Gateway au milieu, le VPC d'inspection avec son pare-feu et deux VPC spoke attachés.
• Les étiquettes des arêtes nomment le type de connexion : peering, attachement, VPN ou circuit privé.
• Le bloc Markdown liste les règles de routage et les chiffres de coût ci-dessus.

Dessiner des topologies réseau qui passent la relecture

• Écrivez la plage CIDR sur chaque réseau. Les chevauchements sont la première chose que vérifie un relecteur.
• Dessinez le pare-feu là où le trafic passe réellement, et montrez la route par défaut qui pointe vers lui.
• Étiquetez chaque connexion par son type. Peering, attachement et VPN se comportent et se facturent différemment.
• Gardez un diagramme par région. Les réseaux multirégions dessinés sur une seule toile cachent souvent les liens interrégions qui comptent.

Pour l'intérieur d'un réseau, voyez le diagramme de VPC AWS. Le diagramme de topologie réseau couvre les topologies physiques et logiques en général, et le diagramme d'architecture zero trust explique pourquoi la position dans le réseau ne doit pas suffire à donner un accès. Les conceptions multirégions sont traitées dans le diagramme d'architecture AWS multirégion.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez en haut une Boîte du pack Base pour le réseau sur site.
3. Ajoutez un Cadre du pack Base pour Azure. À l'intérieur, ajoutez un nœud VPC du pack Réseau pour le réseau virtuel hub, avec un Pare-feu et un nœud Appareil pour la passerelle VPN dedans, puis deux autres nœuds VPC pour les spokes, chacun avec son CIDR.
4. Ajoutez un Cadre du pack Base pour AWS. À l'intérieur, ajoutez un Routeur du pack Réseau pour le Transit Gateway, un nœud VPC pour le VPC d'inspection avec un Pare-feu dedans, et deux nœuds VPC pour les spokes.
5. Reliez le site à la passerelle Azure et au Transit Gateway, les spokes à leurs hubs, et étiquetez chaque arête avec son type de connexion.
6. Ajoutez un bloc Markdown du pack Base avec les règles de routage et les coûts.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Qu'est-ce qu'une topologie réseau hub-and-spoke ? Une conception où un réseau central, le hub, porte la connectivité, la sécurité et les services partagés, et où chaque réseau de workload, un spoke, ne se connecte qu'au hub. Le trafic entre spokes et vers le site passe par le hub.

Le peering de réseaux virtuels est-il transitif ? Non, ni dans Azure ni dans AWS. Deux spokes appairés au même hub ne peuvent pas se joindre à travers lui, sauf si des routes envoient leur trafic vers un pare-feu ou un routeur du hub.

Quelle est la différence entre Transit Gateway et le peering de VPC ? Le peering de VPC relie directement deux VPC et n'est pas transitif. Transit Gateway est un routeur régional auquel s'attachent de nombreux VPC et connexions vers le site, avec des tables de routage pour la segmentation.

Faut-il utiliser Azure Virtual WAN plutôt qu'un réseau virtuel hub ? Virtual WAN convient aux grands parcs ou aux parcs multirégions qui veulent que Microsoft gère le routage du hub et les passerelles. Un hub autogéré donne plus de contrôle et reste courant pour une poignée de spokes dans une ou deux régions.

Combien coûte le hub-and-spoke ? Les connexions au hub et le trafic traité sont facturés à l'heure et au Go, plus le traitement du pare-feu. Dans AWS, au moment de la rédaction, un attachement Transit Gateway coûte 0,05 USD de l'heure et le traitement des données 0,02 USD par Go dans US East.

Commencez gratuitement — un siège, sans carte bancaire.