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.
Construire une zone d'atterrissage
AWS Transform vous guide tout au long de la conception et du déploiement d'une zone d' AWS atterrissage dans le cadre de votre projet de migration. Une zone de destination est un AWS environnement multi-comptes qui sert de base à vos charges de travail. Les limites organisationnelles, les contrôles de gouvernance et la structure des comptes sont en place avant l'arrivée des charges de travail. AWS Transform analyse votre inventaire de migration et vos exigences commerciales pour recommander une unité organisationnelle (UO) et une structure de compte, appliquer les politiques de contrôle des services (SCP) recommandées et générer le and/or déploiement de l'infrastructure sous forme de code (iAc).
L'agent de zone d'atterrissage vous guide à travers deux phases :
-
Configuration de base — Établissez la structure de base de la zone d'atterrissage : AWS Control Tower, unités d'organisation de base et comptes principaux.
-
Conception de comptes de charge de travail — Concevez et créez des unités d'organisation et des comptes de charge de travail en fonction de vos vagues de migration, de vos unités commerciales et des exigences de séparation des environnements.
AWS Transform prend en charge à la fois les environnements nouveaux (aucune zone d'atterrissage existante) et les environnements industriels (unités d'organisation existantes et comptes déjà déployés). Dans les scénarios de friche industrielle, AWS Transform détecte la structure organisationnelle existante et recommande uniquement les modifications nécessaires pour combler les lacunes par rapport aux AWS meilleures pratiques.
Configuration du connecteur
L'agent de zone d'atterrissage nécessite un Compte AWS connecteur cible pour provisionner les ressources dans le compte de gestion de votre organisation. Le connecteur est autorisé à :
-
Configuration de la AWS Control Tower
-
Configuration des politiques de contrôle des services (SCP)
Lorsque vous approuvez la demande de connecteur, vous accordez des autorisations de AWS transformation pour :
-
Fournir et gérer l'infrastructure de la zone d'atterrissage dans la cible Compte AWS et dans la région. Cela inclut les autorisations pour les éléments suivants, limitées aux ressources étiquetées avec
CreatedBy:AWSTransformet par le casATWorkspace:{workspace-id}échéant :-
Opérations sur les compartiments S3 (création, lecture, écriture, suppression) pour les compartiments commençant par
transform-vmware-landing-zone- -
CloudFormation déploiements de piles et gestion des ensembles de modifications pour les piles de zones d'atterrissage
-
AWS Opérations de la Control Tower (gestion des zones d'atterrissage, activation des lignes de base et des contrôles)
-
AWS Gestion des organisations (création et gestion d'unités organisationnelles, création de comptes et transfert de comptes)
-
Gestion de la politique de contrôle des services (SCP) via AWS Control Tower
-
AWS Service Catalog : provisionnement et gestion des artefacts
-
Lorsque vous créez le connecteur, vous spécifiez une cible Région AWS. Cette région doit être la même que celle de votre Control Tower d'origine. Pour plus d'informations sur les régions de Control Tower, consultez How Régions AWS work with AWS Control Tower.
Au début de la configuration de la zone d'atterrissage, AWS Transform récupère la configuration de votre connecteur et présente l'ID du compte de gestion de AWS l'organisation et la région cible pour confirmation. Pour de plus amples informations, veuillez consulter AWS Connecteurs Transform.
Important
Dépendance de la région du centre d'identité IAM — AWS Transform nécessite AWS IAM Identity Center (IAM Identity Center), ce qui signifie que la région de votre connecteur doit correspondre à la fois à la région d'origine de votre AWS Control Tower et à la région de votre centre d'identité IAM. Si IAM Identity Center est déjà configuré dans votre organisation, l'initialisation de AWS Control Tower échouera si le connecteur cible une autre région. Pour plus d'informations, consultez la section Considérations pour les clients d'IAM Identity Center dans le guide de l'utilisateur AWS de Control Tower.
Configuration de la fondation
La phase de configuration des fondations établit l'infrastructure de base de la zone d'atterrissage à l'aide AWS de Control Tower. Lorsque AWS Control Tower met en place une zone de landing zone, elle fournit automatiquement un ensemble de ressources gérées dans votre compte de gestion qui constituent la base de la gouvernance de AWS l'ensemble de votre organisation :
-
Root : le parent de niveau supérieur qui contient toutes les unités d'organisation de votre zone de landing zone.
-
OU de sécurité : créée automatiquement par Control Tower. Contient deux comptes partagés : le compte Log Archive (journalisation centralisée et immuable pour toutes les activités d' AWS API et les modifications des ressources au sein de votre organisation) et le compte Audit (accès en lecture seule à tous les comptes à des fins de vérification de la sécurité et de la conformité). Ces comptes ne peuvent pas être renommés ou remplacés après la configuration initiale.
-
Contrôles obligatoires (garde-corps) — Control Tower applique automatiquement des contrôles préventifs et de détection au sein de votre organisation afin de faire appliquer les politiques de gouvernance de base. Ils ne peuvent pas être désactivés.
-
Répertoire IAM Identity Center — Control Tower crée un annuaire cloud natif avec des groupes préconfigurés et un accès par authentification unique pour les utilisateurs de votre zone de landing zone. Pour plus d'informations, consultez AWS IAM Identity Center.
Control Tower les utilise CloudFormation StackSetspour déployer et gérer ces ressources de manière cohérente sur tous les comptes et régions de votre organisation. Vous ne devez pas modifier ou supprimer les ressources gérées par Control Tower en dehors des méthodes prises en charge, car cela pourrait faire passer votre zone d'atterrissage à un état inconnu.
Convention relative au courrier électronique du compte
AWS nécessite une adresse e-mail unique pour chaque compte. Ces e-mails reçoivent des notifications importantes pour le compte. AWS Transform utilise l'adressage plus pour générer des e-mails de compte uniques à partir d'une seule boîte aux lettres.
Format : prefix+account-name@domain
Vous fournissez un préfixe (par exempleaws-admin) et un domaine (par exemple,acme.com), et AWS Transform obtient automatiquement tous les e-mails du compte. Par exemple :
-
Compte d'audit :
aws-admin+audit@acme.com -
Compte Log Archive :
aws-admin+log-archive@acme.com -
Compte Sandbox :
aws-admin+sandbox@acme.com
Dans les scénarios de friche industrielle, AWS Transform inspecte les e-mails des comptes existants pour en déduire la convention d'adressage positif déjà utilisée et propose de continuer sur la même lancée.
Structure de fondation recommandée
Sur la base des AWS meilleures pratiques, AWS Transform recommande la structure d'UO de base suivante. Vous pouvez le personnaliser avant de le créer.
| UO | Objectif | Comptes |
|---|---|---|
| Sécurité | Journalisation et surveillance centralisées des audits. L'isolation de ces services dans des comptes dédiés est conçue pour séparer votre piste d'audit des équipes chargées de la charge de travail. | Audit, archivage des journaux |
| Infrastructures | Réseau partagé (Transit Gateway, VPN), DNS et services communs. Il est recommandé de les centraliser afin de réduire les doublons et de donner à votre équipe réseau un seul endroit pour gérer la connectivité. | Aucun (créé vide) |
| Sandbox | Expérimentation pour les développeurs avec des limites de dépenses et un accès restreint. Recommandé pour donner aux développeurs un espace leur permettant d'expérimenter sans risquer les ressources de production. | Sandbox |
| Charges de travail | Contient des sous-unités Non-Production de production et éventuellement des sous-unités réglementées. Les comptes de charge de travail sont conçus dans la phase suivante en fonction de vos exigences de migration. | Aucun (créé vide) |
Note
L'unité d'organisation de sécurité avec les comptes Audit et Log Archive est créée dans le cadre de la configuration de base de Control Tower. Les unités d'organisation relatives à l'infrastructure, au bac à sable et aux charges de travail sont créées séparément une fois que vous avez confirmé la structure.
Dans les scénarios de friche industrielle, AWS Transform compare votre base existante à cette structure recommandée et ne signale que les lacunes. Par exemple : « Votre fondation possède des unités d'organisation relatives à la sécurité et à l'infrastructure, mais aucune unité d'organisation Sandbox. »
Politiques de contrôle des services
Les SCP sont des barrières d'autorisation au niveau de l'organisation qui fixent les autorisations maximales pour tous les comptes de votre organisation. AWS Ils n'accordent pas d'accès, ils définissent plutôt des limites que personne ne peut dépasser dans le compte, même les administrateurs du compte.
Dans le cadre du déploiement de la Control Tower, les glissières de sécurité de base sont appliquées automatiquement. AWS Transform recommande également des SCP supplémentaires conçus pour renforcer la posture de votre organisation. Elles sont basées sur les AWS meilleures pratiques pour une zone d'atterrissage minimale viable.
Les SCP peuvent être appliqués aux unités d'organisation d'infrastructure, de sandbox et de charges de travail. L'UO de sécurité est gérée par Control Tower et ne peut pas être ciblée par les SCP via cet outil.
Important
L'UO de sécurité est une UO de base gérée par Control Tower. Vous ne pouvez pas y ajouter de comptes, de SCP ou de ressources via l'agent de zone d'atterrissage.
Dans les scénarios de friche industrielle, AWS Transform vérifie quels SCP sont déjà appliqués et ne recommande que ceux qui pourraient combler les lacunes.
Déploiement de Foundation
Une fois la conception de base terminée, vous choisissez le mode de déploiement :
-
Déployez pour moi — AWS Transform déploie les unités d'organisation, les comptes et les SCP de base au sein de votre AWS organisation.
-
Je vais le déployer moi-même. AWS Transform génère des artefacts d'infrastructure en tant que code (IaC) à télécharger dans le format de votre choix (voirFormats iAc).
-
Concevez d'abord les comptes de charge de travail : ignorez le déploiement et passez à la phase de conception des comptes de charge de travail. Vous pourrez tout déployer ensemble ultérieurement.
Initialisation de la Control Tower
Si AWS Transform détecte que AWS Control Tower n'est pas encore initialisée dans votre organisation, il fournit à l'utilisateur un lien vers la page de console AWS Transform. La génération de l'opération dans le lien créera une CloudFormation pile pour démarrer Control Tower. Le processus créera cette pile dans la CloudFormation console pour votre région cible. Une fois la création de la pile terminée, AWS Transform poursuit le déploiement.
Conception du compte de charge de travail
Au cours de la phase de conception du compte de charge de travail, AWS Transform conçoit l'unité d'organisation et la structure de compte pour les charges de travail de vos applications en fonction de votre inventaire de migration, de vos exigences commerciales et de vos préférences en matière de séparation des environnements.
Contexte de planification de la migration
AWS Transform extrait les données de votre phase de planification de migration, notamment les plans de vagues, les mappages serveur-application et le contexte partagé. Si les données de planification de la migration sont disponibles, AWS Transform affiche un résumé et vous demande de le confirmer ou de le modifier. Si aucune donnée de planification de migration n'est disponible, AWS Transform pose directement des questions de découverte.
Découverte
AWS Transform pose des questions pour comprendre vos exigences en matière de charge de travail. Vous pouvez ignorer n'importe quelle question. Les sujets suivants sont notamment abordés :
-
Nombre d'unités commerciales ou d'équipes utilisant AWS
-
L'industrie et tous les cadres applicables (HIPAA, SOC2 PCI-DSS, FedRAMP)
-
Si les charges de travail traitent des données sensibles (PII, PHI, financières)
-
Préférences de séparation des environnements (dev/test/staging/prod sous forme de comptes séparés ou partagés)
-
Exigences d'isolation des charges de travail
-
Les applications métiers et leurs objectifs
-
Regroupement de serveurs en applications
-
Besoins en matière de suivi et d'allocation des coûts (par unité commerciale, projet, environnement)
-
Croissance prévue au cours des 12 à 24 prochains mois
-
Préférence en matière de stratégie de compte (application unique par compte, groupée ou basée sur l'environnement)
Structure de charge de travail proposée
Sur la base de vos réponses et des données de planification de la migration, AWS Transform propose une structure d'unité d'organisation et de compte dans le cadre de l'unité d'organisation Workloads. La proposition inclut le raisonnement qui sous-tend chaque décision de conception.
AWS Transform suit les principes de conception suivants :
-
Lors d'une vague de migration, tous les serveurs sont connectés au même compte ; les vagues ne peuvent pas être réparties sur plusieurs comptes. Il s'agit d'une limite de réhébergement lors de l'exécution des vagues.
-
Si vous demandez des environnements isolés, AWS Transform crée Workloads/Production des Workloads/Non-Production sous-OU.
-
Si les frameworks applicables sont identifiés, AWS Transform crée Workloads/Regulated des Workloads/Standard sous-OU.
-
Si plusieurs unités commerciales nécessitent une gouvernance différente, AWS Transform crée des unités opérationnelles spécifiques à chaque unité commerciale sous Workloads.
-
Les applications contenant des données critiques ou sensibles ne disposent que d'une seule application par compte. Dans ce cas, il vous sera peut-être demandé de répéter votre plan de vague.
-
Les applications étroitement couplées avec des dépendances partagées sont regroupées dans un seul compte.
Chaque compte proposé inclut : le nom, l'objectif, l'unité d'organisation cible et l'unité commerciale. AWS Transform indique la convention de dénomination utilisée (par exemple,<business-unit>-<environment>-<workload>).
Vous pouvez revoir et modifier la structure proposée avant que AWS Transform n'applique les modifications. Après avoir postulé, vous pouvez itérer, en apportant des modifications supplémentaires jusqu'à ce que vous soyez satisfait.
Configuration SCP de la charge de travail
Une fois la structure de charge de travail créée, AWS Transform présente les SCP disponibles et vous demande si vous souhaitez en appliquer une à vos unités d'organisation de charge de travail. Vous sélectionnez les SCP à appliquer et à quelles UO. AWS Transform applique les SCP et affiche l'arborescence organisationnelle mise à jour avec un tableau récapitulatif des SCP.
Déploiement des charges
Une fois la conception de la charge de travail terminée, vous choisissez le mode de déploiement :
-
Déployez pour moi — AWS Transform déploie les unités d'organisation, les comptes et les SCP de charge de travail au sein de votre AWS organisation.
-
Je vais le déployer moi-même. AWS Transform génère des artefacts IaC à télécharger dans le format de votre choix (voirFormats iAc).
Formats iAc
Lorsque vous choisissez l'autodéploiement, AWS Transform génère des artefacts d'infrastructure sous forme de code dans les formats suivants :
-
Cloud Development Kit AWS (AWS CDK)— TypeScript projet de déploiement d'infrastructures programmatiques.
-
HashiCorp Terraform — Génère des modèles HashiCorp de langage de configuration (HCL) pour gérer les ressources de la zone d'atterrissage.
-
Landing Zone Accelerator (LZA) — Fichiers de configuration YAML basés sur la version 1.1.0 de LZA Universal Configuration. Ces modèles adaptés aux entreprises fonctionnent avec le Landing Zone Accelerator AWS pour créer des environnements AWS multi-comptes. Les fichiers générés incluent des paramètres préconfigurés de gouvernance, de structure organisationnelle et de mise en réseau conformes aux AWS meilleures pratiques. Pour en savoir plus, consultez la section Configuration universelle du LZA.
Note
Lors du 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 divergence entre les identifiants Organizations utilisés dans AWS Transform et LZA. Pour savoir comment configurer votre installation LZA à l'aide de Organizations, consultez la section Installation basée sur AWS des organisations.
Après avoir sélectionné un format, AWS Transform génère les artefacts et les rend disponibles au téléchargement.
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 en utilisant :
openssl dgst -sha256 -binary <file.zip> | base64
Processus d'approbation des déploiements
Les demandes de déploiement de zones d'atterrissage nécessitent une approbation explicite avant d'être exécutées. 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 examinent les CloudFormation modèles et les configurations de zone d'atterrissage. Seuls les utilisateurs ayant le rôle d'administrateur dans AWS Transform peuvent approuver les demandes de déploiement. 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. Le système suit toutes les décisions d'approbation à des fins d'audit et conserve l'historique des déploiements.
Étiqueter les ressources de la zone de landing zone
AWS Transform étiquette automatiquement toutes les ressources générées "CreatedBy": "AWSTransform" avec des identifiants de définition et d'exécution à des fins de suivi.
Tags automatiques
Toutes les ressources de la zone d'atterrissage reçoivent les balises suivantes :
-
CreatedBy— AWS Transform -
ATWorkspace— Identifiant d'espace de travail
Note
Si votre migration fait partie du AWS Migration Acceleration Program (MAP 2.0), vous pouvez inclure la balise MAP requise : Key : map-migrated Value : migMPE_ID (où MPE_ID est l'identifiant d'évaluation de votre portefeuille de migration). La balise MAP est demandée lors de la phase de configuration du connecteur. AWS Transform applique ces balises lors du déploiement de la zone d'atterrissage.
Inversion des modifications
Seuls les éléments non déployés peuvent être retirés. Une fois qu'une unité d'organisation ou un compte est déployé, il ne peut pas être supprimé via l'agent de zone d'atterrissage.
Lorsque vous supprimez des éléments, l'ordre est important : vous devez retirer les enfants avant les parents :
-
Supprimez d'abord les comptes (par e-mail).
-
Supprimez les SCP des unités d'organisation.
-
Supprimer les unités d'organisation secondaires : une unité d'organisation ne peut pas être supprimée si elle possède toujours des comptes ou des unités d'organisation imbriquées.
Ressources connexes
