Connectivité interrégion et multicloud

Cet article vous aide à connecter Azure charges de travail entre plusieurs régions et à étendre la connectivité à d’autres fournisseurs de cloud tels qu’Amazon Web Services (AWS) et Google Cloud.

Présentation de cet article

Cet article traite des décisions de conception relatives à la connexion des réseaux virtuels Azure (VNet) entre différentes régions et à l’établissement de chemins réseau vers des charges de travail exécutées sur d’autres clouds. Vous apprenez à utiliser global VNet Peering, Virtual WAN, ExpressRoute Global Reach, VPN de site à site et Serveur de routes Azure pour les scénarios interrégions et multiclouds.

Qui a besoin de cet article

Lisez cet article si une ou plusieurs de ces conditions s’appliquent :

  • Votre architecture s’étend sur plusieurs régions Azure et nécessite une connectivité privée entre elles.
  • Vous devez connecter les charges de travail Azure à AWS, Google Cloud ou à un autre réseau externe.
  • Vous devez comparer global VNet Peering, Virtual WAN, ExpressRoute Global Reach, VPN de site à site ou Serveur de routes Azure.
  • Vous devez concevoir une connectivité résiliente pour la récupération d’urgence, l’expansion mondiale ou les opérations multiclouds.

Tip

Suivre le parcours du scénario ? Sélectionnez votre scénario en haut de la page pour obtenir des conseils personnalisés. Les conseils fondamentaux qui suivent s’appliquent à tous les lecteurs.

Priorité au lift-and-shift : incluez cet article dans votre parcours de lecture uniquement si votre migration couvre plusieurs régions Azure ou se connecte à un autre cloud. La plupart des projets lift-and-shift commencent par une seule région et ajoutent une connectivité interrégion ultérieurement lorsque la récupération d’urgence ou l’expansion géographique devient une priorité.

Focus de modernisation : Incluez cet article si votre modernisation nécessite une connectivité privée interrégion explicite au-delà de ce que couvre l’article multirégion . Vous avez besoin de ces recommandations lorsque des spokes situés dans différentes régions nécessitent des chemins de communication directs ou lorsque votre déploiement actif-actif requiert un peering privé entre des hubs régionaux.

Orientation multi-cloud : Cet article présente votre décision de conception principale. Lisez-le avant de choisir entre hub-spoke et Virtual WAN pour votre architecture de transit intercloud. Vous utilisez cet article pour découvrir votre topologie multicloud existante, mapper des services entre AWS ou Google Cloud et Azure, et définir comment Azure se connecte aux charges de travail qui restent dans d’autres clouds pendant la migration.

Azure services et fonctionnalités

Azure fournit plusieurs services pour la connectivité interrégion et multicloud. Chaque service répond à différentes exigences de mise à l’échelle, de bande passante et de gestion.

Service Ce qu’il fournit Quand l′utiliser ?
VNet Peering global Connectivité privée à faible latence entre les réseaux virtuels dans différentes régions Azure. Le trafic reste sur le réseau principal de Microsoft. La bande passante est limitée uniquement par la référence SKU de machine virtuelle, et non par une passerelle. Communication directe entre deux réseaux virtuels dans différentes régions sans appliance de passerelle.
Azure Virtual WAN (niveau Standard) hub de transit mondial géré par Microsoft qui connecte des VNets, des branches et des utilisateurs distants dans toutes les régions. Fournit un routage transitif entre tous les réseaux connectés. Organisations disposant de nombreuses régions et succursales nécessitant une connectivité de type any-to-any sans gérer des connexions de peering individuelles.
ExpressRoute via Cloud Exchange Connexion multicloud dédiée via un fournisseur d’échange tiers (par exemple, Equinix ou Megaport). Fournit une connectivité privée et à bande passante élevée à AWS ou Google Cloud. Architectures multiclouds avec exigences du contrat SLA de bande passante où le trafic ne doit pas traverser l’Internet public.
VPN de site à site vers d’autres clouds Tunnel IPsec chiffré entre Passerelle VPN Azure et la passerelle VPN d'un autre fournisseur de cloud (passerelle privée virtuelle AWS ou VPN Google Cloud). Connectivité multicloud pour les scénarios de test, de développement ou de production où les circuits dédiés ne sont pas justifiés.
Serveur de routage Azure Activez l’échange dynamique de routes BGP entre votre VNet et les appliances réseau virtuelles (NVA). Injecte des itinéraires appris par NVA dans l’infrastructure de routage SDN Azure. Routage personnalisé avec des appliances réseau virtuelles (NVA) tierces dans un réseau virtuel central (hub), ou routage multicloud complexe nécessitant la propagation BGP vers les réseaux connectés à Azure.

