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 AWS en une fraction du temps nécessaire à la conception et au déploiement manuels. AWS Transform utilise un AI-powered agent pour traduire la configuration de votre environnement source en ressources AWS réseau prêtes pour la production, 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. Vous passez en revue et modifiez la configuration réseau générée via une interface conversationnelle avant le déploiement. Vous pouvez déployer directement avec AWS Transform ou choisir l'auto-dé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.

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.

  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 diagramme 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 organisations 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

AWS Transform génère une infrastructure réseau cible à partir d'une grande variété de fichiers de configuration réseau sources. Téléchargez un ou plusieurs fichiers de configuration depuis votre environnement source et AWS Transform utilise les informations pour générer des réseaux cibles, notamment des VPC Amazon, des sous-réseaux et des groupes de sécurité. Bien que AWS Transform ne génère pas de ressources de pare-feu ou d'équilibreur de charge, la configuration de ces éléments de réseau peut être utilisée 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 la configuration Cisco ACI pour l'infrastructure centrée sur les applications Cisco.

  • Réseaux VMware vSphere : https://www.dell.com/en-us/shop/vmware/sl/rvtools 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 informations supplémentaires provenant du pare-feu ou des 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 : 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 maximale de fichier réseau source prise en charge est de 70 Mo.

Note

Pour permettre la suppression des règles de groupe de sécurité obsolètes lors de l'examen du réseau, soumettez les données de trafic réseau observées à partir de l'outil de découverte AWS Transform ou de ModelizeIt en même temps que votre configuration réseau source. Pour plus d'informations, consultez la section Recommandations de réseau guidées.

Avertissement

