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.
# Gestion des identités et contrôle d'accès pour la transition vers une architecture à comptes multiples
Cette première étape lors de la transition vers une architecture à comptes multiples consiste à configurer votre nouvelle structure de compte au sein d'une organisation. Vous pouvez ensuite ajouter des utilisateurs et configurer leur accès aux comptes. Cette section décrit les approches permettant de gérer l'accès humain à plusieurs Comptes AWS.
**Topics**
+ [Configurer une organisation](set-up-organization.md)
+ [Création d'une zone de destination](create-landing-zone.md)
+ [Ajouter des unités d'organisation](add-organizational-units.md)
+ [Ajouter des utilisateurs d'origine](add-initial-users.md)
+ [Gérer les comptes membres](manage-member-accounts.md)
# Configurer une organisation
Lorsque vous en avez plusieurs Comptes AWS, vous pouvez gérer ces comptes de manière logique par le biais d'une organisation dans [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). Un *compte* dans AWS Organizations est une norme Compte AWS qui contient vos AWS ressources et les identités qui peuvent accéder à ces ressources. Une *organisation* est une entité qui consolide les vôtres Comptes AWS afin que vous puissiez les administrer en tant qu'unité unique.
Lorsque vous utilisez un compte pour créer une organisation, ce compte devient le *compte de gestion* (également appelé *compte payeur* ou *compte root*) pour l'organisation. Une organisation ne peut avoir qu'un seul compte de gestion. Lorsque vous ajoutez des informations supplémentaires Comptes AWS à l'organisation, elles deviennent *des comptes membres*.
**Note**
Chacun possède Compte AWS également une seule identité appelée *utilisateur root*. Vous pouvez vous connecter en tant qu'utilisateur root avec l'adresse e-mail et le mot de passe que vous avez utilisés pour créer le compte. Toutefois, il est vivement recommandé de ne pas utiliser l'utilisateur root pour vos tâches quotidiennes, y compris pour les tâches administratives. Pour plus d'informations, veuillez consulter [Utilisateur root Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).
Nous recommandons également de [centraliser l'accès root pour les comptes membres](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) et de supprimer les informations d'identification de l'utilisateur root des comptes membres de votre organisation.
Vous organisez les comptes dans une structure arborescente hiérarchique qui comprend la racine de l'organisation, les unités organisationnelles (OUs) et les comptes des membres. La *racine* est le conteneur parent pour tous les comptes de votre organisation. Une *unité d'organisation* (UO) est un conteneur pour [comptes](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) au sein de la [racine](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root). Une UO peut contenir d'autres comptes OUs ou des comptes de membres. Une unité d'organisation ne peut posséder qu'un seul parent et chaque compte peut être un membre d'une seule unité d'organisation. Pour plus d'informations, consultez [Terminologie et concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentation).
Une [politique de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) spécifie les services et les actions que les utilisateurs et les rôles peuvent utiliser. SCPs sont similaires aux politiques d'autorisation Gestion des identités et des accès AWS (IAM) sauf qu'elles n'accordent pas d'autorisations. SCPs Définissez plutôt les autorisations maximales. Lorsque vous attachez une politique à l'un des nœuds de la hiérarchie, elle s'applique à tous les comptes OUs et de ce nœud. Par exemple, si vous appliquez une politique à la racine, elle s'applique à tous les [OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)[comptes](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) de l'organisation, et si vous appliquez une politique à une unité d'organisation, elle ne s'applique qu'aux comptes OUs et de l'unité d'organisation cible.
Une [politique de contrôle des ressources (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) permet de contrôler de manière centralisée les autorisations maximales disponibles pour les ressources de votre organisation. RCPs vous aider à vous assurer que les ressources de votre compte respectent les directives de contrôle d'accès de votre organisation.
Vous pouvez utiliser la AWS Organizations console pour visualiser et gérer de manière centralisée tous vos comptes au sein d'une organisation. L'un des avantages de l'utilisation d'une organisation est que vous pouvez recevoir une facture consolidée indiquant tous les frais associés aux comptes de gestion et aux comptes membres. Pour plus d'informations, voir [Facturation consolidée](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations documentation).
## Bonnes pratiques
+ N'utilisez pas une organisation existante Compte AWS pour créer une organisation. Commencez par un nouveau compte, qui devient votre compte de gestion pour l'organisation. Les opérations privilégiées peuvent être effectuées dans le compte de gestion d'une organisation SCPs et RCPs ne s'appliquent pas au compte de gestion. C’est pourquoi vous devez limiter les ressources et données cloud contenues dans le compte de gestion à celles qui doivent être gérées dans le compte de gestion.
+ Limitez l'accès au compte de gestion aux seules personnes qui ont besoin d'approvisionner de nouveaux comptes Comptes AWS et d'administrer l'organisation.
+ SCPs À utiliser pour définir les autorisations maximales pour la racine, les unités organisationnelles et les comptes des membres. SCPs ne peut pas être directement appliqué au compte de gestion.
+ RCPs À utiliser pour définir les autorisations maximales pour les ressources dans les comptes des membres. RCPsne peut pas être directement appliqué au compte de gestion.
+ Respectez les [meilleures pratiques pour AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html) (AWS Organizations documentation).
# Création d'une zone de destination
Une *zone d'atterrissage* est un AWS environnement multi-comptes bien conçu qui constitue un point de départ à partir duquel vous pouvez déployer des charges de travail et des applications. Elle sert de référence pour démarrer avec l'architecture à comptes multiples, la gestion des identités et des accès, la gouvernance, la sécurité des données, la conception de réseaux et la journalisation. [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) est un service qui simplifie la maintenance et la gouvernance d'un environnement à comptes multiples en proposant des barrières de protection automatisées. En général, vous configurez une zone AWS Control Tower d'atterrissage unique qui gère l'ensemble de votre environnement Régions AWS. AWS Control Tower fonctionne en orchestrant les autres Services AWS au sein de votre compte. Pour plus d'informations, voir [Que se passe-t-il lorsque vous configurez une zone d'atterrissage](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower documentation).
Lorsque vous configurez une zone d'atterrissage avec AWS Control Tower, vous identifiez trois comptes partagés : le compte de gestion, le compte d'archivage des journaux et le compte d'audit. Pour plus d'informations, voir [Quels sont les comptes partagés](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower documentation). Pour le compte de gestion, vous devez utiliser un compte existant qui n'héberge aucune charge de travail pour configurer la zone de destination. Pour les comptes d'archivage des journaux et d'audit, vous pouvez choisir de réutiliser Comptes AWS les comptes existants ou AWS Control Tower de les créer pour vous.
Pour obtenir des instructions sur la configuration de votre zone AWS Control Tower d'atterrissage, consultez [Getting started](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) (AWS Control Tower documentation).
## Bonnes pratiques
+ Adhérez aux meilleures pratiques des [principes de conception pour votre stratégie multi-comptes](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS livre blanc).
+ Respectez les [meilleures pratiques pour AWS Control Tower les administrateurs](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) (AWS Control Tower documentation).
+ Créez votre zone de landing zone dans celle Région AWS qui héberge la majorité de vos charges de travail.
**Important**
Si vous décidez de modifier cette région après avoir déployé votre zone d'atterrissage, vous avez besoin de l'assistance de AWS Support la zone d'atterrissage et vous devez la mettre hors service. Cette pratique n'est pas recommandée.
+ Lorsque vous déterminez quelles régions AWS Control Tower seront gouvernées, sélectionnez uniquement les régions dans lesquelles vous prévoyez de déployer immédiatement des charges de travail. Vous pouvez modifier ces régions ou en ajouter d'autres ultérieurement. S'il AWS Control Tower gouverne une région, il déploiera ses garde-fous détectives dans cette région en tant que. [AWS Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ Après avoir déterminé quelles régions AWS Control Tower seront gouvernées, refusez l'accès à toutes les régions non gouvernées. Cela permet de garantir que vos charges de travail et vos développeurs ne peuvent utiliser que des Régions AWS approuvées. Ceci est mis en œuvre en tant que politique de contrôle des services (SCP) dans l'organisation. Pour plus d'informations, voir [Configurer le contrôle de Région AWS refus](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) (AWS Control Tower documentation).
+ Lorsque vous configurez votre zone d'atterrissage dans AWS Control Tower, nous vous recommandons de renommer OUs les comptes suivants :
+ Nous vous recommandons de renommer l'UO **Sécurité** en **Security\$1Prod** pour indiquer que cette UO sera utilisée pour des Comptes AWS liés à la sécurité de la production.
+ **Nous vous recommandons d'autoriser la création AWS Control Tower d'une unité d'organisation supplémentaire, puis de la renommer **Sandbox** en Workloads.** Dans la section suivante, vous allez créer des éléments supplémentaires OUs au sein de l'unité d'organisation **des charges** de travail, que vous utiliserez pour organiser votre Comptes AWS.
+ Nous vous recommandons de renommer la journalisation centralisée Compte AWS de **Log Archive** en **log-archive-prod**.
+ Nous vous recommandons de renommer le compte d'audit d'**Audit** en **security-tooling-prod**.
+ Pour aider à prévenir la fraude, il AWS faut Comptes AWS disposer d'un historique d'utilisation avant de pouvoir les ajouter à une zone d' AWS Control Tower atterrissage. Si vous utilisez une nouvelle instance Compte AWS sans historique d'utilisation, dans le nouveau compte, vous pouvez lancer une instance Amazon Elastic Compute Cloud (Amazon EC2) qui ne figure pas dans AWS le niveau gratuit. Laissez l'instance s'exécuter pendant quelques minutes, puis résiliez-la.
# Ajouter des unités d'organisation
La mise en place d'une structure organisationnelle appropriée est essentielle à la configuration d'un environnement à comptes multiples. Dans la mesure où vous utilisez les politiques de contrôle des services (SCPs) pour définir les autorisations maximales pour une unité d'organisation et les comptes qu'elle contient, la structure de votre organisation doit être logique du point de vue de la gestion, des autorisations et des rapports financiers. Pour plus d'informations sur la structure d'une organisation, y compris les unités organisationnelles (OUs), voir [Terminologie et concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentation).
Dans cette section, vous personnalisez la zone d'atterrissage en créant des environnements imbriqués OUs qui vous aident à segmenter et à structurer vos environnements, tels que ceux de production et de non-production. Ces bonnes pratiques recommandées sont conçues pour segmenter votre zone de destination afin de séparer les ressources de production des ressources autres que de production et de séparer l'infrastructure des charges de travail.
Pour plus d'informations sur la création OUs, voir [Gestion des unités organisationnelles](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations documentation).
## Bonnes pratiques
+ Dans l'unité d'**organisation des charges** de travail que vous avez créée[Création d'une zone de destination](create-landing-zone.md), créez les éléments imbriqués OUs suivants :
+ **Prod** : utilisez cette UO pour les Comptes AWS qui stockent et accèdent aux données de production, y compris les données des clients.
+ **NonProd**— Utilisez cette UO pour Comptes AWS stocker des données non liées à la production, telles que des environnements de développement, de préparation ou de test
Sous la racine de l'organisation, créez une UO **Infrastructure\$1Prod**. Utilisez cette unité d'organisation pour héberger un compte de mise en réseau centralisé.
# Ajouter des utilisateurs d'origine
Il existe deux manières de donner aux personnes l'accès aux Comptes AWS :
+ Identités IAM, telles que les utilisateurs, les groupes et les rôles
+ Fédération d'identité, par exemple en utilisant AWS IAM Identity Center
Dans les petites entreprises et les environnements à compte unique, il est courant que les administrateurs créent un utilisateur IAM lorsqu'une nouvelle personne rejoint l'entreprise. Les informations d'identification de la clé d'accès et de la clé secrète associées à un utilisateur IAM sont appelées *informations d'identification à long terme*, car elles n'expirent pas. Toutefois, il ne s'agit pas d'une bonne pratique de sécurité recommandée, car si un pirate informatique compromettait ces informations d'identification, vous devriez générer un autre ensemble d'informations d'identification pour l'utilisateur. Une autre méthode d'accès Comptes AWS consiste à utiliser les [rôles IAM](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/). Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) pour demander temporairement des *informations d'identification à court terme*, qui expirent au bout d'une période configurable.
Vous pouvez gérer l'accès des personnes à votre compte Comptes AWS via [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). Vous pouvez créer des comptes utilisateur individuels pour chacun de vos employés ou sous-traitants, où ils peuvent gérer leurs propres mots de passe et solutions d'authentification multifactorielle (MFA), et vous pouvez les regrouper pour gérer l'accès. Lorsque vous configurez le MFA, vous pouvez utiliser des jetons logiciels, tels que des applications d'authentification, ou des jetons matériels, tels que des appareils. YubiKey
IAM Identity Center prend également en charge la fédération à partir de fournisseurs d'identité externes (IdPs) tels qu'Okta et Ping Identity. JumpCloud Pour plus d'informations, veuillez consulter la rubrique [Supported identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (documentation IAM Identity Center). En fédérant avec un IdP externe, vous pouvez gérer l'authentification des utilisateurs dans toutes les applications, puis utiliser IAM Identity Center pour autoriser l'accès à des applications spécifiques. Comptes AWS
## Bonnes pratiques
+ Adhérez aux [bonnes pratiques de sécurité](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (documentation IAM) pour configurer l'accès des utilisateurs.
+ Gérez l'accès aux comptes par groupes plutôt que par utilisateurs individuels. Dans IAM Identity Center, créez des groupes qui représentent chacune de vos fonctions métier. Par exemple, vous pouvez créer des groupes pour l'ingénierie, les finances, les ventes et la gestion de produits.
+ Souvent, les groupes sont définis en séparant ceux qui ont besoin d'un accès à tous les Comptes AWS (accès souvent en lecture seule) et ceux qui ont besoin d'accéder à un seul Compte AWS. Nous vous recommandons d'utiliser la convention de dénomination suivante pour les groupes afin d'identifier facilement les autorisations Compte AWS et autorisations associées au groupe.
`--`
+ Par exemple, pour le groupe `AWS-A-dev-nonprod-DeveloperAccess`, `AWS-A` est un préfixe qui indique l'accès à un seul compte, `dev-nonprod` est le nom du compte et `DeveloperAccess` est l'ensemble d'autorisations attribué au groupe. Pour le groupe `AWS-O-BillingAccess`, le préfixe `AWS-O` indique l'accès à l'ensemble de l'organisation, tandis que `BillingAccess` indique l'ensemble d'autorisations pour le groupe. Dans cet exemple, étant donné que le groupe a accès à l'ensemble de l'organisation, aucun nom de compte n'est représenté dans le nom du groupe.
+ Si vous utilisez IAM Identity Center avec un IdP externe basé sur SAML et que vous souhaitez exiger la MFA, vous pouvez utiliser le contrôle d'accès par attributs (ABAC) pour transmettre la méthode d'authentification de l'IdP à IAM Identity Center. Les attributs sont envoyés via les assertions SAML. Pour plus d'informations, veuillez consulter la rubrique [Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) (documentation IAM Identity Center).
De nombreuses entreprises IdPs, telles que Microsoft Azure Active Directory et Okta, peuvent utiliser la revendication Authentication Method Reference (`amr`) dans une assertion SAML pour transmettre le statut MFA de l'utilisateur à IAM Identity Center. La réclamation utilisée pour confirmer l'état de la MFA et son format varient selon l'IdP. Pour plus d'informations, consultez la documentation relative à votre IdP.
Dans IAM Identity Center, vous pouvez ensuite créer des politiques d'ensemble d'autorisations qui déterminent qui peut accéder à vos AWS ressources. Lorsque vous activez ABAC et spécifiez des attributs, IAM Identity Center transmet la valeur d'attribut de l'utilisateur authentifié dans IAM pour une utilisation dans l'évaluation de politiques. Pour plus d'informations, veuillez consulter la rubrique [Create permission policies for ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html) (documentation IAM Identity Center). Comme le montre l'exemple suivant, vous utilisez la clé de condition `aws:PrincipalTag` pour créer une règle de contrôle d'accès pour la MFA.
```
"Condition": {
"StringLike": { "aws:PrincipalTag/amr": "mfa" }
}
```
# Gérer les comptes membres
Dans cette section, vous invitez votre compte préexistant dans l'organisation et vous commencez à en créer d'autres au sein de votre organisation. Une partie importante de ce processus consiste à définir les critères que vous utilisez pour déterminer si vous devez allouer un nouveau compte.
**Topics**
+ [Inviter votre compte préexistant](#invite-account)
+ [Personnalisez les paramètres VPC dans AWS Control Tower](#customize-vpc-settings)
+ [Définir les critères de portée](#define-scoping-criteria)
## Inviter votre compte préexistant
Au sein de cette section AWS Organizations, vous pouvez inviter le compte préexistant de votre entreprise à rejoindre votre nouvelle organisation. Seul le compte de gestion de l'organisation peut inviter d'autres comptes à la rejoindre. Lorsque l'administrateur du compte invité accepte, le compte rejoint immédiatement l'organisation, tandis que le compte de gestion de l'organisation devient responsable de tous les frais encourus par le nouveau compte membre. Pour plus d'informations, veuillez consulter les rubriques [Invitation d'un Compte AWS à rejoindre votre organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) et [Acceptation ou refus d'une invitation d'une organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite) (documentation AWS Organizations ).
**Note**
Vous pouvez inviter un compte à rejoindre une organisation uniquement s'il n'appartient pas actuellement à une autre organisation. Si le compte est membre d'une organisation existante, vous devez le supprimer de l'organisation. S'il s'agit du compte de gestion d'une autre organisation créée par erreur, vous devez supprimer l'organisation.
**Important**
Si vous avez besoin d'accéder à des informations historiques sur les coûts ou l'utilisation depuis votre compte préexistant, vous pouvez les utiliser AWS Cost and Usage Report pour exporter ces informations vers un bucket Amazon Simple Storage Service (Amazon S3). Faites-le avant d'accepter l'invitation à rejoindre l'organisation. Lorsqu'un compte rejoint une organisation, vous perdez l'accès à ses données historiques. Pour plus d'informations, veuillez consulter la rubrique [Setting up an Amazon S3 bucket for Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (documentation AWS Cost and Usage Report ).
*Bonnes pratiques*
+ Nous vous recommandons d'ajouter votre compte préexistant, qui contient probablement des charges de travail de production, à l'unité d'organisation **Charges de travail** > **Prod** que vous avez créée dans [Ajouter des unités d'organisation](add-organizational-units.md).
+ Par défaut, le compte de gestion de l'organisation ne dispose pas d'un accès administratif sur les comptes membres invités à rejoindre l'organisation. Si vous souhaitez que le compte de gestion dispose d'un contrôle administratif, vous devez créer le rôle **OrganizationAccountAccessRole**IAM dans le compte de membre et autoriser le compte de gestion à assumer ce rôle. Pour plus d'informations, voir [Création du OrganizationAccountAccessRole dans un compte de membre invité](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations documentation).
+ Pour le compte préexistant que vous avez invité à rejoindre l'organisation, consultez [les meilleures pratiques pour les comptes de membres](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations documentation) et vérifiez que le compte est conforme à ces recommandations.
## Personnalisez les paramètres VPC dans AWS Control Tower
Nous vous recommandons d'en approvisionner de nouvelles Comptes AWS via [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) dans AWS Control Tower. En utilisant Account Factory, vous pouvez utiliser l' AWS Control Tower intégration avec Amazon EventBridge pour provisionner de nouvelles ressources Comptes AWS dès la création du compte.
Lorsque vous en configurez un nouveau Compte AWS, un [cloud privé virtuel (VPC) par défaut](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) est automatiquement provisionné. Toutefois, lorsque vous créez un compte via Account Factory, AWS Control Tower alloue automatiquement un VPC supplémentaire. Pour plus d'informations, consultez la section [Présentation de AWS Control Tower et VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower documentation). Cela signifie que, par défaut, deux AWS Control Tower provisions sont par défaut VPCs sur chaque nouveau compte.
Il est courant que les entreprises souhaitent avoir plus de contrôle VPCs sur leurs comptes. Beaucoup préfèrent utiliser d'autres services AWS CloudFormation, tels que Hashicorp Terraform ou Pulumi, pour configurer et gérer leur. VPCs Vous devez personnaliser les paramètres d'Account Factory pour empêcher la création du VPC supplémentaire alloué par AWS Control Tower. Pour obtenir des instructions, consultez [Configurer les paramètres Amazon VPC](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html) (AWS Control Tower documentation) et appliquez les paramètres suivants :
1. Désactivez l'option **Sous-réseau accessible par Internet**.
1. Dans **Nombre maximum de sous-réseaux privés**, choisissez **0**.
1. Dans **Régions pour la création de VPC**, supprimez toutes les régions.
1. Dans **Zones de disponibilité**, choisissez **3**.
*Bonnes pratiques*
+ Supprimez le VPC par défaut qui est automatiquement alloué dans chaque nouveau compte. Cela empêche les utilisateurs de lancer des instances EC2 publiques dans le compte sans créer explicitement un VPC dédié. Pour plus d'informations, veuillez consulter la rubrique [Supprimer vos sous-réseaux par défaut et votre VPC par défaut](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc) (documentation Amazon Virtual Private Cloud). Vous pouvez également configurer [AWS Control Tower Account Factory pour Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) pour supprimer automatiquement le VPC par défaut dans les comptes qui viennent d'être créés.
+ Fournissez un nouveau Compte AWS nom appelé **dev-nonprod** dans l'unité organisationnelle **Workloads** >. **NonProd** Utilisez ce compte pour votre environnement de développement. Pour obtenir des instructions, consultez [la section Comptes Provision Account Factory avec AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower documentation).
## Définir les critères de portée
Vous devez sélectionner les critères que votre entreprise utilisera pour décider d'en fournir un nouveau Compte AWS. Vous pouvez décider d'allouer des comptes pour chaque unité commerciale, ou vous pouvez décider d'allouer des comptes en fonction de l'environnement, tel que l'environnement de production, de test ou d'assurance qualité. Chaque entreprise a ses propres exigences quant à sa Comptes AWS taille. En règle générale, vous évaluez les trois facteurs suivants lorsque vous décidez de la taille de vos comptes :
+ **Équilibrage des quotas** de *service — Les quotas* de service sont les valeurs maximales du nombre de ressources, d'actions et d'éléments pour chacun d'entre eux Service AWS au sein d'un Compte AWS. Si de nombreuses charges de travail partagent le même compte et qu'une charge de travail consomme la majeure partie ou la totalité d'un quota de service, cela peut avoir un impact négatif sur une autre charge de travail du même compte. Dans ce cas, vous devrez peut-être répartir ces charges de travail dans différents comptes. Pour plus d'informations, veuillez consulter [Quotas Service AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) (Références générales AWS).
+ **Rapport sur les coûts** : isolez des charges de travail dans des comptes distincts pour visualiser les coûts au niveau du compte dans les rapports sur les coûts et l'utilisation. Lorsque vous utilisez le même compte pour plusieurs charges de travail, vous pouvez utiliser des balises pour vous aider à gérer et à identifier les ressources. Pour plus d'informations sur le balisage, consultez [AWS Ressources de balisage](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) ()Références générales AWS.
+ **Contrôle d'accès** : lorsque des charges de travail partagent un compte, vous devez réfléchir à la manière dont vous allez configurer les politiques IAM afin de limiter l'accès aux ressources du compte pour que les utilisateurs n'aient pas accès aux charges de travail auxquelles ils n'ont pas besoin. Au lieu de cela, vous pouvez utiliser plusieurs comptes et [ensembles d'autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) dans IAM Identity Center pour gérer l'accès aux comptes individuels.
*Bonnes pratiques*
+ Respectez les meilleures pratiques en matière de [stratégie AWS multi-comptes pour votre zone de AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) (AWS Control Tower documentation).
+ Établissez une stratégie de balisage efficace qui vous aide à identifier et à gérer les ressources AWS . Vous pouvez utiliser des balises pour classer vos ressources par objectif, unité commerciale, environnement ou selon d'autres critères. Pour plus d'informations, consultez la section [Meilleures pratiques en matière de balisage](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices) (Références générales AWS documentation).
+ Ne surchargez pas un compte avec trop de charges de travail. Si la demande de la charge de travail dépasse un quota de service, cela peut entraîner des problèmes de performances. Vous pouvez séparer les charges de travail concurrentes en différentes Comptes AWS ou demander une augmentation du quota de service. Pour plus d'informations, veuillez consulter la rubrique [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Documentation Service Quotas).