Fonctionnement du peering global de réseaux virtuels

Global VNet Peering crée un lien direct entre deux réseaux virtuels dans différentes régions Azure. Le lien passe entièrement par le backbone Microsoft et ne transite jamais par l’internet public. Après avoir configuré une relation de peering, les ressources de chaque réseau virtuel peuvent communiquer à l’aide d’adresses IP privées comme si elles se trouvaient dans le même réseau.

Contrairement aux approches reposant sur une passerelle, le peering n’introduit pas de point d’étranglement unique. La bande passante entre réseaux virtuels appairés évolue en fonction du niveau SKU des machines virtuelles de chaque côté. Il n’existe aucune appliance de passerelle dédiée limitant le débit. Cette conception fait du peering global de réseaux virtuels l’option offrant la latence la plus faible pour les communications interrégionales entre un petit nombre de réseaux virtuels.

Toutefois, le peering n'est pas transitif par conception. Si le réseau virtuel A est appairé au réseau virtuel B et que le réseau virtuel B est appairé au réseau virtuel C, le trafic du réseau virtuel A ne peut pas atteindre le réseau virtuel C via le réseau virtuel B. Chaque paire de réseaux virtuels nécessitant une communication directe doit disposer de son propre lien de peering. Dans un modèle hub-and-spoke, cela signifie que vous appairez généralement les réseaux virtuels hub régionaux entre eux et utilisez des itinéraires définis par l'utilisateur (UDR) ou des NVA pour transférer le trafic entre spokes de différentes régions via les hubs.

Transit global Virtual WAN

Azure Virtual WAN (niveau Standard) supprime la nécessité de configurer manuellement le peering entre les hubs régionaux. Lorsque vous déployez Virtual WAN hubs dans plusieurs régions, Microsoft établit automatiquement des connexions hub-à-hub sur la colonne principale. Les itinéraires appris dans un hub se propagent à tous les autres hubs, créant ainsi une infrastructure de transit quelconque.

Ce routage automatique signifie qu’un réseau virtuel spoke connecté à un hub dans la région Est des États-Unis peut atteindre un réseau virtuel spoke connecté à un hub dans la région Europe Ouest sans aucune configuration supplémentaire d’appairage ou de table de routage. Virtual WAN étend également cette transitivité aux filiales (connectées via un VPN de site à site ou ExpressRoute) et des utilisateurs distants (connectés via un VPN point à site). Le résultat est un réseau mondial entièrement maillé géré par Microsoft.

Pour l’inspection du trafic entre les régions, activez l’intention de routage sur des hubs virtuels sécurisés. L'intention de routage force le trafic entre hubs à passer par Pare-feu Azure, ce qui vous offre une visibilité centralisée et l'application des stratégies dans toutes les régions sans avoir à déployer ni gérer des NVA individuelles dans chaque hub.

Comment choisir

Utilisez les tableaux de décision suivants pour sélectionner l’approche de connectivité appropriée pour votre scénario.

Options de connectivité entre régions

Schéma montrant les schémas de connectivité entre régions, notamment le peering global de VNets, le transit de hub à hub via Virtual WAN et les chemins VPN intercloud.

Votre scénario Approche recommandée Pourquoi
Deux réseaux virtuels dans différentes régions ont besoin d’une communication directe VNet Peering global Latence la plus faible par rapport aux chemins Internet, aucun goulot d’étranglement de passerelle, simple à configurer. La bande passante varie en fonction de la taille de la machine virtuelle (SKU).
De nombreuses régions, de nombreuses succursales, transit géré requis Azure Virtual WAN (niveau Standard) Fournit un routage transitif de type any-to-any entre tous les hubs connectés. Microsoft gère l’infrastructure de routage.
Connecter des sites locaux entre eux via Azure Service Global Reach d’ExpressRoute Relie deux circuits ExpressRoute afin que le trafic du site local transite par le backbone Microsoft. Aucun besoin de faire transiter le trafic via les réseaux virtuels Azure.
Routage personnalisé ou NVA tierces dans un hub régional Serveur de routage Azure Active le peering BGP dynamique entre les NVAs et Azure. Les itinéraires appris par la NVA sont automatiquement injectés dans les réseaux virtuels spoke.

Options de connectivité multicloud

