Managing your Game Studio on AWS part 2:

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

In part one of our series, we discussed the importance of management and governance of your AWS resources for Game Development Studios. We focused on deploying Landing Zones using AWS Control Tower and the services it orchestrates on your behalf, like AWS Organizations and AWS Single-Sign on. Please note SSO is now AWS IAM Identity Center. For more information on the AWS IAM Identity Center announcement click this link.

In part 2, we will discuss the best practices around tagging and tagging enforcement, how AWS Control Tower enables you to easily create new accounts using the account factory feature, how you can track costs with budget views and AWS Cost Explorer, and finally, how your studio leads can deploy the CUDOs dashboard to have a granular view in to the studio’s AWS costs.

Tagging AWS Resources

For Game Studios to operate efficiently in the cloud, they need to be able to know the who, what, where and how much for all the AWS services their development teams are using. To accomplish this, you use something called a tag to help manage and identify the resources deployed in your AWS environment. More specifically, Tags are custom attribute labels that you assign or that AWS assigns to AWS resources. Tags are composed of two parts: the tag key and the tag value. Tags can help you manage, identify, organize, search for, and filter resources.

Tagging is important to game development studios of any size because everyone needs to controls costs at some point. If you’re a larger studio or game publisher then odds are you have multiple titles in production internally or throughout a portfolio of startups and indie studios you own. You will need a way to track the AWS costs associated with each studio or separate title and tagging your resources is the easiest way to enable that.

If you’re a smaller indie or startup studio then you may be operating on lean budgets to make the most out of your latest funding round. Tagging can enable you to not only have granular insight in to your spending but also the ability to perform actions like spinning down Amazon EC2 instances with a developer environment tag during the weekend.

Using tags to help monitor and control costs is just one example of the benefits of tagging. If you’d like to read more about tagging and how it works on AWS visit the tagging technical docs.

The above tags are best practices examples and can be tailored specifically to your studio or games notation processes. 

At a minimum you should create tags in 4 main categories: technical tags, tags for automation, business tags and security tags. Technical tags are used to identify and group resources based on game, device cluster, and other information. Tags for automation are used to schedule processes or opt an application or resource in to an automated process. Business tags are used to identify things like cost center and who the resource owner is. Finally, security tags can be used to identify resources that hold PII or are subject to compliance and regulations.

Take a look at the tagging examples here and see if you implement your own tagging schema in your studio’s environment.

Enforcing Tagging with Tag Policies and Service Control Policies

Once your tagging schema is in place it’s time to decide how to enforce it. Tagging enforcement can mean different things at each studio. Some game studios may only want to send alerts based on non-compliant resources while others may prevent the creation of resources that aren’t tagged properly.

Example of the Tag Policies console in the Organizations AWS console page

You can automatically enforce the tagging standards that your game studio chooses to adopt by creating and deploying tag policies using the AWS Organization in your Landing Zone. Tag policies let you specify tagging rules that define valid key names and the values that are valid for each key. You can choose to enforce or only monitor, giving you an opportunity to evaluate and clean up your existing tags. Once your tags are following your chosen standards, you can then turn on enforcement in the tag policies to prevent non-compliant tags from being created. For more information, see the AWS Organizations User Guide.

{
    "tags": {
        "Environment ": {
            "tag_key":{
                "@@assign": "environment"
            },
            "tag_value":{
                "@@assign": [
                    "Production",
                    "Sandbox",
                    "Developer",
                    "QA Testing"
                    ]
            },
            "enforced_for":{
                "@@assign":[
                    "EC2:instance"
                    ]
            }
            
        }
    }
}

Example Tag Policy enforcing valid environment tag for EC2 instances.

Above is an example tag policy for EC2 instances; it specifies that all EC2 instances have an environment tag, and that tag must have a value of Production, Sandbox, etc. This will keep game developers and back-end engineers from improperly tagging EC2 resources but will not prevent those resources from launching, for that we’ll need to use one additional feature of Organizations mentioned in our previous post.

As mentioned previously, AWS Organization service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. With SCP’s we can do things like prevent resources, such as EC2 instances, from being launched if they aren’t properly tagged. This is a great way to ensure your resources are launched according to your studio’s standards.

Take a look at the SCP example below. In the statement, you can see we set an explicit deny for the EC2:RunInstances API call for EC2 instances and volumes. This disallows the creation and deployment of new EC2 instances and volumes in the account regardless of a user’s IAM permissions. Normally we wouldn’t want to instantiate a policy like this in to a prod environment as we wouldn’t be able to launch any game servers. However, we can include conditions in SCP statements to allow you to limit when the overall policy is in effect. In the below policy we see that the SCP becomes null when an allowed tag from the environment tag policy above is applied to the EC2 instance and volume. This will allow users to launch EC2 instances in that account as long as they’re properly tagged.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2Creation",
      "Effect": "Deny",
      "Action": [
        "EC2:RunInstances"
      ],
      "Resource": [
        "arn:aws:EC2:*:*:instance/*",
        "arn:aws:EC2:*:*:volume/*"
      ],
      "Condition": {
        "Null": {
          "aws:RequestTag/environment": "true"
        }
      }
    }

Example AWS Organizations Service Control Policy preventing EC2 instance creation without the proper environment tag.

The combination of Organization’s tag policies and SCP’s gives your studio a very granular and flexible management and enforcement mechanism that ensures you can see who and what is deployed in your AWS environments. Once you have tagging and enforcement mechanisms in place, you can begin to take advantage of other features like AWS Control Tower’s account factory to automate the creation of additional environments with enforced tagging standards. For a deeper dive and examples on how you can use tagging policies take a look at this post from the AWS management and governance blog

