À la fin de ce tutoriel, vous saurez expliquer pourquoi un modèle multi-compte AWS, dessiner une landing zone (OUs + SCPs + comptes partagés), brancher IAM Identity Center, et dérouler un lab lecture / dry-run en ca-central-1 sans créer de comptes coûteux ni casser le management account.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : AWS Organizations · IAM Identity Center · AWS CLI v2 · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-multi-account-org · Série : WOW (45/50) · Mot-clé SEO : AWS Organizations · Publish : HOLD

→ Suivant : Azure Bicep avancé : modules et CI · Aussi : FinOps AWS · IAM users, groupes, rôles · Démarrer avec AWS

Prérequis

Coût estimé : 0 € pour ce lab (STS, describe, exemples JSON). La création de comptes Organizations / Control Tower / NAT / Transit Gateway est hors scope et peut facturer. Ne lancez Account Factory que sur une org jetable.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

AWS Organizations landing zone (WOW 45/50) — ca-central-1
  ├── Pourquoi multi-compte (blast radius, factu, sécu)
  ├── Org : management account, OUs, SCPs
  ├── Architecture DEH (Security / Infra / Workloads)
  ├── Lab : identity + org describe + SCP sketch
  ├── Identity Center (SSO) vs users IAM locaux
  └── Quiz + FAQ + maillage WOW / FinOps

(Schéma — alt : « Management account orchestre OUs Security, Infrastructure et Workloads vers des comptes Dev/Prod en ca-central-1 ».)

Étape 1 — Pourquoi le multi-compte en 2026 ?

Un seul compte AWS « pour tout » fonctionne en POC. En équipe, c’est un blast radius maximal : une clé IAM fuite, un Deny mal posé, ou une facture Spot hors contrôle touchent toute la boîte.

Le modèle multi-compte isole :

Besoin Compte dédié (exemple)
Prod vs sandbox workload-prod, workload-dev
Logs immuables log-archive
Security tooling audit / security-tooling
Réseau partagé network (TGW, DNS)
Facturation lisible tags + comptes séparés

Vous gagnez aussi des quotas par compte, des SCPs org, et une séparation claire pour les audits. C’est le socle d’une landing zone : un contrat d’organisation cloud, pas un produit magique. Voir FinOps AWS — multi-compte + tags Owner/Env.

Étape 2 — AWS Organizations : vocabulaire utile

AWS Organizations regroupe des comptes sous un management account. Ce compte est spécial : facturation consolidée, création de comptes, SCPs. Ne déployez pas vos apps métier dedans.

  1. OU — dossier logique (Security, Infrastructure, Workloads, Suspended)
  2. SCP — garde-fou max permissions : elle ne donne aucun droit, elle restreint ce que IAM peut encore autoriser
  3. Member accounts — comptes enfants
  4. Delegated admin — GuardDuty, Security Hub, Config hors management

Arborescence DEH minimale :

Root
├── OU Security
│   ├── log-archive
│   └── audit
├── OU Infrastructure
│   ├── network
│   └── shared-services
├── OU Workloads
│   ├── OU NonProd (dev, staging)
│   └── OU Prod
└── OU Sandbox (labs individuels)

Les SCPs s’attachent au Root, à une OU ou à un compte. Une SCP trop large sur le Root peut verrouiller jusqu’au management account — toujours tester sur une OU Sandbox d’abord.

Étape 3 — Landing zone de référence (légère)

Une landing zone = comptes + OUs + SCPs + identité + logs + réseau de base. Control Tower accélère (Account Factory). Pour apprendre, une landing zone légère suffit :

Couche Pattern DEH
Identité IAM Identity Center (SSO), groupes → permission sets
Sécurité GuardDuty / Security Hub délégués vers audit
Logs CloudTrail org + Config → bucket dans log-archive
Réseau VPC patterns + (plus tard) TGW dans network
Workloads comptes Dev/Prod, pas de users IAM permanents
Guardrails SCPs : DenyLeaveOrg, DenyRegions hors allow-list

Region lab DEH : ca-central-1. Une SCP « deny all regions except ca-central-1 » est un excellent exercice, mais dangereuse si appliquée trop haut sans exception management / services globaux (IAM, Organizations, CloudFront, Route 53, Billing). Commencez en lecture et sur OU Sandbox.

Ce n’est pas Crossplane ni Terraform à eux seuls : l’IaC implémente la landing zone ; Organizations en est le cadre. Voir aussi Crossplane AWS pour le self-service dans les comptes enfants.

Étape 4 — Lab safe : inspecter l’org (ca-central-1)

Objectif : vérifier l’identité, détecter si le compte est dans une org, lister OUs/comptes si autorisé, et préparer un sketch SCP sans l’attacher en prod.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

aws sts get-caller-identity
aws organizations describe-organization
aws organizations list-roots
aws organizations list-organizational-units-for-parent 
  --parent-id "$(aws organizations list-roots --query 'Roots[0].Id' --output text)"

Si AccessDeniedException : votre profil n’est pas management / pas assez privilégié. Restez sur la théorie + JSON ci-dessous — c’est le happy path lab DEH sans Account Factory.

Sketch SCP — refuser de quitter l’org (à tester d’abord sur Sandbox) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": ["organizations:LeaveOrganization"],
      "Resource": "*"
    }
  ]
}

Sketch SCP — restreindre les régions (⚠️ ne pas coller au Root sans exceptions) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideCaCentral1",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "billing:*",
        "budgets:*",
        "cloudfront:*",
        "iam:*",
        "organizations:*",
        "route53:*",
        "support:*",
        "sts:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ca-central-1"]
        }
      }
    }
  ]
}

