Topologie réseau hub-and-spoke dans 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.

Hub-spoke est l’une des topologies réseau recommandées par le Cloud Adoption Framework. Consultez Définir une topologie de réseau Azure pour comprendre pourquoi cette topologie est considérée comme une bonne pratique pour de nombreuses organisations.

Architecture

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

Concepts hub-spoke

Les topologies réseau hub-spoke incluent généralement les nombreux concepts 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. Le hub contient votre point de sortie principal et fournit un mécanisme permettant de connecter un spoke à un autre dans les situations où le trafic entre réseaux virtuels est nécessaire.

  Un hub est une ressource régionale. Les organisations qui ont leurs charges de travail dans plusieurs régions doivent avoir plusieurs hubs, un par région.

  Le hub active les concepts suivants :

  • passerelle intersite : la connectivité intersite est la possibilité de connecter et d’intégrer différents environnements réseau les uns aux autres. Cette passerelle est généralement un VPN ou un circuit ExpressRoute.

  • contrôle de sortie : gestion et régulation du trafic sortant provenant des réseaux virtuels spoke appairés.

  • (facultatif) Contrôle d’entrée : gestion et régulation du trafic entrant vers les points de terminaison qui existent dans les réseaux virtuels spoke appairés.

  • accès à distance : l’accès à distance est la façon dont les charges de travail individuelles dans les réseaux spoke sont accessibles à partir de l’emplacement réseau autre que le propre réseau du spoke. Cela peut être destiné aux données ou au plan de contrôle de la charge de travail.

  • 'accès à distance spoke pour les machines virtuelles : le hub peut être un emplacement pratique pour créer une solution de connectivité à distance inter-organisation pour l’accès RDP et SSH aux machines virtuelles distribuées dans les réseaux spoke.

  • routage : gère et dirige le trafic entre le hub et les spokes connectés pour permettre une communication sécurisée et efficace.

• réseaux virtuels Spoke - 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 la production et la non-production. Une charge de travail peut même être répartie sur plusieurs spokes.

  Dans la plupart des scénarios, un spoke ne doit être appairé qu’à un seul réseau hub et ce réseau hub doit se trouver dans la même région que le spoke.

  Ces réseaux spoke suivent les règles pour accès sortant par défaut. L’objectif principal de cette topologie de réseau hub-spoke est de diriger généralement le trafic Internet sortant via les mécanismes de contrôle offerts par le hub.

• de connectivité croisée de réseau virtuel : la connectivité de réseau virtuel est le chemin d’accès dans lequel un réseau virtuel isolé peut communiquer avec un autre via un mécanisme de contrôle. Le mécanisme de contrôle applique les autorisations et la direction autorisée des communications entre les réseaux. Un hub fournit une option permettant de prendre en charge la sélection de connexions inter-réseaux pour transiter par le réseau centralisé.

• dns - Les solutions hub-spoke sont souvent responsables de fournir une solution DNS à utiliser par tous les spokes appairés, en particulier pour le routage intersite et pour les enregistrements DNS de point de terminaison privé.

Composants

• 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.

  Cette architecture connecte des réseaux virtuels au hub à l’aide de connexions de peering qui sont des connexions non transitives et à faible latence entre les réseaux virtuels. Les réseaux virtuels appairés peuvent échanger du trafic sur le réseau principal Azure sans avoir besoin d’un routeur. Dans une architecture hub-spoke, le peering direct de réseaux virtuels entre eux est minimal et réservé pour des scénarios de cas spéciaux.

• 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. Dans cette architecture, Azure Bastion est utilisé comme une offre managée pour prendre en charge l’accès direct aux machines virtuelles entre les spokes connectés.

• 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.

  Dans cette architecture, le Pare-feu Azure a plusieurs rôles potentiels. Le pare-feu est le point de sortie principal pour le trafic destiné à Internet à partir des réseaux virtuels spoke appairés. Le pare-feu peut également être utilisé pour inspecter le trafic entrant, à l’aide de règles IDPS. Enfin, le pare-feu peut également être utilisé comme serveur proxy DNS pour prendre en charge les règles de trafic FQDN.

