Aller au contenu

AWS Mis à jour le 2026-07-04

Mise en place d'une landing zone AWS : la fondation multi-compte propre avant que la croissance devienne le bordel

La mise en place d'une landing zone AWS vous donne la structure de comptes, la journalisation, l'identité et les garde-fous dont hérite chaque charge de travail qui suit. Voici ce qu'une landing zone contient vraiment et comment la monter avec Control Tower.

Une landing zone, c’est la partie d’un environnement AWS qu’on bâtit avant les charges de travail : la structure de comptes, la journalisation centralisée, l’identité et les garde-fous dont tout ce qui se déploie ensuite hérite automatiquement. Montez-la tôt et chaque nouveau projet atterrit dans un compte gouverné avec CloudTrail, l’authentification unique et les alarmes budgétaires déjà en place. Sautez-la, et dix-huit mois plus tard vous greffez de la gouvernance sur des comptes qui ont poussé tout croche — ce qui coûte bien plus que les deux ou trois jours que la landing zone aurait pris. AWS Control Tower est la façon gérée d’en monter une; la décision porte surtout sur le moment et sur le degré de personnalisation nécessaire.

Ce qui se passe

Une landing zone n’est pas un produit, c’est un paquet de décisions prises une fois et appliquées automatiquement. Concrètement : une Organization AWS avec un compte de gestion délibérément vide; un compte Log Archive où l’historique CloudTrail et AWS Config de chaque compte s’accumule, immuable et hors de portée des identifiants des charges de travail; un compte Audit pour l’outillage de sécurité avec un accès en lecture inter-compte; une structure d’OU qui sépare la production du bac à sable; des garde-fous SCP qui fixent des plafonds de permissions; IAM Identity Center pour que les humains obtiennent des sessions SSO de courte durée au lieu d’utilisateurs IAM permanents; et une façon répétable de créer de nouveaux comptes qui naissent gouvernés.

Control Tower assemble tout ça pour vous. Il crée l’OU Security avec les comptes Log Archive et Audit, active un journal d’organisation, applique un ensemble de contrôles de départ — les préventifs implantés en SCP, les détectifs en règles AWS Config, les proactifs qui vérifient les ressources CloudFormation avant le provisionnement — et vous donne Account Factory pour distribuer de nouveaux comptes. Ce que Control Tower n’est pas : un outil de migration (les comptes existants doivent être inscrits délibérément), un produit de sécurité (il impose la structure, pas la sécurité des charges de travail), ni une infrastructure optionnelle qu’on éteint à la légère une fois adoptée.

Quoi vérifier en premier

  • Si une Organization existe déjà et dans quel état. Control Tower peut s’installer dans une Organization existante, mais des SCP en conflit et des enregistreurs Config déjà présents dans les comptes membres sont les sources classiques de friction à l’installation.
  • Votre région d’attache. Control Tower s’installe dans une région d’attache et gouverne une liste de régions que vous choisissez; prenez celle où vos charges de travail roulent vraiment — pour des exigences canadiennes de résidence des données, c’est habituellement ca-central-1 — parce qu’en changer plus tard est pénible.
  • Les adresses courriel des nouveaux comptes partagés. Log Archive et Audit ont chacun besoin d’un courriel racine unique; préparez des adresses fonctionnelles plutôt que de les inventer en plein assistant.
  • La configuration existante d’IAM Identity Center. Control Tower s’y intègre; une instance déjà configurée dans une autre région est un bloqueur fréquent.
  • Qui a présentement l’admin partout. La landing zone changera la façon dont les humains accèdent aux comptes; sachez à qui vous êtes sur le point de modifier le quotidien.

Comment vérifier

Si vous héritez d’un environnement sans savoir si une landing zone existe ou a dérivé :

# Y a-t-il une Organization, et quels comptes en font partie?
aws organizations describe-organization
aws organizations list-accounts \
  --query 'Accounts[].[Id,Name,Email,Status]' --output table

# Quels contrôles Control Tower applique-t-il réellement sur une OU?
aws controltower list-enabled-controls \
  --target-identifier arn:aws:organizations::111122223333:ou/o-exampleorgid/ou-exampleouid

# Le journal d'organisation est-il vivant?
aws cloudtrail describe-trails --query 'trailList[].[Name,IsOrganizationTrail,HomeRegion]'
aws cloudtrail get-trail-status --name aws-controltower-BaselineCloudTrail

Dans la console, Control Tower > Landing zone settings montre la version de la landing zone et si elle a besoin d’une mise à jour, et le tableau de bord signale la dérive — des comptes ou des politiques modifiés à l’insu de Control Tower. La dérive n’est pas cosmétique : une dérive non résolue bloque les mises à jour de la landing zone.

