AWS multi-comptes : 5 erreurs critiques à éviter en 2026

Le multi-comptes AWS est devenu un standard. Isoler le blast radius, séparer les environnements, simplifier la facturation, déléguer l’autonomie aux équipes : sur le papier, tout le monde est d’accord.

Dans la réalité, la majorité des PME que nous auditons ont multiplié les comptes sans multiplier la rigueur. Le résultat : une dette opérationnelle qui ralentit chaque livraison, complique chaque audit, et qui coûte cher à rattraper.

Cet article liste les cinq erreurs critiques que nous voyons le plus souvent — et le pattern minimal qui permet de les éviter.

Le pattern de référence

Avant les anti-patterns, le pattern cible. Une Landing Zone AWS Organizations bien faite, c’est ça :

Quatre Organizational Units (OU), au minimum. Chacune avec une responsabilité claire. Les Service Control Policies (SCP) appliquées au niveau OU, pas au niveau compte. L’authentification centralisée via IAM Identity Center. Les logs agrégés dans un compte dédié à rétention longue, en immutable.

C’est ce vers quoi nous tirons systématiquement les chantiers de remédiation. Voyons maintenant ce qui en empêche.

Erreur 1 — Pas de Landing Zone

Le symptôme : chaque nouveau compte est créé à la main, dans la console, par une personne différente. La conséquence : aucun compte n’a la même config CloudTrail, le même réseau, les mêmes garde-fous.

À 3 comptes, c’est gérable. À 10, c’est ingérable. À 20, c’est un risque opérationnel critique.

Le fix : AWS Control Tower (managé) ou une Landing Zone custom Terraform. Control Tower fait 80 % du boulot pour vous : structure d’OU, baseline CloudTrail/Config, blueprints d’IAM Identity Center, garde-fous SCP de base. Si vous démarrez aujourd’hui, c’est le choix par défaut.

# Bootstrap d'une Org via Terraform (à exécuter dans le compte management)
resource "aws_organizations_organization" "main" {
  feature_set = "ALL"

  enabled_policy_types = [
    "SERVICE_CONTROL_POLICY",
    "TAG_POLICY",
    "BACKUP_POLICY"
  ]

  aws_service_access_principals = [
    "cloudtrail.amazonaws.com",
    "config.amazonaws.com",
    "guardduty.amazonaws.com",
    "securityhub.amazonaws.com",
    "sso.amazonaws.com"
  ]
}

resource "aws_organizations_organizational_unit" "security" {
  name      = "Security"
  parent_id = aws_organizations_organization.main.roots[0].id
}

resource "aws_organizations_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = aws_organizations_organization.main.roots[0].id
}

Erreur 2 — IAM cross-account anarchique

Le symptôme : des dizaines de rôles IAM avec sts:AssumeRole cross-account, créés au coup-par-coup. Personne ne sait qui peut faire quoi, où.

À chaque audit interne ou pré-SOC2, c’est la première chose qui saute aux yeux. Et c’est aussi la première chose qu’un attaquant cherche après une compromission initiale : un chemin de pivot via un rôle assumable trop laxiste.

Le fix : AWS IAM Identity Center (ex-AWS SSO). Un point d’entrée unique, des permission sets versionés, fédération SAML/OIDC avec votre IdP existant (Okta, Google Workspace, Entra ID).

Une fois Identity Center activé au niveau de l’organisation :

resource "aws_ssoadmin_permission_set" "developer" {
  name             = "DeveloperAccess"
  instance_arn     = local.identity_center_arn
  session_duration = "PT8H"
}

resource "aws_ssoadmin_managed_policy_attachment" "developer_powers" {
  instance_arn       = local.identity_center_arn
  managed_policy_arn = "arn:aws:iam::aws:policy/PowerUserAccess"
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
}

# Assignation à un compte cible pour un groupe IdP
resource "aws_ssoadmin_account_assignment" "dev_to_staging" {
  instance_arn       = local.identity_center_arn
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  principal_id       = data.aws_identitystore_group.developers.group_id
  principal_type     = "GROUP"
  target_id          = local.staging_account_id
  target_type        = "AWS_ACCOUNT"
}

