Diagramme de landing zone AWS : architecture multicompte avec Organizations et Control Tower

Un seul compte AWS pour tout fonctionne, jusqu'au jour où ça ne fonctionne plus. Un script de test supprime un bucket de production. La finance ne peut pas répartir la facture par équipe. Un auditeur demande qui peut modifier les journaux d'audit, et la réponse honnête est « toute personne ayant des droits d'admin ». Une landing zone est la fondation multicompte que vous posez avant l'arrivée des workloads : la structure des comptes, l'identité, les garde-fous, la journalisation et le réseau dont hérite chaque nouveau compte.

Cet article parcourt la conception d'une landing zone à l'aide d'un diagramme : pourquoi plusieurs comptes, les unités d'organisation recommandées, les comptes principaux, les garde-fous avec les politiques de contrôle des services (SCP), les politiques de contrôle des ressources (RCP) et les politiques déclaratives, l'identité, la journalisation centrale et les outils de sécurité, le réseau, et comment tout construire avec Control Tower, y compris ce qui a changé dans la landing zone 4.0, ou avec Terraform.

Pourquoi plusieurs comptes

Un compte AWS est la frontière d'isolation la plus forte qu'offre AWS. Les permissions IAM, les quotas de service, les coûts et la plupart des pannes s'arrêtent à sa limite. Des comptes séparés vous apportent :

• Un rayon d'impact limité. Une erreur ou des identifiants compromis dans une sandbox ne peuvent pas toucher la production.
• Une responsabilité et une facturation claires par équipe, application ou environnement.
• Des permissions plus simples. Au lieu d'un compte rempli de conditions sur des tags, chaque compte reçoit l'accès dont son équipe a besoin.
• Des quotas indépendants, pour que le test de charge d'une équipe n'épuise pas les limites d'une autre.

Le prix à payer est la coordination : identité, journalisation, garde-fous et réseau doivent fonctionner sur des dizaines de comptes. C'est cette coordination qu'apporte une landing zone.

La structure : les unités d'organisation

AWS Organizations regroupe les comptes en unités d'organisation (OU), et les politiques attachées à une OU s'appliquent à chaque compte en dessous. Le livre blanc d'AWS sur l'organisation de votre environnement recommande un ensemble d'OU de départ :

Divisez tôt Workloads en sous-OU Prod et Non-prod. Les garde-fous y diffèrent, et déplacer des comptes plus tard est pénible. Ajoutez une OU Suspended avec une politique qui refuse tout pour les comptes en attente de fermeture.

Le compte de gestion

Le compte de gestion possède l'organisation, la facturation consolidée et Control Tower. Gardez-en les workloads à l'écart, pour une raison décisive : les SCP n'affectent pas les utilisateurs ni les rôles du compte de gestion, comme l'indique la documentation d'Organizations. Rien de ce que vous y déployez n'est contraint par vos garde-fous ; donnez-lui donc aussi peu d'utilisateurs et de ressources que possible.

Les comptes principaux

• Log Archive. Reçoit le trail CloudTrail de l'organisation et l'historique AWS Config dans S3. Presque personne n'a d'accès en écriture ou en suppression ; envisagez S3 Object Lock pour que même les administrateurs ne puissent pas modifier les journaux.
• Security Tooling, aussi appelé Audit. L'administrateur délégué de GuardDuty, Security Hub, IAM Access Analyzer et de l'agrégateur AWS Config, pour que l'équipe sécurité voie tous les comptes depuis un seul endroit sans accès au compte de gestion.
• Network. Possède le Transit Gateway, la connectivité privée vers les datacenters, les résolveurs DNS et la gestion des adresses IP, partagés avec les comptes de workloads via AWS Resource Access Manager.
• Shared Services. CI/CD, dépôts d'artefacts et autres outils utilisés par de nombreuses équipes.

Les garde-fous : SCP, RCP et politiques déclaratives

Organizations propose plusieurs types de politiques, qui répondent à des questions différentes :

Les politiques ne font que restreindre ; elles n'accordent jamais de permissions. Commencez par une courte liste de garde-fous à forte valeur :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