La marche à suivre

  1. Décidez le squelette d’OU avant l’assistant. Control Tower crée une OU Security; vous ajoutez le reste. Workloads/Prod, Workloads/NonProd et Sandbox est un départ éprouvé. Les OU existent pour porter des politiques — créez-les pour des différences de politiques, pas pour des départements.
  2. Lancez l’installation de Control Tower depuis le compte de gestion. Choisissez la région d’attache, les régions gouvernées (activez le contrôle de refus de région si la résidence des données compte), et fournissez les courriels des comptes Log Archive et Audit. L’installation prend moins d’une heure d’horloge.
  3. Inscrivez les comptes existants un à la fois. L’inscription applique les bases de référence et exige le rôle AWSControlTowerExecution dans le compte cible. Testez d’abord sur le compte le moins critique : les enregistreurs Config préexistants sont l’échec d’inscription habituel et doivent être retirés ou réconciliés avant.
  4. Superposez vos propres SCP aux contrôles gérés. Les contrôles obligatoires de Control Tower protègent sa propre plomberie; vos besoins de politiques — interdire de toucher à CloudTrail, restrictions de régions, blocage des services jamais utilisés — vont dans des SCP additionnelles, gardées en contrôle de version. Un ensemble fonctionnel est dans la base de référence SCP pour Organizations.
  5. Branchez l’identité. Définissez les ensembles de permissions dans IAM Identity Center (admin, utilisateur avancé, lecture seule), mappez les groupes depuis votre fournisseur d’identité, et commencez à retirer les utilisateurs IAM par compte pour les humains.
  6. Standardisez la distribution de comptes. Les nouveaux comptes viennent d’Account Factory avec les bases de référence appliquées à la naissance — la liste de vérification qui rend chaque compte distribué prêt pour la production est dans Control Tower Account Factory.
  7. Planifiez les mises à jour de la landing zone. Les versions de Control Tower avancent; rester plusieurs versions en arrière rend chaque mise à jour plus risquée. Mettez une vérification trimestrielle au calendrier — c’est le travail de propriété récurrent qui sépare une landing zone entretenue d’une landing zone abandonnée.

Quand c’est la mauvaise approche

Un fondateur solo avec un compte et une charge de travail n’a pas besoin de Control Tower ce trimestre-ci — un compte unique bien tenu avec CloudTrail, MFA et des budgets se défend jusqu’à l’arrivée de la deuxième équipe ou de la première exigence de conformité. À l’autre bout, les organisations aux besoins de personnalisation lourds (réseau sur mesure dans chaque compte, topologies de régions inhabituelles) dépassent parfois les valeurs par défaut d’Account Factory et jumellent Control Tower avec des personnalisations en infrastructure-code, ou montent plutôt une landing zone en Terraform — plus de contrôle, et nettement plus d’ingénierie à entretenir. Et si vos comptes sont déjà en pleine prolifération non gouvernée, la consolidation sous Organizations vient d’abord; une landing zone suppose que les comptes répondent à un seul compte de gestion.

Erreurs courantes

  • Des charges de travail dans le compte de gestion. Les SCP ne s’y appliquent pas, et Control Tower suppose qu’il reste propre. Cette erreur coûte cher à renverser.
  • Choisir la région d’attache à la légère. La région d’attache héberge les ressources propres de la landing zone; la traiter comme un détail crée des questions de résidence et de latence plus tard.
  • Ignorer les avertissements de dérive. Des changements manuels aux SCP gérées ou aux comptes partagés mettent la landing zone en dérive, et la dérive s’accumule jusqu’à faire échouer les mises à jour.
  • Traiter l’installation comme la ligne d’arrivée. Une landing zone dont les versions ne sont jamais mises à jour, les contrôles jamais revus et les comptes distribués jamais audités se dégrade dès le premier jour.

Garder le contrôle

  • Passez en revue le tableau de bord Control Tower pour la dérive et les ressources non conformes chaque mois.
  • Gardez les SCP personnalisées et les ensembles de permissions en contrôle de version avec une étape de revue.
  • Mettez la landing zone à jour dans le trimestre suivant une nouvelle version, dans une fenêtre de maintenance.
  • Auditez la liste des comptes chaque trimestre : chaque compte a un responsable, une raison d’être, et vit dans la bonne OU.
  • Revalidez la liste des régions gouvernées chaque année contre l’endroit où vos données ont réellement le droit de vivre.

La landing zone est une construction de deux jours qui rapporte pendant des années, mais seulement si quelqu’un en possède l’entretien. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.