Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce guide fournit un chemin de lecture séquencé via le guide de conception de mise en réseau Azure pour les clients qui migrent des charges de travail locales vers Azure Infrastructure as a Service (IaaS) sans re-architecture d’applications. Suivez les étapes numérotées pour créer votre réseau à partir du terrain, en prenant les bonnes décisions à chaque étape.
Overview
Une migration lift-and-shift déplace les charges de travail locales existantes vers Azure machines virtuelles avec des modifications minimales apportées à l’architecture d’application. Vos applications conservent leurs modèles de communication, dépendances et configurations existants. Le réseau que vous générez dans Azure doit prendre en charge ces modèles existants tout en tirant parti des services de sécurité et de connectivité natifs Azure.
Votre architecture cible est une topologie hub-and-spoke avec des services partagés centralisés. Un réseau virtuel à hub unique héberge votre connexion passerelle VPN ou ExpressRoute vers un emplacement local, Azure Bastion pour sécuriser l’accès aux machines virtuelles, Pare-feu Azure pour l’inspection centralisée du trafic et le transfert DNS. Les réseaux virtuels spoke hébergent les machines virtuelles de vos charges de travail migrées. Ils sont isolés les uns des autres par défaut et connectés via le hub pour permettre la communication entre charges de travail.
Ce parcours de lecture vous guide dans 10 articles essentiels en cinq phases. Chaque article s’appuie sur les décisions que vous avez prises à l’étape précédente. À la fin, vous disposez d’une conception réseau prête pour la production qui prend en charge vos charges de travail migrées avec une sécurité et une connectivité de défense en profondeur.
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 disponibles et la structure du guide.
- Effectuez un inventaire de votre réseau local existant : plages d’adresses IP, sous-réseaux, règles de pare-feu, zones DNS et flux de trafic inter-applications (vous référencez cet inventaire dans les articles fondamentaux : réseaux virtuels et sous-réseaux, planification d’adresses IP et configuration de groupe de sécurité réseau).
- Identifiez les charges de travail que vous envisagez de migrer en premier. Commencez par un groupe pilote avant de migrer votre patrimoine complet.
- Documentez vos besoins en matière de connectivité locale : bande passante pour Azure, sensibilité de la latence et attentes de basculement.
Votre chemin de lecture
Parcourez ces phases dans l’ordre. Chaque phase s’appuie sur les décisions de la précédente.
Phase 1 : Fondements
Commencez par les trois articles fondamentaux. Ces décisions forment tout ce qui suit.
1. Réseaux virtuels et sous-réseaux
Créez le réseau virtuel qui héberge vos machines virtuelles migrées. Mappez vos segments réseau existants en sous-réseaux Azure. Concentrez-vous sur les limites d’isolation de sous-réseau : les charges de travail qui partagent un sous-réseau, qui ont besoin de leur propre et le nombre d’adresses IP dont chaque sous-réseau a besoin en fonction du nombre de machines virtuelles.
2. Planification des adresses IP
Évitez le chevauchement d’adresses IP avec votre environnement local. Utilisez une plage CIDR /16 (Classless Inter-Domain Routing) par réseau virtuel afin de prévoir une marge de croissance. Si vos plages d’adresses locales se chevauchent avec des adresses réservées d’Azure ou avec celles d’autres abonnements Azure, planifiez une stratégie de réadressage avant la migration.
3. Groupes de sécurité réseau et groupes de sécurité d’application
Reproduisez vos règles de pare-feu existantes sous forme de groupes de sécurité réseau (GSR). Traduisez vos listes de contrôle d’accès (ACL) sur site en règles NSG avec une stratégie de refus par défaut. Utilisez des groupes de sécurité d’application (ASG) pour regrouper des machines virtuelles par rôle au lieu de gérer des adresses IP individuelles.
Phase 2 : Topologie
La topologie hub-and-spoke est la topologie par défaut pour les migrations lift-and-shift de plusieurs charges de travail. Placez les services partagés dans le réseau virtuel hub : passerelle VPN, Azure Bastion, Pare-feu Azure et redirecteurs DNS. Chaque charge de travail dispose de son propre réseau virtuel spoke appairé au hub. Les spokes communiquent via le pare-feu du hub, ce qui vous permet de centraliser le contrôle du trafic.
Phase 3 : Connectivité
passerelle VPN ou Azure ExpressRoute en local est votre dépendance de migration la plus critique. Sans cette connexion, les machines virtuelles migrées ne peuvent pas atteindre les services locaux dont elles dépendent, et vos utilisateurs ne peuvent pas atteindre les applications migrées. Dimensionner la bande passante de votre passerelle en fonction des modèles de trafic que vous avez documentés dans votre inventaire.
6. Accès développeur et administrateur
Azure Bastion fournit un accès RDP (Secure Bureau à distance Protocol) et SECURE Shell (SSH) sécurisé à vos machines virtuelles migrées sans les exposer à l’Internet public. Déployez Bastion dans le réseau virtuel hub afin que tous les spokes partagent un point d’accès unique. Remplacez votre infrastructure de jump box existante par ce service géré.
Phase 4 : Sécurité
7. Sécurité DNS et résolution de noms privés
Conservez votre comportement de nommage DNS hérité lors de la migration. Vos machines virtuelles migrées doivent résoudre les noms d’hôte locaux et les systèmes locaux doivent résoudre les noms hébergés Azure. Configurez le résolveur privé DNS Azure pour le transfert bidirectionnel. Conservez vos conventions d’affectation de noms DNS existantes pour éviter la reconfiguration de l’application.
Centraliser tout le trafic Internet sortant via le pare-feu hub. Désactivez l’accès sortant par défaut sur vos réseaux virtuels Spoke et acheminez le trafic sortant via Pare-feu Azure à l’aide de routes définies par l’utilisateur (UDR). Cette approche met en miroir votre modèle local existant où un pare-feu de périmètre contrôle tout le trafic lié à Internet.
Déployez Pare-feu Azure dans le réseau virtuel hub pour centraliser le contrôle du trafic est-ouest (entre spokes) et nord-sud (sortant). Traduisez vos stratégies de pare-feu locales en règles Pare-feu Azure. Utilisez des règles réseau pour le trafic non HTTP et les règles d’application pour le filtrage HTTP/HTTPS avec des cibles de nom de domaine complet (FQDN).
Phase 5 : Opérations
10. Surveillance et observabilité du réseau
Configurez Azure Network Watcher et Moniteur de connexion pour valider votre base de référence de migration. Vérifiez que les chemins de connectivité fonctionnent comme prévu. Mesurez la latence entre les machines virtuelles Azure et les systèmes locaux et établissez des benchmarks de performances avant de migrer des charges de travail de production.
Articles conditionnels
Toutes les migrations lift-and-shift ne nécessitent pas le même ensemble d’articles. Incluez ces articles en fonction de vos besoins spécifiques :
| Pathologie | Article | Quand inclure |
|---|---|---|
| Application accessible sur Internet | Entrée Internet | Votre application migrée doit être accessible à partir d’Internet |
| Équilibrage de charge de couche 7 (L7) nécessaire | Remise et performances des applications | Votre charge de travail a besoin de Azure Application Gateway ou de Azure Front Door |
| Application web publique | Web Application Firewall | Votre application migrée sert le trafic HTTP/HTTPS public |
| Exposition à l’adresse IP publique | Protection DDoS | Vous avez des exigences de disponibilité pour les ressources disposant de points de terminaison publics |
| Plusieurs régions nécessaires | Mise en réseau multirégion | Une récupération d'urgence ou un déploiement actif-actif est requis |
| Connectivité inter-régions | Connectivité interrégion et multicloud | D’autres régions ou d’autres environnements cloud sont inclus dans le périmètre |
| Transit au niveau de la succursale | Azure Virtual WAN | Vous disposez de nombreuses succursales ou périphéries de connectivité |
| Composants PaaS | Accès privé PaaS | Certains composants de charge de travail passent à Azure services PaaS |
| Vaste environnement VNet | Gestion centralisée du réseau | Votre migration crée un patrimoine multi-réseau virtuel nécessitant une gouvernance centralisée |
Résumé
En suivant ce chemin de lecture, vous avez conçu un réseau hub-and-spoke avec des services partagés centralisés, une connectivité VPN ou ExpressRoute établie à l’emplacement local, déployé Pare-feu Azure pour l’inspection centralisée du trafic, configuré le transfert DNS pour la résolution de noms, l’accès aux machines virtuelles sécurisées via Azure Bastion et configurer la supervision pour valider votre migration. Cette architecture prend en charge vos charges de travail migrées tout en vous offrant une sécurité centralisée et une visibilité opérationnelle.
Étapes suivantes
- Migrer et moderniser le chemin de mise en réseau : si votre prochaine phase implique l’adoption de services ou de conteneurs PaaS
- Phases de conception en un coup d’œil : pour le résumé générique par phases de la conception du réseau Azure
- Vue d’ensemble de la planification et de la conception du réseau Azure : pour l’exploration basée sur les fonctionnalités de tous les services disponibles