Prolifération de comptes AWS : consolider des comptes fragmentés sous Organizations

La plupart des entreprises ne conçoivent pas leur environnement multi-compte AWS — elles l’accumulent. Un développeur a ouvert un compte en 2021 sur une carte personnelle, une agence en a créé un autre pour un projet puis est partie, quelqu’un en a monté un troisième pour « des tests » qui roule maintenant de la production. La gestion multi-compte AWS commence par admettre que c’est la situation, puis par consolider ces comptes sous une seule Organization AWS pour que la facturation, l’identité, la sécurité et les garde-fous aient un seul endroit où vivre. La consolidation elle-même est surtout à faible risque — les charges de travail continuent de rouler pendant que les comptes se joignent — mais l’ordre des opérations compte.

Ce que vous décidez

La décision n’est pas d’avoir ou non plusieurs comptes — plusieurs comptes, c’est le bon patron AWS, parce qu’un compte est la frontière d’isolation la plus forte qu’AWS offre. La décision, c’est de savoir si ces comptes relèvent d’une structure. Sans Organizations, chaque compte est une île : facture séparée, utilisateur racine séparé avec le mot de passe et le courriel de sa naissance, CloudTrail séparé (ou absent), aucun moyen d’imposer une politique à l’ensemble, et aucune réponse honnête à « combien de comptes AWS avons-nous? »

Sous une Organization, vous obtenez une facture consolidée, des unités organisationnelles (OU) pour grouper les comptes par fonction, des politiques de contrôle de service (SCP) pour fixer des plafonds de permissions, l’administration déléguée pour l’outillage de sécurité, et une seule histoire d’identité via IAM Identity Center au lieu d’utilisateurs IAM par compte. Le compromis : un compte de gestion qui devient une infrastructure critique et qui doit lui-même être verrouillé et gardé vide de charges de travail.

L’autre décision possible — fusionner les charges de travail dans moins de comptes — est presque toujours mauvaise. Déplacer une charge de production entre comptes veut dire recréer les ressources; joindre un compte à une Organization ne touche pas du tout à ses charges de travail. Consolidez la couche de gestion, pas les ressources.

Quoi vérifier en premier

L’inventaire réel des comptes. La comptabilité peut chercher « Amazon Web Services » dans les factures; les admins courriel peuvent chercher les messages d’inscription de aws.amazon.com. Il y a presque toujours plus de comptes que ce dont on se souvient.
La propriété du courriel racine de chaque compte. Un compte dont le courriel racine est l’adresse personnelle d’un ancien employé est un risque actif et bloque la récupération.
L’appartenance existante à une Organization. Un compte ne peut appartenir qu’à une seule Organization; les comptes créés par une agence sont parfois encore dans la sienne.
Qui paie quoi. Les comptes sur cartes personnelles exigent de toute façon un changement de mode de paiement — la facturation consolidée règle ça en effet secondaire.
Si un compte a déjà des fonctions Organizations activées — deux Organizations existantes ne peuvent pas fusionner; les comptes membres doivent quitter l’une pour joindre l’autre.

Comment vérifier

Depuis chaque compte accessible, établissez sa situation :

# Dans quel compte suis-je, et est-il déjà dans une Organization?
aws sts get-caller-identity
aws organizations describe-organization

# Depuis le futur compte de gestion : liste des membres actuels
aws organizations list-accounts \
  --query 'Accounts[].[Id,Name,Email,Status]' --output table

# Structure d'OU, s'il y en a une
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-examplerootid

Un describe-organization qui retourne AWSOrganizationsNotInUseException signifie que le compte est autonome — un candidat à inviter. Dans la console, AWS Organizations > AWS accounts sur le compte de gestion montre les membres et les invitations en attente.

L’approche