Les restrictions de région sont populaires et faciles à mal faire, car les services globaux comme IAM doivent rester autorisés. Testez chaque nouvelle politique sur une OU de préproduction contenant un compte représentatif avant de l'attacher à Workloads.

Control Tower présente les garde-fous sous forme de contrôles de trois types : des contrôles préventifs mis en œuvre avec des SCP et des RCP, des contrôles de détection mis en œuvre avec des règles AWS Config, et des contrôles proactifs qui vérifient les ressources avant que CloudFormation ne les crée.

L'identité

Les personnes ne devraient jamais avoir d'utilisateurs IAM avec des clés de longue durée dans les comptes de workloads. Connectez IAM Identity Center à votre fournisseur d'identité d'entreprise, provisionnez utilisateurs et groupes avec SCIM et donnez l'accès via des ensembles d'autorisations assignés à des groupes par compte : par exemple, les développeurs ont un accès power-user en Non-prod et en lecture seule en Prod.

Gardez deux identités de secours (break-glass) avec MFA matérielle, conservées hors ligne et surveillées. Pour les utilisateurs root, IAM peut désormais gérer de façon centralisée l'accès root des comptes membres, une fonction introduite en novembre 2024 : vous pouvez supprimer entièrement les identifiants root des comptes membres et effectuer les quelques tâches réservées au root depuis un point central.

Journalisation et détection

1. Un trail d'organisation dans CloudTrail enregistre l'activité API de chaque compte et de chaque région dans le compte Log Archive.
2. AWS Config enregistre la configuration des ressources partout, avec un agrégateur dans Security Tooling.
3. GuardDuty et Security Hub sont activés dans toute l'organisation, avec Security Tooling comme administrateur délégué, pour que les nouveaux comptes soient couverts automatiquement.
4. Les résultats partent vers votre SIEM ou vos outils d'astreinte.

Le réseau

Les comptes de workloads possèdent leurs VPC, mais pas leur connectivité. Le compte Network fournit un Transit Gateway partagé via Resource Access Manager, une sortie et une inspection centralisées, la résolution DNS entre le cloud et le datacenter, et un plan d'adressage IP, idéalement géré avec Amazon VPC IP Address Manager pour qu'aucun VPC ne se chevauche. Le diagramme de VPC AWS couvre ce qui se trouve dans chaque VPC de workload, et le diagramme d'architecture AWS multirégion l'extension de la conception à plusieurs régions.

La construction : Control Tower ou Terraform

AWS Control Tower met en place l'organisation, les comptes principaux, un trail d'organisation, Config et un catalogue de contrôles, et fournit Account Factory pour créer de nouveaux comptes. La landing zone version 4.0, publiée le 17 novembre 2025, l'a rendu nettement plus flexible, selon les notes de version de Control Tower :

• Les intégrations AWS Config, CloudTrail, des rôles de sécurité et d'AWS Backup sont devenues facultatives.
• Une OU Security n'est plus obligatoire ; vous pouvez définir votre propre structure d'OU.
• Une configuration minimale peut se limiter à l'intégration Organizations et aux contrôles.
• Config et CloudTrail reçoivent des ressources dédiées, et un agrégateur Config lié au service remplace l'ancienne agrégation.

Les équipes Terraform combinent souvent Control Tower avec Account Factory for Terraform (AFT), qui provisionne et personnalise les comptes à partir d'un dépôt Git. Depuis septembre 2026, AFT peut exécuter les personnalisations en mode plan uniquement pour prévisualiser les changements avant de les appliquer. D'autres gèrent Organizations entièrement avec Terraform, ou utilisent la solution Landing Zone Accelerator on AWS. Les trois fonctionnent ; l'essentiel est que la création de comptes soit automatisée et reproductible.

La distribution de comptes

Les nouveaux comptes doivent arriver prêts à l'emploi : une demande, souvent une pull request, crée le compte dans la bonne OU, applique la base (affectations Identity Center, budgets et alertes, un VPC rattaché au Transit Gateway, services de sécurité par défaut) et le remet à l'équipe. Organizations limite par défaut une organisation à 10 comptes, ajustable via Service Quotas ; demandez donc une augmentation avant d'en avoir besoin.

