Aller au contenu

AWS Mis à jour le 2026-05-04

Account Factory de Control Tower — la liste de vérification de nouveau compte qui ferme vraiment

Une procédure répétable de nouveau compte AWS avec Control Tower Account Factory plus Customizations for Control Tower (CfCT), avec la liste post-distribution qui attrape les items que la factory ne couvre pas.

La première fois que vous montez une AWS Organization, un nouveau compte est un exercice manuel — connexion à la console, clics, nommage de l’OU, attachement de la SCP, configuration des ensembles de permissions IAM Identity Center, configuration de CloudTrail, dépôt du VPC. Au cinquième compte, vous avez construit soit un runbook, soit un arriéré de comptes incohérents. L’Account Factory de Control Tower est la réponse gérée par AWS ; CfCT (Customizations for Control Tower) et AFT (Account Factory for Terraform) l’étendent pour les items que la factory de base ne couvre pas. Cet article est la procédure que nous suivons quand un client demande un nouveau compte géré par le payeur, et la liste post-distribution qui ferme l’écart.

Comment vérifier

Ce que la landing zone pense réellement être configuré :

aws controltower get-landing-zone --landing-zone-identifier <arn>
aws controltower list-enabled-baselines
aws controltower get-enabled-baseline --enabled-baseline-identifier <id>
aws organizations describe-organization
aws sso-admin list-instances

Pour un compte distribué spécifiquement, la vérification unique la plus utile est l’assomption du rôle AWSControlTowerExecution — si vous pouvez sts:AssumeRole dedans depuis le compte de gestion, le compte est branché dans la landing zone :

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/AWSControlTowerExecution \
  --role-session-name verify

Un échec ici signifie habituellement que le compte a été créé hors de la factory (un compte Organizations « ordinaire ») et qu’il manque la relation de confiance. Le remède est de l’enrôler via la console Control Tower — il n’y a pas d’API pour l’enrôlement rétroactif au moment d’écrire ceci.

Ce qui se passe

Le modèle mental de Control Tower a trois pièces :

  • Landing Zone — la configuration au niveau de l’organisation : la disposition d’OU, le CloudTrail à l’échelle de l’org, l’archive de journaux centralisée et les comptes d’audit, la configuration IAM Identity Center. Il y a une landing zone par organisation.
  • Account Factory — la machine à distribuer par compte. Crée un nouveau compte dans une OU choisie, applique la base activée (un ensemble de contrôles obligatoires), et l’enregistre auprès d’Identity Center.
  • Contrôles (anciennement Garde-fous) — politiques préventives (SCP) et détectives (règles Config) attachées au niveau OU. Certaines sont obligatoires ; beaucoup sont électives.

La factory de base vous remet un compte avec CloudTrail activé, un agrégateur Config branché, l’accès Identity Center pour un groupe configuré, et les SCP obligatoires attachées. Elle ne vous donne pas de VPC, pas de base SCP que vous avez écrite vous-même, pas de bucket d’état Terraform, pas d’activation GuardDuty à l’échelle de l’organisation, et aucun étiquetage par compte que vous voulez réellement.

C’est cet écart que CfCT et AFT existent pour combler. CfCT est un cadre de pile CloudFormation qui tourne après que l’Account Factory distribue. AFT est une alternative basée sur Terraform qui fait la même chose en HCL. D’une façon ou de l’autre, vous commitez du code de personnalisation de compte dans un dépôt Git, et le pipeline le lance contre les nouveaux comptes au fur et à mesure qu’ils sortent.

Le piège que la plupart des équipes frappent : ils traitent Control Tower comme une installation ponctuelle et ne reviennent jamais. Deux ans plus tard, la version de la landing zone est dépassée, la liste des contrôles s’est allongée, et une dérive CloudFormation dans le compte d’archive de journaux signifie que la piste à l’échelle de l’org perd silencieusement des événements depuis un trimestre. Le patron de retouche est « mettre à jour la landing zone tous les trimestres, réparer la dérive sur calendrier » — pas « régler et oublier ».

