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.
# Fondation de la plateforme
Cette section se concentre sur l'évaluation de l'état de préparation de l'infrastructure sur site, la préparation de la zone AWS d'atterrissage ou la révision de la conception de la zone d'atterrissage existante, et l'identification des outils de migration nécessaires. Vous passez en revue les questions courantes relatives à l'infrastructure, aux opérations et à la sécurité que vous devez prendre en compte lors de la création d'une plate-forme. Vous documentez vos réponses et vos décisions sous forme de principes de migration. Vous disposez ainsi d'une plate-forme solide pour atteindre l'échelle et la rapidité requises pour les migrations de grande envergure.
Cette section comprend les rubriques suivantes:
+ [Considérations relatives à la zone d'atterrissage pour une migration de grande envergure](landing-zone.md)
+ [Considérations sur site pour une migration de grande envergure](on-premises.md)
+ [Documentez vos principes de migration](document.md)
# Considérations relatives à la zone d'atterrissage pour une migration de grande envergure
Une *zone d'atterrissage* est un AWS environnement bien conçu, évolutif et sécurisé. En établissant des normes pour la zone d'atterrissage, telles que la définition du nombre de comptes et la conception des sous-réseaux et des groupes de sécurité, vous établissez une base solide. Cette base vous permet d'activer, de provisionner et d'exploiter votre environnement pour garantir à la fois l'agilité commerciale et la gouvernance à grande échelle, tout en accélérant votre transition vers le cloud. Pour plus d'informations sur les zones d'atterrissage et les stratégies pour les créer, consultez la section [Configuration d'un AWS environnement multi-comptes sécurisé et évolutif](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/).
Outre les considérations commerciales, opérationnelles, de sécurité et de conformité standard pour votre stratégie de zone d'atterrissage, vous devez réfléchir à la manière de faciliter une migration de grande envergure. Vous devez concevoir la zone de destination pour prendre en charge les charges de travail existantes sur site pendant et après la migration, dans les cas où certaines charges de travail restent sur site. Ce guide fournit des considérations supplémentaires relatives à la zone d'atterrissage qui ont une incidence sur la vitesse de migration et le calendrier global de la migration.
Généralement, les zones d'atterrissage sont conçues et déployées pour prendre en charge les nouvelles charges de travail dans le AWS Cloud. Cela s'explique par le fait que les entreprises adoptent un grand nombre d'applications existantes AWS avant de prendre la décision de migrer. L'avantage de cette approche est que l'organisation acquiert des connaissances et des compétences précieuses AWS avant la migration importante, mais elle peut également entraîner des conflits entre les différentes parties prenantes. Certaines parties prenantes souhaiteront peut-être moderniser l'application pendant la migration afin de tirer parti des fonctionnalités natives du cloud. Cependant, l'objectif commun d'une migration de grande envergure est d'atteindre une vitesse de migration maximale et de faciliter la transition en faisant migrer autant d'applications que possible sans modifier la charge de travail. Vous modernisez ensuite ces applications une fois la migration terminée.
Certains facteurs clés de la zone d'atterrissage qui peuvent affecter votre projet de vaste programme de migration sont les suivants :
+ Disponibilité et gestion de la bande passante réseau
+ Stratégie de compte pour l'isolation de la charge de travail et la gestion des ressources
+ Contrôles administratifs et de sécurité pour les charges de travail migrées
Cette section passe en revue les questions relatives à l'infrastructure, aux opérations et à la sécurité que vous devez prendre en compte lors de la création de votre zone AWS d'atterrissage. Il contient également des recommandations sur la manière de concevoir et de déployer votre zone d'atterrissage pour soutenir un projet de migration de grande envergure. Au fur et à mesure que vous répondez aux questions de cette section, ces décisions deviennent des principes de migration, que vous documentez conformément aux instructions de la section [Documenter vos décisions en tant que grands principes de migration](document.md).
## Considérations relatives à l’infrastructure
| Y avez-vous pensé ? | Description | Actions |
| --- | --- | --- |
| Quelle quantité de données allez-vous migrer par jour et par semaine ? | La vitesse de migration souhaitée détermine le type de connexion réseau et les exigences de débit du réseau. Cela peut également affecter les critères de sélection de la planification des vagues. | Une fois l'évaluation du portefeuille terminée, déterminez la quantité totale de stockage nécessaire pour toutes les ressources migrées dans le cloud. Utilisez cette valeur pour calculer le temps nécessaire à la migration des données en utilisant la bande passante réseau actuelle. Vous devrez peut-être augmenter la bande passante pour respecter les délais de migration, ou vous devrez peut-être utiliser d'autres solutions, telles que AWS Snow Family des solutions. Dans les [modèles de playbook de base](samples/foundation-playbook-templates.zip), vous pouvez utiliser le *calculateur de réplication de données* (format Microsoft Excel) pour calculer la bande passante requise pour chaque vague de migration. |
| Quelle est la vitesse d'écriture moyenne des serveurs sources à chaque vague ? | La bande passante requise pour transférer les données répliquées est basée sur la vitesse d'écriture des serveurs sources participants. La quantité de bande passante requise pour la réplication des serveurs est la vitesse d'écriture moyenne de vos serveurs sources multipliée par le nombre de serveurs de la plus grande vague. | Lors de l'évaluation du portefeuille, vous devez déterminer le nombre moyen d'écritures de données effectuées par chaque serveur. Dans les [modèles de playbook de base](samples/foundation-playbook-templates.zip), vous pouvez utiliser le *calculateur de réplication de données* (format Microsoft Excel) pour comprendre la bande passante requise pour le trafic de migration. La bande passante requise pour le trafic de migration s'ajoute à la bande passante utilisée pour les activités commerciales normales. Une fois la migration terminée, vous n'avez plus besoin de bande passante supplémentaire pour prendre en charge les activités de migration. |
| Des activités réseau supplémentaires ou une infrastructure existante pourraient-elles limiter ou réduire la vitesse de réplication ? | Si la bande passante du réseau prend également en charge d'autres fonctions commerciales, ces activités peuvent réduire la quantité de bande passante disponible pour la réplication des serveurs pendant la migration. | Au début du cycle de vie du projet, évalue et calcule soigneusement la bande passante réseau requise pour soutenir toutes les activités commerciales. Tenez compte de la bande passante nécessaire aux activités commerciales normales, à la réplication des serveurs et aux nouvelles activités liées à la migration, telles que la synchronisation des partages de fichiers sur site avec les données stockées sur place. AWS Les fournisseurs peuvent avoir de longs délais pour augmenter la capacité du réseau, et il se peut que vous deviez mettre à niveau l'infrastructure sur site existante. Déterminez si des mises à niveau supplémentaires seraient nécessaires à la suite de la mise à niveau de l'infrastructure réseau. L'évaluation des besoins en bande passante au début du projet donne le temps d'apporter les modifications nécessaires. |
| Votre stratégie de AWS sous-réseau actuelle répond-elle aux exigences d'adressage IP pour la migration des charges de travail sur site ? | Le nombre de serveurs et les exigences d'isolation de la charge de travail dictent la stratégie de sous-réseau pour votre zone de landing zone. Les migrations de grande envergure peuvent nécessiter des sous-réseaux plus grands que ce à quoi vous vous attendiez. Lors d'une migration de grande envergure, vous regroupez les charges de travail dans des sous-réseaux de la même manière qu'elles sont configurées dans l'infrastructure sur site. Pour simplifier la migration, il est préférable de concevoir des sous-réseaux plus grands et plus plats dans un premier temps, puis, au cours de la modernisation, vous redessinez les sous-réseaux selon les besoins. | Lorsque l'évaluation du portefeuille dispose de suffisamment d'informations sur l'inventaire de l'infrastructure, évaluez la structure du réseau sur site et intégrez-la dès que possible dans la conception de la zone d'atterrissage. |
| Combien de serveurs prévoyez-vous de répliquer et de migrer en parallèle ? | L'ampleur de la vague de migration la plus importante influe sur les exigences du sous-réseau et les [quotas AWS de service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). | Passez en revue le plan de migration de haut niveau et utilisez-le pour concevoir votre sous-réseau. Par exemple, si vous envisagez de migrer 200 serveurs vers un sous-réseau, la plage de routage interdomaines sans classe (CIDR) de ce sous-réseau doit comporter suffisamment d'adresses IP pour prendre en charge le nombre cible de serveurs. Augmentez également le quota AWS de service pour chaque compte cible selon les besoins. |
| Avez-vous identifié les stratégies des groupes de sécurité pour vos ressources de migration ? | Les groupes de sécurité sont utilisés pour gérer le trafic entrant et sortant des AWS ressources. Il est important de concevoir les groupes de sécurité à un stade précoce afin de ne pas retarder la migration. | Dans votre manuel de hiérarchisation des applications, passez en revue les stratégies de migration, puis concevez les groupes de sécurité en fonction de ces stratégies de migration. Par exemple, si la stratégie de migration consiste à réhéberger la plupart des charges de travail, envisagez un groupe de sécurité générique temporaire qui prend en charge le transfert de migration au lieu de refactoriser le réseau et d'appliquer des groupes de sécurité spécifiques à l'application. |
| Des équilibreurs de charge sont-ils utilisés ? | Généralement, lors de la migration de serveurs dans un environnement doté d'équilibreurs de charge, vous devez évaluer la configuration de l'équilibreur de charge, puis le migrer. Les options de migration pour l'équilibreur de charge incluent l'utilisation d'Elastic Load Balancing (ELB) ou d'une solution basée sur une appliance partenaire. | L'évaluation des équilibreurs de charge doit commencer tôt dans la phase de découverte afin de prendre en compte toute configuration personnalisée. Dans la plupart des environnements, les configurations des équilibreurs de charge sont relativement standard, mais certains peuvent avoir une logique complexe qui détermine si vous pouvez migrer vers ELB ou vers une solution basée sur une appliance partenaire. |
| Certains serveurs doivent-ils conserver leur adresse IP source ? | Le moyen le plus sûr et le plus simple de migrer des serveurs vers le cloud consiste à attribuer de nouvelles adresses IP aux instances migrées. Dans certains cas, il se peut que vous deviez conserver la même adresse IP que le serveur source. Par exemple, une ancienne application peut avoir une adresse IP codée en dur que personne ne sait comment modifier. | La conservation des adresses IP sources influe sur la façon dont vous formez des groupes de déménagement lors de la planification des vagues. L'approche la plus courante consiste à migrer l'ensemble d'un sous-réseau vers AWS un seul groupe de déplacement, car cela simplifie le routage et la commutation au niveau du réseau. Voici les principales mesures à prendre pour conserver les adresses IP : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html) |
| Quel est le niveau de latence acceptable entre la source et AWS ? | Il est courant de démarrer la migration avec des liens VPN car ils peuvent être configurés rapidement, puis passer à une connexion directe établie à l'aide de AWS Direct Connect. Les liaisons VPN ont généralement une latence plus élevée et plus variable, ce qui affecte le débit de données et, plus important encore, les temps de réponse des applications. | Si vous utilisez un type de connexion à latence élevée ou variable, passez en revue les exigences de chaque application et planifiez les vagues de migration en conséquence. Prévoyez de placer les applications nécessitant des connexions à faible latence dans les vagues ultérieures, lorsque d'autres types de connexion seront disponibles. |
## Considérations relatives aux opérations
| Y avez-vous pensé ? | Description | Actions |
| --- | --- | --- |
| Avez-vous défini une stratégie de AWS compte pour votre zone de landing zone ? | AWS les meilleures pratiques pour un environnement bien conçu recommandent de séparer vos ressources et vos charges de travail sur plusieurs comptes. AWS Vous pouvez considérer les AWS comptes comme des conteneurs de ressources isolés : ils permettent de catégoriser la charge de travail et de réduire l'impact en cas de sinistre. | Dans votre manuel de hiérarchisation des applications, passez en revue les stratégies de migration que vous avez sélectionnées et utilisez-les pour déterminer la stratégie de votre compte. Par exemple, si vous souhaitez migrer le plus rapidement possible et que le réhébergement est la stratégie de migration la plus courante, il est plus facile de gérer moins de comptes. Toutefois, si vos stratégies de migration nécessitent la modernisation des applications et que vous devez séparer les unités commerciales pour des raisons de conformité, vous devez inclure un ou plusieurs comptes pour chaque unité commerciale dans votre stratégie de compte. |
| Devez-vous changer d'outil de surveillance pendant la migration ? Dans l'affirmative, est-ce que cela fait partie du processus de migration ou est-ce que cela se produit avant ou après la migration ? | Les outils de surveillance sont essentiels pour les opérations dans le cloud. Vos outils existants peuvent ne pas fonctionner dans le cloud pour des raisons de compatibilité ou de licence. Dans le cadre de la conception, vous devez choisir les outils de surveillance à utiliser pour la charge de travail du AWS Cloud. | Sélectionnez un outil de surveillance avant de démarrer la migration. Assurez-vous que l'équipe de migration intègre des instructions pour configurer la surveillance dans les modèles de migration. Nous vous recommandons de créer un script d'automatisation qui remplace ou réutilise les outils de surveillance, selon les besoins. |
| Avez-vous identifié les propriétaires des applications et sont-ils au courant des modifications qui doivent être apportées à l'application pour qu'elle fonctionne correctement dans le cloud ? | Une migration à grande échelle est une transformation plutôt qu'un simple projet d'infrastructure. Incluez rapidement les propriétaires des applications afin de soutenir la migration. Par exemple, les propriétaires de l'application valident le plan de vague, créent des plans de test et participent à la transition. | Travaillez avec un bureau de gestion de projet et l'équipe Cloud Enablement Engine pour vous aligner sur les chefs d'équipe des applications et vous assurer que la communication est claire entre toutes les équipes chargées des applications. Pour plus d'informations sur la communication et la transparence des projets, consultez le [manuel de gouvernance de projet pour les AWS grandes migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/). |
| Avez-vous sélectionné une solution de sauvegarde et de restauration, et celle-ci est-elle compatible avec les charges de travail migrées ? | Les outils de sauvegarde et de restauration sont essentiels pour les opérations dans le cloud. Vos outils existants peuvent ne pas fonctionner dans le cloud pour des raisons de compatibilité ou de licence. Dans le cadre de la conception, vous devez choisir les outils de sauvegarde et de restauration à utiliser pour la charge de travail du AWS Cloud. | Sélectionnez les outils de sauvegarde et de restauration avant de démarrer la migration. Assurez-vous que l'équipe de migration intègre les instructions de configuration de la sauvegarde et de la restauration dans les modèles de migration. Nous vous recommandons de créer un script d'automatisation qui remplace ou réutilise les outils de sauvegarde et de restauration, selon les besoins. |
| Avez-vous identifié tous les services partagés et les avez-vous déployés dans la zone de landing zone ? | Les *services partagés* sont des services qui prennent en charge plusieurs applications, telles que le courrier électronique, Active Directory ou les environnements de base de données partagés. Vous devez généralement déployer des services partagés dans le cloud avant la migration afin que les applications migrées fonctionnent comme prévu. | Planifiez une analyse approfondie avec l'équipe d'infrastructure et les chefs d'équipe d'application avant de terminer la conception de la zone d'atterrissage. Consultez et confirmez la liste des services partagés que vous devez déployer dans le cloud avant de commencer la migration. Les services partagés les plus courants sont Active Directory, les périphériques réseau, le système de noms de domaine (DNS) et les logiciels d'infrastructure. |
| Avez-vous revu les quotas AWS de service pour votre AWS région et votre compte cibles ? | Chaque AWS service est soumis à un quota de service. Certains de ces quotas peuvent être augmentés. Il est important de revoir les quotas avant le passage aux quotas. Si les ressources disponibles sont insuffisantes, le transfert peut échouer. | Passez en revue le plan de migration. Pour tout compte cible nécessitant un quota de service accru, demandez une augmentation. Pour plus d'informations et d'instructions, consultez la section [Quotas AWS de service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). |
| Avez-vous besoin de mettre à jour votre plan AWS Support ? | AWS Le plan d'assistance aux entreprises offre une assistance téléphonique 24 heures sur 24, 7 jours sur 7 et des temps de réponse plus rapides que les autres plans. La période de transition étant généralement très courte, l'accès à un ingénieur expérimenté pour aider à résoudre les problèmes de transition peut être essentiel au succès d'une migration de grande envergure. | Contactez l'équipe chargée de votre AWS compte pour discuter des différentes options de support et sélectionner le plan de support adapté à votre projet de migration de grande envergure. |
| Avez-vous informé votre responsable de compte AWS technique (TAM) de votre plan de migration de grande envergure ? | L'équipe d'assistance AWS d'Enterprise On-Ramp désigne un pool de responsables de comptes techniques (TAMs) qui coordonnent l'accès aux programmes proactifs, aux programmes préventifs et aux experts en la AWS matière. TAMs Vous pouvez planifier la disponibilité des ressources d'assistance selon vos besoins. | Informez votre responsable de compte AWS technique de votre prochain grand projet de migration et faites-lui part de votre plan de migration. Vous TAMs veillerez à ce que les ressources d' AWS assistance soient disponibles en cas de besoin. Par exemple, vous TAMs pouvez faire appel à un ingénieur de support pendant le transfert, qui pourra vous aider à atténuer les problèmes techniques et à rationaliser le transfert. |
## Considérations sur la sécurité
| Y avez-vous pensé ? | Description | Actions |
| --- | --- | --- |
| Avez-vous identifié les rôles et les politiques Gestion des identités et des accès AWS (IAM) pour la gestion des accès ? | Gérez l'identité et l'accès de tous les membres de votre grand projet de migration. En associant des rôles IAM aux ressources migrées et en définissant des politiques d'accès, vous contrôlez qui peut accéder aux ressources migrées dans le cloud. | Collaborez avec l'équipe de migration pour identifier les rôles et les responsabilités. Déterminez quels rôles peuvent accéder à quel AWS compte et identifiez le niveau d'accès de chaque rôle. Travaillez avec les équipes de sécurité pour vérifier que les rôles IAM sont corrects pour chaque AWS ressource cible. |
| Existe-t-il des exigences de conformité pour vos charges de travail ? | Les charges de travail peuvent être soumises à des exigences de conformité différentes, telles que la loi HIPAA (Health Insurance Portability and Accountability Act) ou la norme de sécurité des données du secteur des cartes de paiement (PCI DSS). Vous devez identifier ces exigences avant la migration et planifier la manière de les satisfaire. | Travaillez avec l'équipe de conformité et l'équipe du portefeuille pour identifier les exigences de conformité pour chaque application et concevez votre AWS compte cible en conséquence. Par exemple, vous devrez peut-être migrer certaines charges de travail vers AWS GovCloud (US) ou vers une AWS région spécifique. Nous vous recommandons de documenter les exigences de conformité pour chaque application afin de pouvoir utiliser ces informations ultérieurement dans le processus de priorisation des applications et de planification des vagues. |
| Votre équipe de sécurité doit-elle examiner et approuver les outils ou services que vous prévoyez d'utiliser pendant la migration ? | Un projet de migration de grande envergure AWS Cloud utilise de nombreux services, tels que AWS Application Migration Service, AWS Database Migration Service (AWS DMS) AWS DataSync, et des outils de découverte de portefeuille (tels que Flexera One). Certaines organisations exigent que tous les nouveaux outils et services soient approuvés avant leur utilisation. | Collaborez avec l'équipe de migration pour identifier tous les outils, services et applications que vous comptez utiliser dans le cadre de la migration. Travaillez avec l'équipe de sécurité pour revoir les politiques de l'entreprise et approuvez ces outils en conséquence avant le début de la migration. |
# Considérations sur site pour une migration de grande envergure
L'infrastructure sur site qui prend en charge vos opérations commerciales doit également être préparée à la migration de grande envergure. En préparant l'infrastructure actuelle, vous pouvez contribuer à réduire l'impact de la migration à grande échelle sur les opérations commerciales et les utilisateurs des applications.
Cette section passe en revue les questions relatives à l'infrastructure, aux opérations et à la sécurité que vous devez prendre en compte lors de la préparation de votre infrastructure sur site pour une migration de grande envergure. Au fur et à mesure que vous répondez aux questions de cette section, ces décisions deviennent des *principes de migration*, que vous documentez conformément aux instructions de la section [Documenter vos décisions en tant que grands principes de migration](document.md).
## Considérations relatives à l’infrastructure
| Y avez-vous pensé ? | Description | Actions |
| --- | --- | --- |
| Avez-vous conçu le DNS et les routeurs sur site pour prendre en charge le trafic à destination et en provenance des comptes cibles ? AWS | En raison du grand nombre de serveurs et de AWS comptes cibles, il est important de vérifier que les différents composants réseau sont correctement configurés afin de prendre en charge les stratégies de migration et de mise à l'échelle. | Passez en revue la conception des tables de routage et assurez-vous qu'il existe des itinéraires corrects entre les AWS comptes et les centres de données locaux. Assurez-vous également que le serveur DNS est capable de prendre en charge les requêtes DNS provenant à la fois des serveurs locaux et AWS des ressources. |
| Comment l'équipe de migration accèdera-t-elle à la fois aux locaux et aux AWS environnements ? | L'équipe de migration doit accéder aux serveurs source et cible pour effectuer des activités de migration, telles que l'installation d'un agent de réplication sur un serveur source ou la désinstallation d'anciens logiciels sur un serveur cible. | Passez en revue les mécanismes d'authentification et d'autorisation existants et élaborez une stratégie pour accorder l'accès. Vous pouvez utiliser un groupe Active Directory, un rôle IAM et une fédération SAML 2.0 (Security Assertion Markup Language 2.0) pour autoriser l'authentification unique au compte. AWS Nous vous recommandons de créer un utilisateur administrateur local en cas de problème d'authentification avec Active Directory. |
| Existe-t-il des points de congestion connus dans la configuration réseau actuelle susceptibles de ralentir le débit de données pendant la migration ? | Une migration de grande envergure nécessite beaucoup de bande passante pour répliquer les données du centre de données sur site vers le cloud. Comprendre les points de congestion ou les limites existants vous aide à mieux planifier la migration. | Passez en revue la configuration réseau avec l'équipe réseau afin de mieux comprendre le chemin réseau entre les machines source et les AWS comptes cibles. Identifiez les points de congestion potentiels, tels qu'une connexion partagée entre les charges de travail de migration et de production. |
## Considérations relatives aux opérations
| Y avez-vous pensé ? | Description | Actions |
| --- | --- | --- |
| Avez-vous des jours bloqués planifiés, également connus sous le nom de *gel des modifications*, qui pourraient avoir un impact sur la migration ? | Un gel des modifications pendant la migration peut affecter des ressources et du temps essentiels à un projet de migration en cours. | Passez en revue le processus de gestion des modifications avec l'équipe des opérations et tenez compte des jours bloqués lorsque vous planifiez des périodes de transition. |
| Avez-vous réservé des jours de changement pour la migration ? | Les processus de gestion du changement peuvent être complexes, et certaines organisations n'autorisent les modifications que dans certaines fenêtres de maintenance. | Selon votre processus de gestion du changement, planifiez les changements au moins cinq vagues à l'avance. Cela permet d'éviter les retards |
| Tous les serveurs concernés par la migration ont-ils récemment été redémarrés ? | Les modifications du système ou les correctifs désinstallés peuvent entraîner des problèmes lors de la migration, ce qui peut nécessiter de longues périodes de transition ou le redémarrage du serveur. La meilleure pratique consiste à vérifier que le serveur a été récemment redémarré du côté cible avant de procéder à la migration. | Vérifiez les dates des derniers redémarrages du serveur. Si aucun serveur n'a été redémarré au cours des 90 derniers jours, planifiez un redémarrage avant de migrer le serveur. |
| Comment fonctionne le plan de reprise après sinistre et de continuité des activités aujourd'hui, et cela a-t-il été pris en compte dans la conception de la zone d'atterrissage ? | Les plans de reprise après sinistre et de continuité des activités sont des éléments essentiels pour atteindre les objectifs de temps de restauration (RTO) et de point de reprise (RPO) de l'application. Vous devez vous assurer que ces plans fonctionnent à la fois pour votre environnement sur site et pour vos AWS charges de travail pendant la période de transition. | Passez en revue les plans de reprise après sinistre et de continuité des activités existants et assurez-vous qu'ils fonctionnent pour votre AWS compte cible. Si ce n'est pas le cas, concevez de nouveaux plans avant de transférer la charge de travail vers le AWS Cloud. |
## Considérations sur la sécurité
| Y avez-vous pensé ? | Description | Actions |
| --- | --- | --- |
| Avez-vous créé des règles de pare-feu pour prendre en charge la migration à grande échelle ? | Selon les processus de votre organisation, le traitement d'une demande de modification des configurations de pare-feu peut prendre beaucoup de temps. | Passez en revue le processus de changement de pare-feu existant avec l'équipe de sécurité et concevez une stratégie pour les modifications importantes du pare-feu de migration en conséquence. Vous devrez peut-être concevoir un processus personnalisé pour le grand projet de migration, ou vous devrez peut-être soumettre des modifications au début du projet. Il est recommandé d'envisager d'utiliser un cloud privé AWS virtuel (VPC) comme extension de votre centre de données et d'éviter de créer des règles de pare-feu trop complexes, qui pourraient retarder considérablement une migration de grande envergure. |
| Avez-vous configuré Active Directory dans l' AWS environnement ? | Active Directory est utilisé pour l'authentification et l'autorisation. Vous devez vous assurer que les charges de travail du compte cible peuvent se connecter au contrôleur de domaine à des fins d'authentification et d'autorisation. Vous pouvez soit ajouter un nouveau contrôleur de domaine dans le VPC cible, soit autoriser la AWS charge de travail à se connecter aux contrôleurs de domaine locaux. | Passez en revue la conception d'Active Directory avec vos équipes chargées de la sécurité et de l'infrastructure. Assurez-vous que le AWS compte cible est connecté au contrôleur de domaine approprié. Assurez-vous que les blocs CIDR du AWS sous-réseau cible se trouvent sur les sites Active Directory appropriés afin que les charges de travail puissent se connecter aux contrôleurs de domaine les plus proches. AWS |
| Avez-vous identifié des connexions tierces et des interdépendances entre applications ? | Les connexions tierces et les interdépendances des applications nécessitent que vous modifiiez la règle de pare-feu, la liste de contrôle d'accès au réseau et le groupe de sécurité. | Au cours de la session d'analyse approfondie avec les propriétaires de l'application, passez en revue les dépendances externes de chaque application. Soumettez une demande de modification des règles de pare-feu et de la liste de contrôle d'accès au réseau et modifiez les groupes de sécurité en conséquence, en fonction des exigences de dépendance des tiers. |
| Votre environnement sur site dispose-t-il d'outils de sécurité supplémentaires qui contrôlent l'accès et les processus exécutés sur les systèmes, par exemple ? CyberArk | Vous devrez peut-être évaluer et mettre à jour ces outils de sécurité afin de permettre aux outils de migration de fonctionner dans la zone de AWS landing zone. | Passez en revue la politique d'accès de votre environnement source. Si un outil de sécurité est utilisé dans la politique d'accès, vérifiez que l'outil fonctionne dans les environnements source et cible AWS Cloud, puis assurez-vous que l'équipe de migration a accès à la fois aux environnements source et cible. Si des modifications sont nécessaires, ajoutez ces étapes à vos livrets de migration. |
# Documentez vos principes de migration
Après avoir examiné la zone d'atterrissage et les considérations sur site, vous devez documenter vos réponses et vos décisions. Ils deviennent les principes de migration qui guident le reste du projet.
Procédez comme suit :
1. Dans les [modèles de playbook de base](samples/foundation-playbook-templates.zip), ouvrez le *modèle de principes de migration* (format Microsoft Word).
1. Passez en revue les considérations relatives à l'infrastructure, aux opérations et à la sécurité dans les sections de ce guide [relatives à la zone d'atterrissage pour une migration](landing-zone.md) [de grande envergure et aux considérations sur site pour une migration](on-premises.md) de grande envergure, et discutez des questions avec les équipes recommandées.
1. Documentez les décisions relatives à l'infrastructure, aux opérations et à la sécurité dans votre document sur les principes de migration. Pour des exemples de la façon d'enregistrer ces décisions, consultez le tableau suivant.
1. Selon les besoins de votre cas d'utilisation, ajoutez de nouvelles catégories, de nouveaux éléments et de nouveaux principes. Par exemple, vous souhaiterez peut-être enregistrer les principes de migration pour l'évaluation du portefeuille ou les décisions de gestion de projet.
Voici un exemple de la façon dont vous pouvez consigner vos décisions relatives à certaines des questions de ce guide.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)