Introduction
Imaginez une usine très fréquentée : une grande pièce où les concepteurs, les testeurs, les constructeurs et même le PDG travaillent côte à côte. Les machines bourdonnent tandis que les prototypes sont construits juste à côté de la chaîne de production, partageant tous les mêmes outils, la même alimentation électrique et le même espace exigu. Cela semble compliqué, n’est-ce pas ?
L’un de nos clients était confronté au même problème et gérait tout (développement, tests et production) sur un seul compte. Tout semblait assez simple au début. Mais à mesure que leur charge de travail augmentait, cette configuration est devenue un casse-tête constant. Les coûts étaient déroutants, l’évolutivité atteignait ses limites et la sécurité commençait à passer entre les mailles du filet. Les développeurs avaient trop accès à la production et la facture mensuelle constituait un énorme casse-tête qui ne donnait aucune visibilité sur la destination réelle de l’argent. Pour résoudre ce problème, nous sommes en train de reconstruire leur structure AWS avec AWS Organizations, un service conçu pour gérer et gouverner plusieurs comptes en un seul endroit. Le concept était simple : nous souhaitions une configuration sécurisée, évolutive et rentable dans laquelle chaque environnement pourrait être autonome tout en suivant un modèle de gouvernance unique.
L’ancienne méthode : un compte, trop de problèmes.
Au début, tout était créé dans un seul compte AWS. Cela fonctionnait bien quand il n’y avait que quelques personnes qui le géraient. Mais à mesure que les équipes grandissaient, le chaos augmentait également. Les développeurs, les testeurs et les opérations se déployaient tous dans le même environnement. Les groupes de sécurité ont été réutilisés à travers les étapes, les rôles IAM ont été partagés et même les informations d’identification de production traînaient avec plus de personnes qu’elles n’auraient dû l’être. Le pire ? Les coûts étaient un mystère. Avec tout facturé sur le même compte, il était presque impossible de séparer les dépenses de développement, d’UAT et de production. Les journaux de tous les environnements étaient mélangés, donc le suivi des problèmes ou la réalisation d’audits prenaient du temps. Et la mise à l’échelle ? Chaque changement d’infrastructure comportait le risque de casser quelque chose de critique dans la production.
Architecture moderne : redéfinir les environnements avec AWS Organizations.
Pour résoudre ce problème, nous avons mis en œuvre une nouvelle conception à l’aide d’AWS Organizations. Cela nous a permis de diviser chaque environnement en son propre compte AWS tout en gérant tout à partir d’une structure centralisée. Enfin, chaque compte disposait de son propre espace, de son propre budget (un montant de financement limité) et de ses propres limites d’accès, mais tout était toujours régi de manière cohérente.
Voici à quoi ressemblait la nouvelle architecture :
Discussion fluide
Schéma architectural
Organisation racine :
Le centre de contrôle principal pour l’ensemble du paysage AWS. Il est géré via AWS Organizations et AWS SSO (maintenant IAM Identity Centre), et il est lié à AWS Control Tower pour la gouvernance et les garde-fous.
UO de sécurité (unité organisationnelle) :
C’est là que résident tous les comptes axés sur la sécurité et la conformité.
• Compte d’archive de journaux : stocke les journaux de chaque environnement (CloudTrail, AWS Config, etc.) dans un emplacement sécurisé en lecture seule.
UO Services partagés :
Il comprendra toutes les plates-formes et outils partagés tels que les pipelines CI/CD, ECR (Elastic Container Registry), les systèmes de journalisation et de surveillance et les services de mise en réseau, y compris Transit Gateway et VPC Peering. Les centraliser évite les duplications et maintient la cohérence de tout. Cette nouvelle configuration établit enfin des frontières claires entre les environnements, qui pourraient être sécurisés, isolés et évolutifs. Cela a donné aux développeurs la liberté d’agir rapidement et aux opérations la visibilité et le contrôle qu’elles recherchaient.
Pourquoi la conception basée sur l’organisation AWS fonctionne tout simplement
La nouvelle conception a transformé trois domaines majeurs : la sécurité, la gestion des coûts et l’évolutivité.
Sécurité:
L’isolement a vraiment changé la donne. Chaque compte est devenu sa propre bulle de sécurité. Si quelque chose se brisait dans Dev (par exemple, une clé était divulguée), la brèche ne pouvait pas se propager. La production est restée sûre. Toutes les actions sur les comptes étaient enregistrées de manière centralisée dans le compte Log Archive, garantissant une traçabilité et une immuabilité complètes. Les résultats d’AWS Security Hub et de GuardDuty à l’échelle de l’organisation ont été transmis à l’unité d’organisation de sécurité, offrant ainsi aux équipes une vue unique et cohérente.
Gestion des coûts :
Lorsque nous avons activé la facturation consolidée avec AWS Organizations, tout a enfin commencé à prendre un sens. Pour la première fois, chaque environnement avait son propre contrôle : plus besoin de se demander tard dans la nuit « est-ce que ça brûle en ce moment ? des jeux de devinettes pour savoir quel projet consommait des ressources. Ils pouvaient réellement voir où allait l’argent et qui le dépensait. Nous avons également ajouté des budgets et des alertes au niveau du compte pour garder les choses sous contrôle avant que les coûts ne deviennent incontrôlables. Et honnêtement, quelque chose d’aussi simple que de marquer chaque ressource avec « Environnement » et « Propriétaire » a fait toute la différence. Soudainement, le suivi des coûts n’était plus un jeu de devinettes : c’était clair, organisé et transparent.
Évolutivité :
Désormais, chaque compte était libre d’évoluer selon son propre calendrier. De nouveaux environnements pourraient être créés en Dev et ne jamais toucher à l’UAT ou à la Prod. La mise en réseau a été conçue comme une plate-forme en étoile, avec un compte de services partagés hébergeant les connexions Transit Gateway dans tous les environnements. À mesure que l’entreprise grandissait, elle pouvait continuer à intégrer de nouveaux comptes en douceur en utilisant le même modèle de gouvernance – aucune réarchitecture n’était nécessaire.
Le parcours migratoire : ce que nous avons appris.
Sur le papier, tout cela semble propre et bien rangé. Mais la migration ? C’était une autre histoire.
Migration des ressources
Le déplacement de ressources telles que EC2, RDS et S3 entre des comptes n’est pas une opération de copier-coller. De nombreux services sont étroitement liés au compte sur lequel ils ont été initialement créés. Nous avons donc réécrit certaines choses à partir de zéro et adopté une approche progressive pour migrer les données à l’aide d’AWS DataSync et de Database Migration Service (DMS), sans aucun temps d’arrêt.
Dans le même temps, nous avons migré l’ancien système monolithique du client vers une architecture basée sur des microservices. Cela nous a permis de conteneuriser les parties importantes, de les rendre plus déployables et d’adhérer à la nouvelle configuration multi-comptes. La mise à l’échelle et les mises à jour sont devenues plus fluides, chaque microservice pouvant être déployé indépendamment sur n’importe quel environnement.
Refonte du réseau
L’ancienne configuration avait des blocs CIDR qui se chevauchaient – un problème classique. Nous avons dû ré-architecturer le plan IP et tout connecter via TGW afin que tous aient leur espace d’adressage propre.
IAM et contrôle d’accès
Tous les utilisateurs et rôles se trouvaient auparavant dans un seul compte. À cette époque, nous sommes passés à une configuration multi-comptes sur AWS SSO. Désormais, si les utilisateurs se voyaient attribuer des rôles, ils étaient automatiquement placés dans les bons comptes : développeurs en développement, testeurs en UAT et opérateurs en production. Tous les rôles ont été créés par CloudFormation StackSets et tout se ressemblait.
Suivi des données et des coûts
Nous avons utilisé le marquage pour nous garder en vue pendant la migration. Étant donné que les nouveaux comptes n’avaient pas d’historique de facturation, AWS Cost Explorer a été utilisé pour corréler les anciens et les nouveaux coûts. Chaque ressource est étiquetée avec son environnement et son propriétaire pour rester transparente.
Conformité et surveillance
Pour tous les comptes, CloudTrail et AWS Config ont été activés avec la diffusion des journaux vers le compte Log Archive. Les garde-corps dans la tour de contrôle garantissaient que personne ne dérogeait aux normes de conformité.
Avantages post-migration
Dès l’instant où nous avons actionné l’interrupteur, il y a eu une grande différence.
• Le client était désormais en mesure de constater une séparation transparente des coûts entre les environnements.
• Les développeurs pouvaient jouer sans craindre de faire planter la production.
• Les équipes de sécurité ont reçu une seule interface pour surveiller et identifier les menaces.
La nouvelle architecture est bien plus évolutive, sécurisée et maintenable. Créer une nouvelle équipe ou un nouvel environnement était aussi simple que de créer un compte AWS distinct au sein de l’entreprise. L’IAM et le SSO centralisés ont réduit la complexité des accès, et les audits qui prenaient auparavant des jours pouvaient désormais être réalisés en quelques heures. Pour DevOps, l’automatisation est devenue plus fluide. Le code a été promu en toute sécurité entre les environnements à l’aide de rôles IAM entre comptes et de pipelines CI/CD au sein du compte de services partagés. Les images ECR pouvaient être partagées : il s’agissait de la même image extraite et transmise sur plusieurs comptes, sans réplication lors du déploiement.
Conclusion
La transition d’une configuration de compte AWS unique à une organisation multi-comptes n’est pas seulement une mise à niveau : c’est un changement de paradigme. Cela demande de la planification, de la patience et de la précision, mais les bénéfices à long terme sont énormes. Ce changement de paradigme signifie que notre client peut désormais bénéficier des dernières normes de sécurité, d’une transparence accrue des coûts et d’options d’évolutivité plus élevées. Nous avons remplacé ce gâchis par une organisation AWS bien architecturée, dans laquelle chaque compte était attribué à ses propres comptes dédiés de développement, d’UAT et de production, tous pris en charge par nos services centraux de sécurité et partagés.
décembre 30, 2025
Architecture avec des organisations AWS multi-comptes : comment concevoir votre organisation
Introduction
Imaginez une usine très fréquentée : une grande pièce où les concepteurs, les testeurs, les constructeurs et même le PDG travaillent côte à côte. Les machines bourdonnent tandis que les prototypes sont construits juste à côté de la chaîne de production, partageant tous les mêmes outils, la même alimentation électrique et le même espace exigu. Cela semble compliqué, n’est-ce pas ?
L’un de nos clients était confronté au même problème et gérait tout (développement, tests et production) sur un seul compte. Tout semblait assez simple au début. Mais à mesure que leur charge de travail augmentait, cette configuration est devenue un casse-tête constant. Les coûts étaient déroutants, l’évolutivité atteignait ses limites et la sécurité commençait à passer entre les mailles du filet. Les développeurs avaient trop accès à la production et la facture mensuelle constituait un énorme casse-tête qui ne donnait aucune visibilité sur la destination réelle de l’argent. Pour résoudre ce problème, nous sommes en train de reconstruire leur structure AWS avec AWS Organizations, un service conçu pour gérer et gouverner plusieurs comptes en un seul endroit. Le concept était simple : nous souhaitions une configuration sécurisée, évolutive et rentable dans laquelle chaque environnement pourrait être autonome tout en suivant un modèle de gouvernance unique.
L’ancienne méthode : un compte, trop de problèmes.
Au début, tout était créé dans un seul compte AWS. Cela fonctionnait bien quand il n’y avait que quelques personnes qui le géraient. Mais à mesure que les équipes grandissaient, le chaos augmentait également. Les développeurs, les testeurs et les opérations se déployaient tous dans le même environnement. Les groupes de sécurité ont été réutilisés à travers les étapes, les rôles IAM ont été partagés et même les informations d’identification de production traînaient avec plus de personnes qu’elles n’auraient dû l’être. Le pire ? Les coûts étaient un mystère. Avec tout facturé sur le même compte, il était presque impossible de séparer les dépenses de développement, d’UAT et de production. Les journaux de tous les environnements étaient mélangés, donc le suivi des problèmes ou la réalisation d’audits prenaient du temps. Et la mise à l’échelle ? Chaque changement d’infrastructure comportait le risque de casser quelque chose de critique dans la production.
Architecture moderne : redéfinir les environnements avec AWS Organizations.
Pour résoudre ce problème, nous avons mis en œuvre une nouvelle conception à l’aide d’AWS Organizations. Cela nous a permis de diviser chaque environnement en son propre compte AWS tout en gérant tout à partir d’une structure centralisée. Enfin, chaque compte disposait de son propre espace, de son propre budget (un montant de financement limité) et de ses propres limites d’accès, mais tout était toujours régi de manière cohérente.
Voici à quoi ressemblait la nouvelle architecture :
Discussion fluide
Schéma architectural
Organisation racine :
Le centre de contrôle principal pour l’ensemble du paysage AWS. Il est géré via AWS Organizations et AWS SSO (maintenant IAM Identity Centre), et il est lié à AWS Control Tower pour la gouvernance et les garde-fous.
UO de sécurité (unité organisationnelle) :
C’est là que résident tous les comptes axés sur la sécurité et la conformité.
• Compte d’archive de journaux : stocke les journaux de chaque environnement (CloudTrail, AWS Config, etc.) dans un emplacement sécurisé en lecture seule.
UO Services partagés :
Il comprendra toutes les plates-formes et outils partagés tels que les pipelines CI/CD, ECR (Elastic Container Registry), les systèmes de journalisation et de surveillance et les services de mise en réseau, y compris Transit Gateway et VPC Peering. Les centraliser évite les duplications et maintient la cohérence de tout. Cette nouvelle configuration établit enfin des frontières claires entre les environnements, qui pourraient être sécurisés, isolés et évolutifs. Cela a donné aux développeurs la liberté d’agir rapidement et aux opérations la visibilité et le contrôle qu’elles recherchaient.
Pourquoi la conception basée sur l’organisation AWS fonctionne tout simplement
La nouvelle conception a transformé trois domaines majeurs : la sécurité, la gestion des coûts et l’évolutivité.
Sécurité:
L’isolement a vraiment changé la donne. Chaque compte est devenu sa propre bulle de sécurité. Si quelque chose se brisait dans Dev (par exemple, une clé était divulguée), la brèche ne pouvait pas se propager. La production est restée sûre. Toutes les actions sur les comptes étaient enregistrées de manière centralisée dans le compte Log Archive, garantissant une traçabilité et une immuabilité complètes. Les résultats d’AWS Security Hub et de GuardDuty à l’échelle de l’organisation ont été transmis à l’unité d’organisation de sécurité, offrant ainsi aux équipes une vue unique et cohérente.
Gestion des coûts :
Lorsque nous avons activé la facturation consolidée avec AWS Organizations, tout a enfin commencé à prendre un sens. Pour la première fois, chaque environnement avait son propre contrôle : plus besoin de se demander tard dans la nuit « est-ce que ça brûle en ce moment ? des jeux de devinettes pour savoir quel projet consommait des ressources. Ils pouvaient réellement voir où allait l’argent et qui le dépensait. Nous avons également ajouté des budgets et des alertes au niveau du compte pour garder les choses sous contrôle avant que les coûts ne deviennent incontrôlables. Et honnêtement, quelque chose d’aussi simple que de marquer chaque ressource avec « Environnement » et « Propriétaire » a fait toute la différence. Soudainement, le suivi des coûts n’était plus un jeu de devinettes : c’était clair, organisé et transparent.
Évolutivité :
Désormais, chaque compte était libre d’évoluer selon son propre calendrier. De nouveaux environnements pourraient être créés en Dev et ne jamais toucher à l’UAT ou à la Prod. La mise en réseau a été conçue comme une plate-forme en étoile, avec un compte de services partagés hébergeant les connexions Transit Gateway dans tous les environnements. À mesure que l’entreprise grandissait, elle pouvait continuer à intégrer de nouveaux comptes en douceur en utilisant le même modèle de gouvernance – aucune réarchitecture n’était nécessaire.
Le parcours migratoire : ce que nous avons appris.
Sur le papier, tout cela semble propre et bien rangé. Mais la migration ? C’était une autre histoire.
Migration des ressources
Le déplacement de ressources telles que EC2, RDS et S3 entre des comptes n’est pas une opération de copier-coller. De nombreux services sont étroitement liés au compte sur lequel ils ont été initialement créés. Nous avons donc réécrit certaines choses à partir de zéro et adopté une approche progressive pour migrer les données à l’aide d’AWS DataSync et de Database Migration Service (DMS), sans aucun temps d’arrêt.
Dans le même temps, nous avons migré l’ancien système monolithique du client vers une architecture basée sur des microservices. Cela nous a permis de conteneuriser les parties importantes, de les rendre plus déployables et d’adhérer à la nouvelle configuration multi-comptes. La mise à l’échelle et les mises à jour sont devenues plus fluides, chaque microservice pouvant être déployé indépendamment sur n’importe quel environnement.
Refonte du réseau
L’ancienne configuration avait des blocs CIDR qui se chevauchaient – un problème classique. Nous avons dû ré-architecturer le plan IP et tout connecter via TGW afin que tous aient leur espace d’adressage propre.
IAM et contrôle d’accès
Tous les utilisateurs et rôles se trouvaient auparavant dans un seul compte. À cette époque, nous sommes passés à une configuration multi-comptes sur AWS SSO. Désormais, si les utilisateurs se voyaient attribuer des rôles, ils étaient automatiquement placés dans les bons comptes : développeurs en développement, testeurs en UAT et opérateurs en production. Tous les rôles ont été créés par CloudFormation StackSets et tout se ressemblait.
Suivi des données et des coûts
Nous avons utilisé le marquage pour nous garder en vue pendant la migration. Étant donné que les nouveaux comptes n’avaient pas d’historique de facturation, AWS Cost Explorer a été utilisé pour corréler les anciens et les nouveaux coûts. Chaque ressource est étiquetée avec son environnement et son propriétaire pour rester transparente.
Conformité et surveillance
Pour tous les comptes, CloudTrail et AWS Config ont été activés avec la diffusion des journaux vers le compte Log Archive. Les garde-corps dans la tour de contrôle garantissaient que personne ne dérogeait aux normes de conformité.
Avantages post-migration
Dès l’instant où nous avons actionné l’interrupteur, il y a eu une grande différence.
• Le client était désormais en mesure de constater une séparation transparente des coûts entre les environnements.
• Les développeurs pouvaient jouer sans craindre de faire planter la production.
• Les équipes de sécurité ont reçu une seule interface pour surveiller et identifier les menaces.
La nouvelle architecture est bien plus évolutive, sécurisée et maintenable. Créer une nouvelle équipe ou un nouvel environnement était aussi simple que de créer un compte AWS distinct au sein de l’entreprise. L’IAM et le SSO centralisés ont réduit la complexité des accès, et les audits qui prenaient auparavant des jours pouvaient désormais être réalisés en quelques heures. Pour DevOps, l’automatisation est devenue plus fluide. Le code a été promu en toute sécurité entre les environnements à l’aide de rôles IAM entre comptes et de pipelines CI/CD au sein du compte de services partagés. Les images ECR pouvaient être partagées : il s’agissait de la même image extraite et transmise sur plusieurs comptes, sans réplication lors du déploiement.
Conclusion
La transition d’une configuration de compte AWS unique à une organisation multi-comptes n’est pas seulement une mise à niveau : c’est un changement de paradigme. Cela demande de la planification, de la patience et de la précision, mais les bénéfices à long terme sont énormes. Ce changement de paradigme signifie que notre client peut désormais bénéficier des dernières normes de sécurité, d’une transparence accrue des coûts et d’options d’évolutivité plus élevées. Nous avons remplacé ce gâchis par une organisation AWS bien architecturée, dans laquelle chaque compte était attribué à ses propres comptes dédiés de développement, d’UAT et de production, tous pris en charge par nos services centraux de sécurité et partagés.
Source link
Partager :
Articles similaires