Modifier

Topologie réseau hub-and-spoke dans Azure

Azure Bastion
Pare-feu Azure
Azure Network Watcher
Réseau virtuel Azure
Passerelle VPN Azure

Cette architecture de référence implémente un modèle de réseau hub-and-spoke avec des composants d’infrastructure hub gérés par le client. Pour obtenir une solution d’infrastructure hub gérée par Microsoft, consultez Topologie réseau hub-and-spoke avec Azure Virtual WAN.

Architecture

Diagramme illustrant une topologie de réseau virtuel hub-and-spoke dans Azure avec des réseaux spoke connectés via le hub ou directement.

Téléchargez un fichier Visio de cette architecture.

Workflow

Cette configuration réseau hub-and-spoke utilise les éléments architecturaux suivants :

  • Réseau virtuel Hub. Le réseau virtuel hub héberge des services Azure partagés. Les charges de travail hébergées dans les réseaux virtuels spoke peuvent utiliser ces services. Le réseau virtuel hub est le point central de connectivité pour vos réseaux entre différents locaux.

  • Réseaux virtuels spokes. Les réseaux virtuels Spoke isolent et gèrent les charges de travail séparément dans chaque spoke. Chaque charge de travail peut inclure plusieurs niveaux, avec plusieurs sous-réseaux connectés à l’aide d’équilibreurs de charge Azure. Les spokes peuvent exister dans différents abonnements et représenter différents environnements, tels que Production et Hors production.

  • Connectivité de réseau virtuel. Cette architecture connecte des réseaux virtuels à l’aide de connexions de peering ou de groupes connectés. Les connexions de peering et les groupes connectés sont des connexions non transitives et à faible latence entre des réseaux virtuels. Les réseaux virtuels appairés ou connectés peuvent échanger du trafic sur le réseau principal Azure sans avoir besoin d’un routeur. Azure Virtual Network Manager crée et gère les groupes de réseaux et leurs connexions.

  • Hôte Azure Bastion. Azure Bastion fournit une connectivité sécurisée du portail Azure vers les machines virtuelles en utilisant votre navigateur. Un hôte Azure Bastion déployé à l’intérieur d’un réseau virtuel Azure peut accéder aux machines virtuelles de ce réseau virtuel ou de réseaux virtuels connectés.

  • Pare-feu Azure. Une instance de pare-feu managée Pare-feu Azure existe dans son propre sous-réseau.

  • Passerelle VPN Azure ou passerelle Azure ExpressRoute. Une passerelle de réseau virtuel permet à un réseau virtuel de se connecter à un appareil de réseau privé virtuel (VPN) ou à un circuit Azure ExpressRoute. La passerelle fournit une connectivité réseau entre différents locaux. Pour plus d’informations, consultez Connecter un réseau local à un réseau virtuel Microsoft Azure et Étendre un réseau local à l’aide d’un VPN.

  • Périphérique VPN. Un appareil ou service VPN assure la connectivité externe au réseau entre différents locaux. L’appareil VPN peut être un appareil matériel ou une solution logicielle comme le service RRAS (Service Routage et accès à distance) dans Windows Server. Pour plus d’informations, consultez Appareils VPN validés et guides de configuration des appareils.

