GAMEOPS02-BP01 Adopt a multi-account strategy to isolate different games and applications into their own accounts

Design an account structure that would guide the infrastructure deployment to comply to each environment's security, isolation, and operational needs. Environment isolation by restricting access to it and permitting only requisite AWS services to be used in them is essential, with production environments being locked down, while development and testing environments are lenient to permit experimentation. Further isolation of major sub-systems in each environment, and common services that are used by multiple environments to be hosted and managed out of their own AWS accounts is highly recommended.

Level of risk exposed if this best practice is not established: High

Implementation guidance

Adopt a multi-account strategy on AWS by isolating the different environments (like development, test, staging, production, and shared services) to individual AWS accounts, which reduces the scope of incidents. Consider AWS Organizations to centrally manage the hierarchy of your AWS accounts to further simplify operations, as well as define and apply account-level and organizational unit-level (OU-level) policies selectively. By designing an appropriate OU and AWS account structure that is aligned to your development and productional workflow needs, you can optimize your costs and enhance scalability.

Implementation steps

A game system deployed in AWS should use multiple accounts that are logically organized to provide proper isolation, which reduces the blast radius of issues and simplifies operations as your game infrastructure scales. AWS accounts that host game infrastructure are typically grouped into the following logical environments:

For game infrastructure on AWS, it is recommended to create separate accounts for each game environment (development, testing, staging, and production), as well as accounts for security, logging, and central shared services.

Typically, smaller game development studios that manage a limited number of infrastructure resources, usually a few hundred servers or less, may create one AWS account for each of these environments (for example, one production account, one development account, and one staging account). However, as your game infrastructure or team size grows over time, this simplified model may not scale well.

When setting up these environments, consider that many AWS services share resource and API-level Service Quotas for an entire account within a particular Region. This must be considered when determining how to logically organize accounts. AWS accounts only incur cost for consuming services deployed into them. Therefore, this provides a way to effectively reduce resource contention and service quotas, particularly as your game grows and more developers need access to build and manage resources.

Based on our experience working with larger game development studios that typically operate thousands of servers with hundreds of developers accessing resources, we recommend you design a more fine-grained account structure where individual applications supporting your game have their own development, testing, staging, and production accounts. Because it's difficult and time consuming to re-design your AWS multi-account strategy after you have launched your game due to the complexity in planning and migrating live systems, consider your future scaling needs when determining the right multi-account structure. 

You can use AWS Organizations to set up a hierarchy and grouping of AWS accounts, and define organizational units (OUs) to apply common OU-level policies to them through service control policies (SCPs). AWS Organizations centrally manages and governs your environment as you grow and scale your resources. You can programmatically create new accounts and allocate resources, group accounts to organize your workflows, apply policies to accounts or groups for governance, and simplify billing by using a single payment method for your accounts. Additionally, Organizations is integrated with other services so that you can define central configurations, security mechanisms, audit requirements, and resource sharing across accounts in your organization.

AWS Control Tower provides a straightforward way to set up and govern a secure, multi-account environment, called a landing zone. Control Tower creates your landing zone using AWS Organizations, bringing ongoing account management and governance as well as implementation best practices based on AWS's experience working with thousands of customers as they move to the cloud. AWS Config , AWS Trusted Advisor, and AWS Security Hub CSPM are services that provide an aggregated or centralized view of your account's hygiene.

This isolation assists you to set up custom or individual permissions and guardrails to each game environment. Production accounts should have the necessary guardrails, access restrictions, monitoring and alerting, and security tools, while non-production accounts may not require the same level of guardrails and permissions. Non-production environments can be automated to shut down resources after hours and save costs. Separation of accounts at this level of granularity makes it straightforward to monitor infrastructure costs for each of the environments supporting a game.

The following is an example of a multi-account structure for a game company using AWS Organizations and organizational units (OUs) to logically group AWS accounts into separate environments and studios. In this example, OUs are used to group together accounts based on their environment and then based on the studio that operates the environment. This demonstrates how you can create a nested hierarchy to allow separate applications and games to be deployed into their own accounts within their environment (depicted as OUs), which can be useful if you develop and operate multiple games. Refer to the documentation and whitepapers provided in the resources section of this pillar to learn about additional strategies that you can consider for organizing your multi-account strategy.

Based on the discussion above, the sample diagram below assumes a game studio (Organization) that has a development pipeline comprised of 4 stages (development, testing, staging, and production). For a given game (game1), each of the environments (OU) has individual AWS accounts for game services, dedicated game servers, social services, and web servers. The resources that run in each AWS account are relevant to the respective sub-systems. Typically, every individual game using this kind of development pipeline would replicate this or a similar structure for its AWS accounts.

In addition to these game-centric environment OUs, there are also the shared services OU and security OU. These OUs should be organization-wide, not for each individual game. That way the games would consume the shared services for development tools and data and analytics as in this example. Then, send application and system logs to the AWS account set up for logs in the security OU.