Erreurs courantes

• Des workloads dans le compte de gestion, où aucune SCP ne s'applique.
• Une seule OU Workloads à plat, si bien que production et développement partagent les mêmes garde-fous.
• Des garde-fous écrits après que les équipes ont bâti sur des hypothèses qu'ils cassent.
• Un compte Log Archive que les administrateurs peuvent modifier.
• Des comptes créés à la main, tous légèrement différents.

Le diagramme de landing zone

Comment le lire :

• Le compte de gestion en haut porte l'organisation et les politiques ; ses arêtes vers chaque OU sont des rattachements de garde-fous.
• L'OU Security contient Log Archive, qui reçoit les journaux de tous les comptes, et Security Tooling, qui administre GuardDuty et Security Hub.
• L'OU Infrastructure contient le compte Network, dont le Transit Gateway relie les VPC des workloads, et Shared Services pour la CI/CD.
• L'OU Workloads sépare les comptes Prod et Non-prod ; l'OU Sandbox reste isolée.
• IAM Identity Center, à droite, donne l'accès aux personnes via des ensembles d'autorisations.
• Le bloc Markdown liste les garde-fous de départ.

Dessiner clairement une structure de comptes

• Dessinez les OU comme des conteneurs et placez-y les comptes ; la hiérarchie est le modèle de politiques.
• Montrez le compte de gestion à part. Il est hors de vos garde-fous, et l'image doit le dire.
• Ne dessinez que les flux qui traversent les comptes : journaux vers l'archive, rattachements réseau, administration déléguée, identité.
• Nommez les comptes par fonction, pas par numéro de compte.

Pour le modèle de sécurité sous-jacent, voyez le diagramme d'architecture zero trust. Si vous gérez l'infrastructure en tant que code, le diagramme d'architecture Terraform montre comment dessiner des environnements gérés avec Terraform.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un nœud Politique du pack Sécurité pour le compte de gestion et un Fournisseur d'identité pour IAM Identity Center.
3. Ajoutez quatre nœuds Cadre du pack Base pour les OU : Security, Infrastructure, Workloads et Sandbox.
4. Dans Security, ajoutez un nœud Stockage objet du pack Cloud pour Log Archive et un nœud Alerte du pack DevOps pour Security Tooling. Dans Infrastructure, ajoutez un Routeur du pack Réseau pour le compte Network et un Pipeline CI/CD du pack DevOps pour Shared Services.
5. Ajoutez des nœuds Instance de calcul du pack Cloud pour les comptes Prod, Non-prod et Sandbox.
6. Reliez le compte de gestion à chaque OU, les comptes à Log Archive et le compte Network aux workloads, puis ajoutez un bloc Markdown du pack Base avec les garde-fous.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Qu'est-ce qu'une landing zone AWS ? Un environnement AWS multicompte configuré selon vos standards de sécurité et d'exploitation avant l'arrivée des workloads : unités d'organisation, comptes principaux, identité, garde-fous, journalisation et réseau.

Faut-il AWS Control Tower pour une landing zone ? Non. Control Tower est la façon managée d'en construire une, et la version 4.0 l'a rendu plus flexible. Vous pouvez aussi gérer Organizations avec Terraform, Account Factory for Terraform ou le Landing Zone Accelerator.

Quelle est la différence entre une SCP et une RCP ? Une SCP limite ce que les principaux des comptes membres peuvent faire. Une RCP limite ce qui peut être fait aux ressources des comptes membres, par exemple en empêchant le partage de buckets hors de l'organisation. Aucune des deux n'accorde de permissions.

Pourquoi le compte de gestion doit-il rester vide ? Les SCP ne s'appliquent pas aux utilisateurs et rôles du compte de gestion ; tout ce qui s'y trouve échappe donc à vos garde-fous. Il contrôle aussi la facturation et l'organisation elle-même, ce qui en fait le compte le plus sensible que vous ayez.

Combien de comptes une organisation peut-elle avoir ? Dix par défaut. Le quota est ajustable via Service Quotas, et seul le compte de gestion peut demander l'augmentation.

Commencez gratuitement — un siège, sans carte bancaire.