Composants

  • Virtual Network Manager est un service de gestion qui vous aide à regrouper, à configurer, à déployer et à gérer des réseaux virtuels à grande échelle entre des abonnements, des régions et des locataires Azure. Avec Virtual Network Manager, vous pouvez définir des groupes de réseaux virtuels pour identifier et segmenter de manière logique vos réseaux virtuels. Vous pouvez définir et appliquer des configurations de connectivité et de sécurité sur tous les réseaux virtuels d’un groupe de réseaux à la fois.

  • Le réseau virtuel Azure est le composant fondamental pour vos réseaux privés dans Azure. Réseau virtuel permet à de nombreuses ressources Azure, telles que les machines virtuelles Azure, de communiquer de manière sécurisée entre elles, avec vos réseaux entre différents locaux et avec Internet.

  • Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell Protocol) plus sécurisé et transparent aux machines virtuelles sans exposer leurs adresses IP publiques.

  • Pare-feu Azure est un service de sécurité réseau cloud managé qui protège les ressources de réseau virtuel. Ce service de pare-feu avec état dispose d’une haute disponibilité intégrée et d’une scalabilité cloud illimitée pour vous aider à créer, à appliquer et à journaliser des stratégies de connectivité réseau et d’application entre des abonnements et des réseaux virtuels.

  • Une passerelle VPN est un type spécifique de passerelle de réseau virtuel qui achemine du trafic chiffré entre un réseau virtuel et un emplacement local via l’Internet public. Vous pouvez également utiliser une passerelle VPN pour envoyer du trafic chiffré entre les réseaux virtuels Azure sur le réseau Microsoft.

  • Azure Monitor peut collecter, analyser et exploiter les données de télémétrie issues d’environnements entre différents locaux, notamment Azure et les environnements locaux. Azure Monitor vous aide à optimiser les performances et la disponibilité de vos applications, et à identifier de manière proactive les problèmes en quelques secondes.

Détails du scénario

Cette architecture de référence implémente un modèle réseau hub-and-spoke où le réseau virtuel hub joue le rôle de point central de connectivité à de nombreux réseaux virtuels spoke. Les réseaux virtuels spoke sont connectés au hub et peuvent être utilisés pour isoler les charges de travail. Vous pouvez également activer des scénarios entre différents locaux à l’aide du hub pour vous connecter à des réseaux locaux.

Cette architecture décrit un modèle réseau avec des composants d’infrastructure hub gérés par le client. Pour obtenir une solution d’infrastructure hub gérée par Microsoft, consultez Topologie réseau hub-and-spoke avec Azure Virtual WAN.

Les avantages offerts par l’utilisation d’une configuration hub-and-spoke sont les suivants :

  • Réduction des coûts
  • Dépassement des limites de l’abonnement
  • Isolation des charges de travail

Pour plus d’informations, consultez Topologie de réseau hub-and-spoke.

Cas d’usage potentiels

Les utilisations courantes d’une architecture hub-and-spoke incluent les charges de travail qui :

  • Ont plusieurs environnements qui nécessitent des services partagés. Par exemple, une charge de travail peut avoir des environnements de développement, de test et de production. Les services partagés peuvent inclure des ID DNS, le protocole NTP (Network Time Protocol) ou les services de domaine Active Directory (AD DS). Les services partagés sont placés dans le réseau virtuel hub, et chaque environnement est déployé sur un spoke différent afin de garantir l’isolation.
  • N’exigent pas de connectivité entre elles, mais nécessitent un accès aux services partagés.
  • Exigent un contrôle central sur la sécurité, comme un pare-feu de réseau de périmètre (également appelé DMZ) dans le hub avec une gestion séparée des charges de travail dans chaque spoke.
  • Exigent un contrôle central sur la connectivité, comme la connectivité sélective ou l’isolation entre les spokes de certains environnements ou charges de travail.

Recommandations

Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez des besoins spécifiques qui vous obligent à les ignorer.

Groupes de ressources, abonnements et régions

Cet exemple de solution utilise un seul groupe de ressources Azure. Vous pouvez également implémenter le hub et chaque spoke dans différents abonnements et groupes de ressources.

Lorsque vous homologuez des réseaux virtuels dans différents abonnements, vous pouvez associer les abonnements à des locataires Microsoft Entra identiques ou différents. Cette flexibilité permet de décentraliser la gestion de chaque charge de travail tout en conservant les services partagés dans le hub. Consultez Créer un appairage de réseaux virtuels – Azure Resource Manager, abonnements et locataires Microsoft Entra différents.

En règle générale, il est préférable d’avoir au moins un hub par région. Cette configuration aide à ne pas avoir de point de défaillance unique, par exemple pour éviter que les ressources de la région A ne soient affectées au niveau du réseau par une panne dans la région B.

Sous-réseaux du réseau virtuel

Les recommandations suivantes décrivent comment configurer les sous-réseaux du réseau virtuel.

GatewaySubnet