Votre scénario Approche recommandée Pourquoi
Bande passante élevée et contrat SLA requis pour le trafic entre les clouds ExpressRoute via le fournisseur cloud Exchange Fournit une capacité dédiée avec une latence prévisible. Le fournisseur Exchange connecte votre circuit ExpressRoute au service de connexion directe de l’autre cloud.
Charges de travail à budget limité, de test ou à faible débit VPN de site à site Utilise une connectivité Internet existante sans coût de circuit. Adapté lorsque les besoins en bande passante sont modestes.
Hybride et multicloud (sur site, Azure et un autre cloud) ExpressRoute Global Reach + Cloud Exchange Combine Global Reach pour le transit entre les environnements locaux et Azure avec un point d’échange cloud pour la connectivité entre Azure et d’autres clouds, créant ainsi une dorsale privée unifiée.

Considérations relatives à la conception

Pour la plupart des migrations lift-and-shift, la connectivité interrégion est une considération d’expansion future au lieu d’une exigence quotidienne. Votre déploiement initial cible probablement une seule région Azure.

Lorsque vous prévoyez une expansion future :

  • Peering global de réseaux virtuels : utilisez le peering global de réseaux virtuels entre les réseaux virtuels hub régionaux lorsque vous ajoutez une deuxième région Azure. Cette approche vous offre une connectivité privée à faible latence sans déployer une appliance de passerelle. Le trafic reste sur le réseau principal de Microsoft et s’adapte à la taille de machine virtuelle (SKU).
  • Complexité différée : Évitez de déployer Virtual WAN ou ExpressRoute Global Reach jusqu’à ce que votre patrimoine dépasse deux régions ou que vous ajoutez des exigences de connectivité de branche.
  • Préparation de la récupération d’urgence : Même si la connectivité entre régions n’est pas nécessaire aujourd’hui, documentez les charges de travail qui nécessitent une récupération d’urgence et planifiez la topologie de peering afin de pouvoir la déployer rapidement si nécessaire.

Votre architecture modernisée utilise des déploiements en mode actif-actif dans plusieurs régions. Le peering interrégion permet une communication directe entre spokes lorsque les niveaux de votre application s'étendent sur plusieurs régions.

Décisions de conception clés pour la modernisation :

  • Peering interrégion pour une architecture actif-actif : appairez les réseaux virtuels hub de votre région principale et de votre région de secours afin d'activer un flux de trafic bidirectionnel. Les équipes d'application des spokes ContosoBiz et ContosoCare peuvent accéder aux ressources de l'une ou l'autre région via le chemin de peering des hubs.
  • Routage via les hubs : étant donné que le peering global de réseaux virtuels n'est pas transitif, acheminez le trafic entre spokes de différentes régions via la NVA régionale du hub ou Pare-feu Azure. Utilisez des routes définies par l’utilisateur (UDR) pour diriger le trafic interrégional d’un spoke à l’autre via le pare-feu du hub afin qu’il soit inspecté.
  • Peering sélectif : tous les spokes n'ont pas besoin d'une connectivité interrégion. Appairez uniquement les réseaux virtuels hub et utilisez la propagation des itinéraires pour atteindre les réseaux virtuels spoke spécifiques qui participent aux charges de travail actif-actif.

Cet article vous permet de concevoir votre architecture de connectivité multicloud. Avant de planifier Azure infrastructure, vous devez découvrir votre topologie cloud existante et mapper les services entre les fournisseurs.

Flux de travail de découverte multicloud

  1. Découvrez votre topologie existante : Utilisez Workload Discovery sur AWS et Google Cloud Network Intelligence Center pour mapper votre topologie de cloud privé virtuel (VPC) actuelle, les relations de peering et les modèles de flux de trafic.
  2. Identifier les flux de trafic : Documentez la communication VPC-à-VPC, les chemins d’accès entrants et sortants Internet, ainsi que les connexions de branche à cloud dans votre environnement AWS ou Google Cloud.
  3. Faire correspondre les services à leurs équivalents Azure : Les correspondances clés pour la conception de la connectivité sont les suivantes :
Service AWS / Google Cloud Équivalent Azure
Passerelle de transit Azure Virtual WAN
VPC / réseau VPC Réseau virtuel Azure
Groupes de sécurité / Règles de pare-feu Groupes de sécurité réseau (NSG)

Pour obtenir un mappage complet des services AWS vers Azure et Google Cloud vers Azure, consultez Liste de contrôle de découverte intercloud.

Décisions relatives à l’architecture de connectivité

