Chemin de conception réseau intercloud

Ce guide fournit un chemin de lecture séquencé dans le guide de conception de mise en réseau Azure pour les clients qui se connectent Azure à Amazon Web Services (AWS), Google Cloud ou migrent des charges de travail à partir d’un autre fournisseur de cloud. Suivez les étapes numérotées pour concevoir une connectivité sécurisée et surveillée entre Azure et votre infrastructure cloud existante.

Pourquoi la découverte vient en premier

La mise en réseau multicloud connecte Azure à un ou plusieurs environnements cloud externes. Vous pouvez exécuter des charges de travail dans AWS ou Google Cloud qui ont besoin d’une connectivité privée pour Azure services, ou vous pouvez migrer des applications d’un autre cloud vers Azure tout en conservant la connectivité aux applications qui restent derrière elles. Dans les deux cas, votre réseau Azure doit s'intégrer à l'infrastructure que vous ne contrôlez pas entièrement de l'autre côté.

Ce chemin de lecture commence par la découverte plutôt que par la conception de l’infrastructure Azure. Vous mappez d’abord votre topologie multicloud existante (comprendre ce qui s’exécute où, comment il se connecte et quel trafic circule entre les clouds) avant de concevoir le côté Azure. Cette approche axée d’abord sur la découverte évite les reprises : si vous concevez l’architecture réseau sur Azure sans comprendre la topologie de votre environnement AWS ou Google Cloud, vous risquez des conflits d’adresses IP, des lacunes de connectivité et des angles morts en matière de sécurité.

Votre architecture cible utilise Azure réseau étendu virtuel (WAN) comme hub de transit (l’équivalent Azure de aws Transit Gateway) avec des tunnels VPN IPSec vers une passerelle privée virtuelle AWS et un VPN Google Cloud. Pare-feu Azure dans un hub virtuel sécurisé inspecte tout le trafic intercloud et de branche. Le DNS exige une planification minutieuse du basculement afin d’assurer le bon fonctionnement de la résolution de noms entre les environnements cloud pendant la migration.

Prerequisites

  • Lisez la vue d’ensemble du plan de mise en réseau et de la conception Azure pour obtenir une orientation sur les services de mise en réseau disponibles Azure.
  • Découverte complète de la topologie de vos environnements AWS et Google Cloud :
    • AWS : Exécutez AWS Migration Hub ou Workload Discovery sur AWS pour inventorier les clouds privés virtuels (VPC), les passerelles de transit et la connectivité inter-VPC.
    • Google Cloud : Utilisez Network Intelligence Center pour mapper les réseaux VPC, les pièces jointes d’interconnexion cloud et les règles de pare-feu.
  • Documentez les flux de trafic entre les clouds : les applications communiquent entre les clouds, la bande passante requise, la sensibilité à la latence et les exigences de chiffrement.
  • Créez un inventaire des plages d’adresses IP sur les trois clouds pour identifier les chevauchements.

Votre chemin de lecture

Les phases suivantes vous guident dans la conception réseau intercloud en séquence.

Phase 1 : Découverte

Commencez par la découverte. Comprendre votre paysage multicloud avant de concevoir Azure infrastructure.

1. Connectivité interrégion et multicloud

Cet article est votre point de décision de conception central. Mappez votre topologie multicloud : les VPN AWS et les VPN Google Cloud qui ont besoin d’une connectivité à Azure, quels flux de trafic circulent entre les clouds et quel modèle d’architecture correspond à votre échelle. Utilisez le mappage des services entre fournisseurs de cloud (Transit Gateway vers Virtual WAN, Security Groups vers groupes de sécurité réseau, peering de VPC vers peering de réseaux virtuels) pour traduire votre conception existante en termes Azure.

2. Azure Virtual WAN

Virtual WAN est le modèle de transit recommandé lorsque vous avez plusieurs VPN, branches, régions ou périphéries cloud. Virtual WAN fournit le Azure équivalent d’AWS Transit Gateway : routage automatisé, sécurité centralisée et échelle multirégulation/multirégion. Évaluez si votre patrimoine intercloud justifie Virtual WAN ou si un hub-and-spoke plus simple avec passerelle VPN est suffisant.

Phase 2 : Fondements

3. Réseaux virtuels et sous-réseaux

Concevez votre réseau virtuel Azure comme zone d’atterrissage pour les charges de travail migrées ou connectées. Mappez les concepts AWS VPC et Google Cloud VPC : les sous-réseaux VPC deviennent des sous-réseaux Azure, les zones de disponibilité correspondent aux zones de disponibilité Azure, et les tables de routage suivent des modèles similaires. Concentrez-vous sur le dimensionnement du sous-réseau pour les charges de travail qui atterrissent dans Azure.

4. Planification de l’adresse IP

Planifiez un espace d’adressage non chevauchant dans l’ensemble des trois environnements cloud. Cette étape est essentielle pour la connectivité entre les clouds : si vos plages de réseaux virtuels Azure se chevauchent avec les plages AWS VPC ou les plages DE VPN Google Cloud, vous ne pouvez pas établir de tunnels VPN entre eux. Documentez chaque bloc CIDR utilisé dans tous les environnements avant d’allouer l’espace d’adressage Azure.

