AWS multi-accounts : solution d’architecture ou dette organisationnelle déguisée ?

Le multi-account AWS est souvent présenté comme une bonne pratique universelle. En réalité, il s’agit d’un outil structurel puissant, qui nécessite des choix techniques, organisationnels et sécuritaires explicites.

I. Introduction  

La création de multiples comptes AWS est aujourd’hui présentée comme une bonne pratique quasi universelle.
Elle est souvent introduite par des tutoriels simples, orientés console, qui donnent l’impression que le problème se résume à une série de clics.

Cette vision est trompeuse.

Le multi-account n’est pas un détail d’implémentation, mais un choix architectural fondamental.
Il influence directement :

• la manière dont les équipes travaillent,
• la façon dont la sécurité est imposée,
• la lisibilité des coûts,
• la capacité à automatiser,
• et la résilience organisationnelle face aux erreurs humaines.

Mal compris, il crée une dette organisationnelle aussi coûteuse qu’une dette technique classique.

II. Les quotas AWS ne sont généralement qu’un signal révélateur d’un problème architectural  

Les quotas par compte sont souvent l’élément déclencheur :
Lambda concurrency, limites DynamoDB, quotas API Gateway, etc.

Techniquement, ces quotas sont :

• propres à chaque compte et à chaque région,
• parfois augmentables via Service Quotas,
• parfois hard limits non négociables.

Créer un nouveau compte permet effectivement :

• de repartir avec un quota vierge,
• d’augmenter mécaniquement la capacité globale.

Mais cette approche cache un point crucial :

Le quota n’est pas le bon point d’entrée pour résoudre le problème dans la majorité des cas.

Les limites atteintes traduisent le plus souvent un problème de conception :

• fan-out non contrôlé (multiplication incontrôlée des traitements déclenchés par un même événement)
• absence de backpressure (incapacité du système à ralentir ou refuser la charge lorsqu’il atteint ses limites)
• un design événementiel naïf,
• une gestion incorrecte de la concurrence.

Le multi-account ne corrige pas une architecture fragile.
Il la rend plus coûteuse à diagnostiquer.

III. Un compte AWS n’est pas une unité technique  

Un compte AWS est avant tout une frontière forte.

Il délimite :

• les permissions IAM maximales,
• les quotas,
• la facturation,
• l’exposition aux erreurs destructrices.

C’est ce qu’on appelle un blast radius.

Supprimer un bucket, désactiver CloudTrail ou casser une politique IAM dans un compte ne doit jamais impacter les autres.
C’est précisément ce que garantit le multi-account — à condition qu’il soit pensé comme tel.

Utiliser un compte comme simple conteneur de ressources revient à gaspiller son principal bénéfice.

IV. L’erreur classique : créer des comptes sans modèle  

Créer des comptes “au fil de l’eau” mène presque toujours à un système instable.

Sans modèle clair, on observe :

• des comptes par projet,
• puis par environnement,
• puis par équipe,
• puis par urgence.

Résultat :

• aucune cohérence globale,
• des exceptions partout,
• des règles impossibles à expliquer aux nouveaux arrivants.

Un bon modèle de découpage doit répondre à des questions simples :

• Qui est responsable de ce compte ?
• Que se passe-t-il s’il est compromis ?
• Peut-on le supprimer sans impact global ?
• Quel est son cycle de vie ?

Si ces réponses ne sont pas évidentes, le découpage est probablement mauvais.

V. Sécurité : le vrai cœur du multi-account  

L’un des apports majeurs de Organizations est la sécurité imposée par le haut.

Les Service Control Policies (SCP) permettent :

• d’interdire des actions irréversibles,
• même à un administrateur local,
• même par erreur.

Exemples concrets :

• interdire la suppression de CloudTrail,
• bloquer l’usage de régions non autorisées,
• empêcher la création de clés root,
• forcer l’utilisation de services de sécurité centralisés.

Sans SCP, chaque compte reste potentiellement incontrôlable.
Avec SCP, le multi-account devient une barrière systémique, pas une simple isolation logique.

VI. IAM : complexité multipliée, pas supprimée  

Un piège fréquent consiste à croire que : “Chaque compte a son IAM, donc c’est plus simple.”

C’est FAUX.

Le multi-account introduit :

• du cross-account access,
• des rôles d’assumption,
• des chaînes de confiance,
• des politiques globales et locales.

Sans règles strictes :

• les rôles deviennent trop permissifs,
• les permissions divergent,
• l’audit devient impossible.

Un bon design IAM multi-account impose :

• une identité centralisée,
• des rôles minimalistes,
• une séparation stricte humains / workloads,
• des conventions de nommage non négociables.

Sinon, l’IAM devient le point de rupture principal du système.

VII. Automatisation : condition non négociable  

Créer un compte manuellement est acceptable :

• une fois,
• pour un test,
• dans un lab personnel.

En production, c’est un anti-pattern.

Un compte AWS doit être :

• créé via Infrastructure as Code,
• configuré automatiquement,
• sécurisé dès sa naissance,
• observable immédiatement.

Sans cela :

• chaque compte est différent,
• chaque exception est permanente,
• chaque correction devient manuelle.

Le multi-account sans automatisation vous créera des problèmes rapidement.

VIII. Facturation : isolation ≠ maîtrise  

Séparer les comptes permet :

• d’isoler les coûts,
• d’attribuer la responsabilité.

Mais sans :

• budgets par compte,
• alertes automatiques,
• règles d’usage claires,

cela ne crée aucune discipline financière.

Un compte “isolé” qui dérive reste un problème, simplement localisé.

Le multi-account est un outil de lisibilité, pas de contrôle automatique.

IX. Le faux confort des emails “+1”  

L’astuce des emails nom+X@… est souvent présentée comme anodine.

En pratique, elle pose problème pour :

• la traçabilité légale,
• la délégation d’accès,
• le support AWS,
• la gestion des incidents.

Elle fonctionne tant que :

• une seule personne gère tout,
• il n’y a pas d’audit,
• il n’y a pas de rotation d’équipe.

Autrement dit : jusqu’au jour où le système devient sérieux.

X. Ce que le multi-account fait vraiment  

Le multi-account :

• n’efface pas les erreurs,
• n’élimine pas la complexité,
• ne remplace pas l’architecture.

Il agit comme un amplificateur :

• des bonnes décisions,
• mais aussi des mauvaises.

Il force les équipes à rendre leurs choix :

• explicites,
• traçables,
• assumables dans le temps.

Conclusion  

Créer plusieurs comptes AWS est facile.
Concevoir une organisation multi-account saine est difficile.

Le multi-account n’est pas une solution magique.
C’est un engagement architectural à long terme.

Avant d’ajouter un nouveau compte, il faut être capable de répondre à une question simple :

Si ce compte disparaît demain,
le système reste-t-il compréhensible, sécurisé et gouvernable ?

🔗 Ressources utiles  

• AWS Service Quotas – comprendre et gérer les limites Documentation officielle expliquant les quotas par service, par compte et par région, ainsi que les quotas ajustables et non ajustables.

• AWS Organizations & Service Control Policies (SCP) Référence complète sur la gouvernance multi-account, le rôle des SCP et leur importance pour imposer des garde-fous de sécurité à l’échelle de l’organisation.