Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# GAMEOPS02-BP01 Adoptez une stratégie multi-comptes pour isoler les différents jeux et applications sur leurs propres comptes
Concevez une structure de compte qui orienterait le déploiement de l'infrastructure afin de répondre aux besoins opérationnels, de sécurité et d'isolation de chaque environnement. L'isolation de l'environnement en restreignant l'accès à celui-ci et en n'autorisant que l'utilisation des AWS services requis est essentielle, les environnements de production étant verrouillés, tandis que les environnements de développement et de test sont indulgents pour permettre l'expérimentation. Il est vivement recommandé d'isoler davantage les principaux sous-systèmes de chaque environnement, ainsi que des services communs utilisés par plusieurs environnements pour être hébergés et gérés indépendamment Comptes AWS .
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Adoptez une stratégie multi-comptes AWS en isolant les différents environnements (tels que le développement, les tests, la mise en scène, la production et les services partagés) des environnements individuels Comptes AWS, ce qui réduit la portée des incidents. Envisagez AWS Organizations de gérer de manière centralisée votre hiérarchie Comptes AWS afin de simplifier davantage les opérations, ainsi que de définir et d'appliquer des politiques au niveau du compte et au niveau de l'unité organisationnelle () OU-level de manière sélective. En concevant une unité d' Compte AWS organisation et une structure adaptées à vos besoins en matière de flux de travail de développement et de production, vous pouvez optimiser vos coûts et améliorer l'évolutivité.
+ **Adoptez une stratégie multi-comptes : ** isolez les environnements pour réduire le rayon des incidents et simplifier les opérations.
+ **Utilisation AWS Organizations : ** gérez les comptes de manière hiérarchique, appliquez des politiques et activez une gouvernance centralisée.
+ **Planifiez l'évolutivité : ** concevez des structures de comptes précises et mettez en œuvre des mesures de réduction des coûts pour la croissance future.
### Étapes d’implémentation
Un système de jeu déployé dans AWS doit utiliser plusieurs comptes organisés de manière logique pour fournir une isolation adéquate, ce qui réduit le nombre de problèmes et simplifie les opérations à mesure que votre infrastructure de jeu évolue. Comptes AWS qui hébergent l'infrastructure de jeu sont généralement regroupés dans les environnements logiques suivants :
+ ****Les environnements de développement de jeux sont utilisés par les développeurs pour développer les logiciels et les systèmes du jeu.
+ ****Les environnements de test ou d'assurance qualité (QA) sont utilisés pour effectuer des tests d'intégration, des tests d'assurance qualité manuels et d'autres tests automatisés qui doivent être effectués.
+ ****Des environnements de préparation ou de pré-production sont utilisés pour héberger le logiciel complet afin que des tests de charge et de fumée puissent être effectués avant le lancement en production.
+ ****Les environnements en direct ou de production sont utilisés pour héberger le logiciel et l'infrastructure en direct et pour gérer le trafic de production des joueurs.
+ **Les environnements de services ou d'outils partagés ** permettent d'accéder à des systèmes, logiciels et outils communs utilisés par de nombreuses équipes différentes. Par exemple, un référentiel central de contrôle de source auto-hébergé et une ferme de builds de jeux peuvent être hébergés dans un compte de services partagés.
+ ****Les environnements de sécurité sont utilisés pour consolider les journaux centralisés et les technologies de sécurité utilisées par les équipes qui se concentrent sur la sécurité du cloud.
Lorsque l'infrastructure de jeu est activée AWS, il est recommandé de créer des comptes distincts pour chaque environnement de jeu (développement, test, préparation et production), ainsi que des comptes pour la sécurité, la journalisation et les services partagés centraux.
En général, les petits studios de développement de jeux qui gèrent un nombre limité de ressources d'infrastructure, généralement quelques centaines de serveurs ou moins, peuvent en créer un Compte AWS pour chacun de ces environnements (par exemple, un compte de production, un compte de développement et un compte de test). Cependant, à mesure que votre infrastructure de jeu ou la taille de votre équipe augmentent au fil du temps, ce modèle simplifié risque de ne pas s'adapter correctement.
Lorsque vous configurez ces environnements, tenez compte du fait que de nombreux AWS services partagent des quotas de ressources et de API-level [ services ](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) pour l'ensemble d'un compte au sein d'une région donnée. Cela doit être pris en compte pour déterminer comment organiser les comptes de manière logique. Comptes AWS n'entraînent des coûts que pour la consommation des services qui y sont déployés. C'est donc un moyen de réduire efficacement les conflits de ressources et les quotas de service, en particulier lorsque votre jeu se développe et que de plus en plus de développeurs ont besoin d'un accès pour créer et gérer des ressources.
Sur la base de notre expérience de collaboration avec de grands studios de développement de jeux qui exploitent généralement des milliers de serveurs et des centaines de développeurs accèdent à des ressources, nous vous recommandons de concevoir une structure de compte plus précise dans laquelle les applications prenant en charge votre jeu disposent de leurs propres comptes de développement, de test, de test, de test et de production. Comme il est difficile et fastidieux de redéfinir votre stratégie AWS multi-comptes une fois que vous avez lancé votre jeu en raison de la complexité de la planification et de la migration des systèmes en direct, tenez compte de vos futurs besoins d'évolutivité lorsque vous déterminez la bonne structure multi-comptes.
Vous pouvez l'utiliser [AWS Organizations](https://aws.amazon.com/organizations/) pour établir une hiérarchie et un regroupement d'unités organisationnelles ( Comptes AWS UO) et définir des unités [ organisationnelles ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (UO) afin de leur appliquer des OU-level politiques communes par le biais de politiques de contrôle des [ services ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP). AWS Organizations gère et gère de manière centralisée votre environnement au fur et à mesure que vous développez et adaptez vos ressources. Vous pouvez créer de nouveaux comptes par programmation et allouer des ressources, regrouper des comptes pour organiser vos flux de travail, appliquer des politiques aux comptes ou aux groupes à des fins de gouvernance et simplifier la facturation en utilisant un mode de paiement unique pour vos comptes. En outre, Organizations est intégré à d'autres services afin que vous puissiez définir des configurations centrales, des mécanismes de sécurité, des exigences d'audit et le partage des ressources entre les comptes de votre organisation.
[AWS Control Tower](https://aws.amazon.com/controltower/)fournit un moyen simple de configurer et de gérer un environnement sécurisé à comptes multiples, appelé zone * d'*atterrissage. Control Tower crée votre zone de destination en utilisant AWS Organizations, en apportant une gestion et une gouvernance continues des comptes, ainsi que les meilleures pratiques de mise en œuvre, basées sur AWS l'expérience de travail avec des milliers de clients lors de leur migration vers le cloud. [AWS Config](https://aws.amazon.com/config/)[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), et [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) sont des services qui fournissent une vue agrégée ou centralisée de l'hygiène de votre compte.
Cette isolation vous aide à configurer des autorisations et des barrières personnalisées ou individuelles pour chaque environnement de jeu. Les comptes de production doivent disposer des barrières, des restrictions d'accès, des outils de surveillance et d'alerte et de sécurité nécessaires, tandis que les comptes hors production peuvent ne pas nécessiter le même niveau de garde-fous et d'autorisations. Non-production les environnements peuvent être automatisés pour arrêter les ressources en dehors des heures de bureau et réduire les coûts. La séparation des comptes à ce niveau de granularité facilite le suivi des coûts d'infrastructure pour chacun des environnements supportant un jeu.
Voici un exemple de structure multi-comptes pour une société de jeux utilisant des unités organisationnelles ( AWS Organizations UO) à regrouper logiquement Comptes AWS dans des environnements et des studios distincts. Dans cet exemple, les unités d'organisation sont utilisées pour regrouper les comptes en fonction de leur environnement, puis en fonction du studio qui gère l'environnement. Cela montre comment créer une hiérarchie imbriquée pour permettre le déploiement d'applications et de jeux distincts sur leurs propres comptes au sein de leur environnement (représentés par des unités d'organisation), ce qui peut être utile si vous développez et exploitez plusieurs jeux. Consultez la documentation et les livres blancs fournis dans la section des ressources de ce pilier pour en savoir plus sur les stratégies supplémentaires que vous pouvez envisager pour organiser votre stratégie multi-comptes.
Sur la base de la discussion ci-dessus, l'exemple de schéma ci-dessous suppose un studio de jeux (organisation) qui dispose d'un pipeline de développement composé de 4 étapes (développement, test, mise en scène et production). Pour un jeu donné (jeu1), chacun des environnements (OU) possède des services de jeu individuels Comptes AWS , des serveurs de jeu dédiés, des services sociaux et des serveurs Web. Les ressources qui s'exécutent dans chacun Compte AWS sont pertinentes pour les sous-systèmes respectifs. En règle générale, chaque jeu utilisant ce type de pipeline de développement reproduirait cette structure ou une structure similaire pour son Comptes AWS.
Outre ces UO d'environnement centrées sur le jeu, il existe également l'UO de services partagés et l'UO de sécurité. Ces UO doivent être applicables à l'ensemble de l'organisation, et non à chaque jeu individuel. De cette façon, les jeux consommeraient les services partagés pour les outils de développement, les données et les analyses, comme dans cet exemple. Envoyez ensuite les journaux de l'application et du système à la Compte AWS configuration des journaux dans l'unité d'organisation de sécurité.
