Amazon SAP-C02: Complexité organisationnelle et stratégie multi-comptes — Guide d'étude

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fait partie du AWS Solutions Architect Professional SAP-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Stratégie multi-comptes et distribution de comptes

Une stratégie multi-comptes commence par une séparation claire des responsabilités : sécurité et audit, réseau partagé, charges de travail de production, et comptes de bac à sable (sandbox) ou de développeur. L’utilisation d’AWS Organizations avec AWS Control Tower ou une zone d’atterrissage (landing zone) personnalisée impose cette séparation dès le premier jour. L’Account Factory de Control Tower fournit un modèle de distribution de comptes (account vending) qui automatise la création de comptes, les rôles IAM de base, les modèles de VPC et les garde-fous (guardrails), tandis qu’une zone d’atterrissage personnalisée construite avec CloudFormation/CDK et Service Catalog offre plus de flexibilité pour des réseaux et une gouvernance sur mesure. Le compromis principal se situe entre la surcharge opérationnelle et la réduction du rayon d’impact (blast radius) : plus de comptes augmentent la surface de gestion (automatisation, rôles inter-comptes, visibilité de la facturation) mais limitent l’exposition en cas de compromission d’un domaine et simplifient la conformité par compte. Les choix réseau — partage de VPC avec AWS Resource Access Manager, architecture en étoile (hub-and-spoke) avec Transit Gateway, ou VPC isolés avec peering de VPC — entraînent des compromis en matière de coût et de latence. Les services partagés (DNS, NAT, Active Directory) résident souvent dans un compte réseau ou de services partagés ; la distribution de comptes devrait automatiquement rattacher les nouveaux comptes à ces ressources partagées ou provisionner des VPC délégués. Planifiez les quotas et l’automatisation : centralisez les pipelines pour les artefacts de base afin que la mise à l’échelle des comptes ne multiplie pas les tâches manuelles.

Gouvernance : SCPs, garde-fous Control Tower et politiques organisationnelles

La gouvernance dans un environnement AWS multi-comptes repose sur l’application de politiques au niveau de l’organisation et sur des contrôles d’exécution (runtime) délégués. Les politiques de contrôle de service (SCPs) définissent le plafond des actions autorisées à travers les comptes ; elles sont puissantes mais impitoyables — des règles de refus (deny) au niveau de l’UO racine empêchent même les administrateurs de créer des rôles liés à un service ou d’utiliser des services, sauf autorisation explicite. Control Tower propose des garde-fous prédéfinis (obligatoires, fortement recommandés, facultatifs) qui implémentent des SCPs et des règles Config courantes, mais il peut être restrictif pour des modèles de service avancés. La décision de conception s’articule autour d’une gouvernance centralisée ou déléguée : une liste de refus (deny-list) stricte au niveau racine maximise la conformité mais augmente la friction pour les équipes produit et l’automatisation, tandis que des bases de référence permissives avec des périmètres de permissions (permission boundaries) et des contrôles de rôles IAM permettent une vélocité de développement plus rapide. Les politiques de journalisation et d’audit (CloudTrail au niveau de l’organisation, agrégateur AWS Config, administrateurs délégués pour Security Hub et GuardDuty) doivent être appliquées depuis le compte de gestion pour garantir des pistes d’audit immuables. Une approche pragmatique est la gouvernance en couches : des SCPs au niveau de l’organisation pour les restrictions à fort impact, des périmètres de permissions pour le champ d’action des développeurs, et des garde-fous automatisés appliqués par le CI/CD de la zone d’atterrissage pour maintenir la cohérence sans validation manuelle.

Frontières de sécurité : rôles inter-comptes, KMS et politiques de ressources

L’accès inter-comptes est un modèle fondamental et doit être mis en œuvre avec le moindre privilège et des contrôles de confiance stricts. Le modèle courant délègue l’accès via des rôles IAM dans chaque compte, que des principaux de confiance (principals) assument avec STS : les rôles pour le déploiement CI/CD, la surveillance (CloudWatch/SSM) et les intégrations tierces devraient exiger le MFA le cas échéant et utiliser des ID externes pour l’accès des partenaires. Les politiques basées sur les ressources sur les clés S3, SQS et KMS permettent un accès inter-comptes direct, mais KMS ajoute de la complexité : une politique de clé KMS doit autoriser explicitement les principaux et les services du compte de confiance, et des autorisations (grants) ou des autorisations avec contraintes peuvent être nécessaires pour un accès temporaire. L’utilisation d’une clé KMS centralisée dans le compte de journalisation ou de sécurité simplifie le chiffrement centralisé mais crée un couplage opérationnel et des considérations de disponibilité potentielles ; des clés par compte réduisent le rayon d’impact mais multiplient la rotation des clés et la gestion des autorisations. Les pièges courants incluent des SCPs qui refusent par inadvertance la création de clés KMS ou de rôles liés à un service, des politiques de compartiment (bucket policies) qui entrent en conflit avec les SCPs, et l’oubli d’ajouter le rôle de délégation à Config/CloudTrail dans le compte collecteur. Les décisions de conception doivent peser la simplicité administrative, le moindre privilège et la latence inter-comptes.

