Landing zone AWS : séparer production, tests et sécurité sans surdimensionner l'organisation

Une équipe qui a grandi dans un seul compte AWS y fait tout cohabiter : l'expérimentation, la production, les journaux et l'administration. Le jour où une expérimentation consomme le budget, où un déploiement de test touche la production, où un rôle IAM (Identity and Access Management, la gestion des identités et des accès d'AWS) trop large sert à autre chose que prévu ou où une trace utile disparaît, l'incident ne reste pas à sa place : dans un seul compte, la facture, les quotas, les accès et les journaux sont communs.

Une landing zone répond à ce problème. AWS la définit comme un environnement multicompte bien conçu, évolutif et sécurisé, point de départ du déploiement des charges de travail, construit avec AWS Control Tower ou de façon personnalisée. Cet article en propose un exemple dimensionné pour une petite équipe : quatre familles de comptes, ce que l'équipe garde à sa charge avec AWS Organizations seul ou avec Control Tower, dix tests d'acceptation et la façon de faire entrer le compte existant. AWS précise lui-même que, selon les exigences, toutes les unités d'organisation (OU, organizational units) qu'il recommande ne sont pas nécessaires.

Partir de quatre incidents pour justifier chaque frontière

Un compte AWS est à la fois une frontière de sécurité, d'accès et de facturation. D'après le livre blanc d'AWS sur l'organisation en plusieurs comptes, séparer les comptes limite le périmètre d'impact d'un incident, permet des contrôles distincts par environnement, cantonne les données sensibles à des comptes dédiés et répartit les quotas et les limites d'appels d'API (interfaces de programmation), appliqués par compte. Les coûts sont attribués au compte par défaut, et AWS ne facture pas les comptes eux-mêmes, seulement les ressources utilisées.

Quatre incidents permettent de justifier chaque frontière par ce qu'elle évite, l'accès qu'elle laisse et la preuve qu'elle produit.

Une alerte de budget n'est pas un plafond : AWS Budgets rafraîchit ses données jusqu'à trois fois par jour, et une notification peut arriver après le dépassement. Pour agir, une action de budget prévue à l'avance peut appliquer une politique IAM ou une SCP (depuis le compte de gestion seulement), ou arrêter des instances Amazon EC2 (machines virtuelles) ou Amazon RDS (bases de données gérées). Le budget autorisé par environnement se prépare avec la méthode de « Budget cloud d'un SaaS en croissance : prévoir trois scénarios », et l'attribution des coûts par compte rejoint la démarche de « FinOps, c'est quoi ? Définition 2026, méthode et par où commencer ».

Un compte est une frontière utile, pas suffisante. Les ressources d'un compte sont logiquement isolées de celles des autres, et un accès d'un compte à l'autre exige une autorisation des deux côtés : la politique de la ressource dans le compte qui la possède, la politique d'identité dans le compte qui y accède. Les relations de confiance IAM, les partages de données et les connexions réseau entre comptes déterminent donc l'isolement réel : un rôle de production qui fait confiance à un compte de non-production réduit d'autant la séparation.

Environnement, produit ou client : ne pas confondre les découpages

Pour une petite équipe, la première frontière à justifier est l'environnement : production et non-production n'ont ni les mêmes accès, ni les mêmes contrôles, ni les mêmes données. Un découpage par produit se justifie quand deux produits ont des propriétaires, des données ou des contrôles différents. Un compte par client n'est pas une obligation : la SaaS Lens du cadre AWS Well-Architected rappelle que le nombre de comptes provisionnables est limité et que ce modèle peut devenir lourd à grande échelle, et elle décrit des modèles mixtes, comme l'isolement par niveau d'offre. La décision commerciale d'isoler un client se traite à part, comme dans « Hébergement sur mesure : faut-il accepter ce client SaaS ? ».

Séparer l'administration de l'exécution

Le compte de gestion ne sert qu'aux tâches qui l'exigent. AWS recommande d'y limiter ressources et données, d'en réserver l'accès à un petit nombre de personnes de confiance et de préférer l'administration déléguée à un compte membre quand un service le permet. Il ne porte aucune charge de travail : les SCP ne le restreignent pas, et le cadre Well-Architected place les ressources des charges de travail dans les seuls comptes membres.

Dessiner une première structure de comptes et d'OU

Le livre blanc d'AWS recommande deux OU fondamentales, Security et Infrastructure, une OU Workloads pour la production et la non-production, une OU Sandbox pour l'expérimentation, et d'autres OU selon les besoins, comme Policy Staging, Suspended ou Exceptions. L'exemple suivant en retient le minimum pour une petite équipe qui part d'un seul compte : quatre familles de comptes, et des OU optionnelles ajoutées sur une raison écrite.

Dans l'OU de sécurité, le compte de journaux consolide les journaux de tous les comptes. AWS recommande d'en réserver l'accès aux équipes chargées de la conformité et des investigations et à leurs outils, qui lisent les journaux par des rôles en lecture seule au moindre privilège : les comptes de charge de travail n'y ont aucun accès. Le compte d'outils de sécurité agrège des services comme AWS Security Hub, Amazon GuardDuty ou Amazon Detective. Protéger les journaux contre la modification reste un objectif de conception, atteint par la configuration du bucket et des accès, et non une propriété automatique du compte : AWS recommande des SCP sur l'OU de sécurité qui empêchent de modifier ou de supprimer les fichiers du bucket de journalisation centralisée, et le versionnage de ce bucket.

Pour les charges de travail, AWS propose deux OU enfants, Prod et Test, chacune avec ses propres politiques. Une seule OU de non-production suffit quand les charges hors production demandent les mêmes politiques d'accès ou gagnent à être exploitées ensemble ; des OU Test et Dev séparées se justifient quand leurs politiques diffèrent.

Une fiche par compte, avant sa création

Chaque compte reçoit, avant sa création, une fiche : propriétaire, coût de fonctionnement, région, données et permission d'administration. Les propriétaires sont des rôles dans votre organisation ; dans une petite équipe, une même personne peut en tenir plusieurs.

Un administrateur délégué de CloudTrail peut modifier, arrêter ou supprimer la trace d'organisation. Avec l'intégration Security Roles de Control Tower, le compte d'outils de sécurité, qui sert d'agrégateur AWS Config, détient aussi des rôles d'audit en lecture seule et d'administration complète vers tous les comptes de la landing zone : y accéder revient à pouvoir administrer la production. L'accès aux comptes qui portent ces rôles se réserve donc aux personnes chargées de la sécurité.

Le coût de fonctionnement de chaque compte s'estime sur le périmètre et les régions retenus, journalisation et contrôles compris ; la région est celle où vivent ses charges et ses données, et toute région supplémentaire se justifie par écrit.

La permission d'administration passe par IAM Identity Center, qu'AWS recommande pour l'accès du personnel à plusieurs comptes : une authentification unique (SSO, single sign-on) qui délivre des identifiants temporaires plutôt que des utilisateurs IAM à long terme. Des ensembles d'autorisations par profil sont affectés à des groupes, et Identity Center crée les rôles IAM correspondants dans chaque compte. Le compte de gestion fait exception : l'administrateur délégué d'Identity Center ne peut pas gérer les ensembles d'autorisations provisionnés dans ce compte, et AWS recommande d'y affecter directement des utilisateurs à des ensembles dédiés, sans groupe.

Les OU regroupent des politiques, pas l'organigramme

AWS demande de ne pas confondre les OU avec des dossiers : ce sont des cibles de politiques. On y regroupe les comptes qui ont besoin des mêmes contrôles, on applique les SCP à l'OU plutôt qu'au compte quand c'est possible, et on garde une hiérarchie peu profonde : cinq niveaux d'OU au plus sous la racine, un quota non ajustable. Une OU par service de l'organigramme reproduit la hiérarchie de l'entreprise sans refléter des besoins de sécurité ou d'exploitation partagés.

Ce qui ferait évoluer le découpage

• Une OU Transitional, pour accueillir un compte existant avant de l'intégrer : une zone d'attente temporaire, avec son propre jeu de SCP, que le compte quitte une fois ses tests passés.
• Une OU Sandbox, si l'expérimentation existe vraiment : des comptes détachés des réseaux internes, avec un budget et une alerte.
• Une OU ou un compte d'infrastructure, si un réseau partagé entre comptes existe.
• Une OU Policy Staging, dès la première SCP large : on y teste un changement de politique sur un seul compte avant de l'étendre.
• Une OU Suspended, à la première fermeture : un environnement très restreint pour les comptes suspendus ou fermés.
• Un compte de production dédié aux magasins de données sensibles, si des données personnelles ou réglementées le demandent.

Une organisation accepte 10 comptes par défaut, mais une organisation récente peut démarrer sous ce seuil, et une invitation en attente compte dans le quota. Ce quota s'ajuste dans Service Quotas, par une demande depuis le compte de gestion, à faire avant de créer les comptes.

Avant de déplacer un compte existant

• Les SCP de l'OU de destination : un compte déplacé en hérite, ce qui peut casser une fonction ou retirer une protection.
• Les Reserved Instances et Savings Plans : dans une organisation, leurs remises se partagent entre comptes, sauf si le compte de gestion désactive le partage pour un compte, et le partage doit être actif des deux côtés. Les montants qui en résultent se lisent avec « Coût facturé, coût amorti, crédits : réconcilier des montants AWS qui ne tombent jamais juste ».
• L'historique de coûts : un compte autonome qui rejoint une organisation ne voit plus dans Cost Explorer les données de sa période autonome ; AWS conseille de l'exporter (Cost and Usage Report vers un bucket) avant d'accepter l'invitation.
• La trace CloudTrail existante : avec Control Tower, une trace préexistante non supprimée avant l'enrôlement peut entraîner une double facturation.
• L'enregistreur AWS Config existant : un compte à enrôler dans Control Tower ne doit avoir ni enregistreur ni canal de livraison AWS Config ; s'il en a, AWS documente une procédure pour les ressources Config existantes, à suivre avant le lot pilote.
• Le rôle d'accès depuis le compte de gestion : Organizations ne crée pas le rôle OrganizationAccountAccessRole dans un compte invité, contrairement à un compte créé dans l'organisation. Ce rôle donne la politique AdministratorAccess sur le compte aux principaux du compte de gestion qui peuvent l'assumer.

Organizations seul ou Control Tower : ce que l'équipe garde à sa charge

AWS Organizations fournit la structure : comptes, OU, facturation consolidée et politiques. Les SCP et les politiques de contrôle des ressources (RCP, resource control policies) exigent son mode « all features », celui par défaut, plutôt que la seule facturation consolidée ; le passage à ce mode est sans retour et demande l'approbation des comptes invités. AWS Control Tower orchestre plusieurs services, dont Organizations, AWS Service Catalog et IAM Identity Center, pour construire une landing zone. AWS recommande de commencer par lui, une landing zone personnalisée demandant l'expertise nécessaire pour la gérer, la mettre à jour et l'exploiter. Dans les deux voies, l'équipe garde des responsabilités ; elles changent de forme.

La dérive Control Tower naît notamment d'un compte déplacé, d'une OU fondamentale supprimée ou déplacée, d'une SCP gérée modifiée ou d'un contrôle changé hors de Control Tower ; AWS demande de ne pas modifier les ressources qu'il gère. AFT, pipeline Terraform qui provisionne et personnalise les comptes, s'installe dans un compte de gestion AFT distinct de celui de Control Tower et ne sert pas à déployer des ressources applicatives.

Les points de décision datés

• Version de landing zone. Au 8 novembre 2026, la plus récente est la 4.0, publiée le 17 novembre 2025. Elle rend optionnelles les intégrations AWS Config, CloudTrail, Security Roles et AWS Backup, avec des dépendances entre elles (Security Roles suppose AWS Config ; IAM Identity Center et AWS Backup supposent Security Roles), n'impose plus d'OU Security (les comptes d'intégration doivent alors se trouver dans une même OU, directement sous la racine) et propose une expérience « controls only » qui applique les contrôles gérés à une organisation existante sans landing zone complète. Depuis août 2024, une mise à jour permet de choisir parmi plusieurs versions à partir de la 3.1 ; en 4.0, désactiver la journalisation centralisée retire les ressources de journalisation que Control Tower avait déployées dans le compte de journaux, et ce compte cesse d'être géré par Control Tower.
• Comportements par défaut de la 4.0. Les contrôles obligatoires, qui protègent les ressources déployées par Control Tower, ne s'appliquent plus par défaut. L'intégration AWS Config au niveau de la landing zone n'installe l'enregistrement que dans les comptes d'intégration : les contrôles détectifs, qui reposent sur des règles AWS Config, supposent d'activer la baseline AWS Config sur chaque OU gérée. Les alertes de dérive passent par EventBridge dans le compte de gestion, et non plus par une rubrique SNS : elles demandent une règle EventBridge et une cible.
• Noms des comptes partagés. Avant la 4.0, ils s'appellent par défaut « Log Archive » et « Audit » ; en 4.0, la documentation parle d'un compte administrateur CloudTrail et d'un compte agrégateur AWS Config. Cet article nomme des familles fonctionnelles : compte de journaux, compte d'outils de sécurité.
• Région d'origine. Elle ne se change plus après l'installation, sauf démantèlement de la landing zone avec le support AWS, et une région retirée de la gouvernance n'empêche pas d'y déployer. Europe (Paris) fait partie des régions prises en charge.
• Organisation existante. Control Tower s'installe sur une organisation existante, après des vérifications automatiques : il crée deux comptes partagés, ce qui demande un quota de deux comptes de plus, ou reprend des comptes existants qui passent ses vérifications, et laisse inchangées les OU non enregistrées.

Le coût à estimer

Control Tower n'entraîne aucun frais supplémentaire, pas plus qu'Organizations ou IAM Identity Center. On paie les services qu'il active, comme AWS Service Catalog et CloudTrail, et ceux qui portent les contrôles, comme les règles AWS Config, dont le coût augmente avec des charges éphémères ; Config propose un enregistrement quotidien au lieu de continu, avec un effet sur les contrôles qui en dépendent. Estimez ce coût à une date donnée, sur le périmètre, le nombre de comptes, de ressources et de régions retenus.

Ce que Control Tower ne fait pas à la place de l'équipe

Control Tower orchestre la gouvernance ; il ne conçoit ni le réseau, ni les autorisations dont l'application a besoin. D'après sa documentation, il ne crée pas l'OU Infrastructure, et l'OU Workloads s'ajoute à la main : topologie réseau, connexions entre comptes et rôles applicatifs restent des décisions à documenter. Sur une plateforme Kubernetes, la même logique consiste à encadrer les accès, les ressources, les secrets et les traces avant de donner de l'autonomie aux équipes ; la répartition des responsabilités de plateforme est traitée dans « Platform engineering pour une scale-up : par où commencer sans sur-ingénierie ».

Deux noms prêtent à confusion. Landing Zone Accelerator on AWS (LZA) est une solution open source construite avec l'AWS CDK (Cloud Development Kit), qu'AWS recommande d'ajouter à une landing zone Control Tower pour des exigences de conformité ; au 8 novembre 2026, sa dernière version est la 1.17.0, publiée le 2 novembre 2026, sans annonce de dépréciation. L'ancienne solution AWS Landing Zone (ALZ) est en support à long terme, sans nouvelle fonctionnalité prévue : AWS recommande de passer à Control Tower. Aucun de ces outils ne rend un environnement conforme par construction.

Deux scénarios comparés : SaaS simple et données sensibles

Prenons deux exemples : ils montrent comment le même socle s'étend quand les exigences changent, et ce que l'on refuse dans chaque cas.

Tester les accès, les journaux et les limites réellement appliquées

Une politique écrite ne prouve pas une limite appliquée. Trois propriétés des SCP décident de ce que l'on teste. Une SCP n'accorde aucune permission : elle borne ce que les politiques IAM peuvent accorder. Elle s'applique aux utilisateurs et aux rôles des comptes membres, y compris leur utilisateur racine et les comptes administrateurs délégués, mais ne restreint ni le compte de gestion, ni les actions faites avec les permissions d'un rôle lié à un service, ni les principaux d'un compte extérieur à l'organisation. Enfin, une autorisation explicite (Allow) doit exister à chaque niveau, de la racine au compte : la SCP gérée FullAWSAccess, attachée par défaut à chaque racine, OU et compte, la fournit, et la remplacer par une politique sans autorisation adaptée bloque toutes les actions sous ce niveau, et Organizations refuse de détacher la dernière SCP d'une racine, d'une OU ou d'un compte.

Les RCP, annoncées le 13 novembre 2024, bornent de la même façon les permissions applicables aux ressources des comptes membres, par exemple pour qu'aucun principal extérieur à l'organisation n'accède aux buckets Amazon S3 (le stockage d'objets d'AWS) ; elles n'agissent pas sur les ressources du compte de gestion, et la liste des services couverts s'allonge : relisez-la sur leur page de documentation. Les politiques déclaratives, annoncées en décembre 2024, imposent une configuration de base à un service, comme le blocage de l'accès public aux instantanés de volumes ; un rapport d'état des comptes mesure l'existant avant de les appliquer.

Tester avant d'étendre, et garder le chemin de retour

AWS recommande fortement de ne pas attacher une SCP à la racine sans avoir testé son effet, et de créer une OU où déplacer les comptes un par un. L'OU Policy Staging sert à cela : le changement s'associe d'abord à un seul compte, puis s'étend après validation. AWS recommande aussi, à la racine, une SCP qui refuse organizations:LeaveOrganization et account:CloseAccount, c'est-à-dire de quitter l'organisation et de fermer un compte. Depuis le 10 juillet 2026, une organisation créée depuis la console AWS Organizations active les SCP et reçoit cette politique à la racine par défaut ; une organisation plus ancienne, ou créée par l'API, la CLI (interface en ligne de commande) ou CloudFormation, doit l'ajouter elle-même. Le chemin de retour se documente avant le premier test : détacher une SCP modifie immédiatement les permissions des comptes concernés.

Pour les régions, Control Tower propose un refus de région au niveau de la landing zone, et un contrôle configurable au niveau d'une OU (CT.MULTISERVICE.PV.1, avec le paramètre obligatoire AllowedRegions) ; la région d'origine ne peut pas être refusée, et des services globaux comme IAM et AWS Organizations sont exemptés. Sans Control Tower, une SCP de régions autorisées, testée par l'équipe et qui exempte elle-même les services globaux, peut tenir ce rôle.

Préparer l'accès d'urgence avant l'incident

AWS documente deux mécanismes. Le premier fédère directement vers un compte d'opérations d'urgence quand IAM Identity Center est indisponible ; en temps normal, le groupe d'urgence du fournisseur d'identité n'a aucun membre, et ce mécanisme ne protège pas d'une panne du fournisseur d'identité lui-même. Le second repose sur des utilisateurs IAM dits « break-glass », exception à la règle d'éviter les utilisateurs IAM : au moins deux, avec une authentification multifacteur (MFA) matérielle, une garde séparée du mot de passe et de la clé MFA, et une alerte à chaque usage. Dans les deux cas, la procédure s'écrit et s'exerce avant d'en avoir besoin.

La gestion centralisée de l'accès racine des comptes membres permet en outre de supprimer leurs identifiants racine à long terme : une tâche privilégiée passe alors par une session de 15 minutes au plus, lancée depuis le compte de gestion ou un administrateur délégué.

Dix tests d'acceptation

Chaque ligne décrit une action à exécuter, le résultat attendu et la preuve à conserver. Les tests de refus utilisent des actions sans effet de bord, un compte de test placé dans l'OU Policy Staging, ou une remise en état prévue si l'action réussit.

Relier chaque décision à sa justification, à son propriétaire et à sa preuve

Conservez chaque preuve avec la date de la décision.

Faire entrer le compte existant, puis tenir la structure chaque mois

Rattacher un compte à l'organisation, puis l'enrôler dans Control Tower, lui applique une gouvernance : aucune ressource ne bouge. Migrer des ressources est une autre opération, car elles ne se transfèrent pas directement d'un compte à l'autre : une instance EC2 passe par une image de machine (AMI, Amazon Machine Image) partagée puis un nouveau lancement, une base RDS par un instantané partagé puis restauré dans le compte cible. Séparer les deux opérations permet d'attribuer un échec à l'une ou à l'autre.

La séquence pour une équipe installée dans un seul compte

1. Créer un nouveau compte, qui devient le compte de gestion, plutôt que de créer l'organisation depuis le compte existant : AWS le recommande, et les charges en place restent intactes.
2. Inventorier les dépendances du compte existant selon la liste du chapitre 2, puis exporter l'historique de coûts avant d'accepter l'invitation.
3. Inviter le compte depuis le compte de gestion. L'invitation expire après 15 jours ; un compte membre d'une autre organisation doit d'abord la quitter ; dès l'acceptation, le compte de gestion devient responsable de ses frais.
4. Créer, si l'équipe en a besoin, le rôle OrganizationAccountAccessRole dans le compte invité. Il donne AdministratorAccess sur un compte qui héberge la production : il devient facultatif une fois les accès passés par IAM Identity Center, et la liste des principaux qui peuvent l'assumer se restreint.
5. Placer d'abord le compte dans une OU Transitional, depuis le compte de gestion : il mélange production et test, aucune OU Prod ou NonProd ne lui convient encore, et il hérite des SCP de cette zone d'attente. Pour l'enrôler manuellement dans Control Tower, sans inscription automatique, le rôle AWSControlTowerExecution doit exister et l'OU de destination être enregistrée ; dans tous les cas, ses ressources AWS Config existantes se traitent avant, et une SCP de cette OU peut faire échouer l'enrôlement. Le compte ne rejoint l'OU de production qu'une fois les tests du chapitre 4 passés.
6. Nettoyer les identités du compte existant : inventorier les utilisateurs IAM et leurs clés d'accès, faire passer les accès humains par IAM Identity Center, supprimer les identifiants racine du compte par la gestion centralisée de l'accès racine, et conserver ou migrer l'historique S3 de l'ancienne trace CloudTrail avant de supprimer celle-ci.
7. Ne déplacer des ressources qu'en projet séparé, par recréation, partage d'image ou d'instantané.

Avec l'inscription automatique de Control Tower, annoncée à l'automne 2025 pour les landing zones 3.1 ou plus récentes et à activer dans les paramètres de la landing zone, un compte déplacé vers une OU enregistrée en reçoit les baselines et les contrôles, après un délai de quelques minutes à plusieurs heures ; déplacé vers une OU non enregistrée ou vers la racine, il les perd. Sans ce réglage, un déplacement laisse une dérive d'héritage à résoudre à la main. La reprise de l'infrastructure existante dans du code est décrite dans « Terraform import : reprendre une infrastructure AWS existante sans la recréer ».

Lot pilote et conditions d'arrêt

Le premier lot porte sur un compte de non-production nouvellement créé et précède le rattachement du compte qui héberge la production. Ses conditions d'arrêt s'écrivent avant de commencer : un refus d'accès inattendu en production, une trace absente du compte de journaux, une dérive signalée sans résolution connue, un enrôlement qui échoue à cause d'une SCP. Le lot se valide en rejouant les tests du chapitre 4 sur le périmètre concerné, avant de passer au compte suivant.

Les responsabilités de chaque mois

Une landing zone ne s'arrête pas à l'installation. Chaque mois, passez en revue :

• Nouveaux comptes : un propriétaire, une OU, une fiche à jour, une création par le chemin standard (test T10).
• Contrôles en dérive : relevés et résolus ; avec Control Tower, la détection est automatique et la résolution manuelle, sauf la dérive d'héritage reprise par l'inscription automatique quand elle est activée. En 4.0, vérifier que la règle EventBridge de dérive du compte de gestion existe et livre ses notifications à une cible suivie.
• Identités : affectations revues, accès en écriture à la production justifiés, dernier exercice d'accès d'urgence daté (test T8).
• Budgets : un budget par compte, ou par catégorie de coûts regroupant les comptes d'une OU, et des écarts expliqués.
• Exceptions : SCP et régions accordées par exception, chacune avec sa date de fin.
• Version de landing zone : version disponible comparée à la version installée.
• Comptes à fermer : un compte membre fermé reste réouvrable par le support pendant 90 jours et compte pendant ce temps dans le quota de comptes de l'organisation, sauf s'il en a été retiré avant sa fermeture ; les fermetures sont aussi limitées par un quota sur 30 jours glissants, à vérifier sur la page des quotas.

Un compte de non-production dont les accès, les journaux et les politiques suivent ceux de la production rend aussi une répétition de mise en production représentative. C'est le point de départ de la page Mise en production Kubernetes : ouvrir par étapes : nous commençons par vérifier que le service peut être observé et redéployé, nous rejouons le déploiement sur un environnement représentatif et nous exécutons le chemin de retour sur ce même périmètre, en adaptant les contrôles à l'état de départ.

Sources officielles et limites de lecture

Les faits cités proviennent de la documentation officielle d'AWS (guides des services, livre blanc « Organizing Your AWS Environment Using Multiple Accounts », AWS Prescriptive Guidance, cadre Well-Architected), d'annonces datées d'AWS, d'un article du Knowledge Center d'AWS et du dépôt officiel de Landing Zone Accelerator on AWS.

Les quotas des SCP, la version de landing zone, la liste des services couverts par les RCP et la version de LZA évoluent : relisez-les le jour de la mise en œuvre.

Sources

1. Qu'est-ce qu'une zone d'atterrissage ? (Conseils prescriptifs AWS), Amazon Web Services, https://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html, consulté le 08/11/2026.
2. Création d'une zone d'atterrissage (Conseils prescriptifs AWS), Amazon Web Services, https://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html, consulté le 08/11/2026.
3. Benefits of using multiple AWS accounts (Organizing Your AWS Environment Using Multiple Accounts), Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html, consulté le 08/11/2026.
4. Recommended OUs and accounts, Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous-and-accounts.html, consulté le 08/11/2026.
5. Foundational OUs (Security OU, Log Archive et Security Tooling), Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/foundational-ous.html, consulté le 08/11/2026.
6. Application OUs (Workloads OU), Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/application-ous.html, consulté le 08/11/2026.
7. Advanced OUs (OU structure for non-production environments), Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/advanced-ous.html, consulté le 08/11/2026.
8. Procedural OUs (Transitional, Policy Staging et Suspended OU), Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/procedural-ous.html, consulté le 08/11/2026.
9. Organizing Your AWS Environment Using Multiple Accounts, version PDF (section Break glass access), Amazon Web Services, https://docs.aws.amazon.com/pdfs/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.pdf, consulté le 08/11/2026.
10. Best practices for managing organizational units (OUs) with AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html, consulté le 08/11/2026.
11. Design principles for your multi-account strategy, Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html, consulté le 08/11/2026.
12. Quotas and service limits for AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html, consulté le 08/11/2026.
13. Best practices for the management account, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html, consulté le 08/11/2026.
14. COST02-BP03 Implement an account structure (AWS Well-Architected Framework), Amazon Web Services, https://docs.aws.amazon.com/wellarchitected/2025-02-25/framework/cost_govern_usage_account_structure.html, consulté le 08/11/2026.
15. Multi Account Strategy (Amazon EKS Best Practices), Amazon Web Services, https://docs.aws.amazon.com/eks/latest/best-practices/multi-account-strategy.html, consulté le 08/11/2026.
16. Cross-account policy evaluation logic (IAM), Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html, consulté le 08/11/2026.
17. Silo isolation (SaaS Lens), Amazon Web Services, https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html, consulté le 08/11/2026.
18. Silo, Pool, and Bridge Models (SaaS Lens), Amazon Web Services, https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-pool-and-bridge-models.html, consulté le 08/11/2026.
19. Tier-based isolation (SaaS Lens), Amazon Web Services, https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/tier-based-isolation.html, consulté le 08/11/2026.
20. Budget filters, Amazon Web Services, https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create-filters.html, consulté le 08/11/2026.
21. Managing your costs with AWS Budgets, Amazon Web Services, https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html, consulté le 08/11/2026.
22. Configuring budget actions, Amazon Web Services, https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html, consulté le 08/11/2026.
23. AWS Cost Categories FAQs, Amazon Web Services, https://aws.amazon.com/aws-cost-management/aws-cost-categories/faqs/, consulté le 08/11/2026.
24. Service control policies (SCPs), Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html, consulté le 08/11/2026.
25. SCP evaluation, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html, consulté le 08/11/2026.
26. AWS Organizations now supports higher quotas for service control policies (SCPs), Amazon Web Services, https://aws.amazon.com/about-aws/whats-new/2026/05/aws-organizations-increased-scp-quotas/, consulté le 08/11/2026.
27. DetachPolicy (AWS Organizations API), Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/APIReference/API_DetachPolicy.html, consulté le 08/11/2026.
28. Detaching an SCP (AWS Organizations), Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_detach.html, consulté le 08/11/2026.
29. Default security controls in AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_security_default_controls.html, consulté le 08/11/2026.
30. AWS Organizations now applies account departure security controls by default for new organizations created via AWS Organizations console, Amazon Web Services, https://aws.amazon.com/about-aws/whats-new/2026/07/aws-organizations-security-controls-new-orgs-console/, consulté le 08/11/2026.
31. Resource control policies (RCPs), Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html, consulté le 08/11/2026.
32. Introducing resource control policies (RCPs) to centrally restrict access to AWS resources, Amazon Web Services, https://aws.amazon.com/about-aws/whats-new/2024/11/resource-control-policies-restrict-access-aws-resources/, consulté le 08/11/2026.
33. Amazon Web Services announces declarative policies, Amazon Web Services, https://aws.amazon.com/about-aws/whats-new/2024/12/aws-declarative-policies/, consulté le 08/11/2026.
34. Declarative policies in AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_policies.html, consulté le 08/11/2026.
35. Generating the account status report for EC2 policies, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ec2_status-report.html, consulté le 08/11/2026.
36. Terminology and concepts for AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html, consulté le 08/11/2026.
37. Enabling all features for an organization, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html, consulté le 08/11/2026.
38. Consolidating billing for AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html, consulté le 08/11/2026.
39. What Is AWS Control Tower?, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html, consulté le 08/11/2026.
40. Optionally self-manage AWS account access (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/select-idp.html, consulté le 08/11/2026.
41. January to December 2023 (notes de version AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/2023-all.html, consulté le 08/11/2026.
42. Control behavior and guidance (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/controlreference/control-behavior.html, consulté le 08/11/2026.
43. About logging in AWS Control Tower, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/about-logging.html, consulté le 08/11/2026.
44. Best practices for landing zone updates (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/lz-update-best-practices.html, consulté le 08/11/2026.
45. Creating a trail for an organization (AWS CloudTrail), Amazon Web Services, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html, consulté le 08/11/2026.
46. Organization delegated administrator (AWS CloudTrail), Amazon Web Services, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-delegated-administrator.html, consulté le 08/11/2026.
47. Validating CloudTrail log file integrity, Amazon Web Services, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html, consulté le 08/11/2026.
48. Types of governance drift (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/governance-drift.html, consulté le 08/11/2026.
49. Resolving drift (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/resolving-drift.html, consulté le 08/11/2026.
50. Overview of AWS Control Tower Account Factory for Terraform (AFT), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html, consulté le 08/11/2026.
51. Configuration update management in AWS Control Tower, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/configuration-updates.html, consulté le 08/11/2026.
52. January 2026 to Present (notes de version AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/2026-all.html, consulté le 08/11/2026.
53. Key changes (landing zone 4.0), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/key-changes-lz-v4.html, consulté le 08/11/2026.
54. Landing Zone v4.0 migration guide, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/landing-zone-v4-migration-guide.html, consulté le 08/11/2026.
55. AWS Control Tower launches landing zone version selection, Amazon Web Services, https://aws.amazon.com/about-aws/whats-new/2024/08/aws-control-tower-landing-zone-version-selection/, consulté le 08/11/2026.
56. Select a landing zone version (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/lz-version-selection.html, consulté le 08/11/2026.
57. Service integration accounts (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/special-accounts.html, consulté le 08/11/2026.
58. How AWS Regions Work With AWS Control Tower, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html, consulté le 08/11/2026.
59. Configure the Region deny control (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html, consulté le 08/11/2026.
60. Region deny control applied to the OU (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html, consulté le 08/11/2026.
61. AWS Control Tower endpoints and quotas, Amazon Web Services, https://docs.aws.amazon.com/general/latest/gr/controltower.html, consulté le 08/11/2026.
62. Extend governance to an existing organization (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/about-extending-governance.html, consulté le 08/11/2026.
63. Prerequisite: Automated pre-launch checks for your management account (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-prereqs.html, consulté le 08/11/2026.
64. AWS Control Tower Pricing, Amazon Web Services, https://aws.amazon.com/controltower/pricing/, consulté le 08/11/2026.
65. AWS Control Tower FAQs, Amazon Web Services, https://aws.amazon.com/controltower/faqs/, consulté le 08/11/2026.
66. Manage AWS Config costs in AWS Control Tower, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/config-costs.html, consulté le 08/11/2026.
67. Recording AWS Resources with AWS Config, Amazon Web Services, https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html, consulté le 08/11/2026.
68. AWS multi-account strategy for your AWS Control Tower landing zone, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html, consulté le 08/11/2026.
69. Landing Zone Accelerator on AWS (page solution), Amazon Web Services, https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/, consulté le 08/11/2026.
70. Landing Zone Accelerator on AWS, solution overview, Amazon Web Services, https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/solution-overview.html, consulté le 08/11/2026.
71. awslabs/landing-zone-accelerator-on-aws (releases), Amazon Web Services (GitHub), https://github.com/awslabs/landing-zone-accelerator-on-aws/releases, consulté le 08/11/2026.
72. Walkthrough: Move from ALZ to AWS Control Tower, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/alz-to-control-tower.html, consulté le 08/11/2026.
73. Workforce identity management (AWS Prescriptive Guidance), Amazon Web Services, https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture-identity-management/workforce-identity-management.html, consulté le 08/11/2026.
74. Security best practices in IAM, Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html, consulté le 08/11/2026.
75. Create a permission set (IAM Identity Center), Amazon Web Services, https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocreatepermissionset.html, consulté le 08/11/2026.
76. Delegated administration (IAM Identity Center), Amazon Web Services, https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html, consulté le 08/11/2026.
77. Set up emergency access to the AWS Management Console (IAM Identity Center), Amazon Web Services, https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html, consulté le 08/11/2026.
78. Centralize root access for member accounts (IAM), Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html, consulté le 08/11/2026.
79. Perform a privileged task on an AWS Organizations member account (IAM), Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html, consulté le 08/11/2026.
80. Creating Aggregators for AWS Config, Amazon Web Services, https://docs.aws.amazon.com/config/latest/developerguide/aggregated-create.html, consulté le 08/11/2026.
81. Set up an organization (Transitioning to multiple AWS accounts), Amazon Web Services, https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/set-up-organization.html, consulté le 08/11/2026.
82. Billing considerations (Transitioning to multiple AWS accounts), Amazon Web Services, https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/billing-considerations.html, consulté le 08/11/2026.
83. Managing account invitations with AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html, consulté le 08/11/2026.
84. Migrate an account to another organization, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_account_migration.html, consulté le 08/11/2026.
85. Creating OrganizationAccountAccessRole for an invited account, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create-cross-account-role.html, consulté le 08/11/2026.
86. Reserved Instances (AWS Billing), Amazon Web Services, https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-behavior.html, consulté le 08/11/2026.
87. MoveAccount (AWS Organizations API), Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/APIReference/API_MoveAccount.html, consulté le 08/11/2026.
88. Move and enroll accounts with auto-enrollment (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/account-auto-enrollment.html, consulté le 08/11/2026.
89. AWS Control Tower supports automatic enrollment of accounts, Amazon Web Services, https://aws.amazon.com/about-aws/whats-new/2025/11/aws-control-tower-automatic-enrollment/, consulté le 08/11/2026.
90. Update and move accounts with AWS Control Tower, Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/updating-account-factory-accounts.html, consulté le 08/11/2026.
91. About enrolling existing accounts (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html, consulté le 08/11/2026.
92. Prerequisites for enrollment (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/enrollment-prerequisites.html, consulté le 08/11/2026.
93. Troubleshooting (AWS Control Tower), Amazon Web Services, https://docs.aws.amazon.com/controltower/latest/userguide/troubleshooting.html, consulté le 08/11/2026.
94. Resource migration (Transitioning to multiple AWS accounts), Amazon Web Services, https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/resource-migration.html, consulté le 08/11/2026.
95. Transfer ownership of Amazon RDS resources to a different AWS account (Knowledge Center), Amazon Web Services, https://repost.aws/knowledge-center/account-transfer-rds, consulté le 08/11/2026.
96. Close an AWS account (AWS Account Management), Amazon Web Services, https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html, consulté le 08/11/2026.