Une fois la découverte et la cartographie des services terminées, décidez :

  • Modèle de transit : Choisissez Virtual WAN si vous avez plusieurs VPN, branches, régions ou périphéries cloud. Virtual WAN fournit l’équivalent Azure d’AWS Transit Gateway avec un routage any-to-any géré.
  • VPN multicloud: Déployez des connexions passerelle VPN depuis votre hub Virtual WAN (ou hub de réseau virtuel) vers AWS Virtual Private Gateway et Google Cloud VPN. Utilisez des tunnels IPsec pour la communication entre les clouds chiffrées.
  • Applications qui restent : Identifiez les charges de travail qui restent dans AWS ou Google Cloud pendant la migration. Ces charges de travail ont besoin d’une connectivité persistante via les tunnels VPN interclouds jusqu’à ce que la migration se termine.

Prerequisites

Avant d’implémenter une connectivité interrégion ou multicloud, vérifiez les exigences suivantes :

  • Deux ou plusieurs régions Azure avec des réseaux virtuels déployés : vos charges de travail doivent déjà exister (ou être planifiées) dans plusieurs régions. Consultez l’article sur les réseaux virtuels et les sous-réseaux pour obtenir des conseils de planification de réseau virtuel.
  • Topologie hub-spoke ou Virtual WAN : les conceptions interrégions s’appuient sur une topologie établie dans chaque région. Consultez l’article sur l’architecture hub-and-spoke ou l’article sur Virtual WAN.
  • Circuits ExpressRoute (pour Global Reach) : Si vous envisagez de connecter des sites locaux, vous avez besoin de circuits ExpressRoute existants dans chaque emplacement. Consultez l’article sur la connectivité hybride.
  • Accès à un compte multicloud : Pour la connectivité VPN multicloud ou exchange, vous avez besoin d’un accès administratif à la console réseau de l’autre fournisseur de cloud pour configurer le côté distant de la connexion.

Considérations relatives à la sécurité

La connectivité interrégion et multicloud introduit des problèmes de sécurité spécifiques qui n’existent pas dans les déploiements à une seule région.

Inspection du trafic interrégion

Global VNet Peering n’est pas transitif. Le trafic entre les réseaux virtuels appairés circule directement sans passer par un pare-feu ou un point d’inspection. Si vous devez inspecter le trafic interrégion, routez-le via une appliance virtuelle réseau (NVA) ou Pare-feu Azure dans chaque hub régional.

Pour Virtual WAN, activez l’intention de routage avec des stratégies de trafic privé sur des hubs virtuels sécurisés. Routing Intent force le trafic inter-hub à passer à travers des pare-feu gérés par Azure Firewall Manager, assurant ainsi une inspection centralisée du trafic entre régions. Cette configuration nécessite le niveau Virtual WAN Standard.

Chiffrer les connexions entre les clouds

Les tunnels VPN de site à site vers d’autres clouds sont chiffrés par défaut (IPsec/IKE). Toutefois, les connexions ExpressRoute via un échange cloud sont privées, mais pas chiffrées au niveau de la couche réseau. Si vous avez besoin d’un chiffrement sur ExpressRoute, déployez MACsec sur des circuits ExpressRoute Direct ou utilisez le chiffrement TLS de couche application.

Pour le trafic intercloud traversant un point d'échange cloud sans superposition VPN, envisagez de déployer un tunnel IPsec basé sur une NVA dans le chemin ExpressRoute. Cette approche ajoute le chiffrement sans renoncer à la bande passante et aux avantages de latence d’un circuit dédié. Vous pouvez également utiliser le protocole TLS mutuel (mTLS) au niveau de la couche application afin que chaque point de terminaison de service valide l’identité et chiffre les données quel que soit le transport sous-jacent. Le choix varie selon que vous avez besoin d’un chiffrement de couche réseau (tout-trafic) ou d’appliquer le chiffrement au niveau de la couche application.

Considérations relatives aux coûts

Toutes les connexions interrégions entraînent des frais de transfert de données. Le peering VNet global, le trafic inter-hubs de Virtual WAN et les tunnels interrégionaux de passerelle VPN utilisent tous une tarification basée sur le trafic sortant. Les tarifs varient selon la paire de zones :

  • Intra-continental (par exemple, États-Unis Est vers États-Unis Ouest) : tarif par Go plus bas, généralement dans la fourchette des tarifs de sortie standard pour la région.
  • Inter-continent (par exemple, USA Est vers l’Europe Ouest) : taux plus élevé par Go en raison de distances de base plus longues et d’une capacité inter-continentale.

Virtual WAN ajoute des frais d’unité de connexion pour chaque réseau virtuel spoke ou branche attaché à un hub, ainsi qu’une charge de traitement des données pour le trafic transitant par le biais d’un hub sécurisé exécutant Pare-feu Azure. Cette tarification en couches signifie que Virtual WAN peut coûter plus cher qu'un simple peering global de réseaux virtuels pour des architectures comportant seulement quelques régions et quelques spokes, mais offre une meilleure économie d'échelle lorsque des dizaines de succursales et de régions sont connectées.