Modèles de journalisation, de facturation et d’automatisation centralisées

La journalisation et la facturation centralisées sont l’épine dorsale de la visibilité d’entreprise. Un CloudTrail d’organisation avec des journaux d’événements (trails) livrés à un compartiment S3 dans un compte de sécurité ou d’audit centralisé garantit une capture d’événements infalsifiable ; complétez cela avec des filtres d’abonnement CloudWatch Logs vers Kinesis Data Firehose pour l’analyse, et agrégez les données de Config avec un agrégateur vers le même compte. La visibilité des coûts nécessite une facturation consolidée dans Organizations, Cost Explorer, Budgets, et des rapports sur les coûts et l’utilisation (Cost and Usage Reports) livrés de manière centralisée ; la gouvernance des balises (tags) et l’application automatisée des balises via les règles Config améliorent la précision de la refacturation (chargeback). Les modèles d’automatisation qui s’étendent sur plusieurs comptes utilisent généralement un pipeline CI/CD partagé ou un compte de déploiement qui assume des rôles de déploiement inter-comptes, ou des CloudFormation StackSets avec un administrateur délégué pour le provisionnement en masse. Utilisez Systems Manager Automation et State Manager pour l’application de correctifs (patching) et la configuration inter-comptes, mais n’oubliez pas que chaque compte doit accorder les rôles et les autorisations SSM nécessaires. Les compromis équilibrent la centralisation et la latence : l’agrégation centrale réduit le stockage dupliqué et simplifie l’analyse, mais crée des dépendances réseau et de disponibilité ; la journalisation distribuée duplique les données mais isole les défaillances. Planifiez la rétention, les règles de cycle de vie, la réplication inter-régions pour la reprise après sinistre (DR), et la gestion des clés de chiffrement en accord avec les exigences de conformité.

Problème pratique : Scénario d’utilisation

Scénario : Contoso Media exploite un environnement AWS d’entreprise avec Organizations et Control Tower en place. Ils disposent d’un compte de gestion, d’un compte réseau pour les services partagés, et de 20 comptes membres exécutant des charges de travail (workloads) de production, de pré-production (staging) et de développement dans deux Régions.

Défi : Contoso doit intégrer (onboard) rapidement 15 nouveaux comptes de projet tout en garantissant une journalisation centralisée, des garde-fous SCP appropriés, une connectivité réseau automatisée au compte de services partagés via Transit Gateway, et des pipelines de déploiement qui ne nécessitent pas de configuration IAM manuelle par compte.

Approche recommandée :

Utiliser Control Tower Account Factory ou un flux de travail automatisé via l’API AWS Organizations pour distribuer (vend) les comptes avec un modèle de base CloudFormation/CDK qui enregistre le compte dans AWS Config, active un CloudTrail d’organisation pointant vers le compartiment S3 du compte d’audit, et applique les balises requises.
Attacher des SCP au niveau de l’UO (OU) qui appliquent des interdictions à fort impact (par exemple, interdire la suppression de clés inter-régions et les régions non autorisées) tout en gardant les UO de développement moins restrictives ; valider les SCP dans un environnement de test (sandbox) avant une application à grande échelle.
Configurer Transit Gateway dans le compte réseau des services partagés et créer des attachements pour l’attachement VPC Transit Gateway de chaque nouveau compte en utilisant l’Infrastructure-as-Code et un administrateur délégué ou un rôle inter-comptes que le processus de distribution assume pour automatiser la création des attachements et la propagation des routes.
Provisionner un pipeline de déploiement CI/CD centralisé dans un compte d’outillage (tooling) qui utilise des rôles IAM inter-comptes (assume-role) créés par le processus de distribution de comptes ; utiliser des CloudFormation StackSets (administrateur délégué) ou des actions CodePipeline inter-comptes pour le provisionnement de base initial et les mises à jour continues.

Justification : L’automatisation de la distribution de comptes avec des artefacts de base impose la gouvernance tout en minimisant les étapes manuelles ; la délégation des tâches de réseau et de déploiement via des rôles inter-comptes et Transit Gateway centralise les services partagés, réduit le rayon d’impact (blast radius), et permet de faire évoluer l’intégration (onboarding) sans sacrifier la sécurité ou l’auditabilité.

Tous les domaines · Réseau et connectivité hybride →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →