Leçons apprises et meilleures pratiques

La conception de la structure de l'UO n'est pas un effort ponctuel. Au fur et à mesure qu'une entreprise adopte le cloud et migre des charges de travail supplémentaires vers la zone AWS d'atterrissage, la conception de son unité d'organisation (et implicitement son concept de politiques) évoluera également naturellement.

Ne OUs les confondez pas avec des dossiers ; considérez-les comme une cible pour les politiques. Les OUs et leur hiérarchie fournissent l'élément structurant Comptes AWS et doivent toujours être traités comme des conteneurs pour les politiques. Nous vous recommandons de placer tous ceux Comptes AWS qui nécessitent le même ensemble de politiques dans la même unité d'organisation. Cette directive s'étend également à l'imbriqué OUs (à OUs l'intérieur OUs).

AWS les environnements qui nécessitent des fonctionnalités partagées de manière centralisée et des capacités de partage de données entre charges de travail (fréquemment utilisées sur les plateformes de données d'entreprise) sont plus faciles à intégrer dans une structure d'unité organisationnelle qui n'est pas basée sur la classification des fonctions des secteurs d'activité (LOB). Par exemple, un environnement de production pour une application de fabrication n'est pas différent d'un environnement de production pour une application d'analyse d'essais cliniques en termes de politiques dans AWS Organizations.

Respectez et utilisez l'héritage. Lorsque vous attachez une politique à une unité d'organisation spécifique, les Comptes AWS personnes situées directement sous cette unité d'organisation ou sous une unité d'organisation enfant héritent de la politique. Lorsque vous associez une politique à un élément spécifique Compte AWS, elle ne concerne que cela Compte AWS.

L'effort de migration d'une structure d'unité d'organisation à une autre dépend de l'étendue de la configuration des politiques existantes au niveau de l'unité d'organisation ou au Compte AWS niveau de l'unité d'organisation. Un autre facteur important est de savoir dans quelle mesure l'héritage des politiques a été utilisé dans la hiérarchie de l'unité d'organisation existante, ou si l'héritage a été rompu. La complexité de la migration augmente avec la mise en œuvre de voies d'héritage irrégulières ou divergentes. Par exemple, si vous appliquez des politiques au Compte AWS niveau individuel ou si vous faites de fréquentes exceptions aux règles (ce qui rompt l'héritage), la migration de ces politiques vers une nouvelle structure demandera beaucoup plus d'efforts. Dans de tels cas de grande complexité, nous vous recommandons de prendre le temps de revoir et de redéfinir l'héritage des politiques lors de la planification de la migration.

Prenez soin des AWS Organizations politiques et des AWS Control Tower contrôles. La structure de l'UO est partagée entre AWS Control Tower et AWS Organizations. AWS Control Tower fournit son propre ensemble de contrôles de détection et de prévention. Ces contrôles s'appliquent au niveau de l'unité d' Compte AWS organisation ou de l'unité d'organisation. AWS Organizations orchestre les politiques au niveau de l'UO. Lors d'une migration d'unité d'organisation, nous vous recommandons de migrer d'abord AWS Organizations les politiques, car celles-ci ont plus de poids en termes de conformité. Nous vous recommandons d'appliquer AWS Control Tower des contrôles à la nouvelle structure d'unité d'organisation lors de la deuxième étape de migration.

La mise à jour prend du temps Comptes AWS. Vous devez vous réinscrire Comptes AWS individuellement dans la nouvelle structure d'unité d'organisation en utilisant. AWS Control Tower Cela prend du temps. Si vous possédez un grand nombre de comptes, nous vous recommandons de rationaliser ce travail grâce à l'automatisation afin de contrôler et d'automatiser le placement des unités d'organisation Comptes AWS. Voici deux exemples de scénarios :