La procédure

  1. Distribuez le compte depuis le compte de gestion. Depuis la console AWS sous Control Tower → Account Factory → Créer un compte. Vous fournissez un nom de compte, une adresse courriel (doit être unique sur tout AWS — les astuces d’adresses plus jetables fonctionnent), l’OU cible, et un nom d’affichage pour Identity Center. Le processus de distribution prend 25 à 40 minutes ; le courriel du nouveau compte arrive une fois terminé.

    Via l’API, si vous avez configuré Service Catalog pour exposer l’Account Factory :

    aws servicecatalog provision-product \
  --product-id prod-xxxx \
  --provisioning-artifact-id pa-xxxx \
  --provisioned-product-name "client-prod-acct" \
  --provisioning-parameters \
    Key=AccountEmail,Value=aws+client-prod@example.com \
    Key=AccountName,Value=client-prod \
    Key=ManagedOrganizationalUnit,Value="Workloads/Prod" \
    Key=SSOUserEmail,Value=ops-team@example.com \
    Key=SSOUserFirstName,Value=Ops \
    Key=SSOUserLastName,Value=Team

  2. Attendez que la distribution se termine, puis assumez dans le nouveau compte. La factory provisionne le rôle AWSControlTowerExecution automatiquement ; c’est votre point d’ancrage pour la personnalisation post-distribution :

    aws sts assume-role \
  --role-arn arn:aws:iam::<new-acct-id>:role/AWSControlTowerExecution \
  --role-session-name post-vending

  3. Exécutez la liste de vérification post-distribution. Les items ci-dessous ne sont pas couverts par la factory de base :

    • Définissez l’alias de compte (améliore les pages de connexion IAM) : 
      aws iam create-account-alias --account-alias client-prod-acct
    • Activez les étiquettes d’allocation de coûts au niveau de l’organisation si ce n’est pas déjà fait.
    • Définissez le niveau de support s’il est plus élevé que Basic — Business / Enterprise doivent être activés par compte.
    • Appliquez votre base SCP si vous en avez une attachée à l’OU mais que le nouveau compte a migré dans une mauvaise OU.
    • Déployez le VPC standard (ou confirmez « pas de VPC, ceci est un compte sans serveur »). Le VPC par défaut qu’AWS crée devrait être supprimé dans presque tous les cas.
    • Activez GuardDuty / Security Hub / Inspector si votre liste de contrôles détectifs le dit. Ce sont par région, par compte, et l’administrateur d’organisation peut les activer de manière centralisée.
    • Enregistrez le compte dans les politiques organisationnelles de Backup si vous utilisez AWS Backup.
    • Étiquetez le compte au niveau Organizations : cost-center, environment, owner, data-classification.

  4. Branchez le compte dans CfCT ou AFT. Si vous utilisez AFT, ajoutez une entrée à votre module Terraform account-request avec le nouvel ID de compte et le profil de personnalisation que vous voulez appliquer. Le pipeline le prend au prochain passage et applique le Terraform par compte.

    module "client_prod_request" {
  source = "./modules/aft-account-request"
  control_tower_parameters = {
    AccountEmail              = "aws+client-prod@example.com"
    AccountName               = "client-prod"
    ManagedOrganizationalUnit = "Workloads/Prod"
    SSOUserEmail              = "ops-team@example.com"
    SSOUserFirstName          = "Ops"
    SSOUserLastName           = "Team"
  }
  account_customizations_name = "workload-baseline"
  account_tags = {
    cost-center  = "12345"
    environment  = "prod"
    owner        = "team-payments"
  }
}

  5. Vérifiez que le nouveau compte est entièrement conforme à la base avant de remettre les identifiants :

    aws configservice describe-conformance-pack-status \
  --conformance-pack-names baseline-pack
aws securityhub get-findings \
  --filters '{"AwsAccountId":[{"Value":"111122223333","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}]}' \
  --max-results 50

Notes opérationnelles

  • Le rôle AWSControlTowerExecution est le seul chemin que la factory utilise pour le travail inter-comptes. Ne le supprimez pas d’un compte distribué, et ne modifiez pas sa politique de confiance — les deux casseront les futures mises à jour de landing zone.
  • Les mises à jour de version de landing zone requièrent un clic manuel sur le bouton « Mettre à jour » dans la console ; le système ne se met pas à jour automatiquement. Suivez la version actuelle par rapport à la dernière publiée et planifiez la mise à jour dans une fenêtre de maintenance.
  • La fermeture de compte est asynchrone et effectivement permanente après 90 jours. Un compte distribué reste en état SUSPENDED et compte vers les limites Organizations pendant l’attente. Planifiez cela quand « on va simplement supprimer le compte sandbox » — vous ne pouvez pas, pendant trois mois.
  • Les pipelines CfCT et AFT tournent avec de larges permissions. Le rôle du pipeline devrait avoir sa propre OU avec SCP attachée et une alarme sur toute dérive de politique.
  • Un compte déplacé entre OU prend immédiatement les contrôles de l’OU de destination mais ne nettoie pas rétroactivement les ressources qui violaient les nouveaux contrôles — une instance t2 lancée dans une OU qui ne refusait pas t2 n’est pas terminée quand le refus arrive.

Stack Harbor opère Control Tower pour des clients dont la distribution de nouveau compte est un passage de pipeline de 30 minutes, pas une demi-journée de clics dans la console, et dont les mises à jour de landing zone atterrissent sur un calendrier trimestriel publié. Si votre équipe construit aujourd’hui les nouveaux comptes AWS en suivant une page wiki, le pipeline de distribution client est l’une des premières améliorations qui rembourse les heures d’ingénierie sous la gestion de comptes AWS.