• passerelle VPN est un type spécifique de passerelle de réseau virtuel qui envoie le trafic chiffré entre un réseau virtuel sur Azure et un autre réseau via l’Internet public. Vous pouvez également utiliser la passerelle VPN pour envoyer le trafic chiffré entre d’autres réseaux virtuels hubs sur le réseau Microsoft.

  Dans cette architecture, il s’agit d’une option permettant de connecter certains ou tous les spokes au réseau distant. Les spokes ne déploient généralement pas leur propre passerelle VPN et utilisent plutôt la solution centralisée offerte par le hub. Vous devez établir la configuration du routage pour gérer cette connectivité.

• passerelle Azure ExpressRoute échange des itinéraires IP et route le trafic réseau entre votre réseau local et votre réseau virtuel Azure. Dans cette architecture, ExpressRoute peut également utiliser une passerelle VPN pour connecter un ou plusieurs spokes à un réseau distant. Les spokes ne déploieraient pas leur propre ExpressRoute et, au lieu de cela, ces spokes utiliseraient la solution centralisée offerte par le hub. Comme avec une passerelle VPN, vous devez établir une configuration de routage pour gérer cette connectivité.

• 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. Dans cette architecture, Azure Monitor est le récepteur de journaux et de métriques pour les ressources hub et pour les métriques réseau. Azure Monitor peut également être utilisé comme récepteur de journalisation pour les ressources dans les réseaux spoke, mais il s’agit d’une décision pour les différentes charges de travail connectées et n’est pas mandatée par cette architecture.

Alternatives

Cette architecture implique la création, la configuration et la maintenance de plusieurs primitives de ressources Azure, à savoir : virtualNetworkPeerings, routeTableset subnets. Azure 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 les abonnements, régions et répertoires Microsoft Entra. Avec Virtual Network Manager, vous pouvez définir groupes de réseaux pour identifier et segmenter logiquement vos réseaux virtuels. Vous pouvez utiliser groupes connectés qui permettent aux réseaux virtuels au sein d’un groupe de communiquer entre eux comme s’ils étaient connectés manuellement. Cette couche ajoute une couche d’abstraction sur ces primitives pour vous concentrer sur la description de la topologie de mise en réseau et sur l’implémentation de cette topologie.

Il est recommandé d’évaluer à l’aide du Gestionnaire de réseau virtuel comme moyen d’optimiser vos dépenses de temps avec les opérations de gestion réseau. Évaluez le coût du service par rapport à votre valeur/économies calculées pour déterminer si Virtual Network Manager est un avantage net pour la taille et la complexité de votre réseau.

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 de l’utilisation d’une configuration hub-and-spoke gérée par le client sont les suivants :

• Réduction des coûts
• Dépassement des limites de l’abonnement
• Isolation des charges de travail
• Flexibilité
  • Contrôlez davantage la façon dont les appliances virtuelles réseau sont déployées, telles que le nombre de cartes réseau, le nombre d’instances ou la taille de calcul.
  • Utilisation d’appliances virtuelles réseau réseau qui ne sont pas prises en charge par Virtual WAN

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.

Zones d’atterrissage Azure

L’architecture zone d’atterrissage Azure est basée sur la topologie hub-spoke. Dans cette architecture, les ressources et le réseau partagés du hub sont gérés par une équipe de plateforme centralisée, tandis que les spokes partagent un modèle de co-propriété avec l’équipe de plateforme et l’équipe de charge de travail qui utilise le réseau spoke. Tous les hubs résident dans un abonnement « Connectivité » pour la gestion centralisée, tandis que les réseaux virtuels spoke existent sur de nombreux abonnements de charge de travail individuels, appelés abonnements de zone d’atterrissage d’application.

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éer un sous-réseau nommé gatewaySubnet avec une plage d’adresses d’au moins 26. La plage d’adresses /26 offre au sous-réseau suffisamment d’options de configuration de scalabilité pour empêcher d’atteindre les limitations de taille de passerelle à l’avenir et de prendre en charge un nombre plus élevé de circuits ExpressRoute. Pour plus d’informations sur la configuration de la passerelle, consultez Réseau hybride à l’aide d’une passerelle 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
• Private Link peut être utilisé pour exposer de manière sélective des ressources individuelles à d’autres réseaux virtuels. Par exemple, l’exposition d’un équilibreur de charge interne à un autre réseau virtuel, sans avoir à former ou à gérer des relations de peering ou de routage.

Pour plus d’informations sur les modèles de mise en réseau spoke-to-spoke, consultez mise en réseau spoke-to-spoke.

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é.

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.

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

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.

Fiabilité