Choisissez ou créez le compte de gestion délibérément. Il ne doit exécuter aucune charge de travail — ses seuls rôles sont la facturation, l’administration d’Organizations et l’identité. Un compte existant plein de ressources de production est un mauvais choix; un compte neuf est habituellement plus propre.
Récupérez d’abord l’accès racine partout. Pour chaque compte : réinitialisez le mot de passe racine via le courriel racine, remplacez le courriel racine par une adresse d’entreprise fonctionnelle (style aws-root+prodaccount@entreprise.com), activez la MFA sur la racine. Faites-le avant d’inviter — un compte que vous ne pouvez pas récupérer par la racine est un compte que vous ne contrôlez pas.
Invitez les comptes un à la fois. Depuis le compte de gestion, envoyez l’invitation (AWS Organizations > AWS accounts > Add an AWS account > Invite an existing AWS account); quelqu’un ayant accès au compte membre l’accepte. Les charges de travail ne bougent pas. La facturation bascule vers le compte de gestion dès l’acceptation.
Bâtissez un arbre d’OU minimal, puis déplacez-y les comptes. Security, Workloads/Prod, Workloads/NonProd, Sandbox, Suspended couvre la plupart des organisations. Résistez aux hiérarchies profondes — les OU existent pour attacher des politiques, pas pour refléter l’organigramme.
Attachez les premiers garde-fous. Commencez par des SCP qui ne peuvent rien casser : interdire de quitter l’Organization, interdire les actions de l’utilisateur racine dans les comptes membres, interdire de désactiver CloudTrail, restreindre les régions si vous avez une exigence de résidence des données. Un ensemble de départ fonctionnel est dans la base de référence SCP pour Organizations.
Centralisez l’identité et la journalisation. IAM Identity Center pour l’accès humain, afin de retirer les utilisateurs IAM par compte, et un CloudTrail d’organisation livrant vers un compte d’archives de journaux. À partir de là, les nouveaux comptes doivent venir d’un processus de distribution plutôt que d’une carte de crédit — ce chemin est couvert dans Control Tower Account Factory.
Mettez hors service les vrais orphelins. Les comptes sans rien de valeur voient leurs données prises en instantané, puis sont fermés. Un compte fermé reste récupérable 90 jours, puis disparaît — vérifiez les zones DNS, les compartiments S3 référencés par nom et les identités SES vérifiées avant de fermer.

Quand c’est la mauvaise approche

Si vous avez exactement un compte et aucune pression de conformité, un déploiement complet d’Organization aujourd’hui est prématuré — quoique créer l’Organization tôt ne coûte rien et transforme le deuxième compte en événement de cinq minutes plutôt qu’en projet de migration. Si les comptes fragmentés appartiennent à des entités juridiques réellement distinctes avec des exigences de facturation distinctes, une seule Organization est peut-être une erreur; Organizations suppose une seule entité payeuse. Et si un compte appartient à une agence qui refuse de le céder, planifiez une migration des charges de travail hors de ce compte plutôt qu’une bataille pour le courriel racine.

Erreurs courantes

Exécuter des charges de travail dans le compte de gestion. Les SCP ne s’y appliquent pas, c’est donc le seul compte que vos garde-fous ne peuvent pas protéger — gardez-le vide.
Inviter des comptes avant de régler le courriel racine. Dès qu’un litige ou un départ survient, un compte dont vous ne contrôlez pas le courriel racine est effectivement pris en otage.
Tenter de fusionner des ressources au lieu de comptes. Joindre une Organization, c’est un après-midi; migrer une charge de production entre comptes, c’est un projet. Ne confondez pas les deux.
L’enthousiasme SCP au jour un. Une SCP lourde en refus appliquée à une OU pleine de charges en production, c’est comme ça qu’un projet de consolidation cause sa première panne. Commencez par la liste de refus à laquelle personne ne peut s’opposer.

Garder le contrôle

Les nouveaux comptes passent uniquement par le processus de distribution — plus jamais d’inscription par carte de crédit.
Revue trimestrielle de la liste des comptes avec un responsable nommé par compte; les comptes sans responsable passent dans l’OU Suspended.
Identifiants racine : MFA partout, usage sous alarme via CloudTrail, jamais utilisés pour le travail quotidien.
Une revue de facturation par mois sur la facture consolidée — la prolifération apparaît dans les lignes de coûts avant que quiconque en parle.
Gardez l’arbre d’OU ennuyant; ce sont les besoins de politiques, pas la politique interne, qui créent les OU.

La prolifération de comptes n’est presque jamais la faute de quelqu’un et toujours le problème de tout le monde, et elle ne fait que s’aggraver. 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.