La passerelle de réseau virtuel requiert ce sous-réseau. Vous pouvez également utiliser une topologie hub-and-spoke sans passerelle si vous n’avez pas besoin d’une connectivité réseau entre différents locaux.

Créez un sous-réseau nommé GatewaySubnet avec une plage d’adresses d’au moins /27. La plage d’adresses /27 offre au sous-réseau suffisamment d’options de configuration de scalabilité pour éviter d’atteindre les limitations de taille de passerelle à l’avenir. Pour plus d’informations sur la configuration de la passerelle, consultez les architectures de référence suivantes, en fonction de votre type de connexion :

Pour accroître la disponibilité, vous pouvez utiliser ExpressRoute et un VPN pour le basculement. Consultez Connecter un réseau local à Azure à l’aide d’ExpressRoute avec basculement VPN.

AzureFirewallSubnet

Créez un sous-réseau nommé AzureFirewallSubnet, avec une plage d’adresses d’au moins /26. Quelle que soit l’échelle, la plage d’adresses /26 est la taille recommandée, et couvre toutes les limitations de taille à l’avenir. Ce sous-réseau ne prend pas en charge les groupes de sécurité réseau (NSG).

Le Pare-feu Azure nécessite ce sous-réseau. Si vous utilisez une appliance virtuelle réseau (NVA) partenaire, suivez ses exigences réseau.

Connectivité réseau spoke

L’appairage de réseaux virtuels ou les groupes connectés sont des relations non transitives entre des réseaux virtuels. Si vous avez besoin que les réseaux virtuels spoke se connectent les uns aux autres, ajoutez une connexion de peering entre ces spokes ou placez-les dans le même groupe de réseaux.

Connexions spoke via Pare-feu Azure ou NVA

Le nombre d’appairages de réseaux virtuels par réseau virtuel est limité. Si vous avez de nombreux spokes qui doivent se connecter les uns aux autres, vous pourriez être à court de connexions de peering. Les groupes connectés ont également des limitations. Pour plus d’informations, consultez Limites de mise en réseau et Limites des groupes connectés.

Dans ce scénario, envisagez d’utiliser des routes définies par l’utilisateur afin que le trafic de spoke soit envoyé au Pare-feu Azure ou à une autre appliance virtuelle réseau faisant office de routeur sur le hub. Ce changement permet aux spokes de se connecter les uns aux autres. Pour prendre en charge cette configuration, vous devez implémenter Pare-feu Azure avec la configuration de tunnel forcé activée. Pour plus d’informations, consultez la page Tunneling forcé du Pare-feu Azure.

La topologie de cette conception architecturale facilite les flux de sortie. Bien que le Pare-feu Azure soit principalement destiné à la sécurité en sortie, il peut également être un point d’entrée. Pour découvrir d’autres considérations relatives au routage d’entrée NVA de hub, consultez Pare-feu et Application Gateway pour réseaux virtuels.

Connexions de spokes à des réseaux distants par le biais d’une passerelle hub

Pour configurer des spokes de façon à ce qu’ils communiquent avec des réseaux distants par le biais d’une passerelle hub, vous pouvez utiliser des appairages de réseaux virtuels ou des groupes de réseaux connectés.

Pour utiliser des appairages de réseaux virtuels, dans la configuration Peering de réseau virtuel :

  • Configurez la connexion de peering dans le hub de façon à Autoriser le transit par passerelle.
  • Configurez la connexion de peering dans chaque spoke de façon à Utiliser la passerelle du réseau virtuel distant.
  • Configurez toutes les connexions de peering de façon à Autoriser le trafic transféré.

Pour plus d’informations, consultez Créer un appairage de réseaux virtuels.

Pour utiliser des groupes de réseaux connectés :

  1. Dans Virtual Network Manager, créez un groupe de réseaux et ajoutez des réseaux virtuels membres.
  2. Créez une configuration de connectivité hub-and-spoke.
  3. Pour les Groupes de réseaux Spoke, sélectionnez Hub comme passerelle.

Pour plus d’informations, consultez Créer une topologie hub-and-spoke avec Azure Virtual Network Manager.

