View a markdown version of this page

Construire une zone d'atterrissage - AWS Transformation

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 dans la conception et le déploiement d'une zone AWS d'atterrissage dans le cadre de votre projet de migration. Une zone d'accueil 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 de toute charge de travail. AWS Transform analyse votre inventaire de migration et vos exigences commerciales pour recommander une unité organisationnelle (OU) 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). Ce qui nécessite généralement des semaines de planification et de configuration manuelles, peut être réalisé par AWS Transform en une seule conversation.

L'agent de zone d'atterrissage automatise deux phases :

  • Configuration de base — Établissez la structure de base de la zone d'atterrissage : tour de AWS contrôle, unités d'organisation fondamentales et comptes principaux.

  • Conception des 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 de vos exigences en matière de séparation des environnements.

AWS Transform prend en charge à la fois les environnements entièrement nouveaux (aucune zone d'atterrissage existante) et les environnements désaffectés (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 existante de votre organisation et recommande uniquement les modifications nécessaires pour combler les lacunes par rapport aux AWS meilleures pratiques, sans que vous ayez à repartir de zéro ou à effectuer une analyse manuelle des lacunes.

Configuration du connecteur

Avant que l'agent puisse provisionner des ressources, vous devez le connecter au compte de gestion de votre organisation. L'agent de zone d'atterrissage a besoin d'un Compte AWS connecteur cible autorisé à :

Lorsque vous approuvez la demande de connecteur, vous accordez des autorisations AWS Transform pour :

  • Fournir et gérer l'infrastructure de la zone d'atterrissage dans la cible Compte AWS et la région. Cela inclut les autorisations pour les éléments suivants, limitées aux ressources étiquetées avec CreatedBy:AWSTransform et par, le cas ATWorkspace:{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 tour de contrôle (gestion des zones d'atterrissage, activation des lignes de base et des contrôles)

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

    • AWSProvisionnement et gestion des artefacts du catalogue de services

Lorsque vous créez le connecteur, vous spécifiez une cible Région AWS. Cette région doit être la même que la région de votre tour de contrôle d'origine. Pour plus d'informations sur les régions de la tour de contrôle, consultez Régions AWS Comment utiliser la tour AWS de contrôle.

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 IAM Identity Center — 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 à votre région IAM Identity Center. Si IAM Identity Center est déjà configuré dans votre organisation, l'initialisation AWS de la tour de contrôle échouera si le connecteur cible une autre région. Pour plus d'informations, consultez la section Considérations destinées aux 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 la tour de contrôle. Lorsque AWS Control Tower configure une zone d'atterrissage, elle fournit automatiquement un ensemble de ressources gérées dans votre compte de gestion qui constituent le fondement de la gouvernance pour AWS l'ensemble de votre organisation :

  • Root  : le parent de niveau supérieur qui contient toutes les unités d'organisation de votre zone d'atterrissage.

  • Security OU — Créé automatiquement par Control Tower. Contient deux comptes partagés : le compte Log Archive (journalisation centralisée et immuable de toutes les activités d' AWS API et des modifications de ressources au sein de votre organisation) et le compte Audit (accès en lecture seule à tous les comptes à des fins de contrôle de sécurité et de conformité). Ces comptes ne peuvent pas être renommés ni remplacés après la configuration initiale.

  • Contrôles obligatoires (garde-fous) — Control Tower applique automatiquement des contrôles préventifs et de détection dans l'ensemble 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 natif du cloud avec des groupes préconfigurés et un accès par authentification unique pour les utilisateurs de votre zone de destination. Pour plus d'informations, consultez AWS IAM Identity Center.

Control Tower les utilise CloudFormation StackSets pour déployer et gérer ces ressources de manière cohérente sur tous les comptes et toutes les 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 peut entraîner le passage de votre zone d'atterrissage à un état inconnu.

Convention relative aux comptes de messagerie

AWS nécessite une adresse e-mail unique pour chaque compte. Ces e-mails reçoivent des notifications importantes concernant 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 extrait 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 positive déjà utilisée et propose de continuer avec le même schéma.

Structure de fondation recommandée

Sur la base des AWS meilleures pratiques, AWS Transform recommande la structure d'organisation organisationnelle de base suivante. Vous pouvez le personnaliser avant de le créer.

UO Objectif Comptes
Sécurité Enregistrement et surveillance centralisés des audits. L'isolation de ces services dans des comptes dédiés est conçue pour vous aider à séparer votre piste d'audit de celle des équipes chargées de la charge de travail. Audit, archivage des journaux
Infrastructures Réseau partagé (passerelle de transit, 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 endroit unique pour gérer la connectivité. Aucun (créé vide)
Sandbox Expérimentation par les développeurs en matière de limites de dépenses et d'accès restreint. Recommandé pour donner aux développeurs un espace pour expérimenter sans risquer les ressources de production. Sandbox
Charges de travail Contient la production et, éventuellement Non-Production, des sous-unités d'organisation réglementées. Les comptes de charge de travail sont conçus lors de la phase suivante en fonction de vos besoins en matière de migration. Aucun (créé vide)
Note

L'unité d'organisation de sécurité avec comptes d'audit et d'archivage des journaux est créée dans le cadre de la configuration de base de la Control Tower. Les unités d'organisation Infrastructure, Sandbox et Workloads sont créées séparément une fois que vous avez confirmé la structure.

Dans les scénarios de friches industrielles, AWS Transform compare votre fondation existante à la structure recommandée et ne signale que les lacunes. Par exemple : « Votre fondation possède des unités d'organisation dédiées à 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 définissent les autorisations maximales pour tous les comptes de votre organisation. AWS Ils n'accordent pas l'accès, mais définissent des limites que personne ne peut dépasser sur le compte, même les administrateurs du compte.

Dans le cadre du déploiement de la tour de contrôle, les garde-corps de référence sont appliqués 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 Infrastructure, Sandbox et Workloads. L'unité d'organisation 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 Security est une UO de fondation 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 friches industrielles, AWS Transform vérifie quels SCP sont déjà appliqués et ne recommande que ceux qui combleraient les lacunes.

Déploiement des fondations

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 dans votre AWS organisation.

  • Je vais 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 en même temps plus tard.

Initialisation de la tour de contrôle

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 la 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

Lors de la phase de conception du compte de charge de travail, AWS Transform conçoit l'unité d'organisation et la structure des comptes 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 de séparation des environnements.

Contexte de planification de la migration

AWS Transform extrait les données de la phase de planification de votre migration, notamment les plans Wave, les mappages serveur-application et le contexte partagé. Si des 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 gèrent des données sensibles (PII, PHI, financières)

  • Préférences de séparation des environnements (dev/test/staging/prod en tant que comptes séparés ou partagés)

  • Exigences relatives à l'isolation des charges

  • Les applications métier 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 attendue au cours des 12 à 24 prochains mois

  • Stratégie de compte préférée (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 unité d'organisation et une structure de comptes 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 :

  • Tous les serveurs d'une vague de migration sont dirigés vers le même compte. Les vagues ne peuvent pas être réparties entre les comptes. Il s'agit d'une limitation du réhôte lors de l'exécution d'une vague.

  • Si vous demandez des environnements isolés, AWS Transform crée un Workloads/Production Workloads/Non-Production sous-UO.

  • Si des frameworks applicables sont identifiés, AWS Transform crée un Workloads/Regulated Workloads/Standard sous-UO.

  • 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 dans le cadre des charges de travail.

  • Les applications contenant des données critiques ou sensibles bénéficient d'une seule application par compte. Dans ce cas, il se peut que l'on vous demande de modifier votre plan de vagues.

  • Les applications étroitement couplées avec des dépendances partagées sont regroupées dans un seul compte.

Chaque compte proposé comprend : le nom, l'objectif, l'unité d'organisation cible et l'unité commerciale. AWS La transformation 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 recommencer, en apportant des modifications supplémentaires jusqu'à ce que vous soyez satisfait.

Configuration de la charge de travail SCP

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 à 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'arbre d'organisation mis à 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 la charge de travail dans 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'auto-déploiement, AWS Transform génère des artefacts Infrastructure as Code dans les formats suivants :

  • Cloud Development Kit AWS (AWS CDK)— TypeScript projet de 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 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 prêts à l'emploi 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 pour la gouvernance, la structure organisationnelle et la mise en réseau qui correspondent aux AWS meilleures pratiques. Pour en savoir plus, consultez la section Configuration universelle LZA.

Note

Lors d'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 identifiants d'organisations utilisés dans AWS Transform et LZA. Pour savoir comment configurer votre installation LZA à l'aide des organisations, consultez la section Installation basée sur AWS les organisations.

Une fois que vous avez 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é 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 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, celle-ci est automatiquement acheminée vers des approbateurs autorisés via l'onglet AWS Transformer les approbations.

Les approbateurs examinent les CloudFormation modèles et les configurations des zones 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 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. Le système assure le suivi de toutes les décisions d'approbation à des fins d'audit et tient à jour l'historique des déploiements.

Tag : ressources relatives à la zone d'atterrissage

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— Transformation AWS

  • ATWorkspace— Identifiant du poste de travail

Note

Si votre migration fait partie du programme d'accélération de la AWS migration (MAP 2.0), vous pouvez inclure la balise MAP requise : Clé : map-migrated Valeur : 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.

Inverser les 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é par l'intermédiaire de l'agent de zone d'atterrissage.

Lorsque vous supprimez des éléments, l'ordre est important : vous devez retirer les enfants avant les parents :

  1. Supprimez d'abord les comptes (par e-mail).

  2. Supprimez les SCP des UO.

  3. Supprimer des unités d'organisation enfants : 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.