Pour la connectivité multicloud, ExpressRoute via un point d’échange cloud entraîne des frais de port et de cross-connexion facturés par le fournisseur du point d’échange, ainsi que des frais de circuit Azure ExpressRoute et des frais de connexion directe de l’autre fournisseur cloud. Le VPN de site à site évite les coûts de circuit, mais entraîne toujours des frais de sortie standard pour les données quittant Azure.

Orientation: Colocaliser des charges de travail à trafic élevé dans la même région lorsque cela est possible. Réservez les chemins interrégions à la synchronisation du plan de contrôle, à la réplication asynchrone et au basculement de reprise après sinistre, qui représentent généralement des flux de plus faible volume.

Modèles de récupération d’urgence

La connectivité entre régions est fondamentale pour la reprise d’activité après sinistre (RÉCUPÉRATION d’urgence). Le modèle que vous choisissez détermine votre objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO).

Active-active

Les deux régions servent simultanément le trafic de production. Un équilibreur de charge global (tel que Azure Front Door ou Azure Traffic Manager) distribue les requêtes entre les régions. En cas d’échec d’une région, le trafic passe à la région survivante avec une interruption minimale. Ce modèle fournit le RTO le plus bas (secondes à minutes), mais nécessite une infrastructure complète dans les deux régions et la synchronisation des données bidirectionnelles, ce qui augmente le coût et la complexité.

Active-passive

Une région gère le trafic de production, tandis que la seconde région reste en veille avec une infrastructure prédéployée (mais potentiellement dimensionnée à la baisse). La réplication maintient les données de la région passive à jour. En cas d’échec, vous promouvez la région passive et redirigez le trafic. L'objectif de temps de reprise (RTO) dépend de la rapidité avec laquelle vous mettez à l'échelle les ressources passives et effectuez le basculement DNS ou de l'équilibreur de charge, généralement de quelques minutes à plusieurs dizaines de minutes.

Lumière pilote

Empreinte minimale dans la région secondaire (bases de données réplicant, mise en réseau principale déployée) sans calcul actif. Lors du basculement, vous déployez ou mettez à l'échelle la capacité de calcul de l'application, puis vous basculez le trafic. Cette architecture réduit le coût en régime permanent, mais augmente le RTO, car les ressources de calcul doivent être démarrées avant que la région puisse prendre en charge le trafic.

Dans tous les modèles, la connectivité interrégion (peering global de réseaux virtuels ou interconnexion de hubs Virtual WAN) fournit le chemin de données privé pour le trafic de réplication. Assurez-vous que vos procédures de reprise après sinistre tiennent compte des éventuels délais de propagation des itinéraires et vérifiez que les règles des groupes de sécurité réseau dans la région secondaire autorisent le trafic de basculement.

Contraintes clés

Contrainte Impact
Global VNet Peering n’est pas transitif Ce n’est pas parce que le VNet A est connecté en peering au VNet B, et que le VNet B est connecté en peering au VNet C, qu’A peut joindre C. Vous devez établir directement un peering entre A et C, ou recourir à une solution de transit comme Virtual WAN.
Virtual WAN niveau De base manque de transitivité Basic Virtual WAN ne prend pas en charge la connectivité transitive entre réseaux virtuels. Utilisez le niveau Standard pour le transit interrégion.
ExpressRoute Global Reach nécessite une référence SKU Premium pour les connexions inter-géopolitiques Les circuits dans différentes régions géopolitiques (par exemple, les États-Unis et l’Europe) nécessitent le module complémentaire Premium. Les circuits de référence SKU standard se connectent uniquement dans la même limite géopolitique.
passerelle VPN actif-actif recommandé pour AWS La passerelle privée virtuelle AWS crée deux tunnels par connexion VPN. Configurez Passerelle VPN Azure en mode actif-actif pour utiliser tous les tunnels disponibles et éviter le routage asymétrique.

Learn more

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Prochaine étape de votre parcours lift-and-shift :

Mise en réseau multirégion : planifiez la connectivité multirégion et le basculement si votre migration s’étend au-delà d’une région.

Ensuite, dans votre parcours de modernisation :

Surveillance et observabilité du réseau : activez l’observabilité entre les régions pour la préparation de la production.

Prochaine étape de votre parcours multicloud :

Virtual WAN topologie : utilisez Virtual WAN comme hub de transit pour votre connectivité multicloud et multibranche.

  • Last updated on