Communications des réseaux spoke

Il existe deux manières principales de permettre aux réseaux virtuels spoke de communiquer entre eux :

  • Communication par le biais d’une appliance virtuelle réseau comme un pare-feu et un routeur. Cette méthode implique un tronçon entre les deux spokes
  • Communication à l’aide d’un appairage de réseaux virtuels ou d’une connectivité directe Virtual Network Manager entre les spokes. Cette approche n’implique pas de tronçon entre les deux spokes, et est recommandée pour réduire la latence

Communication par le biais d’une appliance virtuelle réseau

Si vous avez besoin d’une connectivité entre les spokes, déployez Pare-feu Azure ou une autre appliance virtuelle réseau dans le hub. Créez ensuite des routes pour transférer le trafic d’un spoke vers le pare-feu ou l’appliance virtuelle réseau, qui peut ensuite le router vers le deuxième spoke. Dans ce scénario, vous devez configurer les connexions de peering pour autoriser le trafic transféré.

Diagramme illustrant le routage entre des spokes à l’aide de Pare-feu Azure

Vous pouvez également utiliser une passerelle VPN pour router le trafic entre les spokes, bien que cela ait un impact en termes de latence et de débit. Pour connaître les détails de configuration, consultez Configurer le transit par passerelle VPN pour le peering de réseaux virtuels.

Évaluez les services que vous partagez dans le hub, afin que ce dernier puisse prendre en charge un plus grand nombre de spokes. Par exemple, si votre hub fournit des services de pare-feu, tenez compte des limites de bande passante de votre solution de pare-feu quand vous ajoutez plusieurs membres spokes. Vous pouvez déplacer certains de ces services partagés vers un deuxième niveau de hubs.

Communication directe entre les réseaux spoke

Pour établir une connexion directe entre des réseaux virtuels spoke sans traverser le réseau virtuel hub, vous pouvez créer des connexions de peering entre des spokes ou activer la connectivité directe pour le groupe de réseaux. Il est préférable de limiter le peering ou la connectivité directe à des réseaux virtuels spoke qui font partie du même environnement et de la même charge de travail.

Lorsque vous utilisez Virtual Network Manager, vous pouvez ajouter manuellement des réseaux virtuels spoke à des groupes de réseaux, ou ajouter automatiquement des réseaux en fonction des conditions que vous définissez. Pour plus d’informations, consultez Mise en réseau spoke-to-spoke.

Le diagramme suivant illustre l’utilisation de Virtual Network Manager pour la connectivité directe entre les spokes.

Diagramme illustrant l’utilisation de Virtual Network Manager pour la connectivité directe entre les spokes.

Recommandations en matière de gestion

Pour gérer de manière centralisée les contrôles de connectivité et de sécurité, utilisez Virtual Network Manager pour créer de nouvelles topologies de réseau virtuel hub-and-spoke ou intégrer des topologies existantes. L’utilisation de Virtual Network Manager garantit que vos topologies de réseau hub-and-spoke sont préparées à une croissance future à grande échelle sur plusieurs abonnements, groupes d’administration et régions.

Voici quelques exemples de cas d’usage de Virtual Network Manager :

  • Démocratisation de la gestion des réseaux virtuels spoke auprès de groupes tels que les unités commerciales ou les équipes d’application. La démocratisation peut générer un grand nombre d’exigences en matière de règles de sécurité réseau et de connectivité réseau virtuel à réseau virtuel
  • Normalisation des architectures à plusieurs réplicas dans plusieurs régions Azure afin de garantir une empreinte globale pour les applications

Pour garantir l’uniformité des règles de connectivité et de sécurité réseau, vous pouvez utiliser des groupes de réseaux pour regrouper des réseaux virtuels dans n’importe quel abonnement, groupe d’administration ou région sous le même locataire Microsoft Entra. Vous pouvez intégrer automatiquement ou manuellement des réseaux virtuels à des groupes de réseaux par le biais d’attributions d’appartenance dynamiques ou statiques.