5. Groupes de sécurité réseau et groupes de sécurité d’application

Répliquez vos groupes de sécurité AWS et vos règles de pare-feu Google Cloud sous forme de groupes de sécurité réseau Azure (NSG). Traduisez vos règles d’autorisation et de refus existantes au format NSG. Utilisez des groupes de sécurité d’application (ASG) pour répliquer le regroupement basé sur des balises que les références du groupe de sécurité AWS fournissent.

Phase 3 : Connectivité

6. Connectivité hybride

Configurez des tunnels VPN IPSec entre Azure et AWS ou Google Cloud pour un transit intercloud chiffré. Connectez Passerelle VPN Azure (ou Virtual WAN connexions VPN) à la passerelle privée virtuelle AWS et au VPN Google Cloud. Choisissez la bande passante de tunnel en fonction de vos besoins en matière de trafic entre les clouds. Planifiez les tunnels redondants pour éviter les points de défaillance uniques.

Phase 4 : Sécurité

7. Sécurité DNS et résolution de noms privés

Planifiez votre stratégie de basculement DNS avant de migrer les charges de travail. Les applications dans AWS ou Google Cloud résolvent les noms d’hôte qui peuvent avoir besoin de pointer vers Azure après la migration. Configurez Azure DNS Private Resolver avec des points de terminaison sortants pour la résolution de noms intercloud. Consultez la liste de contrôle de transition DNS plus loin dans cet article pour obtenir des instructions pas à pas pour la migration.

8. Pare-feu Azure

Déployez Pare-feu Azure dans un hub virtuel sécurisé pour inspecter tout le trafic intercloud et de branche. Chaque paquet parcouru entre Azure et AWS ou Google Cloud passe par le pare-feu pour la journalisation et l’application des stratégies. Utilisez des règles réseau pour les modèles de trafic intercloud et le filtrage des informations sur les menaces pour bloquer les destinations malveillantes connues.

Phase 5 : Opérations

9. Surveillance et observabilité du réseau

Les domaines interclouds sont plus difficiles à résoudre, car vous ne contrôlez pas les deux extrémités de chaque connexion. Activez Azure Network Watcher pour les tests de connectivité, les diagnostics de tunnel VPN et la capture de paquets. Surveillez la durée de fonctionnement du tunnel, la latence entre les clouds et le débit par rapport à vos besoins en capacité. Définissez des alertes pour les déconnexions de tunnel qui affectent la disponibilité des applications multiclouds.

Articles conditionnels

Incluez ces articles en fonction de vos besoins spécifiques :

Pathologie Article Quand inclure
Application destinée au public Entrée Internet Votre application migrée est accessible sur Internet (accès public direct requis)
Application HTTP/HTTPS Web Application Firewall Un WAF de couche 7 est nécessaire pour les applications web exposées à Internet
Répartition de couche 7 nécessaire Remise et performances des applications Vous avez besoin d’une distribution globale ou régionale du trafic après la migration
Points de terminaison publics Protection DDoS Vous avez des exigences de disponibilité pour les services exposés publiquement
Architecture hub-and-spoke privilégiée Topologie hub-and-spoke Votre environnement multi-cloud est suffisamment réduit pour que Virtual WAN ne se justifie pas.
Azure multirégion Mise en réseau multirégion Votre cible Azure s’étend sur plusieurs régions au-delà de la connectivité intercloud
Accès administrateur de machine virtuelle Accès développeur et administrateur Vous avez besoin d’un accès RDP/SSH sécurisé aux machines virtuelles hébergées sur Azure
Sortie centralisée Accès Internet sortant La stratégie de sortie Internet centralisée fait partie de votre conception cible
Vaste environnement VNet Gestion centralisée du réseau L’environnement Azure évolue pour devenir un environnement multi-abonnements gouverné
Points de terminaison privés PaaS Accès privé PaaS Votre architecture cible inclut Azure services PaaS avec des points de terminaison privés

Liste de contrôle de découverte intercloud

Avant de concevoir le réseau Azure, associez vos services cloud existants à leurs équivalents dans Azure. Ce mappage accélère les décisions de conception et empêche les attentes incompatibles.

Mappage des services AWS vers Azure

Service d'AWS Équivalent Azure Remarques
Passerelle de transit Azure Virtual WAN Hub de routage centralisé pour multi-VPC, multi-région et multi-cloud
VPC Réseau virtuel Azure Limite réseau isolée avec des sous-réseaux et des tables de routage
Appairage de réseau privé virtuel Peering de réseaux virtuels Connectivité directe entre deux réseaux virtuels
Groupes de sécurité Groupes de sécurité réseau (NSG) Filtrage du trafic avec état au niveau du sous-réseau ou de l'interface réseau
Listes de contrôle d’accès réseau NSG (au niveau du sous-réseau) Les NSG Azure combinent les fonctions de groupe de sécurité et de NACL
Passerelle privée virtuelle passerelle VPN Point d’arrêt VPN IPSec
Connexion directe Azure ExpressRoute Connectivité privée dédiée (pas via Internet public)
Zones hébergées privées Route 53 Zones DNS privées Azure Résolution de noms DNS privés dans les réseaux virtuels
Tables de routage Routes définies par l’utilisateur (UDR) Routage personnalisé pour remplacer les itinéraires système Azure ou les itinéraires implicites AWS
Répartiteur de charge élastique (ALB/NLB) Azure Load Balancer / Application Gateway Équilibrage de charge L4 et L7 ; Application Gateway fournit des fonctionnalités WAF similaires à AWS ALB avec AWS WAF
AWS WAF Pare-feu d’applications web Azure Protection HTTP/HTTPS de couche 7
Pare-feu réseau Pare-feu Azure Pare-feu réseau avec état doté de renseignements sur les menaces