Plus aucun rôle IAM long-lived. Plus aucun access key qui traîne. Sessions limitées dans le temps. Chaque accès tracé dans CloudTrail.

Erreur 3 — Pas de Service Control Policies

Une SCP est un garde-fou organisationnel : elle dit “même un Administrator IAM ne peut pas faire X dans cette OU”. Sans SCP, votre stratégie IAM n’a aucun filet.

Les trois SCPs que nous installons systématiquement, dès le jour 1 :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsOutsideEU",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "sts:*", "cloudfront:*", "route53:*",
        "support:*", "organizations:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-west-1", "eu-west-3"]
        }
      }
    },
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "DenyDisablingSecurityServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder",
        "guardduty:DeleteDetector",
        "securityhub:DisableSecurityHub"
      ],
      "Resource": "*"
    }
  ]
}

Région unique, root user banni, services de sécurité non désactivables. Trois statements, énorme bénéfice en posture de sécurité.

Erreur 4 — Pas de logs centralisés

Le symptôme : un incident de sécurité survient sur le compte production. Pour reconstituer la timeline, il faut aller chercher des logs CloudTrail dispersés sur 12 comptes, dont certains avec une rétention de 90 jours par défaut. Bonne chance.

Le fix : un Log Archive account dédié, qui reçoit :

• Le CloudTrail organisationnel (organization trail) — tous les comptes, toutes les régions
• Les logs Config de tous les comptes
• Les findings Security Hub agrégés
• Les findings GuardDuty agrégés

Avec rétention longue (7 ans pour SOC2/RGPD), bucket S3 immutable (Object Lock), et accès lecture seule depuis un compte d’audit.

# Dans le compte management
resource "aws_cloudtrail" "organization" {
  name                          = "organization-trail"
  s3_bucket_name                = aws_s3_bucket.log_archive.id
  is_organization_trail         = true
  is_multi_region_trail         = true
  include_global_service_events = true
  enable_log_file_validation    = true

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }
}

resource "aws_s3_bucket_object_lock_configuration" "log_archive" {
  bucket = aws_s3_bucket.log_archive.id

  rule {
    default_retention {
      mode = "COMPLIANCE"
      days = 2555
    }
  }
}

Un seul endroit où chercher, immutable, prêt pour un auditeur.

Erreur 5 — VPC peering en mesh

Le symptôme : 6 comptes, 6 VPCs, peering bidirectionnel entre tous. 15 connexions VPC peering. Aucune visibilité sur les routes. Une nouvelle équipe = N nouveaux peerings à créer, debugger, documenter.

C’est la dette réseau qui ne se rembourse jamais. Le fix est connu : AWS Transit Gateway.

Un Transit Gateway centralisé dans le compte Network, attaché à tous les VPCs. Les routes sont gérées dans une table centrale. Une nouvelle équipe = une attache TGW, point.

# Dans le compte Network
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Hub réseau organization-wide"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  dns_support                     = "enable"

  tags = { Name = "tgw-main" }
}

resource "aws_ram_resource_share" "tgw_share" {
  name                      = "tgw-share-org"
  allow_external_principals = false
}

resource "aws_ram_principal_association" "share_with_org" {
  principal          = aws_organizations_organization.main.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

Le coût d’un TGW (~36 €/mois + 0,02 $/GB processed) est dérisoire face aux gains opérationnels. Et les flux deviennent observables au point central.

Le minimum vital

Pour résumer ce qu’on appelle chez Distribuée le socle non-négociable d’une organisation AWS multi-comptes :

C’est un investissement de 4 à 8 semaines pour une PME — et c’est rentabilisé dès le premier audit, le premier incident, ou la première compromission évitée.

Conclusion

Aucune de ces erreurs n’est nouvelle. Elles sont documentées par AWS dans les whitepapers Multi-Account Strategy depuis 2018. Ce qui empêche les PME de les éviter, ce n’est pas le savoir — c’est la priorisation.

Tant que le compte unique tient, on remet à plus tard. Le jour où on bascule sur du multi-comptes, on construit dans l’urgence. Et on accumule la dette.

Si vous êtes en train de scaler votre AWS et que vous voyez les premiers signaux, c’est exactement le moment d’investir 8 semaines pour ne pas en perdre 80 plus tard.