Vous définissez la détectabilité des réseaux virtuels que Virtual Network Manager gère à l’aide d’étendues. Cette fonctionnalité offre une flexibilité pour un nombre souhaité d’instances de gestionnaire de réseau, ce qui autorise une démocratisation plus poussée de la gestion pour les groupes de réseaux virtuels.

Pour connecter des réseaux virtuels spoke du même groupe de réseaux les uns aux autres, utilisez Virtual Network Manager pour implémenter l’appairage de réseaux virtuels ou la connectivité directe. Utilisez l’option de maillage global pour étendre la connectivité directe du maillage aux réseaux spoke dans différentes régions. Le diagramme suivant montre la connectivité de maillage global entre régions.

Diagramme montrant la connectivité directe du maillage global spoke entre régions.

Vous pouvez associer des réseaux virtuels au sein d’un groupe de réseaux à un ensemble de règles d’administration de sécurité de base. Les règles d’administration de la sécurité des groupes de réseaux empêchent les propriétaires de réseau virtuel spoke de remplacer les règles de sécurité de base, tout en leur permettant d’ajouter indépendamment leurs propres ensembles de règles de sécurité et de groupes de sécurité réseau. Pour obtenir un exemple d’utilisation de règles d’administration de sécurité dans des topologies hub-and-spoke, consultez Didacticiel : Créer un réseau en étoile sécurisé.

Pour faciliter un déploiement contrôlé de groupes de réseaux, de connectivité et de règles de sécurité, les déploiements de configuration Virtual Network Manager vous aident à publier de manière sécurisée des modifications de configuration potentiellement cassantes dans les environnements hub-and-spoke. Pour plus d’informations, consultez Déploiements de configuration dans Azure Virtual Network Manager.

Pour bien démarrer avec Virtual Network Manager, consultez Créer une topologie hub-and-spoke avec Azure Virtual Network Manager.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Pour garantir un ensemble de règles de sécurité de base, veillez à associer des règles d’administration de sécurité aux réseaux virtuels des groupes de réseaux. Les règles d’administration de sécurité sont prioritaires et évaluées avant les règles NSG. Comme les règles NSG, les règles d’administration de sécurité prennent en charge la hiérarchisation, les étiquettes de service et les protocoles L3-L4. Pour plus d’informations, consultez Règles d’administration de sécurité dans Azure Virtual Network Manager.

Utilisez des déploiements Virtual Network Manager pour faciliter le déploiement contrôlé des modifications potentiellement cassantes apportées aux règles de sécurité des groupes de réseaux.

Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel de périmètre.

Optimisation des coûts

L’optimisation des coûts concerne les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Tenez compte des facteurs liés aux coûts suivants lorsque vous déployez et gérez des réseaux hub-and-spoke. Pour plus d'informations, consultez Tarification de réseau virtuel.

Coûts du Pare-feu Azure

Cette architecture déploie une instance de Pare-feu Azure dans le réseau hub. L’utilisation d’un déploiement de Pare-feu Azure en tant que solution partagée consommée par plusieurs charges de travail peut réduire considérablement les coûts cloud par rapport à d’autres appliances virtuelles réseau. Pour plus d’informations, consultez Pare-feu Azure et appliances virtuelles réseau.

Pour utiliser efficacement toutes les ressources déployées, choisissez la taille de Pare-feu Azure appropriée. Déterminez les fonctionnalités dont vous avez besoin et le niveau le mieux adapté à votre ensemble actuel de charges de travail. Pour en savoir plus sur les références SKU de Pare-feu Azure disponibles, consultez Qu’est-ce qu’un pare-feu Azure ?.

Coût des adresses IP privées

Vous pouvez utiliser des adresses IP privées pour router le trafic entre des réseaux virtuels appairés ou entre des réseaux dans des groupes connectés. Les considérations suivantes en terme de coût s’appliquent :

  • Le trafic d’entrée et de sortie est facturé aux deux extrémités des réseaux appairés ou connectés. Par exemple, le transfert de données à partir d’un réseau virtuel de la zone 1 vers un réseau virtuel de la zone 2 implique un taux de transfert sortant pour la zone 1 et un taux d’entrée pour la zone 2
  • Les différentes zones présentent des taux de transfert différents.