Téléchargez RVTools uniquement depuis le site officiel de Dell à 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 :

  • Réseau virtuel : AWS transformez les groupes de machines virtuelles par vSwitch et réseau local virtuel (VLAN). Les VLAN peuvent apparaître sous plusieurs commutateurs virtuels (à l'exception du VLAN 0).

  • Réseaux NSX : AWS transformez les segments du réseau en fonction des Tier-1 routeurs, en regroupant les routeurs et en collectant leurs segments.

Étape 2 : fichiers de configuration supplémentaires

Pour les environnements sources 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 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 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 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 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 en fonction de la configuration de votre réseau source.

  • Groupes de sécurité (si vous avez fourni des fichiers de configuration de pare-feu ou SDN).

Terminez votre configuration

AWS Transform déploie l'infrastructure réseau principale pour vous. Vous terminez 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 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 vos sous-réseaux privés. Ajoutez une route pour 0.0.0.0/0 pointer vers la passerelle NAT dans la même zone de disponibilité.

  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 le peering VPC ou une passerelle de transit et mettez à jour les tables de routage de chaque VPC pour acheminer le trafic vers la connexion d'appairage ou la pièce jointe TGW.

Hub et rayon

Dans ce modèle, une passerelle de AWS transit 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 en étoile : un VPC par segment de réseau source détecté, avec des sous-réseaux privés et une pièce jointe 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 via la même appliance dans les deux sens d'une connexion.

  • VPC entrant : gère le trafic entrant dans votre réseau depuis l'Internet public (entrant nord-sud). Comprend une passerelle Internet et des sous-réseaux publics dans plusieurs zones de disponibilité.

  • VPC sortant : gère le trafic sortant de votre réseau vers l'Internet public (trafic sortant nord-sud). Comprend 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 de 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. Le tableau Inspecté est associé au VPC d'inspection. Il contient les routes propagées depuis 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 le chemin suivant :

  1. Le trafic provenant d'un VPC en étoile est envoyé à la passerelle de transit (route par défaut 0.0.0). 0/0).

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

  3. Votre pare-feu du VPC d'inspection inspecte le trafic et le retransmet à la passerelle de transit.

  4. La table de routage inspectée achemine le trafic vers le VPC en étoile de destination à l'aide d'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 de routage publique des VPC sortants inclut des itinéraires spécifiques pour chaque plage de Inter-Domain routage sans classe (CIDR) VPC à rayons vers la passerelle de transit. Ces itinéraires permettent au trafic de retour d'atteindre le VPC à rayons correct.

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 principale pour vous, y compris la passerelle de transit, les VPC en étoile et le routage du trafic. Vous terminez la configuration du pare-feu et du service entrant en fonction des exigences de sécurité de votre organisation.

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éployez 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 pièces jointes TGW vers les points de terminaison du pare-feu, et depuis les sous-réseaux du pare-feu vers la passerelle de transit. Vous pouvez déployer un pare-feu AWS réseau ou une appliance tierce. Pour plus d'informations sur le déploiement d'un pare-feu avec une passerelle de transit, voir Création d'un pare-feu avec une passerelle de transit.

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

Configurer les services entrants : pour héberger des services destinés au public, déployez un équilibreur de charge d'application ou un équilibreur de charge réseau dans les sous-réseaux publics du VPC entrant. Configurez des groupes cibles qui pointent vers des instances de vos VPC satellites via la passerelle de transit et vérifiez que la table de routage inspectée contient des itinéraires de retour vers le VPC entrant.

Si vous souhaitez un contrôle précis de 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 la manière dont vos politiques de sécurité des sources sont traduites 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 politique de sécurité, les politiques de passerelle et les règles de politique de passerelle sont converties en groupes de sécurité.

Important

AWS Transform crée des groupes de sécurité de son mieux pour correspondre à 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é lorsqu'il est pris en charge. Le référencement des groupes de sécurité définit les règles de sécurité en fonction d'un autre identifiant de groupe de sécurité plutôt que de plages d'adresses IP spécifiques (blocs CIDR). Cette approche fournit des configurations de sécurité plus flexibles et plus faciles à gérer.

Les règles de votre groupe de sécurité peuvent uniquement faire référence à d'autres groupes de sécurité au sein du même VPC ou d'un VPC connecté dans 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 de groupes de sécurité inter-VPC. Les règles sortantes doivent utiliser des CIDR-based règles. La façon 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 à la fois pour les règles internes au VPC et pour les règles d'entrée croisée. VPC/cross-account Cross-VPC/cross-account les règles de sortie (sortante) utilisent CIDR-based des règles.

  • VPC isolés : vos VPC ne disposent d'aucune connectivité réseau entre eux. AWS Transform utilise le référencement pour les règles internes au VPC uniquement. 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 une compatibilité DHCP. Le DHCP attribue des adresses IP de manière dynamique à partir de la plage d'adresses CIDR du sous-réseau. Par conséquent, les règles de sortie inter-VPC sont étendues pour correspondre au CIDR du sous-réseau de destination complet. Un CIDR plus étroit bloquerait les DHCP-assigned adresses IP qui se situent en dehors de cette plage. Passez en revue ces règles après la migration.

    Utilisez cette option pour la prise en charge DHCP avec la communication entre VPC Transit Gateway. Fonctionne également avec les adresses IP statiques, mais peut produire des règles plus étendues que MAP.

  • SKIP : ne traduit pas les règles de sécurité. Configurez les groupes AWS de sécurité manuellement après la migration. Fonctionne à la fois avec les environnements IP statiques et DHCP. Pour les environnements sources RVTools sans fichiers de configuration supplémentaires, AWS Transform utilise automatiquement SKIP.

Note

Votre stratégie de mappage détermine vos options d'attribution IP. MAP ne prend en charge que les adresses IP statiques. MAP_DHCP et SKIP prennent en charge à la fois le mode statique et le DHCP.

Approches de migration IP

Vous avez deux choix de configuration réseau pour votre migration :

Sélection de la plage de 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 dans le cadre desquelles vous déplacez des applications AWS sans les modifier (lift-and-shift), en particulier pour les applications héritées dont les dépendances IP sont codées en dur ou dont les règles de pare-feu sont déjà en vigueur.

  • Mise à jour vers de nouvelles plages IP (mise à jour du CIDR) : vous pouvez modifier chaque plage d'adresses CIDR VPC pendant la migration, et AWS 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 solution idéale 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 persistent lors des redémarrages d'instance via les interfaces réseau élastiques (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 au lancement de l'instance. Idéal pour les applications conçues pour s'exécuter dans le cloud et les charges de travail à dimensionnement automatique. Réduit les frais opérationnels mais oblige les applications à utiliser le DNS ou la découverte de services.

Vous pouvez combiner l'une ou l'autre sélection de plage 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 examiner les segments de réseau locaux qui ont convergé vers l' AWS infrastructure. Utilisez l'interface visuelle pour passer en revue votre réseau et l'interface de discussion 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.

VPC existants sur 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 multi-comptes, AWS Transform détecte les VPC existants sur tous les comptes de votre AWS organisation.

Cette visibilité vous permet de comprendre comment votre réseau planifié est lié à 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 (pas 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 fractionnement. 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 il ne faut pas migrer 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 dans la migration.

  • Fusionner : 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 jusqu'à 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 multi-comptes, 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 des sous-réseaux 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 à10.0.1.0/24. 10.20.1.0/24

    Les règles des groupes de sécurité qui correspondent exactement à l'ancien CIDR du VPC sont mises à jour automatiquement. Les règles qui se chevauchent 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 pour 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 restent 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 qui se situent 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 des groupes de sécurité qui correspondent exactement à l'ancien CIDR du VPC sont mises à jour automatiquement. Les règles qui se chevauchent partiellement ou ne correspondent pas à l'ancien CIDR ne sont pas modifiées. Passez en revue ces règles après le redimensionnement.

    Exigences de redimensionnement :

    • Le nouveau CIDR doit être compris entre /16 et /28.

    • Le nouveau CIDR ne doit pas chevaucher 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.

  • Séparer : divisez un VPC en deux VPC en fonction des limites CIDR que vous fournissez. Les sous-réseaux sont attribué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 de groupe de sécurité ne sont pas automatiquement mis à 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 correspond 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 chevaucher les autres sous-réseaux du même VPC.

    • Le nouveau CIDR doit se trouver dans le CIDR du 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 pour 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 prioritaires via l'interface de discussion, 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 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 de la portée : identifie les segments de réseau vers lesquels il n'est peut-être 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 toute construction.

  • Ajustement de la capacité des VPC : affiche les VPC dont le CIDR semble 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 de redimensionner ou non.

  • Examen de sécurité : signale les règles des groupes de sécurité qui autorisent un trafic entrant illimité (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 entrantes non utilisées migrées depuis votre environnement sur site et suggère de les supprimer, afin de ne pas reporter une exposition de sécurité qui n'a plus d'utilité. 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 ou ModelizeIt. Vous devez soumettre ces données de trafic en même temps que votre entrée 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, et signale une règle comme non utilisée lorsqu'aucun trafic entrant ne correspond à celle-ci. Sans données de trafic, AWS Transform ne peut pas déterminer quelles règles ne sont pas utilisées et ne suggère pas de suppression. AWS Transform supprime uniquement les règles d'entrée (entrantes) non utilisées. L'absence de trafic entrant observé est un signal fiable indiquant qu'une règle n'est pas utilisée. Passez en revue les suppressions suggérées avant de les appliquer pour vous assurer qu'elles sont conformes à vos politiques de sécurité.

  • Consolidation des VPC : identifie les VPC fragmentés qui semblent 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 des modifications. AWS Transform propose des compromis lorsqu'une recommandation affecte 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 basé sur du 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

Vos ressources réseau sont étiquetées pour le lancement et la réplication. Vous pouvez également ajouter des balises personnalisées et des balises MAP ( AWS Migration Acceleration Program).

Tags 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 basculement dans. AWS

Note

Vos VPC et sous-réseaux migrés n'incluent pas de connectivité Internet par défaut. Ils ne sont donc pas adaptés comme zones de transit pour la réplication.

Pour utiliser également 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'identifiant 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 tags : s'appliquent à un VPC spécifique et se répercutent automatiquement sur toutes ses ressources associées (sous-réseaux, groupes de sécurité, tables de routage).

Note

40 balises maximum par demande. Chaque étiquette nécessite une clé et une valeur. AWS les conventions de balisage s'appliquent.

AWS Transform applique ces balises lorsqu'elle génère l'infrastructure sous forme de modèles de code.

AWS Programme d’accélération des migrations

Si votre migration s'inscrit dans le cadre du programme d'accélération de la AWS migration (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, la balise est appliquée 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'identifiant 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 : migMPE_ID

Étape 8 : Déployez votre réseau

Après avoir marqué, 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 d'une 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 réseau LZA.

Note

Lorsque vous effectuez un déploiement 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 non-concordance entre les ID d'organisation.

Pour l'auto-déploiement, 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é endommagé ou altéré, générez et téléchargez une somme de contrôle, puis comparez-la à un hachage généré localement à l'aide openssl dgst -sha256 -binary <file.zip> | base64 de la commande.

Processus d'approbation des déploiements

Pour garantir que les modifications apportées au réseau sont conformes aux normes de sécurité et aux exigences architecturales de votre organisation, toutes les demandes de déploiement sont soumises à 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, celle-ci est automatiquement acheminée vers des approbateurs autorisés via l'onglet AWS Transformer les approbations. 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 n'ont lieu 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 tient à jour 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 Transformer les approbations.

  • Self-deployments: vous devez supprimer manuellement les ressources déployées via la console de AWS gestion ou l' AWS interface de ligne de commande.

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 sources 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 votre environnement réseau, procédez comme suit. Consultez la documentation du fournisseur pour obtenir les informations les plus récentes.

Fortinet FortiGate

  • La version du microprogramme doit être 7.0 ou ultérieure.

  • Vous avez besoin super_admin de super_admin_readonly nos 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 superadmin.

  • 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 avec tous les privilèges et d'une destination configurée pour le protocole SCP (Secure Copy Protocol), le protocole SFTP (SSH File Transfer Protocol) ou le protocole FTP (File Transfer Protocol).

  • É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 distante 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)