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. # Comment AWS les régions fonctionnent avec AWS Control Tower AWS Control Tower est pris en charge dans les AWS régions suivantes : + USA Est (Virginie du Nord) + USA Est (Ohio) + USA Ouest (Oregon) + Canada (Centre) + Asie-Pacifique (Sydney) + Asie-Pacifique (Singapour) + Europe (Francfort) + Europe (Irlande) + Europe (Londres) + Europe (Stockholm) + Asie-Pacifique (Mumbai) + Asie-Pacifique (Séoul) + Asie-Pacifique (Tokyo) + Europe (Paris) + Amérique du Sud (São Paulo) + USA Ouest (Californie du Nord) + Asie-Pacifique (Hong Kong) + Asie-Pacifique (Jakarta) + Asie-Pacifique (Osaka) + Europe (Milan) + Afrique (Le Cap) + Middle East (Bahrain) + Israël (Tel Aviv) + Moyen-Orient (EAU) + Europe (Espagne) + Asie-Pacifique (Hyderabad) + Europe (Zurich) + Asie-Pacifique (Melbourne) + Canada-Ouest (Calgary) + Malaisie (Kuala Lumpur) + Asie-Pacifique (Thaïlande) + Mexique (Centre) + Asie-Pacifique (Taipei) **À propos de votre région d'origine** Lorsque vous créez une zone d'atterrissage, la région que vous utilisez pour accéder à la console AWS de gestion devient votre AWS région d'origine pour AWS Control Tower. Au cours du processus de création, certaines ressources sont mises à disposition dans la région d'origine. Les autres ressources, telles que OUs les AWS comptes, sont mondiales. Une fois que vous avez sélectionné une région d'origine, vous ne pouvez pas la modifier. **Contrôles et régions** À l'heure actuelle, tous les contrôles préventifs fonctionnent dans le monde entier. Les contrôles Detective et proactifs ne fonctionnent toutefois que dans les régions où AWS Control Tower est pris en charge. Pour plus d'informations sur le comportement des contrôles lorsque vous activez AWS Control Tower dans une nouvelle région, consultez[Configurez vos régions AWS Control Tower](#deploying-to-new-region). ## Configurez vos régions AWS Control Tower Cette section décrit le comportement auquel vous pouvez vous attendre lorsque vous étendez votre zone d'atterrissage AWS Control Tower à une nouvelle AWS région ou que vous supprimez une région de la configuration de votre zone d'atterrissage. Généralement, cette action est effectuée via la fonction **Update** de la console AWS Control Tower. **Note** Nous vous recommandons d'éviter d'étendre la zone de landing de votre AWS Control Tower à des AWS régions dans lesquelles vous n'avez pas besoin de vos charges de travail pour fonctionner. Le fait de vous désinscrire d'une région ne vous empêche pas de déployer des ressources dans cette région, mais ces ressources resteront en dehors de la gouvernance d'AWS Control Tower. Lors de la configuration d'une nouvelle région, AWS Control Tower met à jour la zone d'atterrissage, ce qui signifie qu'elle définit votre zone d'atterrissage *comme base* de référence : + opérer activement dans toutes les régions nouvellement sélectionnées, et + pour cesser de gérer les ressources dans les régions désélectionnées. Les comptes individuels de vos unités organisationnelles (OUs) gérés par AWS Control Tower ne sont pas mis à jour dans le cadre de ce processus de mise à jour de la zone de landing zone. Par conséquent, vous devez mettre à jour vos comptes en réenregistrant votre OUs. Lorsque vous configurez vos régions AWS Control Tower, tenez compte des recommandations et limites suivantes : + Sélectionnez les régions dans lesquelles vous prévoyez d'héberger des AWS ressources ou des charges de travail. + Le fait de vous désinscrire d'une région ne vous empêche pas de déployer des ressources dans cette région, mais ces ressources resteront en dehors de la gouvernance d'AWS Control Tower. Lorsque vous configurez votre zone d'atterrissage pour de nouvelles régions, les contrôles de détection d'AWS Control Tower respectent les règles suivantes : + *Le comportement reste le même pour les éléments existants.* Les comportements de contrôle, qu'ils soient détectifs ou préventifs, restent inchangés pour les comptes existants OUs, dans les régions existantes. + *Vous ne pouvez pas appliquer de nouveaux contrôles de détection à OUs des comptes contenant existants qui ne sont pas mis à jour.* Lorsque vous avez configuré votre zone d'atterrissage AWS Control Tower dans une nouvelle région (en mettant à jour votre zone d'atterrissage), vous devez mettre à jour les comptes existants dans votre zone existante OUs avant de pouvoir activer de nouveaux contrôles de détection sur ces derniers OUs et sur les comptes. + *Vos contrôles de détection existants commencent à fonctionner dans les régions nouvellement configurées dès que vous mettez à jour les comptes.* Lorsque vous mettez à jour votre zone de landing zone AWS Control Tower pour configurer de nouvelles régions, puis que vous mettez à jour un compte, les contrôles de détection déjà activés sur l'unité d'organisation commencent à fonctionner sur ce compte dans les régions nouvellement configurées. **Configuration des régions AWS Control Tower** 1. Connectez-vous à la console AWS Control Tower à l'adresse [https://console.aws.amazon.com//controltower](https://console.aws.amazon.com//controltower) 1. Dans le menu de navigation du volet gauche, choisissez **Paramètres de la zone d'atterrissage**. 1. Sur la page des **paramètres de la zone d'atterrissage**, dans la section **Détails**, cliquez sur le bouton **Modifier les paramètres** en haut à droite. Vous êtes dirigé vers le flux de travail de mise à jour de la zone d'atterrissage, car pour gouverner de nouvelles régions ou supprimer des régions de la gouvernance, vous devez passer à la dernière version de la zone d'atterrissage. 1. Sous ** AWS Régions supplémentaires pour la gouvernance**, recherchez les régions que vous souhaitez gouverner (ou arrêter de gouverner). La colonne **État** indique les régions que vous gouvernez actuellement et celles que vous ne gouvernez pas. 1. Cochez la case correspondant à chaque région supplémentaire à gouverner. Décochez la case correspondant à chaque région dans laquelle vous supprimez la gouvernance. **Note** Si vous choisissez de ne pas gouverner une région, vous pouvez toujours y déployer des ressources, mais ces ressources resteront en dehors de la gouvernance d'AWS Control Tower. 1. Terminez le reste du flux de travail, puis choisissez **Update landing zone**. 1. Lorsque la configuration de la zone d'atterrissage est terminée, **réenregistrez-la** OUs pour mettre à jour les comptes dans vos nouvelles régions. Pour de plus amples informations, veuillez consulter [Quand mettre à jour AWS Control Tower OUs et ses comptes](update-existing-accounts.md). [Une autre méthode pour approvisionner ou mettre à jour des comptes individuels après avoir configuré de nouvelles régions consiste à utiliser [le framework d'API de Service Catalog](https://docs.aws.amazon.com//servicecatalog/latest/dg/API_Reference.html) et AWS CLIà mettre à jour les comptes par lots.](https://docs.aws.amazon.com//cli/latest/reference/servicecatalog/index.html) Pour de plus amples informations, veuillez consulter [Fournir et mettre à jour des comptes à l'aide de l'automatisation](update-accounts-by-script.md). # Évitez la gouvernance mixte lors de la configuration des régions Il est important de mettre à jour tous les comptes d'une unité d'organisation après avoir étendu la gouvernance d'AWS Control Tower à une nouvelle Région AWS entité et après avoir supprimé la gouvernance d'AWS Control Tower d'une région. La *gouvernance mixte* est une situation indésirable qui peut se produire si les contrôles régissant une UO ne correspondent pas parfaitement aux contrôles régissant chaque compte au sein d'une UO. Une gouvernance mixte se produit dans une unité d'organisation si les comptes ne sont pas mis à jour après qu'AWS Control Tower ait étendu la gouvernance à une nouvelle Région AWS entité ou ait supprimé la gouvernance. Dans ce cas, certains comptes d'une unité d'organisation peuvent être soumis à des contrôles différents selon les régions, par rapport à d'autres comptes de l'unité d'organisation ou par rapport à la posture de gouvernance globale de la zone d'atterrissage. Dans une unité d'organisation à gouvernance mixte, si vous créez un nouveau compte, celui-ci bénéficiera de la même posture de gouvernance de région et d'unité organisationnelle (mise à jour) que la zone d'atterrissage. Toutefois, les comptes existants qui ne sont pas encore mis à jour ne bénéficient pas de la nouvelle posture de gouvernance de la région. En général, une gouvernance mixte peut créer des indicateurs de statut contradictoires ou inexacts dans la console AWS Control Tower. Par exemple, dans le cadre d'une gouvernance mixte, les régions optionnelles apparaissent avec le statut **Non gouvernée**, dans Enregistré OUs, pour les comptes qui ne sont pas encore mis à jour. **Note** AWS Control Tower n'autorise pas l'activation des contrôles dans un état de gouvernance mixte. **Comportement des contrôles lors d'une gouvernance mixte** + Dans le cadre d'une gouvernance mixte, AWS Control Tower ne peut pas déployer de manière cohérente des contrôles basés sur des AWS Config règles (c'est-à-dire des contrôles de détection) dans les régions que l'unité d'organisation indique déjà comme étant **gouvernées**, car certains comptes de l'unité d'organisation n'ont pas été mis à jour. Il est possible que vous receviez un message `FAILED_TO_ENABLE` d'erreur. + Dans le cadre d'une gouvernance mixte, si vous étendez la gouvernance de la zone d'atterrissage à une région optionnelle alors qu'aucun compte de l'unité d'organisation n'a encore été mis à jour, le fonctionnement de l'`EnableControl`API sur l'unité d'organisation échoue pour les contrôles détectifs et proactifs. Vous recevrez un message d'`FAILED_TO_ENABLE`erreur, car les comptes de membres non mis à jour au sein de l'UO n'ont pas encore été ajoutés à ces régions. + Dans le cadre d'une gouvernance mixte, les contrôles qui font partie de la **norme gérée par le service Security Hub CSPM : AWS Control Tower** ne peuvent pas signaler la conformité avec précision dans les régions où il existe un décalage entre la configuration de la zone d'atterrissage et les comptes qui ne sont pas mis à jour. + La gouvernance mixte ne modifie pas le comportement des contrôles basés sur les SCP (contrôles préventifs), qui s'appliquent uniformément à tous les comptes d'une unité d'organisation, dans chaque région gouvernée. **Note** La gouvernance mixte n'est pas la même chose que la dérive, et elle n'est pas signalée comme telle. **Pour réparer la gouvernance mixte** + Les clients sont désormais en mesure de remédier à une gouvernance mixte en réinitialisant les contrôles régionaux. Tous les contrôles non globaux sont régionaux (contrôles détectifs et proactifs). Vous serez averti que votre UO est dans une gouvernance mixte par le biais d'une bannière d'alerte. # Considérations relatives à l'activation des AWS régions optionnelles Bien que la plupart Régions AWS soient actives par défaut pour vous Compte AWS, certaines régions ne sont activées que lorsque vous les sélectionnez manuellement. Dans le présent document, ces régions sont appelées « *régions optionnelles »*. En revanche, les régions actives par défaut, dès que la vôtre Compte AWS est créée, sont appelées *régions commerciales*, *régions par défaut* ou simplement *régions*. Le terme « *opt-in »* a une base historique. Toutes les régions Régions AWS introduites après le 20 mars 2019 sont déployées en tant que régions optionnelles. Dans une région optionnelle, votre compte n'est pas activé dans cette région, et votre identité n'est pas dupliquée dans cette région, sauf si vous choisissez d'utiliser cette région. Toutes les données gérées via le service IAM sont considérées comme des données d'identité, y compris les utilisateurs, les groupes, les rôles, les politiques, les fournisseurs d'identité, leurs données associées (par exemple, les certificats de signature X.509 ou les informations d'identification spécifiques au contexte) et les autres paramètres au niveau du compte, tels que la politique de mot de passe et l'alias du compte. Vous pouvez activer automatiquement les régions optionnelles lors de la configuration de la zone d'atterrissage, en les sélectionnant. Votre zone de landing devient active dans toutes les régions sélectionnées. Si vous choisissez de sélectionner une région optionnelle comme région d'origine de votre AWS Control Tower, activez-la d'abord en suivant les étapes décrites dans [Enabling a Region, une](https://docs.aws.amazon.com//general/latest/gr/rande-manage.html#rande-manage-enable) fois connecté à la console AWS de gestion. Pour transférer vos propres comptes d'archivage de journaux et d'audit existants depuis une région optionnelle, activez d'abord manuellement cette région. Les régions AWS optionnelles incluent plusieurs régions dans lesquelles AWS Control Tower est disponible : + Région Asie-Pacifique (Hong Kong), ap-east-1 + Région Asie-Pacifique (Jakarta), ap-southeast-3 + Région Europe (Milan), eu-south-1 + Région Afrique (Cape Town), af-south-1 + Région du Moyen-Orient (Bahreïn), me-south-1 + Israël (Tel Aviv), il-central-1 + Région du Moyen-Orient (EAU), me-central-1 + Région Europe (Espagne), eu-south-2 + Région Asie-Pacifique (Hyderabad), ap-south-2 + Région Europe (Zurich), eu-central-2 + Région Asie-Pacifique (Melbourne), ap-southeast-4 + Région du Canada Ouest (Calgary), ca-west-1 + Asie-Pacifique (Thaïlande), ap-southeast-7 + Mexique (centre), mx-central-1 + Asie-Pacifique (Taipei), ap-east-2 + Asie-Pacifique (Nouvelle Zélande), ap-southeast-6 AWS Control Tower dispose de certains contrôles qui fonctionnent différemment dans les régions optionnelles par rapport aux régions par défaut (autres régions commerciales). Pour de plus amples informations, veuillez consulter [Limites de contrôle](control-limitations.md). Voici quelques points à prendre en compte lorsque vous déployez des charges de travail dans des régions optionnelles. **Gouverner ou activer ?** N'oubliez pas que gouverner une région est une action que vous pouvez sélectionner depuis la console AWS Control Tower, afin que les contrôles puissent être appliqués dans la région. L'activation ou la désactivation d'une région optionnelle est une action différente que vous pouvez choisir dans la AWS console, qui ouvre la région à votre compte, afin que vous puissiez y déployer des ressources et des charges de travail. **Considérations comportementales** + Si vous choisissez de gérer les régions optionnelles, nous vous recommandons de ne désactiver (de vous désinscrire) aucune de vos régions optionnelles gouvernées, car cela pourrait entraîner l'échec de vos charges de travail. AWS Control Tower n'autorise pas la désactivation d'une région gouvernée depuis la console AWS Control Tower, mais assurez-vous de ne pas désactiver les régions gouvernées depuis une source extérieure à AWS Control Tower, telle que la console de AWS facturation ou AWS le SDK. + Lorsqu'AWS Control Tower étend la gouvernance à une région optionnelle, elle active (opts-in) la région dans tous les comptes membres. Lorsque vous supprimez une région de la gouvernance, AWS Control Tower ne la désactive pas (ne désactive pas) la région dans les comptes des membres. + Lors de la désélection d'une région, AWS Control Tower ne supprime pas les ressources d'une région optionnelle si cette région a été désactivée manuellement pour un compte provenant d'une source extérieure à AWS Control Tower, telle que la console de AWS facturation ou le SDK. AWS Nous vous recommandons de supprimer les ressources des régions que vous avez désactivées, sous peine de recevoir des frais de facturation imprévus pour ces ressources. + Si votre zone de landing zone est mise hors service, AWS Control Tower nettoie les ressources dans toutes les régions gouvernées, y compris les régions optionnelles. Cependant, AWS Control Tower ne désactive pas les régions optionnelles. Vous pouvez désactiver les régions optionnelles comme étape supplémentaire après la mise hors service. + Si votre région d'origine est une région optionnelle, et si vous avez l'intention d'inscrire des comptes existants en tant que comptes d'archivage des journaux et d'audit, vous devez activer manuellement la région optionnelle avant de pouvoir la sélectionner comme région d'origine pour votre zone d'atterrissage. Voir [Activation d'une région](https://docs.aws.amazon.com//general/latest/gr/rande-manage.html#rande-manage-enable). + Si AWS Control Tower est configurée avec une région optionnelle comme région d'origine, et si vous visitez le service AWS Control Tower depuis la AWS console d'une autre région, la console ne vous redirige pas automatiquement vers la région d'origine. + L'API sous-jacente comporte des limites de capacité, ce qui peut augmenter la latence de quelques minutes à plusieurs heures, en fonction du nombre de régions, de comptes et de la charge de service. Il est recommandé de n'opter que pour celles dans Régions AWS lesquelles vous allez exécuter les charges de travail, et d'opter pour une région à la fois. **Limitations importantes pour la gouvernance et les comptes** + Si 16 régions commerciales ou plus dans lesquelles AWS Control Tower est disponible sont régies, y compris les régions optionnelles, la limite supérieure du nombre de comptes par unité organisationnelle (UO) est réduite lors de l'enregistrement d'une UO. Pour plus d'informations, consultez la section [Limitations basées sur les AWS services sous-jacents](https://docs.aws.amazon.com/controltower/latest/userguide/region-stackset-limitations.html). # Configurer le contrôle de refus des régions AWS Control Tower propose deux contrôles de refus régionaux. Une commande`GRREGIONDENY`, lorsqu'elle est activée, s'applique à l'ensemble de la zone d'atterrissage. Une autre commande`CTMULTISERVICEPV1`, lorsqu'elle est activée, peut s'appliquer à des éléments spécifiques OUs que vous spécifiez. Pour plus d'informations, consultez la section [Refuser l'accès en AWS fonction de la demande Région AWS](https://docs.aws.amazon.com//controltower/latest/controlreference/primary-region-deny-policy.html) et le [contrôle de refus régional appliqué à l'unité d'organisation](https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html). **Considérations relatives à la région : refus de contrôler la zone d'atterrissage** La Région de refus de contrôle [https://docs.aws.amazon.com//controltower/latest/controlreference/primary-region-deny-policy.html](https://docs.aws.amazon.com//controltower/latest/controlreference/primary-region-deny-policy.html)est unique, car elle s'applique à la zone d'atterrissage dans son ensemble, plutôt qu'à une unité d'organisation spécifique. Pour configurer le refus de contrôle par région, rendez-vous sur la page des **paramètres de la zone d'atterrissage** et sélectionnez **Modifier les paramètres**. + Ce paramètre peut être modifié ultérieurement. + Lorsqu'elle est activée, cette commande s'applique à tous les inscrits OUs. + Ce contrôle ne peut pas être configuré pour un individu OUs. **Note** Avant d'activer le refus de contrôle par région, assurez-vous que vous ne disposez pas de ressources existantes dans ces régions, car vous n'aurez pas accès à vos ressources une fois le contrôle appliqué. Tant que le contrôle est activé, vous ne pourrez pas déployer de ressources dans les régions interdites. Lorsque vous activez le contrôle, il s'applique à tous les niveaux supérieurs OUs enregistrés de votre hiérarchie, et il est hérité par le niveau OUs inférieur de la chaîne. Lorsque vous supprimez le contrôle, il est supprimé pour toutes les régions enregistrées OUs, toutes les régions non gouvernées d'AWS Control Tower conservent le statut **Non gouvernées** et vous pouvez déployer des ressources dans des régions où AWS Control Tower n'est pas disponible. **Exceptions** Vous ne pouvez pas refuser l'accès à votre région d'origine. Certains AWS services internationaux, tels que IAM et AWS Organizations, sont exemptés du refus de contrôle de la Région. Pour en savoir plus, consultez la section [Refuser l'accès AWS en fonction de la demande Région AWS](https://docs.aws.amazon.com//controltower/latest/controlreference/lz-region-deny.html). + Nom du contrôle complet : **refuser l'accès AWS en fonction de la AWS région demandée** + Description du contrôle : interdit l'accès aux opérations non répertoriées dans les services mondiaux et régionaux en dehors des régions spécifiées. + Il s'agit d'un contrôle électif avec des conseils préventifs. Pour consulter le modèle du SCP de refus de contrôle régional, consultez la section [Refuser l'accès en AWS fonction de ce qui est demandé Région AWS](https://docs.aws.amazon.com//controltower/latest/controlreference/lz-region-deny.html) dans la *référence AWS Control Tower Control*. Le SCP d'AWS Control Tower est similaire au [SCP de AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region), mais il n'est pas identique. Vous pouvez déterminer les points de terminaison des services régionaux sur la [page des services régionaux](https://aws.amazon.com//about-aws/global-infrastructure/regional-product-services). ## Considérations relatives au refus de contrôle des régions au niveau de l'UO La principale considération concernant le refus de contrôle de la région au niveau de l'OU est de déterminer comment il interagira avec le contrôle de refus de la région de la zone d'atterrissage, si les deux sont activés. Pour plus d'informations, consultez [la section Contrôle de refus de région appliqué à l'unité d'organisation](https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html). Vous pouvez également consulter [Configurer le contrôle des refus par région](https://docs.aws.amazon.com//controltower/latest/userguide/region-deny.html).