Automation with AWS Control Tower Account Factory

Our management services enable you to automate the creation of accounts, establish guardrails on those accounts and give you the ability to monitor not only what resources are running in your environment but also how much you’re spending on them. Enabling automation gives you more time to focus on the things that matter and less on planning and deploying new environments.

The AWS Control Tower Account Factory enables cloud administrators and IAM Identity Center end users to provision new accounts in your landing zone. An Account Factory is a configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations. These accounts can be preconfigured to work with IAM Identity Center and a 3rd party identity provider to let your team quickly and securely access your environments using SAML federation. As you place these accounts in to their respective Organizational Units (OU); any guardrails, SCPs or tag policies you’ve associated with that OU will automatically apply to the new account. This helps game leads and back end engineers quickly scale out your studios account structures throughout each phase of your game’s development.

Finally, here are some key consideration if your studio is thinking about using AWS Control Tower’s Account Factory in conjunction with your landing zone:

• Accounts that you provision through the AWS Control Tower Account Factory can be updated, they can be closed, or they can be repurposed. For example, you can repurpose existing accounts for other workloads and other users by updating the user parameters for the account.
• If you specify a new AWS SSO user email address when you update the provisioned product associated with an account that was vended by Account Factory, AWS Control Tower creates a new AWS SSO user account. The previously created user account is not removed. If you prefer to remove the previous AWS SSO user email from AWS SSO, see Disabling a User.
• With Account Factory you can also change the OU for an account, or you can unmanage an account. For more information on unmanaging an account, see Unmanage a member account. Certain updates require that you or an administrator must Sign in as a Root User to the account to gain appropriate permissions.

Your studio can further automate the process using services like AWS Lambda, AWS Cloudwatch, AWS Eventbridge, and the AWS Control Tower Account Factory.  For a deeper look at how you can automate account creation with Account Factory, take a look at this blog post.

Budgets and Billing

AWS Control Tower also helps game studios see how much they’re spending across their environments by offering features like consolidated billing and budget views. After creating your landing zone, you can use AWS Organizations to gain better visibility in to how much your spending on AWS. Through Organizations the billing data for all accounts is centralized into a consolidated billing report. This allows organization-wide visibility through AWS Cost Explorer and forecasting and alerting through AWS Budgets.

When setting up your billing alerts with AWS Budgets we suggest you follow the 50/70/90 rule. You would setup separate alerts when you’re 50%, 70% and 90% at your monthly budget.

For example, if you use 50% of your budget by the 10th of the month then you know you’ll be over budget well before the end of the billing period. With that in mind, you can switch your game servers over to spot instances to lower your compute costs for the remainder of the month.

With AWS Cost Explorer you can also create forecasts for how much you may be spending on resources over a given period of time. You can then setup alerts to notify the team to implement cost saving measures. You should note that forecasts are predictions based off of past usage and may not account for final charges at the end of the billing cycle.

Having good tagging and enforcement policies also helps you identify what you’re spending money on. If you’ve tagged your resources properly, you can filter through which services can be switched off during non-peak times. Following AWS’s utility model this will allow you to incur additional savings on things like compute or database resources since you’re only charged while they’re in a running state.

Finally, game studios need a way to visualize their cost and usage across their environments. AWS offers several prebuilt dashboards solutions, the Cloud Intelligence Dashboards, to help with BI and visualization needs.

CUDOS Dashboard

The CUDOS Dashboard is an in-depth, granular, and recommendation-driven dashboard to help customers dive deep into cost and usage and to fine-tune efficiency. CUDOS utilizes the Cost and Usage Reports which is the most granular billing data of all the resources running in an account. The Cost and Usage Reports also follow the structure of your organization allowing a studio to enable these at the root of the account structure which would then allow you to see all the resources running in all of the linked accounts.

CUDOS’s reporting capabilities are compounded by the tagging schema which was mentioned earlier in this blog. By enforcing tagging, a studio will be able to ensure all resources are labeled; this allows you to see at a macro level all of the components of what it takes to run your game. Additionally, CUDOS will make recommendations on specific services to suggest possible cost savings or more efficient machines to ensure you get the most value out of every dollar.

Some of the out of the box features of CUDOS are:

• Cost data for all services running in all regions
• Month over month trends of service usage ensuring you know what is expected versus anomalous
• Built-in tag explorer to group and filter cost and usage by your tags.
• View resource-level detail such as your hourly AWS Lambda or individual Amazon S3 bucket costs.
• Get alerted to service-level areas of focus such as top 3 On-Demand database instances by cost.
• CUDOS is highly customizable and can incorporate 3rd party data

For more information on how to deploy the CUDOS dashboard take a look at this link.

Conclusion

Starting your cloud journey as a new or existing game studio can be challenging. Establishing management and governance early on will enable your studio to quickly scale to the needs of your players. Utilizing services like AWS Control Tower and its management features will allow your studio to quickly scale your accounts throughout the different development phases of your game. Establishing oversight using tags and enforcement polices will ensure you can track the who, what and when for resources deployed in your AWS environments; and your studio can maintain granular insight in to your costs so you can budget for future player experiences and new titles using AWS budgets and the CUDOs dashboard.

For more information on using AWS Control Tower take a look at our first post in the management and governance series. If you’d like to read more about best practices for deploying game workloads on AWS take a look at the Well Architected Framework Games Lens.