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 Adopter une stratégie multi-comptes pour isoler les différents jeux et applications dans 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. Il est essentiel d'isoler l'environnement en restreignant l'accès à celui-ci et en autorisant uniquement l'utilisation des AWS services requis, 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 fortement recommandé d'isoler davantage les principaux sous-systèmes de chaque environnement, ainsi que les services communs utilisés par plusieurs environnements pour être hébergés et gérés de manière autonome 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) au cas par cas Comptes AWS, afin de réduire la portée des incidents. AWS Organizations Envisagez de gérer de manière centralisée la hiérarchie de vos opérations Comptes AWS afin de simplifier davantage les opérations, ainsi que de définir et d'appliquer de manière sélective des politiques au niveau du compte et de l'unité organisationnelle (au niveau de l'unité organisationnelle). En concevant une UO et une Compte AWS structure adaptées à vos besoins de développement et de flux de production, vous pouvez optimiser vos coûts et améliorer l'évolutivité.

Étapes d’implémentation

Un système de jeu déployé dans AWS doit utiliser plusieurs comptes organisés de manière logique pour assurer une isolation adéquate, ce qui réduit la portée des problèmes et simplifie les opérations à mesure que votre infrastructure de jeu évolue. Comptes AWS cette infrastructure de jeu hôte est généralement regroupée dans les environnements logiques suivants :

En ce qui concerne l'infrastructure de jeu AWS, il est recommandé de créer des comptes distincts pour chaque environnement de jeu (développement, test, mise en scène et production), ainsi que des comptes pour la sécurité, la journalisation et les services partagés centralisés.

Généralement, 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 intermédiaire). Toutefois, au fur et à mesure que votre infrastructure de jeu ou la taille de votre équipe s'agrandit au fil du temps, ce modèle simplifié risque de ne pas bien évoluer.

Lorsque vous configurez ces environnements, tenez compte du fait que de nombreux AWS services partagent les ressources et les Quotas de Service au niveau de l'API pour l'ensemble d'un compte au sein d'une région donnée. Cela doit être pris en compte lors de la détermination de la manière d'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. Cela permet donc de réduire efficacement la contention des ressources et les quotas de service, en particulier à mesure que votre jeu grandit et que de plus en plus de développeurs ont besoin d'y accéder pour créer et gérer des ressources.

Sur la base de notre expérience de travail avec de grands studios de développement de jeux qui exploitent généralement des milliers de serveurs avec des centaines de développeurs accédant aux ressources, nous vous recommandons de concevoir une structure de compte plus fine dans laquelle les applications prenant en charge votre jeu disposent de leurs propres comptes de développement, de test, de mise en scène et de production. Comme il est difficile et fastidieux de repenser votre stratégie AWS multicompte une fois que vous avez lancé votre jeu en raison de la complexité de la planification et de la migration des systèmes live, tenez compte de vos futurs besoins d'évolutivité lorsque vous déterminez la bonne structure multicompte. 

Vous pouvez l'utiliser AWS Organizationspour établir une hiérarchie Comptes AWS, regrouper et définir des unités organisationnelles (OUs) afin de leur appliquer des politiques communes au niveau de l'unité organisationnelle par le biais de politiques de contrôle des services ()SCPs. AWS Organizations gère et gouverne de manière centralisée votre environnement au fur et à mesure que vous développez et faites évoluer vos ressources. Vous pouvez créer de nouveaux comptes et allouer des ressources par programmation, 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 centralisées, des mécanismes de sécurité, des exigences d'audit et le partage des ressources entre les comptes de votre organisation.

AWS Control Towerfournit un moyen simple de configurer et de gérer un environnement multi-comptes sécurisé, appelé zone d'atterrissage. Control Tower crée votre zone de landing zone en utilisant AWS Organizations, en apportant une gestion et une gouvernance continues des comptes, ainsi que les meilleures pratiques AWS de mise en œuvre basées sur l'expérience de travail avec des milliers de clients lors de leur migration vers le cloud. AWS Config, AWS Trusted Advisor, et AWS Security Hub CSPMsont 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 garde-fous personnalisés ou individuels pour chaque environnement de jeu. Les comptes de production doivent disposer des garde-fous, 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. Les environnements hors production 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 vidéo utilisant AWS Organizations des unités organisationnelles (OUs) pour se regrouper logiquement Comptes AWS dans des environnements et des studios distincts. Dans cet exemple, OUs sont utilisés pour regrouper des comptes en fonction de leur environnement, puis en fonction du studio qui gère l'environnement. Cela montre comment vous pouvez créer une hiérarchie imbriquée pour permettre à des applications et à des jeux distincts d'être déployés dans leurs propres comptes au sein de leur environnement (illustré par OUs), 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 jeu (organisation) doté d'un pipeline de développement composé de 4 étapes (développement, test, mise en scène et production). Pour un jeu donné (game1), chacun des environnements (UO) 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 général, chaque jeu utilisant ce type de pipeline de développement reproduirait cette structure ou une structure similaire pour le sien Comptes AWS.

Outre cet environnement centré sur le jeu OUs, il existe également l'unité d'organisation des services partagés et l'unité d'organisation de sécurité. Ils OUs devraient ê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é.