Managing Your Game Studio on AWS: Part 1

Written by Adam Hatfield, Pawan Matta and Daniel Whitehead
Edited by Nathan Graves

As game developers first begin their cloud journey, you commonly hear them ask, “Where do we start?” AWS has over 200 services, countless features, and it can be hard to know where to begin and why. One of the most beneficial things your game studio can do early on is establish good management and governance of your AWS environments.

Every studio or game developer needs to maintain control over costs, compliance, and security while quickly innovating; so you’re not slowed in bringing new experiences to your players. As your studio gets closer to certain project milestones, you need to be able to have the peace of mind knowing you can easily scale out your account structures while maintaining insights into your costs and billing.

This is the first post in a series that will discuss best practices and AWS services, like AWS Control Tower, that you – as a single game developer or large studio – can use to manage your AWS environments and scale with your game and players.

Management and governance using AWS Control Tower

AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive AWS best practices. AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, AWS Cloudtrail, AWS Config and AWS Single Sign-On (SSO) to build a landing zone, a multi-account environment meant to hold your associate accounts, compliance standards, guardrails, and single sign-on directories. Once your Landing Zone has been deployed you can begin setting up AWS Organizations and AWS Single Sign-on; this allows you to manage your accounts and allow developers access to AWS resources all from the Control Tower console.

Establishing guardrails

Through guardrails, AWS Control Tower implements preventive or detective controls that help you govern your resources and monitor compliance across groups of AWS accounts. A preventative guardrail prevents users from performing certain actions while a detective guardrail monitors and notifies about policy violations. A guardrail applies to an entire organizational unit (OU), and every AWS account within the OU is affected by the guardrail. When game developers perform work in any AWS account in your landing zone, they’re always subject to the guardrails that are governing their account’s OU.

AWS Control Tower breaks guardrails up into three categories: mandatory, strongly recommended, and elective. Mandatory guardrails, like enabling AWS Config in all regions, are automatically applied when you create your Landing Zone. Strongly recommended guardrails are based on AWS best practices for well-architected multi-account environments. Finally, elective guardrails enable you to lock down and track commonly restricted actions in your AWS environment.

At minimum, you should enable the following the guardrails for your game development studio:

• Mandatory guardrails are enabled by default; view the mandatory guardrails documentation for more information.

Example of Mandatory Guardrails enabled by default

• Strongly recommended guardrails; view the strongly recommended guardrails documentation for more information.

Example of Strongly Recommended Guardrails

• • Detect Whether Encryption is Enabled for Amazon EBS Volumes Attached to Amazon EC2 Instances
  • Detect Whether Unrestricted Internet Connection Through SSH is Allowed
  • Detect Whether MFA for the Root User is Enabled
  • Detect Whether Public Read Access to Amazon S3 Buckets is Allowed
  • Detect Whether Public Write Access to Amazon S3 Buckets is Allowed
  • Detect Whether Amazon EBS Volumes are Attached to Amazon EC2 Instances
  • Detect Whether Amazon EBS Optimization is Enabled for Amazon EC2 Instances

• Elective Guardrails; view the elective guardrails documentation for more information.

Example of Elective Guardrails

• • Disallow Changes to Replication Configuration for Amazon S3 Buckets
  • Disallow Delete Actions on Amazon S3 Buckets Without MFA
  • Detect Whether MFA is Enabled for AWS IAM Users
  • Detect Whether MFA is Enabled for AWS IAM Users of the AWS Console
  • Detect Whether Versioning for Amazon S3 Buckets is Enabled

For a complete list and explanation of all available guardrails, refer to the guardrail reference documentation.

Managing your game studios multi-account structure with AWS Organizations

When you created your Landing Zone, it enabled a way for you to centrally manage your studio’s accounts and environments with AWS Organizations, an account management service that lets you consolidate multiple AWS accounts into an organization that you create and centrally manage; all from the Control Tower console.

AWS Organizations helps centrally manage billing; control access, compliance, and security; and share resources across your member AWS accounts. This will enable your game studio to have good visibility in to your accounts, know how you’re utilizing and spending on AWS services, and allow you to budget for the right resources at the right time.