Mappage des services Google Cloud vers Azure

Service Google Cloud Équivalent Azure Remarques
Réseau VPC Réseau virtuel Azure Ressource globale dans Google Cloud ; régionale dans Azure (utilisez le peering de réseaux virtuels pour l'interrégion)
Cloud Interconnect Azure ExpressRoute Connectivité privée dédiée
Cloud VPN passerelle VPN Tunnels VPN IPSec
Cloud NAT Azure NAT Gateway Accès Internet sortant pour les ressources privées
Routeur de cloud Serveur de routes Azure Échange dynamique de routes BGP avec des équipements réseau virtuels
Cloud Armor Pare-feu d’applications web Azure Protection des applications et DDoS de couche 7
Règles de pare-feu Groupes de sécurité réseau Filtrage du trafic (les règles Google Cloud sont globales ; les groupes de sécurité réseau Azure s’appliquent par sous-réseau ou par interface réseau)
Zones privées Cloud DNS Zones DNS privées Azure Résolution de noms privés dans les réseaux
Centre d'intelligence réseau Azure Network Watcher Visualisation de la supervision, des diagnostics et de la topologie du réseau

Liste de contrôle du basculement DNS

Le basculement DNS est l’étape la plus risquée d’une migration entre les clouds. Suivez cette liste de contrôle pour réduire les échecs de résolution pendant la transition.

Avant la migration

  1. Réduisez les valeurs de durée de vie (TTL) pour tous les enregistrements DNS qui changent. Définissez la durée de vie sur 60 à 300 secondes au moins 48 heures avant le basculement. Cette étape garantit que les caches expirent rapidement lorsque vous mettez à jour des enregistrements.
  2. Documentez chaque enregistrement DNS qui pointe vers l’infrastructure que vous migrez : enregistrements pour les serveurs, enregistrements CNAME pour les services, enregistrements MX pour la messagerie et enregistrements SRV pour la découverte de service.
  3. Configurez le résolveur privé DNS Azure avec des points de terminaison sortants dans votre réseau virtuel Azure. Ce programme de résolution transfère les requêtes pour les zones hébergées par AWS/Google Cloud vers les serveurs DNS en amont appropriés pendant la période de coexistence.
  4. Testez la résolution directe et inverse des réseaux virtuels Azure pour des noms hébergés sur AWS/Google Cloud avant de migrer toute charge de travail.

Pendant la migration

  1. Mettez à jour les enregistrements CNAME pour les services qui passent à Azure. Faites pointer les CNAME vers les points de terminaison d’Azure Front Door, d’Azure Traffic Manager ou d’Azure Application Gateway au fur et à mesure de la migration de chaque service.
  2. Mettez à jour les enregistrements A de l’hôte pour les serveurs individuels qui migrent. Remplacez les adresses IP AWS ou Google Cloud par des adresses IP privées Azure dans vos zones DNS.
  3. Conservez le transfert conditionnel actif afin que les noms des zones que vous n’avez pas encore migrées continuent d’être résolus par les serveurs DNS du cloud d’origine.

Après la migration

  1. Vérifiez la résolution à partir de tous les emplacements : les clients locaux, les réseaux virtuels Azure et toutes les charges de travail AWS ou Google Cloud restantes doivent résoudre correctement les noms migrés.
  2. Ramenez les valeurs TTL aux niveaux de production (3 600 secondes ou plus) après avoir confirmé que la résolution est stable.
  3. Supprimez les redirecteurs conditionnels pour les zones entièrement migrées vers Azure DNS. Conservez les redirecteurs uniquement pour les zones qui restent dans AWS ou Google Cloud.

Ce que vous avez créé

En suivant ce chemin de lecture, vous avez connecté Azure à votre environnement AWS ou Google Cloud existant avec un transit chiffré, une inspection centralisée du pare-feu et une connectivité surveillée. Votre conception comprend :

  • Découverte de topologie multicloud et mappage de service
  • Architecture de transit Virtual WAN ou hub-and-spoke
  • Tunnels VPN IPSec vers AWS et Google Cloud
  • Pare-feu Azure pour l’inspection du trafic entre les clouds
  • Basculement DNS avec Private Resolver pour la résolution de noms
  • surveillance de l’état et des performances des tunnels avec Network Watcher

Étapes suivantes

  • Last updated on