Création dry-run documentaire (ne pas exécuter sur une org prod) :

# EXEMPLE — org de lab jetable uniquement
# aws organizations create-organizational-unit 
#   --parent-id r-xxxx --name Sandbox
# aws organizations create-account 
#   --email lab-sandbox-$(date +%s)@example.com 
#   --account-name "lab-sandbox"

Tags recommandés dès le jour 1 sur chaque compte / ressource : Owner, Environment, CostCenter, Service. Sans ça, le multi-compte n’aide pas le FinOps.

Étape 5 — Identité : Identity Center plutôt que users locaux

Dans une landing zone moderne, les humains se connectent via IAM Identity Center (SSO) : un utilisateur → plusieurs comptes via permission sets (AdministratorAccessLab, PowerUser, ReadOnly, BreakGlass).

Anti-pattern : créer un user IAM alice dans chaque compte membre avec access keys longues. Préférez :

  1. Groupes Identity Center (platform, developers, security)
  2. Permission sets versionnés (IaC)
  3. Assignation groupe → compte OU Workloads
  4. CI/CD via OIDC (GitHub Actions → rôle court) — pas de clés dans le repo

Break-glass : un rôle d’urgence audité, pas le root de chaque compte au quotidien. Le root du management account reste en coffre (MFA hardware), jamais en CI.

Étape 6 — Check-list d’adoption + day-2

Check MVP
Apps hors management account Oui
OU Security + log-archive Oui
CloudTrail org activé Oui
SCP DenyLeaveOrganization Sur Workloads / Sandbox d’abord
Identity Center + MFA Oui
Region allow-list documentée ca-central-1 (+ exceptions globales)
Tags Owner/Env Obligatoires
Compte Suspended / quarantine Process clair

Day-2 : Config drift, GuardDuty vers audit, budgets par compte, offboarding Identity Center le jour J.

Erreurs fréquentes

Erreur Impact Correction
Apps dans le management account Blast radius + audit cauchemar Comptes Workloads uniquement
SCP DenyRegion sur Root sans exceptions Lock-out services globaux OU Sandbox d’abord + NotAction
Users IAM + clés partout Fuites, toil Identity Center + OIDC
Pas de log-archive Preuves non immuables Compte dédié + bucket lock
Control Tower « demain » = rien aujourd’hui Chaos Landing zone légère documentée
Region us-east-1 par défaut Incohérence DEH Forcer ca-central-1

Quiz (5 questions)

1. Le management account doit surtout : – A. Héberger toutes les apps prod
– B. Gouverner l’org (factu, SCPs, création de comptes)
– C. Remplacer IAM Identity Center

2. Une SCP : – A. Accorde des permissions comme une policy IAM
– B. Restreint le maximum autorisable (deny guardrail)
– C. Remplace CloudTrail

3. log-archive sert surtout à : – A. Héberger Redis
– B. Centraliser logs / preuves avec contrôles forts
– C. Remplacer S3 versioning local

4. Region lab DEH imposée : – A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. Identité humaine recommandée multi-compte : – A. User IAM + access key par compte
– B. IAM Identity Center + permission sets
– C. Root partagé Slack

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Organizations = Control Tower ?

Non. Organizations est le socle (comptes, OUs, SCPs). Control Tower ajoute une landing zone managée (baselines, Account Factory). Vous pouvez commencer léger, puis industrialiser.

Combien de comptes au démarrage ?

Souvent 4–8 : management, log-archive, audit, network, shared, dev, prod (+ sandbox). Trop de comptes trop tôt = toil Identity Center ; trop peu = blast radius.

SCP peut-elle bloquer le management account ?

Oui si mal attachée au Root. Testez sur OU Sandbox, gardez un break-glass, documentez les exceptions services globaux.

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : cohérence tutos, IAM et FinOps comparables entre guides.

Faut-il Terraform / Crossplane dès le jour 1 ?

Pour 2–3 comptes, la console + CLI suffisent à apprendre. Dès que vous recréez des comptes souvent, versionnez OUs/SCPs/permission sets en IaC.

Multi-compte aide-t-il vraiment les coûts ?

Oui si tags + comptes séparent env/équipes, et si les sandboxes ont budgets + SCP. Sinon vous multipliez juste les ressources oubliées — voir FinOps AWS.

Pour aller plus loin

Maillage série WOW
← Précédent Spot Instances en prod sans drama
→ Suivant Azure Bicep avancé : modules et CI
Aussi FinOps AWS · IAM · Well-Architected · Crossplane

Meta publication (SEO)

  • Title SEO : AWS Organizations multi-account : landing zone (guide FR)
  • Meta description : AWS Organizations multi-account : OUs, SCPs, landing zone légère, Identity Center. Lab safe en ca-central-1, FAQ, quiz et check-list DEH.
  • Focus keyword : AWS Organizations
  • Secondary : landing zone, SCP, organizational unit, IAM Identity Center, multi-account
  • Image : assets/web/devopelastichayway/cover-wow-multi-account-org-1200x630.webp (à générer)
  • Catégorie : WOW / AWS · Niveau : Intermédiaire
  • URL cible : https://devopelastichayway.com/tutoriels/wow-multi-account-org/
  • Post live : N/A (nouveau) · slug wow-multi-account-org · Publish : HOLD (draft only — feu vert Maître requis)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.