La fiabilité garantit que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez Vue d’ensemble du pilier de fiabilité.

Utilisez zones de disponibilité pour les services Azure dans le hub qui les prennent en charge.

En règle générale, il est préférable d’avoir au moins un hub par région et de connecter uniquement des spokes à ces hubs de la même région. Cette configuration permet aux régions de cloisonnement d’éviter une défaillance dans le hub d’une région à l’origine de défaillances de routage réseau généralisées dans des régions non liées.

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 le basculement VPN et suivez les instructions pour conception et l’architecture d’Azure ExpressRoute pour la résilience.

En raison de la façon dont le pare-feu Azure implémente des règles d’application de nom de domaine complet, assurez-vous que toutes les ressources sortantes via le pare-feu utilisent le même fournisseur DNS que le pare-feu lui-même. Sans cela, le Pare-feu Azure peut bloquer le trafic légitime, car la résolution IP du nom de domaine complet du pare-feu diffère de la résolution IP de l’expéditeur du même nom de domaine complet. L’incorporation du proxy de pare-feu Azure dans le cadre de la résolution DNS spoke est une solution pour garantir que les noms de domaine complets sont synchronisés avec l’originateur de trafic et le pare-feu Azure.

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 liste de vérification de la révision de conception pour security.

Pour vous protéger contre les attaques DDoS, activez Azure DDOS Protection sur n’importe quel réseau virtuel de périmètre. Toute ressource disposant d’une adresse IP publique est susceptible d’une attaque DDoS. Même si vos charges de travail ne sont pas exposées publiquement, vous avez toujours des adresses IP publiques qui doivent être protégées, telles que :

• Adresses IP publiques du Pare-feu Azure
• Adresses IP publiques de la passerelle VPN
• Adresse IP publique du plan de contrôle ExpressRoute

Pour réduire le risque d’accès non autorisé et appliquer des stratégies de sécurité strictes, définissez toujours des règles de refus explicites dans des groupes de sécurité réseau (NSG).

Utilisez la version Pare-feu Azure Premium pour activer l’inspection TLS, la détection des intrusions réseau et le système de prévention (IDPS) et le filtrage d’URL.

Sécurité du Gestionnaire de réseau virtuel

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.

Optimisation des coûts

L’optimisation des coûts consiste à réduire les dépenses inutiles et à améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’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 ?.

Peering direct

L’utilisation sélective du peering direct ou d’autres communications routées non hub entre spokes peut éviter le coût du traitement pare-feu Azure. Les économies peuvent être importantes pour les réseaux qui ont des charges de travail avec une communication à haut débit et à faible risque entre les spokes, telles que la synchronisation de base de données ou les opérations de copie de fichiers volumineuses.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

Activez les paramètres de diagnostic pour tous les services, tels qu’Azure Bastion, le Pare-feu Azure et votre passerelle intersites. Déterminez quels paramètres sont significatifs pour vos opérations. Désactivez les paramètres qui ne sont pas significatifs pour éviter les coûts indus. Les ressources telles que le Pare-feu Azure peuvent être détaillées avec la journalisation et vous pouvez entraîner des coûts de surveillance élevés.

Utilisez moniteur de connexion pour la surveillance de bout en bout pour détecter les anomalies et identifier et résoudre les problèmes réseau.

Utilisez Azure Network Watcher pour surveiller et résoudre les problèmes liés aux composants réseau, notamment en utilisant Traffic Analytics pour vous montrer 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

Si vous utilisez ExpressRoute, utilisez ExpressRoute Traffic Collector où vous pouvez analyser les journaux de flux des flux envoyés sur vos circuits ExpressRoute. ExpressRoute Traffic Collector vous donne une visibilité sur le trafic transitant par les routeurs de périphérie d’entreprise Microsoft.

Utilisez des règles basées sur un nom de domaine complet dans le Pare-feu Azure pour les protocoles autres que HTTP ou lors de la configuration de SQL Server. L’utilisation de noms de domaine complets réduit la charge de gestion par rapport à la gestion des adresses IP individuelles.

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.

Automation avec Azure Virtual Network Manager

Pour gérer de manière centralisée les contrôles de connectivité et de sécurité, utilisez Azure 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.

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 simplifier et simplifier le processus de création et de maintenance des configurations de routage, vous pouvez utiliser gestion automatisée des itinéraires définis par l’utilisateur (UDR) dans Azure Virtual Network Manager.

