View a markdown version of this page

Migrez votre réseau vers AWS - AWS Transformation
Étape 1 : mappage du réseau sourceÉtape 2 : fichiers de configuration supplémentairesÉtape 3 : Topologies du réseauÉtape 4 : mappage des groupes de sécuritéÉtape 5 : Passez en revue et optimisez votre réseauÉtape 6 : Schéma du réseauÉtape 7 : Configuration du balisage des ressourcesÉtape 8 : Déployez votre réseauSupprimer les ressources réseau déployéesExtraction du fichier de configuration

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.

Migrez votre réseau vers AWS

Avec AWS Transform, vous pouvez migrer votre réseau vers AWS. AWS Transform traduit la configuration de votre environnement source en ressources réseau AWSéquivalentes : VPC, sous-réseaux, groupes de sécurité, passerelles NAT, passerelles de transit, adresses IP élastiques, routes et tables de routage selon les besoins. Vous pouvez revoir et modifier la configuration réseau générée avant le déploiement. Vous pouvez déployer la configuration avec AWS Transform et analyser la connectivité réseau. Vous pouvez également choisir le déploiement automatique et recevoir l'infrastructure sous forme de code (IaC) dans le format de votre choix : AWS Cloud Development Kit (AWS CDK) Landing Zone Accelerator (LZA) ou HashiCorp Terraform.

Pour migrer votre réseau, procédez comme suit :

  1. Téléchargez votre fichier réseau source.

  2. Téléchargez des fichiers de configuration supplémentaires (facultatif, pour les environnements RVTools).

  3. Sélectionnez une topologie de réseau.

  4. Sélectionnez une stratégie de mappage des groupes de sécurité.

  5. Passez en revue et optimisez votre réseau.

  6. Générez un schéma de réseau (facultatif).

  7. Configurez le balisage des ressources.

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

Étape 1 : mappage du réseau source

Le processus de mappage réseau nécessite que vous téléchargiez un fichier de configuration depuis votre environnement source. L'outil que vous choisissez dépend du type de réseau source :

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

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

  • Réseaux hybrides qui exécutent à la fois des charges de travail VMware et non VMware : outil de découverte AWS Transform ou ModelizeIt.

  • Autres types de fichiers : si votre fichier de configuration n'est pas l'un des formats pris en charge répertoriés ci-dessus, le fichier est automatiquement converti dans un format pris en charge. 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.

Avertissement

Téléchargez RVTools uniquement depuis le site officiel de Dell à https://www.dell.com/en-us/shop/vmware/sl/rvtoolsl'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 vSwitches (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é en matière de pare-feu.

  • Fortinet FortiGate fournit des politiques de sécurité en matière de 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.

É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 mais vous laisse l'accès à Internet et la connectivité inter-VPC, afin que vous puissiez choisir la configuration qui répond aux exigences de votre entreprise.

Pour activer l'accès à Internet pour un VPC isolé, procédez comme suit :

  1. Créez une passerelle Internet et connectez-la au VPC.

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

  3. Créez des passerelles NAT dans les sous-réseaux publics (une par AZ pour une haute disponibilité). Allouez une adresse IP élastique pour chaque passerelle NAT.

  4. Mettez à jour les tables de routage de votre sous-réseau privé : ajoutez une route pour 0.0.0.0/0 pointer vers la passerelle NAT dans la même zone d'accès.

  5. Passez en revue les règles de votre groupe de sécurité : assurez-vous que les règles sortantes autorisent le trafic dont vos charges de travail ont besoin (HTTPS, DNS, etc.).

Pour VPC-to-VPC la communication, configurez l'appairage VPC ou un Transit Gateway 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 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, un paramètre 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 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 avec des adresses IP élastiques 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 : elle 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 routage 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).

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

  2. La table de routage non inspectée achemine le trafic vers le VPC d'inspection.

  3. Votre pare-feu du VPC d'inspection inspecte le trafic et le redirige vers le Transit Gateway.

  4. La table de routage inspectée achemine le trafic vers le VPC à rayons de destination à l'aide de routes propagées.

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 l'infrastructure réseau, mais vous laisse le soin de configurer le pare-feu et les services entrants, afin que vous puissiez choisir les dispositifs et les politiques de sécurité qui répondent aux exigences 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 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.

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 les problèmes de connectivité.

Configuration des services entrants : pour héberger des services destinés au public, déployez un Application Load Balancer ou un Network Load Balancer 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.

Les règles de votre groupe de sécurité ne peuvent faire référence qu'à 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 également 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 règles. CIDR-based 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 restreint 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 :

Sélection de la plage réseau

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

Attribution d'adresses IP

  • 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 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 — voir Recommandations guidées.

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.

Les opérations suivantes sont disponibles pour 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, la modification 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 une fois les modifications apportées.

  • 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 CIDR des règles des groupes de sécurité ne sont pas automatiquement mis à jour. Passez en revue vos règles après la séparation pour vous assurer que les communications entre VPC fonctionnent 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.

Les opérations suivantes sont disponibles pour 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.

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 guidées pour le réseau

AWS Transform analyse votre réseau cartographié et fournit des recommandations hiérarchisées via l'interface de chat. 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.

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

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 permettent d'utiliser le VPC et le sous-réseau pour lancer des instances de test et de transfert dans. 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, après avoir passé 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, 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 : migMPE_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. Consultez la section Processus d'approbation des déploiements.

  • 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 échouera en cas de divergence entre les identifiants d'organisation.

Pour le déploiement automatique, utilisez le lien fourni pour télécharger un fichier zip contenant les modèles générés. Le dossier zip contient un README.md fichier qui explique comment utiliser les modèles générés.

Pour vérifier que le fichier téléchargé n'a pas été corrompu ou altéré, générez et téléchargez un checksum, puis comparez-le à un hachage généré localement à l'aide de la commande. openssl dgst -sha256 -binary <file.zip> | base64

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 pour garantir la conformité aux normes de sécurité et aux exigences architecturales. 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 via SSH ou un client CLI intégré

    2. Exécuter : show | grep "" (| grep ""désactive la pagination)

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

    2. Ouvrez le menu Admin et choisissez Config Rollbacks

    3. Dans la boîte de dialogue Prendre un instantané, sélectionnez l'option de localisation à distance et choisissez Créer un instantané maintenant.

    4. 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)