With AWS Organizations, accounts are grouped into logical groups, called OUs. OUs enable you to organize your accounts into a hierarchy (such as Studio -> Game Team -> Environment) and make it easier for you to apply management controls. AWS Organizations policies are what you use to apply such controls in the accounts. This enables you to do things like group all of your live/prod accounts for different games into one OU. You could then apply AWS Organizations service control policies to the prod OU that prevent the live game servers from being deleted in any of the governed prod accounts, even if an IAM role in the account has the permissions to do so.

For accounts created with Control Tower or are enrolled in to a Landing Zone you should always use the Control Tower console page to update, create and add accounts or additional OUs. This will automatically enroll them in to the Landing Zone and subject them to all compliance standards and guardrails you’ve enabled. Any account or Organization created outside of Control Tower’s Landing Zone will need to be manually enrolled for management.

OUs are just one part of your overall multi-account strategy. Once you know how you want to manage the accounts, you need plan out how to deploy them. When considering which resources to run in different accounts, you need to consider that AWS services share service and API-level Service Quotas for each account in a Region.

For smaller game development studios, you may find it easier to set up individual accounts for your live/prod, development, and staging environments. Just remember that as your game studio and player base grow, this model may not scale with them. Always consider your future internal team and player needs when creating your account structures so you don’t encounter issues with regional Service Quotas in a single account.

Above is an example AWS Organizations structure for single game developers and smaller game development studios. Here, we create single accounts under different OUs to host our prod, dev, staging, and test accounts; we also include accounts for shared services like your build farms or analytic pipelines for dashboarding. Security logging and tooling should be separated in their own accounts for better granularity of control and isolation. If you’re a single game developer or smaller game development studio, don’t let the number of accounts in the Organizations example be a blocker against setting up AWS Control Tower and a Landing Zone. These services make it easier to manage this number of accounts, scale with future growth, and easily onboard new employees. Single sign-on integration especially makes it easy to sign into each individual account. Finally, using features like service control policies in Organizations helps you manage these accounts by applying rules that limit what can be done in each environment.

For larger game development studios, you should design a more fine-grained account structure where individual applications supporting your game have their own development, test, staging, and production accounts for each. Our experience has shown that it’s both difficult and time consuming to redesign your multi-account strategy after you’ve launched your first game. This is due to the complexities of migrating live services. Always consider your future scaling needs when determining your multi-account strategy. For more tips, take a look at the Well-Architected Game Lens.

This is an example Organizations structure for large game development studios. This works well if you’re managing accounts across multiple games with thousands of game servers. Here, you separate your OUs based on studio, game, and service. Each individual service, whether it’s the dedicated game servers, web servers, or social services, have an individual account. You do this to lower your chance of encountering a regional API or service quota. Shared services, monitoring, and tooling can all be placed in single individual accounts for easier management.

Once you’ve established your OUs and account structures, you must establish identity federation using AWS SSO. Identity federation is a system of trust between two parties for the purpose of authenticating users and conveying information needed to authorize their access to resources. In this system, an identity provider (IdP) is responsible for user authentication, and a service provider (SP), such as a service or an application, controls access to resources.

With Organizations, you’re able to control SSO access and user’s permissions across all your AWS accounts. As a best practice, we recommend you integrate SSO with a third-party identity provider and follow the concept of least privilege when assigning IAM permissions.

From a game developer’s perspective, they would sign into their AWS environment via the SSO login page and MFA. Once they’re authenticated, they’re presented with the roles and accounts they can federate in to as shown below. From here, they can access their AWS environments so they can focus on that next raid boss, jumping puzzle, or whatever innovative experience they’re trying to bring to players.

Conclusion

In this post, we’ve covered how single game developers to large game development studios can establish management and governance of their environments with AWS Control Tower by building a Landing Zone; a container for the AWS Organizations, accounts, users, guardrails, and AWS Single Sign-On capabilities AWS Control Tower orchestrates on your behalf.

We discussed your needs to plan for the future and be able to scale out your account structures easily, while automatically having guardrails and identity federation in place.

In our next post, we will discuss tagging strategies, account templates with AWS Control Tower’s account factory, and introduce the CUDOs Dashboard so you can see the costs associated with your environments.

For more information on the best practices for cloud gaming, visit the Gametech Well-Architected Lens documentation.