Pour simplifier et centraliser la gestion des adresses IP, vous pouvez utiliser gestion des adresses IP (IPAM) dans Azure Virtual Network Manager. IPAM empêche les conflits d’espace d’adressage IP entre les réseaux virtuels locaux et cloud.

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

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à mettre à l’échelle pour répondre aux demandes qu’elle lui impose par les utilisateurs de manière efficace. Pour plus d’informations, consultez vue d’ensemble du pilier Performance Efficiency.

Pour les charges de travail qui communiquent d’un emplacement local vers des machines virtuelles dans un réseau virtuel Azure nécessitant une faible latence et une bande passante élevée, envisagez d’utiliser ExpressRoute FastPath. FastPath vous permet d’envoyer du trafic directement à des machines virtuelles de votre réseau virtuel à partir d’un site local, en contournant la passerelle de réseau virtuel ExpressRoute, ce qui augmente les performances.

Pour les communications spoke-to-spoke qui nécessitent une faible latence, envisagez de configurer réseau spoke-to-spoke.

Choisissez la référence SKU de passerelle appropriée qui répondent à vos besoins, comme le nombre de connexions point à site ou de site à site, les paquets requis par seconde, les exigences en matière de bande passante et les flux TCP.

Pour les flux sensibles à la latence, tels que SAP ou l’accès au stockage, envisagez de contourner le pare-feu Azure ou même le routage via le hub. Vous pouvez la latence de test introduite par le Pare-feu Azure pour vous aider à prendre votre décision. Vous pouvez utiliser des fonctionnalités telles que de peering de réseaux virtuels qui connecte deux réseaux ou plus ou Azure Private Link qui vous permet de vous connecter à un service via un point de terminaison privé dans votre réseau virtuel.

Comprenez que l’activation de certaines fonctionnalités dans le Pare-feu Azure, telles que la détection d’intrusion et le système de prévention (IDPS), réduit votre débit. Pour plus d’informations, consultez de performances du Pare-feu Azure.

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.

• hub-and-spoke avec le déploiement de peering de réseaux virtuels

• hub-and-spoke avec le déploiement de groupes connectés virtual Network Manager

Contributeurs

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

Auteurs principaux :

• Alejandra Palacios | Ingénieur client senior
• Jose Moreno | Ingénieur principal
• Adam Torkar | Blackbelt global de mise en réseau Azure chez Microsoft

Autres contributeurs :

• Matthew Bratschun | Ingénieur client
• Jay Li | Responsable de produit senior
• Telmo Sampaio | Responsable d’ingénierie des services principal

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

Étapes suivantes

• Pour en savoir plus sur les hubs virtuels sécurisés et les stratégies de sécurité et de routage associées configurées par Azure Firewall Manager, consultez Qu’est-ce qu’un hub virtuel sécurisé ?

Scénarios avancés

Votre architecture peut différer de cette architecture hub-spoke simple. Voici une liste de conseils pour certains scénarios avancés :

• Ajouter d’autres régions et mailler entièrement les hubs entre eux - réseau spoke-to-spoke pour les modèles de connectivité multirégion et mise en réseau multirégion avec Azure Route Server

• remplacer le pare-feu Azure par une appliance virtuelle réseau personnalisée - Déployer des appliances virtuelles réseau hautement disponibles

• remplacer la passerelle de réseau virtuel Azure par une appliance virtuelle SDWAN personnalisée - intégration de SDWAN à des topologies de réseau hub-and-spoke Azure

• Utiliser le serveur de routage Azure pour fournir une transitivité entre votre ExpressRoute et votre VPN ou SDWAN, ou pour personnaliser les préfixes publiés sur BGP sur les passerelles de réseau virtuel Azure - prise en charge d’Azure Route Server pour ExpressRoute et azure VPN

• Ajouter un programme de résolution privé ou des serveurs DNS - architecture de programme de résolution privé

Ressources associées

Découvrez les architectures associées suivantes :

• Guide d’architecture du Pare-feu Azure
• Pare-feu et Application Gateway pour réseaux virtuels
• Résoudre les problèmes d’une connexion VPN hybride
• Mise en réseau spoke-to-spoke
• Sécuriser et gouverner les charges de travail avec une segmentation au niveau réseau
• Architecture de référence pour un cluster Azure Kubernetes Service (AKS)