Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Mappez le réseau source aux nouveaux VPC Obtenez un réseau cible complet, prêt pour la production, généré à partir de votre configuration source en un rien de temps. AWS Transform traduit votre environnement source en ressources AWS réseau, notamment des VPC, des sous-réseaux, des groupes de sécurité, des passerelles NAT, des passerelles de transit, des adresses IP élastiques, des itinéraires et des tables de routage, que vous examinez et ajustez avant le déploiement. Vous pouvez déployer directement avec AWS Transform ou choisir l'autodéploiement et recevoir l'infrastructure sous forme de code (IaC) dans le format de votre choix : Cloud Development Kit AWS (AWS CDK) Landing Zone Accelerator (LZA) ou HashiCorp Terraform. Choisissez **Mapper le réseau source aux nouveaux VPC** lorsque vous approvisionnez votre AWS réseau dans le cadre de la migration. L'agent AWS Transform vous guide à travers les étapes suivantes, en gérant l'analyse et la génération pendant que vous prenez les décisions : 1. Téléchargez votre fichier réseau source. 1. Téléchargez des fichiers de configuration supplémentaires (facultatif, pour les environnements RVTools). 1. Sélectionnez une topologie de réseau. 1. Sélectionnez une stratégie de mappage des groupes de sécurité. 1. Passez en revue et optimisez votre réseau. 1. Générez un schéma de réseau (facultatif). 1. Configurez le balisage des ressources. 1. Déployez votre réseau. **Note** Pour les déploiements multicomptes, vous devez configurer les rôles IAM entre comptes et l'accès sécurisé pour les AWS Organizations avant de commencer la migration du réseau. Pour plus d'informations sur les types de migration, consultez[Étape 1 : sélection du type de migration](transform-vmware-connect-target-account.md#transform-vmware-cta-migration-type). ## Étape 1 : mappage du réseau source AWS Transform génère une infrastructure réseau cible à partir d'une grande variété de fichiers de configuration réseau source. Chargez un ou plusieurs fichiers de configuration depuis votre environnement source, et AWS Transform les utilise pour générer des réseaux cibles, notamment des VPC, des sous-réseaux et des groupes de sécurité Amazon. AWS Transform ne génère pas de ressources de pare-feu ou d'équilibreur de charge. Cependant, il peut utiliser la configuration de ces éléments de réseau comme entrée pour générer des réseaux cibles. AWS Transform accepte les fichiers de configuration provenant des types de sources suivants : + **Réseaux définis par logiciel (SDN) :** Import/Export pour la virtualisation du réseau VMware NSX ou pour la configuration Cisco ACI pour l'infrastructure centrée sur les applications Cisco. + **Réseaux VMware vSphere :** [RVTools.](https://www.dell.com/en-us/shop/vmware/sl/rvtools) Lorsque vous utilisez des fichiers RVTools, AWS Transform génère uniquement des configurations Amazon VPC. Les configurations des groupes de sécurité nécessitent des entrées supplémentaires provenant du pare-feu ou de fichiers réseau définis par logiciel. Pour plus d'informations sur la génération de groupes de sécurité à partir de fichiers supplémentaires, consultez la section [Fichiers de configuration supplémentaires](#transform-vmware-firewall-and-sdn-config-files). + **Réseaux basés sur les données de configuration du pare-feu :** exportez des fichiers depuis Palo Alto Networks Firewall, Fortinet FortiGate Firewall ou Cisco ACI. Pour plus d'informations sur les versions prises en charge et les instructions d'extraction, consultez la section [Extraction du fichier de configuration](#transform-vmware-config-file-extraction). + **Réseaux hybrides qui exécutent à la fois des charges de travail VMware et non VMware :** [outil de découverte AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool.html) ou ModelizeIt. + **Autres types de fichiers :** AWS Transform accepte également d'autres fichiers de configuration réseau, tels que les configurations Checkpoint et F5. Si votre fichier de configuration n'est pas l'un des formats répertoriés ci-dessus, AWS Transform le convertit automatiquement et l'utilise pour générer des réseaux cibles. Cette conversion peut prendre jusqu'à deux heures en fonction de la taille et de la complexité du fichier. **Note** La taille de fichier réseau source maximale prise en charge est de 70 Mo. **Note** Pour permettre la suppression des règles de groupe de sécurité obsolètes lors de la révision du réseau, soumettez les données de trafic réseau observées à partir de l'[outil de découverte AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool.html) ou de ModelizeIt en même temps que la configuration de votre réseau source. Pour plus d'informations, consultez la section [Recommandations relatives aux réseaux guidés](#transform-vmware-guided-recommendations). **Avertissement** Téléchargez RVTools uniquement depuis le site officiel de Dell à [https://www.dell.com/en-us/shop/vmware/sl/rvtools](https://www.dell.com/en-us/shop/vmware/sl/rvtools)l'adresse. Ne téléchargez pas RVTools à partir de sources non officielles. Chaque segment de réseau source est mappé à son propre VPC distinct. La segmentation du réseau varie selon le type de source : + **VNetwork :** AWS Transformez les groupes de machines virtuelles par vSwitch et réseau local virtuel (VLAN). Les VLAN peuvent apparaître sous plusieurs commutateurs virtuels (sauf le VLAN 0). + **Réseaux NSX :** AWS transformez les segments du réseau en fonction Tier-1 des routeurs, en regroupant les routeurs et en collectant leurs segments. ## Étape 2 : fichiers de configuration supplémentaires Pour les environnements source RVTools, vous pouvez éventuellement télécharger des fichiers de configuration supplémentaires pour permettre la génération de groupes de sécurité. Si vous ne téléchargez pas de fichiers de configuration supplémentaires, aucun groupe de sécurité n'est généré pour votre RVTools-based migration. AWS Transform prend en charge les types de fichiers de configuration supplémentaires suivants. Vous ne pouvez télécharger qu'un seul fichier de configuration à partir d'une seule plateforme. + L'infrastructure centrée sur les applications (ACI) de Cisco fournit des configurations de politique réseau. + Palo Alto Networks fournit des politiques de sécurité par pare-feu. + Fortinet FortiGate fournit des politiques de sécurité par pare-feu. Lorsque vous téléchargez un pare-feu ou un fichier Cisco ACI, AWS Transform génère une infrastructure réseau et des groupes de sécurité. Lorsque vous téléchargez un fichier RVTools seul, AWS Transform génère uniquement une infrastructure réseau. Pour plus d'informations sur les versions prises en charge et les instructions d'extraction, consultez la section [Extraction du fichier de configuration](#transform-vmware-config-file-extraction). ## Étape 3 : Topologies du réseau Au cours de l'étape de définition du réseau, vous sélectionnez une topologie de réseau. Vous pouvez choisir la topologie **des VPC isolés** ou la topologie **Hub and Spoke**. ### VPC isolés #### Qu'est-ce qui est déployé Les VPC isolés sont des environnements réseau indépendants qui fonctionnent comme des unités distinctes au sein AWS de ceux-ci. Vos VPC sont complètement isolés, sans aucune voie de communication intégrée entre eux. Cette séparation fournit le plus haut niveau de protection des limites du réseau. AWS Transform crée les ressources suivantes : + Un VPC dédié pour chaque segment de réseau source détecté. + Sous-réseaux privés basés sur la configuration de votre réseau source. + Groupes de sécurité (si vous avez fourni des fichiers de configuration de pare-feu ou de SDN). #### Terminez votre configuration AWS Transform déploie l'infrastructure réseau principale pour vous. Vous complétez la configuration finale de connectivité et de sécurité pour répondre aux exigences de votre organisation. Pour activer l'accès à Internet pour un VPC isolé, procédez comme suit : 1. Créez une [passerelle Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) et connectez-la au VPC. 1. Créez des sous-réseaux publics dans chaque zone de disponibilité où vous avez besoin d'un accès à Internet. Ajoutez un itinéraire pour `0.0.0.0/0` pointer vers la passerelle Internet. Pour plus d'informations sur la configuration des sous-réseaux, consultez [Sous-réseaux pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html). 1. Créez des [passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans les sous-réseaux publics (une par AZ pour une haute disponibilité). Allouez une adresse IP élastique pour chaque passerelle NAT. 1. Mettez à jour les [tables de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) de votre sous-réseau privé. Ajoutez une route pour `0.0.0.0/0` pointer vers la passerelle NAT dans le même AZ. 1. Passez en revue les [règles de votre groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html). Assurez-vous que les règles de trafic sortant autorisent le trafic dont vos charges de travail ont besoin (par exemple, HTTPS et DNS). Pour VPC-to-VPC la communication, configurez l'[appairage VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) ou un [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) et mettez à jour les tables de routage dans chaque VPC pour acheminer le trafic vers la connexion d'appairage ou l'attachement TGW. ### Hub et Spoke Dans ce modèle, un [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) fait office de hub central qui connecte plusieurs VPC de charge de travail (les rayons). #### Qu'est-ce qui est déployé AWS Transform crée les ressources suivantes : + **VPC Spoke :** un VPC par segment de réseau source détecté, avec des sous-réseaux privés et une attache Transit Gateway. + **VPC d'inspection :** héberge votre dispositif de pare-feu pour l'inspection du trafic. Tout le trafic inter-VPC est acheminé via ce VPC. La pièce jointe Transit Gateway utilise le [mode appliance](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-appliance-scenario.html), qui garantit que le trafic circule de manière symétrique à travers le même appareil dans les deux sens d'une connexion. + **VPC entrant** : gère le trafic entrant sur votre réseau depuis l'Internet public (trafic entrant nord-sud). Inclut une [passerelle Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) et des sous-réseaux publics répartis sur plusieurs zones de disponibilité. + **VPC sortant** : gère le trafic sortant de votre réseau vers l'Internet public (trafic sortant nord-sud). Inclut une passerelle Internet, des [passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) avec des [adresses IP élastiques](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) dans chaque zone de disponibilité pour une haute disponibilité, et des sous-réseaux privés pour la pièce jointe Transit Gateway. + **Tables de routage Transit Gateway :** deux tables de routage orientent le trafic via le VPC d'inspection : + La table *Non inspectée* est associée aux VPC en étoile, aux VPC entrants et aux VPC sortants. Il achemine tout le trafic (0.0.0. 0/0) à la pièce jointe Inspection VPC et constitue la table de routage d'association par défaut. + La table *Inspected* est associée au VPC d'inspection. Elle contient les routes propagées à partir de tous les VPC en étoile et constitue la table de routes de propagation par défaut. Pour les déploiements multi-comptes, le Transit Gateway est partagé entre les comptes via [AWS Resource Access Manager (RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html). #### Flux de trafic Tout le trafic inter-VPC suit ce chemin : 1. Le trafic provenant d'un VPC en étoile est envoyé au Transit Gateway (route par défaut 0.0.0). 0/0). 1. La table de routage non inspectée achemine le trafic vers le VPC d'inspection. 1. Votre pare-feu du VPC d'inspection inspecte le trafic et le redirige vers le Transit Gateway. 1. La table de routage inspectée achemine le trafic vers le VPC à rayons de destination en utilisant des itinéraires propagés. Pour le trafic Internet sortant, la table de routage inspectée achemine le trafic vers le VPC sortant. Les passerelles NAT traduisent les adresses IP privées avant que le trafic ne soit transféré vers la passerelle Internet. La table des itinéraires publics VPC sortants inclut des itinéraires spécifiques pour chaque plage de routage Inter-Domain sans classe (CIDR) VPC en rayons jusqu'au Transit Gateway. Ces itinéraires permettent au trafic de retour d'atteindre le VPC à rayons approprié. Le trafic Internet entrant entre par la passerelle Internet du VPC entrant et suit le même chemin d'inspection pour atteindre les VPC en étoile. #### Terminez votre configuration AWS Transform déploie pour vous l'infrastructure réseau principale, notamment le Transit Gateway, les VPC en étoile et le routage du trafic. Vous terminez la configuration du pare-feu et la configuration du service entrant en fonction des exigences de sécurité de votre entreprise. **Note** Par défaut, le trafic inter-VPC passe par le VPC d'inspection sans inspection. Vous devez déployer un pare-feu pour permettre l'inspection du trafic. **Déployer un pare-feu :** créez des sous-réseaux supplémentaires dans le VPC d'inspection pour les points de terminaison du pare-feu. AWS Transform crée des sous-réseaux pour la pièce jointe Transit Gateway uniquement. Acheminez le trafic depuis les sous-réseaux de rattachement TGW vers les points de terminaison du pare-feu, et depuis les sous-réseaux du pare-feu vers le Transit Gateway. Vous pouvez déployer [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html) ou une appliance tierce. Pour plus d'informations sur le déploiement d'un pare-feu avec un Transit Gateway, voir [Création d'un pare-feu avec un Transit Gateway](https://docs.aws.amazon.com/network-firewall/latest/developerguide/create-tgw-firewall.html). **Vérifiez la connectivité :** après avoir déployé le pare-feu, testez l'accès Internet sortant à partir d'une instance VPC en étoile (par exemple,). `curl https://aws.amazon.com` Vous pouvez utiliser [Reachability Analyzer pour résoudre](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) les problèmes de connectivité. **Configuration des services entrants : pour héberger des services destinés** au public, déployez un [Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) Balancer ou un [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) dans les sous-réseaux publics VPC entrants. Configurez des groupes cibles qui pointent vers des instances de vos VPC en étoile via le Transit Gateway, et vérifiez que la table de routage inspectée comporte des itinéraires de retour vers le VPC entrant. Si vous souhaitez contrôler avec précision la communication entre les VPC, choisissez l'option VPC **isolés** et modifiez le réseau généré pour créer les chemins de communication spécifiques dont vous avez besoin. ## Étape 4 : mappage des groupes de sécurité Choisissez comment vos politiques de sécurité source se traduisent en groupes AWS de sécurité. AWS Transform crée des groupes de sécurité en fonction des configurations de votre environnement source. Les politiques de sécurité, les règles de sécurité, les politiques de passerelle et les règles de stratégie de passerelle sont converties en groupes de sécurité. **Important** AWS Transform crée des groupes de sécurité dans la mesure du possible pour qu'ils correspondent à votre environnement source. Passez en revue et modifiez les groupes de sécurité générés pour vous assurer qu'ils répondent aux besoins et aux politiques de sécurité de votre entreprise. ### Référencement des groupes de sécurité Lorsque des groupes de sécurité sont générés, AWS Transform utilise le référencement des groupes de sécurité lorsque cela est pris en charge. Le référencement des groupes de sécurité définit des règles de sécurité basées sur un autre identifiant de groupe de sécurité plutôt que sur des plages d'adresses IP spécifiques (blocs CIDR). Cette approche fournit des configurations de sécurité plus flexibles et plus faciles à maintenir. Le référencement des groupes de sécurité suit les règles suivantes : + Les règles peuvent faire référence à d'autres groupes de sécurité au sein du même VPC ou d'un VPC connecté au sein de la même région. + Cross-account les références sont prises en charge. + Vous ne pouvez pas référencer un groupe de sécurité dans un VPC non connecté ou dans plusieurs régions. + Pour les VPC connectés, seules les règles entrantes prennent en charge les références aux groupes de sécurité inter-VPC. Les règles sortantes doivent utiliser des CIDR-based règles. La manière dont AWS Transform crée les règles des groupes de sécurité dépend de la topologie de réseau que vous avez choisie : + **Hub and Spoke :** Transit Gateway fournit une connectivité réseau entre les VPC. AWS Transform utilise le référencement pour les règles intra-VPC et les règles d'entrée croisée. VPC/cross-account Cross-VPC/cross-account les règles de sortie (sortantes) utilisent CIDR-based des règles. + **VPC isolés :** vos VPC n'ont aucune connectivité réseau entre eux. AWS Transform utilise le référencement uniquement pour les règles intra-VPC. Toutes les règles inter-VPC et inter-comptes utilisent des règles. CIDR-based CIDR-based les règles sont également utilisées lorsque les configurations de source ne sont pas symétriques. Choisissez l'une des stratégies de mappage des groupes de sécurité suivantes : + **MAP :** traduit les règles de sécurité de votre environnement source en groupes et règles de AWS sécurité. Utilisez cette option pour les migrations utilisant un adressage IP statique. + **MAP\_DHCP (Translate with DHCP support) :** traduit les règles de sécurité de votre environnement source avec la compatibilité DHCP. Le DHCP attribue des adresses IP de manière dynamique à partir de la plage CIDR du sous-réseau. Par conséquent, les règles de sortie inter-VPC sont étendues pour correspondre au CIDR complet du sous-réseau de destination. Un CIDR plus étroit bloquerait les DHCP-assigned adresses IP situées en dehors de cette plage. Passez en revue ces règles après la migration. Utilisez cette option pour le support DHCP avec la communication Cross-VPC Transit Gateway. Fonctionne également avec les adresses IP statiques, mais peut produire des règles plus larges que le MAP. + **IGNORER :** ne traduit pas les règles de sécurité. Configurez les groupes AWS de sécurité manuellement après la migration. Fonctionne avec les environnements IP et DHCP statiques. Pour les environnements source RVTools sans fichiers de configuration supplémentaires, AWS Transform utilise automatiquement SKIP. **Note** Votre stratégie de mappage détermine vos options d'attribution d'adresses IP. MAP prend uniquement en charge les adresses IP statiques. MAP\_DHCP et SKIP supportent à la fois le mode statique et le protocole DHCP. ### Approches de migration IP Deux options de configuration réseau s'offrent à vous pour votre migration : Pour **sélectionner la plage réseau**, choisissez l'une des options suivantes : + **Conserver les plages existantes (conservation des plages d'adresses IP) :** Conservez les plages d'adresses IP d'origine pendant la migration. Idéal pour les migrations où vous déplacez des applications AWS sans les modifier (lift-and-shift), en particulier pour les applications existantes qui ont des dépendances IP codées en dur ou des règles de pare-feu existantes. + **Mise à jour vers de nouvelles plages d'adresses IP (mise à jour CIDR) :** vous pouvez modifier chaque plage d'adresses CIDR VPC pendant la migration, AWS et Transform propage automatiquement les modifications aux sous-réseaux, aux tables de routage et aux groupes de sécurité. Pour l'**attribution d'adresses IP**, choisissez l'une des options suivantes : + **Adresses IP fixes (statiques) :** AWS Transform attribue des adresses IP statiques en fonction du CIDR. C'est la meilleure solution pour les applications qui nécessitent un comportement réseau prévisible, une gestion DNS ou un contrôle IP-based d'accès. Les adresses IP sont conservées lors des redémarrages des instances via les interfaces réseau Elastic (ENI), qui sont des cartes réseau virtuelles connectées à vos instances. + **Attribution dynamique d'adresses IP (AWS DHCP) :** attribuez automatiquement des adresses IP à partir de pools de sous-réseaux lors du lancement de l'instance. Idéal pour les applications conçues pour s'exécuter dans le cloud et pour l'auto-scaling des charges de travail. Réduit la charge opérationnelle mais oblige les applications à utiliser le DNS ou la découverte de services. Vous pouvez combiner l'une ou l'autre des sélections de plages avec l'une ou l'autre des méthodes d'attribution IP. **Note** La stratégie d'attribution des adresses IP est définie au niveau de la vague. Vous pouvez attribuer différentes stratégies à des serveurs spécifiques en personnalisant le fichier wave. Par exemple, si vous avez choisi une approche d'adresse IP statique pour la vague mais que vous souhaitez attribuer une approche dynamique à un serveur spécifique, vous devez utiliser la méthode `[RESET_VALUE]` décrite dans la section [Modification de votre configuration](https://docs.aws.amazon.com/mgn/latest/ug/configuration-editing.html) dans le *guide de l'utilisateur MGN*. ## Étape 5 : Passez en revue et optimisez votre réseau Une fois que AWS Transform a généré la configuration de votre réseau cible, vous pouvez passer en revue les segments de réseau sur site qui ont convergé vers l' AWS infrastructure. Utilisez l'interface visuelle pour examiner votre réseau, et l'interface de chat pour apporter des modifications et recevoir des recommandations guidées. AWS Transform effectue une analyse d'impact en cascade et met en œuvre les modifications nécessaires pour maintenir la cohérence du réseau et la conformité aux meilleures pratiques. Vous pouvez également demander à AWS Transform d'analyser votre réseau et de suggérer des optimisations. Pour plus d'informations, consultez la section [Recommandations guidées](#transform-vmware-guided-recommendations). ### VPC existants dans votre compte cible Si votre compte cible contient déjà des VPC issus de phases de migration précédentes ou de projets d'infrastructure parallèles, AWS Transform les détecte automatiquement et les affiche à côté de vos VPC mappés pendant le processus de révision. Pour les migrations multicomptes, AWS Transform détecte les VPC existants sur tous les comptes de votre AWS organisation. Cette visibilité vous permet de comprendre le lien entre votre réseau prévu et votre infrastructure existante, d'identifier les conflits CIDR potentiels et de prendre des décisions éclairées avant le déploiement. **Note** AWS Transform détecte uniquement les VPC existants (et non les sous-réseaux ou autres ressources). La détection est en lecture seule. AWS Transform ne modifie pas vos VPC existants. ### Optimisez votre réseau **Note** Ces opérations s'appliquent uniquement aux VPC de charge de travail. Pour les VPC d'appliance dans la topologie Hub and Spoke (inspection, entrée, sortie), seule la modification de l'adresse IP est prise en charge. Vous ne pouvez pas annuler les opérations de suppression, de fusion et de division. Vérifiez attentivement votre configuration avant d'appliquer ces modifications. Vous pouvez effectuer les opérations suivantes sur les VPC : + **Supprimer : supprimez** définitivement un VPC de la configuration. Utilisez-le pour les segments de réseau obsolètes vers lesquels la migration ne doit pas être effectuée AWS. + **Exclure :** supprimez temporairement un VPC de la migration pour les stratégies de migration par étapes. Les VPC exclus ne sont pas déployés mais peuvent être réinclus ultérieurement. + **Inclure :** ajoutez à nouveau un VPC précédemment exclu à la migration. + **Fusion :** combinez deux VPC en un seul. Le premier VPC conserve son identité et absorbe tous les sous-réseaux du second VPC. Les groupes de sécurité sont déplacés vers le VPC fusionné et leurs associations sont reconstruites en conséquence. Le CIDR du premier VPC s'étend à la plus petite plage d'adresses CIDR contenant les deux CIDR d'origine, et le routage est mis à jour automatiquement. Le second VPC est supprimé de la configuration. Exigences relatives à la fusion : + Les CIDR de sous-réseau ne doivent pas se chevaucher entre les deux VPC. + Le CIDR fusionné ne doit pas dépasser /16. + Pour les déploiements multicomptes, les deux VPC doivent être affectés au même compte. + **Modifier l'adresse IP :** modifiez l'adresse IP de base d'un CIDR VPC tout en conservant la même longueur de préfixe. AWS Transform traduit automatiquement tous les CIDR de sous-réseau selon le même décalage. Par exemple, le changement d'un VPC de `10.0.0.0/16` à `10.20.0.0/16` déplace un sous-réseau de vers. `10.0.1.0/24` `10.20.1.0/24` Les règles du groupe de sécurité qui correspondent exactement à l'ancien CIDR VPC sont mises à jour automatiquement. Les règles qui recoupent partiellement ou ne correspondent pas à l'ancien CIDR ne sont pas modifiées. Passez en revue ces règles après la modification. + **Renommer :** modifiez le nom d'un VPC afin de l'aligner sur les conventions de dénomination de votre organisation en matière de répartition des coûts, de suivi de conformité et de normes opérationnelles. + **Redimensionner :** modifiez la longueur du préfixe d'un CIDR VPC pour étendre ou réduire la plage d'adresses IP. + **Diminution de la longueur du préfixe** (plus d'adresses IP, par exemple /20 à /16) : les sous-réseaux s'inscrivent toujours dans la plage la plus large. Aucune modification de sous-réseau n'est nécessaire. + **Augmentation de la longueur du préfixe** (moins d'adresses IP, par exemple /16 à /20) : les sous-réseaux situés en dehors de la nouvelle plage doivent d'abord être redimensionnés à l'aide de l'opération de redimensionnement des sous-réseaux. Les règles du groupe de sécurité qui correspondent exactement à l'ancien CIDR VPC sont mises à jour automatiquement. Les règles qui recoupent partiellement ou ne correspondent pas à l'ancien CIDR ne sont pas modifiées. Passez en revue ces règles après le redimensionnement. Exigences relatives au redimensionnement : + Le nouveau CIDR doit être compris entre /16 et /28. + Le nouveau CIDR ne doit pas se chevaucher avec les autres VPC du réseau (topologie Hub and Spoke). + Lors de la réduction du CIDR, tous les sous-réseaux existants doivent correspondre au nouveau CIDR. Redimensionnez d'abord les sous-réseaux si nécessaire. + Diviser **: divisez** un VPC en deux VPC en fonction des limites CIDR que vous indiquez. Les sous-réseaux sont affectés au nouveau VPC dont le CIDR les contient. Les groupes de sécurité sont clonés sur les deux nouveaux VPC, mais les règles CIDR des groupes de sécurité ne sont pas automatiquement mises à jour. Passez en revue vos règles après le fractionnement pour vous assurer que la communication entre VPC fonctionne comme prévu. Le VPC d'origine est remplacé par les deux nouveaux VPC. Exigences partagées : + Vous devez fournir exactement deux plages CIDR. + Les deux CIDR ne doivent pas se chevaucher. + Chaque CIDR doit être compris entre /16 et /28. + Chaque sous-réseau doit correspondre exactement à l'un des deux CIDR. Si un sous-réseau ne convient pas, l'opération est rejetée. Vous pouvez effectuer les opérations suivantes sur les sous-réseaux : + **Modifier l'adresse IP :** modifiez l'adresse IP de base d'un CIDR de sous-réseau tout en conservant la même longueur de préfixe. + **Supprimer : supprimez** définitivement un sous-réseau de la configuration sans affecter le VPC parent. + **Redimensionner :** modifiez la longueur du préfixe d'un CIDR de sous-réseau pour étendre ou réduire la plage d'adresses IP. Exigences relatives au redimensionnement des sous-réseaux : + Le nouveau CIDR doit être compris entre /16 et /28. + Le nouveau CIDR ne doit pas se chevaucher avec les autres sous-réseaux du même VPC. + Le nouveau CIDR doit se trouver dans le CIDR VPC parent. Vous pouvez effectuer les opérations suivantes sur les groupes de sécurité : + **Créer :** ajoutez un nouveau groupe de sécurité ou une nouvelle règle à un groupe de sécurité existant. + **Configurer :** modifiez les paramètres d'un groupe de sécurité ou l'une de ses règles, telles que le nom, la description, le protocole, la plage de ports ou la direction. + **Supprimer : supprimez** définitivement un groupe de sécurité ou l'une de ses règles de la configuration. + **Associer un CIDR à une règle :** définissez ou mettez à jour la plage d'adresses CIDR dans laquelle une règle de groupe de sécurité autorise le trafic à destination ou en provenance de celui-ci. + **Associer une machine virtuelle source à une règle :** définissez ou mettez à jour la machine virtuelle (VM) source pour une règle de groupe de sécurité en fonction de son identifiant unique universel (UUID). La règle suit ensuite cette charge de travail au lieu d'une adresse IP fixe. + **Activer le référencement pour une règle :** activez le référencement de groupes de sécurité pour une règle spécifique. La règle autorise ensuite le trafic provenant d'un autre groupe de sécurité au lieu d'une plage d'adresses CIDR. Après chaque opération, AWS Transform réévalue le référencement des groupes de sécurité, ce qui peut convertir CIDR-based les règles en références de groupes de sécurité ou vice versa. Passez en revue les règles de votre groupe de sécurité après avoir apporté des modifications afin de vérifier qu'elles répondent à vos exigences. ### Recommandations de réseau guidées AWS Transform analyse automatiquement votre réseau cartographié et propose des recommandations hiérarchisées par le biais de l'interface de chat, en identifiant les optimisations qui nécessitent généralement un examen manuel par les architectes réseau. Les recommandations sont basées sur les données de votre réseau et nécessitent votre confirmation avant que des modifications ne soient appliquées. AWS Transform peut recommander les optimisations suivantes : + **Résolution des conflits CIDR :** signale les plages d'adresses CIDR qui se chevauchent entre vos VPC mappés et les VPC existants sur tous les comptes de votre organisation. AWS Les VPC en conflit sont affichés en premier. Vous pouvez résoudre les conflits en réadressant le VPC mappé, en l'excluant ou en le supprimant, ou en reconnaissant le conflit et en le résolvant vous-même après le déploiement. + **Standardisation des noms :** signale les noms de VPC qui ne suivent pas un modèle cohérent (par exemple, les noms contenant des références matérielles). AWS Transform demande la convention de dénomination de votre cloud avant de proposer des remplacements. + **Examen du périmètre :** identifie les segments du réseau vers lesquels il n'est pas nécessaire de migrer AWS, tels que les systèmes existants ou les constructions en attente de mise hors service. AWS Transform demande votre confirmation avant d'exclure une construction. + **Dimensionnement correct de la capacité du VPC :** surface les VPC dont le CIDR apparaît surdimensionné ou sous-dimensionné pour les sous-réseaux qu'il contient. AWS Transform présente les données de capacité actuelles et vous permet de décider si vous souhaitez les redimensionner. + **Examen de sécurité :** signale les règles de groupe de sécurité qui autorisent le trafic entrant non restreint (0.0.0). 0/0) pour votre évaluation. + **Suppression des règles de groupe de sécurité obsolètes :** identifie les règles de pare-feu entrant non utilisées migrées depuis votre environnement sur site et suggère de les supprimer afin de ne pas perpétuer une exposition de sécurité inutile. Cette recommandation fonctionne comme suit : + Pour identifier les règles non utilisées, AWS Transform utilise les données de trafic réseau observées collectées par l'[outil de découverte AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool.html) ou ModelizeIt. Vous devez envoyer ces données de trafic en même temps que l'entrée de votre réseau source. + AWS Transform compare vos règles de pare-feu migrées au trafic observé sur la fenêtre d'observation capturée dans ces données. Il indique qu'une règle n'est pas utilisée lorsqu'aucun trafic entrant ne correspond à cette règle. L'absence de trafic entrant observé est un signal fiable indiquant qu'une règle n'est pas utilisée. + Sans données de trafic, AWS Transform ne peut pas déterminer quelles règles ne sont pas utilisées et ne suggère aucune suppression. + AWS Transform supprime uniquement les règles d'entrée (entrantes) inutilisées. Passez en revue les suppressions suggérées avant de les appliquer pour vérifier qu'elles sont conformes à vos politiques de sécurité. + **Consolidation des VPC :** identifie les VPC fragmentés qui apparaissent séparés par des limites d'infrastructure physique plutôt que par des exigences d'isolation logique, et suggère de les fusionner. + **Alignement des applications :** identifie les VPC hébergeant des applications issues de plusieurs environnements, tels que les charges de travail de développement et de production qui partagent un seul VPC. Lorsque les environnements peuvent être clairement séparés le long des limites des sous-réseaux, de sorte qu'aucun environnement n'ait de charge de travail des deux côtés de la division proposée, AWS Transform suggère de diviser le VPC le long de cette limite. Les adresses IP des sous-réseaux et des serveurs restent inchangées. La séparation des environnements en VPC dédiés suit les AWS meilleures pratiques en matière d'isolation de la charge de travail et de contrôle d'accès spécifique à l'environnement. Cette recommandation nécessite les données d'application et d'environnement de votre plan de migration. Elles ne sont donc disponibles qu'après la planification de la migration. **Note** Toutes les recommandations nécessitent votre confirmation explicite avant que AWS Transform n'applique les modifications. AWS Transform présente des compromis lorsqu'une recommandation concerne plusieurs aspects de votre réseau. ## Étape 6 : Schéma du réseau Après avoir examiné les configurations VPC générées, vous pouvez éventuellement générer un diagramme de réseau pour visualiser la topologie de votre réseau. AWS Transform prend en charge les formats de diagramme suivants : + **Code Mermaid (.mmd) :** ce format produit un fichier de définition de diagramme sous forme de texte que vous pouvez afficher à l'aide d'outils. Mermaid-compatible + **Image (.png) :** ce format produit une image rendue de la topologie de votre réseau. ## Étape 7 : Configuration du balisage des ressources Les ressources de votre réseau sont étiquetées pour le lancement et la réplication. Vous pouvez également ajouter des balises personnalisées et des balises AWS Migration Acceleration Program (MAP). ### Balises automatiques pour le lancement et la réplication AWS Transform étiquette automatiquement vos ressources réseau migrées (VPC, sous-réseaux, groupes de sécurité et tables de routage) avec les balises suivantes : + **Clé** : **Valeur** `CreatedBy` : `AWSApplicationMigrationService` + **Clé** : **Valeur** `ATWorkspace` : `{{workspace-id}}` Ces balises vous permettent d'utiliser le VPC et le sous-réseau pour lancer des instances de test et de transfert. AWS **Note** Vos VPC et sous-réseaux migrés n'incluent pas de connectivité Internet par défaut. Ils ne conviennent donc pas comme zones intermédiaires pour la réplication. Pour également utiliser le VPC et le sous-réseau comme zone intermédiaire (réplication), ajoutez manuellement les balises suivantes : + **Clé** : **Valeur** `CreatedFor` : `AWSTransform` + **Clé** : **Valeur** `ATWorkspace` : `{{workspace-id}}` Vous pouvez également appliquer ces balises à n'importe quelle ressource AWS réseau existante afin de la rendre disponible pour la réplication. Trouvez l'ID de votre espace de travail dans l'URL de l'application Web AWS Transform : https://... {{workspace-id}} /workspace//-id job/job ### Balises personnalisées Outre les balises appliquées automatiquement par AWS Transform, vous pouvez éventuellement ajouter des balises personnalisées pour organiser, suivre les coûts et gérer la conformité de vos ressources réseau migrées. Vous pouvez appliquer des balises personnalisées à deux niveaux : + **Job-level tags :** s'appliquent à toutes les ressources créées par cette tâche, y compris tous les VPC, sous-réseaux, groupes de sécurité et tables de routage. + **VPC-level balises :** s'appliquent à un VPC spécifique et s'appliquent automatiquement à toutes ses ressources associées (sous-réseaux, groupes de sécurité, tables de routage). **Note** Maximum de 40 tags par demande. Chaque balise nécessite une clé et une valeur. AWS les conventions de balisage s'appliquent. AWS Transform applique ces balises lorsqu'il génère l'infrastructure sous forme de modèles de code. ### AWS Programme d’accélération des migrations Si votre migration fait partie du **AWS Migration Acceleration Program (MAP 2.0)**, AWS Transform applique une balise MAP à vos ressources. Si vous avez fourni votre identifiant MPE plus tôt dans le processus de migration, le tag est appliqué automatiquement. Sinon, une fois que vous avez terminé de passer en revue les configurations VPC générées, AWS Transform vous demande si vous avez un accord MAP et vous invite à fournir votre identifiant MPE. L'ID MPE est un code à 10 caractères composé de lettres majuscules et de chiffres (par exemple, ABCDE12345). La balise appliquée utilise le format suivant : + **Clé** : **Valeur** `map-migrated` : `mig{{MPE_ID}}` ## Étape 8 : Déployez votre réseau Après le balisage, sélectionnez votre stratégie de déploiement : + **AWS Transform-managed déploiement :** AWS Transform utilise des CloudFormation modèles pour déployer votre réseau et exécute Reachability Analyzer pour vérifier la connectivité entre les sous-réseaux de plusieurs VPC et au sein d'un même VPC. **Note** Vous devez obtenir une approbation explicite avant que votre demande de déploiement réseau ne soit exécutée. Voir [Processus d'approbation des déploiements](#deployment-approvals-process). + **Self-deployment:** AWS Transform génère des modèles d'infrastructure en tant que code (IaC). CloudFormation les modèles sont générés par défaut. Vous pouvez également sélectionner d'autres formats de sortie : + AWS CDK génère un TypeScript projet pour le déploiement de l'infrastructure programmatique. + HashiCorp Terraform génère des modèles HashiCorp de langage de configuration (HCL) pour gérer les ressources réseau. + Landing Zone Accelerator (LZA) génère un fichier network-config.yaml pour la configuration du réseau LZA. **Note** Lorsque vous déployez via le pipeline Landing Zone Accelerator (LZA), votre compte AWS Transform et votre installation LZA doivent se trouver dans la même AWS organisation. Le déploiement échoue si les identifiants d'organisation ne correspondent pas. Pour plus de détails sur les artefacts générés, y compris la structure du répertoire de sortie pour chaque format, consultez[Comprendre les artefacts de réseau générés](transform-migrations-generated-artifacts.md). ### Processus d'approbation des déploiements Pour garantir que les modifications du réseau sont conformes aux normes de sécurité et aux exigences architecturales de votre entreprise, toutes les demandes de déploiement passent par un flux de travail d'approbation. Vous devez obtenir une approbation explicite avant que votre demande de déploiement réseau ne soit exécutée. Lorsque vous soumettez une demande de déploiement, elle est automatiquement acheminée vers les approbateurs autorisés via l'onglet AWS Transform Approvals. Les approbateurs valident à la fois les CloudFormation modèles et les configurations réseau. Chaque soumission déclenche un nouveau cycle de révision, et les déploiements ne sont effectués qu'après réception de la confirmation. Si un approbateur refuse votre demande, contactez-le directement pour discuter des modifications nécessaires. AWS Transform suit toutes les décisions d'approbation à des fins d'audit et conserve l'historique des déploiements. ## Supprimer les ressources réseau déployées Si vous devez annuler un déploiement, vous pouvez supprimer les ressources réseau déployées par AWS Transform. Vous pouvez supprimer des ressources immédiatement après la fin du déploiement. Si vous modifiez les ressources réseau déployées après le déploiement, les ressources ne peuvent pas être supprimées automatiquement. + **AWS Transform-managed déploiements :** AWS Transform supprime toutes les CloudFormation piles créées lors du déploiement. Cette action nécessite une approbation via l'onglet AWS Transform Approvals. + **Self-deployments:** vous devez supprimer manuellement les ressources déployées via la console AWS de gestion ou la AWS CLI. ## Extraction du fichier de configuration Si votre environnement source utilise Cisco ACI, Palo Alto Networks ou Fortinet FortiGate, vous devez extraire un fichier de configuration à fournir à Transform. AWS Vous pouvez utiliser ces fichiers comme fichiers source autonomes pour générer une infrastructure réseau et des groupes de sécurité, ou comme fichiers complémentaires à côté d'un téléchargement RVTools pour ajouter la génération de groupes de sécurité. Le processus d'extraction est le même dans les deux cas. Pour extraire les fichiers de configuration de votre pare-feu et de vos environnements réseau, suivez ces procédures. Consultez la documentation du fournisseur pour obtenir les dernières informations. ### Fortinet FortiGate + La version du microprogramme doit être v7.0 ou ultérieure. + Vous avez besoin `super_admin` de `super_admin_readonly` privilèges au niveau mondial. + Étapes : 1. Connectez-vous au pare-feu à l'aide de SSH ou d'un client CLI intégré 1. Exécuter : `show | grep ""` (`| grep ""`désactive la pagination) 1. Enregistrez toutes les sorties dans un fichier à partir de la `show` commande ### Palo Alto Networks + La version du microprogramme doit être 10.1 ou ultérieure. + Vous avez besoin du rôle de superadministrateur. + Connectez-vous au pare-feu via SSH, exécutez les commandes suivantes pour désactiver la pagination, définir le format de sortie, passer en mode configuration et exporter la configuration et les objets prédéfinis. Enregistrez les sorties : ``` set cli pager off set cli config-output-format set configure show # Save as palo-conf.txt show predefined # Save as palo-default.txt ``` ### Cisco ACI + La version du microprogramme doit être 6.0 ou ultérieure. + Vous avez besoin du rôle d'administrateur doté de tous les privilèges et d'une destination configurée pour le protocole SCP (Secure Copy Protocol), le protocole de transfert de fichiers SSH (SFTP) ou le protocole de transfert de fichiers (FTP). + Étapes : 1. Connectez-vous à l'application Policy Infrastructure Controller (APIC) via votre navigateur 1. Ouvrez le menu **Admin** et choisissez **Config Rollbacks** 1. Dans la boîte de dialogue **Prendre un instantané**, sélectionnez l'option de localisation à distance et choisissez **Créer un instantané maintenant**. 1. Après avoir reçu le message « Transfert réussi », connectez-vous au serveur de localisation distant et récupérez le dernier fichier instantané (fichier .gz)