Planifiez l’adressage IP en fonction de vos exigences d’appairage, et vérifiez qu’il n’existe pas de chevauchement des espaces d’adressage IP des emplacements entre différents locaux et des emplacements Azure.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Utilisez Azure Network Watcher pour superviser et résoudre les problèmes liés aux composants réseau à l’aide des outils suivants :

  • Traffic Analytics montre les systèmes de vos réseaux virtuels qui génèrent le plus de trafic. Vous pouvez identifier visuellement les goulots d’étranglement avant qu’ils ne deviennent des problèmes
  • Network Performance Monitor supervise les informations sur les circuits ExpressRoute
  • Les diagnostics VPN permettent de résoudre les problèmes de connexions VPN de site à site qui connectent vos applications aux utilisateurs locaux

Pensez également à activer la journalisation des diagnostics du Pare-feu Azure pour obtenir de meilleurs insights sur les requêtes DNS et les résultats autoriser/refuser dans les journaux.

Déployer ce scénario

Ce déploiement comprend un réseau virtuel hub et deux spokes connectés, ainsi qu’une instance de Pare-feu Azure et un hôte Azure Bastion. Le déploiement peut éventuellement inclure des machines virtuelles dans le premier réseau spoke et une passerelle VPN.

Vous pouvez choisir entre l’appairage de réseaux virtuels ou les groupes connectés Virtual Network Manager pour créer les connexions réseau. Chaque méthode offre plusieurs options de déploiement.

Utiliser l’appairage de réseaux virtuels

  1. Exécutez la commande suivante pour créer un groupe de ressources nommé hub-spoke dans la région eastus pour le déploiement. Sélectionnez Essayer pour utiliser un interpréteur de commandes incorporé.

    az group create --name hub-spoke --location eastus

  2. Exécutez la commande suivante pour télécharger le modèle Bicep.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke/bicep/main.bicep > main.bicep

  3. Exécutez la commande suivante pour déployer la configuration du réseau hub-and-spoke, les appairages de réseaux virtuels entre le hub et les spokes, et un hôte Azure Bastion. Quand vous y êtes invité, entrez un nom d’utilisateur et un mot de passe. Vous pouvez utiliser ce nom d’utilisateur et ce mot de passe pour accéder aux machines virtuelles dans les réseaux spoke.

    az deployment group create --resource-group hub-spoke --template-file main.bicep

Si vous souhaitez obtenir des informations détaillées et d’autres options de déploiement, consultez les Modèles Bicep et ARM hub-and-spoke qui déploient cette solution.

Utiliser des groupes connectés Virtual Network Manager

  1. Exécutez la commande suivante pour créer un groupe de ressources pour le déploiement. Sélectionnez Essayer pour utiliser un interpréteur de commandes incorporé.

    az group create --name hub-spoke --location eastus

  2. Exécutez la commande suivante pour télécharger le modèle Bicep.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/main.bicep > main.bicep

  3. Exécutez les commandes suivantes pour télécharger tous les modules nécessaires dans un nouveau répertoire.

    mkdir modules

curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnm.bicep > modules/avnm.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnmDeploymentScript.bicep > modules/avnmDeploymentScript.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/hub.bicep > modules/hub.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/spoke.bicep > modules/spoke.bicep

  4. Exécutez la commande suivante pour déployer la configuration du réseau hub-and-spoke, les connexions de réseaux virtuels entre le hub et les spokes, et un hôte Bastion. Quand vous y êtes invité, entrez un nom d’utilisateur et un mot de passe. Vous pouvez utiliser ce nom d’utilisateur et ce mot de passe pour accéder aux machines virtuelles dans les réseaux spoke.

    az deployment group create --resource-group hub-spoke --template-file main.bicep

Si vous souhaitez obtenir des informations détaillées et d’autres options de déploiement, consultez les Modèles Bicep et ARM hub-and-spoke qui déploient cette solution.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Alejandra Palacios | Ingénieur client senior

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Découvrez les architectures associées suivantes :