AWS for Small Game Studios - Concepts
Are you a small games studio looking to build your next great game, but unfamiliar with AWS? Here's your on-ramp: the basic concepts to get started!
Isaac Lenhart
Amazon Employee
Published Dec 6, 2024
In my day to day, I come into contact with a lot of small games studios, or groups of students at a game jam who might be looking to build and run their awesome game and bring it to the world successfully.
AWS is an powerful and fully featured cloud, providing a wide and deep range of options, so I'm often not surprised to hear that "getting your feet wet" can be confusing and intimidating. After all, AWS is used the world-over by large, global, enterprise companies, so the functionality of the cloud can seem like it's a lot to take in. "Isn't this super complicated?", "Fortune 500 companies use it all over the world, isn't it super expensive?", "I'm not sure what we would use it for?" For many game developers who are heads down in VS Code, Unreal or Unity UI's, the cloud is sometimes a foreign idea.
I'm here to give you a reassurance that, yes, AWS supports very large global cases, but also the very beginning entry cases, particularly for a small studio or group of students on a budget. Because of the importance of the way game studios are funded and use their funds, here I focus a lot on starting small and looking at costs being low.
This is important to think about, because game studios typically start small with a fantastic idea, then can rapidly grow to be hugely successful. In a short period of time, you (yes, you!) could be that large, global studio, and a key question is whether you have the early foundations to support that growth. The good news is that AWS scales up and down with you.
If this is you, a small games studio, or perhaps a group of students looking to build out a game, and don't know where to start, I'd like to provide a simple "primer" on getting started on AWS, where I'm coming from my own personal experience and advice to provide you the information I think is most useful to a small games studio in particular.
So, in a way, I'm talking to the AWS n00bs (Sorry, I had to do it).
This entry is heavy on some of the important concepts you as a games studio should have in mind as you come into AWS. The more concrete steps will come later, but this is initially here to orient how you should think about AWS.
My personal working definition of the concept of the cloud is basically this: "compute functionality that you pay for on an as-needed basis", where compute means "the processing power needed to accomplish something". As a starting example, this might take the form of requesting specific servers (AWS Instances) that you want to use for whatever period of time you like.
And while this is totally useful in many cases, "using a server" is a very specific way of looking at it. "Compute" can also mean more abstractly "running a process for me, while not specifically caring what hardware or server instances are underneath as long as it fits the need". This is typically referred to as either "serverless" or "managed", the nuances of which I won't get into here, but in general this means some level of administration and management is handled for you by AWS, saving your team time and effort.
Key Point: The time and effort you spend on things is also a cost to you
Case in point: Your team is writing a game server in Unity and you want to host and connect to it for testing. Just to pick a few simple possibilities, you could:
- Request a specific server instance in a specific location in AWS, deploy your game server code to it; and connect your client to that IP address; or,
- You could request a specific server instance in AWS, install Kubernetes on that, run the game server code within a container and connect your client to that IP Address.
In both of these cases, you've asked for a server you want to administer and do whatever you like with it. So, it's your own team's time and effort being used to manage that server instance, and in many cases this is might be exactly the outcome you want. Maybe this is how you've always done it before, which is fine.
However, in a lot of cases your ultimate goal as a studio is not necessarily to be administering and configuring server instances constantly, it's to develop and run a cool game and game-adjacent functionality. Your team may not have the need, time, skills or interest to also be administering the nuts and bolts of *how* it is running. And the time your small team of game developers are having to spend administering server setups is time your team is not spending working on the game itself.
So, instead of thinking about managing server instances, there are also higher levels of abstraction. You could instead wrap your game server in a container and simply provide that container to a service like AWS Fargate which would automatically take care of "the servers" for you under the hood.
Or, you could use a managed service like Amazon Gamelift, where you just upload the game server build, tell it what kind of load requirements you need, and the service automatically takes care of what servers, how many should be running, keeping them updated, etc.
In both of these latter cases, "what the server is" becomes less of a concern and a responsibility for you, because AWS is managing the servers for you.
Side Quest: A Guide to Gamelift and Game Servers
Side Quest: What is Serverless Computing
This whole concept of "not dealing with servers" can sometimes trip up a game studio, who might come with the preconception that a cloud provider like AWS is just about "renting servers for a studio to use". Believe me, I see that all the time, and while that's a solid foundational piece of what AWS can provide, much of the value of the AWS cloud is using the capabilities where you don't have to manage and administer the server instances under the hood.
The underlying point here is that as you think of the cloud and the activities of your studio, you should consider what business outcome and level of administration effort you actually want.
Do you want or need to be requesting specific servers and administering, securing, patching them? Or do you want to abstractly just accomplish your goal of running a game without worrying about the more involved administration? Either scenario is totally appropriate and valid in given contexts, but this underlying decision-point should inform your entire mindset and processes around AWS as you move on.
Side Quest: Six advantages of Cloud Computing
Almost every service in AWS is priced on a per/time basis or on a per/call/data basis. So, if you spin up a server instance or service for 6.5 hours and then shut it off, you will only pay for the 6.5 hours. Alternately, if you use an always-on AWS-managed service like Amazon Bedrock to generate game concept art, you are only paying for the amount of data you exchanged with it: if you didn't send Amazon Bedrock any data, it's not costing anything.
There is some slight nuance to this, particularly around data traffic, but understanding this basic model at a high level tells you something about how you should approach the cloud, if you're trying to do it cheaply.
Key Point: AWS is architected around providing flexibility, scaling and automation. To save on costs, you should take full advantage of these aspects.
In the general sense, if you aren't actively using "a thing", you aren't paying for it. There's no commitments or subscriptions. You can set up an account in AWS, start nothing up, have it sit empty month after month, then close the account. So, it's a low barrier to at least get started and grow as fast as you want.
Many services and products have a free tier. This means that for many services if you're only barely using them, it doesn't cost you anything anyway.
For example, say you want to test out storing player profile data in a NoSQL database: the fully AWS-managed NoSQL DynamoDB has a free tier of 25GB storage and 200M requests/month. If you are consistently under the free tier month after month, it still costs you nothing to use and this is true for a huge number of services. A free tier, no management, and you can just use it? Honestly, that's pretty good.
Despite the no/low-cost aspects above, it's still really important to have a good view on what you're actually spending. Nobody wants surprises, especially a small game studio trying to use their funding efficiently. The flip side of it being easy to start and stop services and products in AWS willy-nilly can also mean it's extra important to keep an eye on what is actually running and what is being charged. Happily, AWS gives you a lot of tools in the form of Cost Explorer, Budgets, Alerts, to help keep an eye on this, as well as the ability to automate turning things on and off.
Side Quest : AWS Cost Optimization Best Practices
As an example, one of the first things I usually recommend for a small studio or a group of students is setting up a budget alert in their account. This can send alerts to tell you whether you currently are -or are forecasted by the end of the month- to exceed some max value that you supply. You can even automate it, so that exceeding the budget switches things off, leading to...
One common case a studio may have is to set up a CI/CD server along with build agents, pulling from a Git repo and creating a build artifact of the game. In a build process, you might not need a server running 24/7 (168 hrs/week), you might only need it running 9-5 on weekdays (40 hours). So, you might set up a schedule for that build controller to only run it during the 23% of the week you need it to, saving 77% of what you otherwise would have spent.
Or say build agent servers, you only want them running when they are actually performing a build. So, you might use "auto-scaling groups" for the build agents: defining a group of servers that start up when they are needed, run their task, and completely disappear when they are done. These servers would only run minutes at a time and be off the rest of the time.
Automation like this is easy to setup and it's a key part of keeping your costs down.
AWS has a huge amount of hardware under the hood, all over the world. Many -if not most- AWS customer companies and studios need to have a known, relatively quantified amount of compute all the time, and in these cases, these are known as dedicated instances.
They "belong" to the AWS customer as long as they continue to use them and cannot be taken away until they release them. However, this still leaves a large amount of spare, unused capacity within AWS. It would be efficient for everyone if there was a way to incentivize that usage as well, leading to AWS offering that extra capacity as Spot Instances.
Some game studio workloads you might be doing don't require holding on to a server for a long time. You might only need a server for 10 minutes for a CI/CD build or a server starting up to run a short session-based multi-player game. In other words, you "know" you won't be needing the server for a long period of time. Because AWS typically has this extra capacity in reserve, AWS can offer up a server instance to you for a steep discount, up to 90% off the price. For example, instead of paying $0.03 per hour, you pay perhaps $0.003 per hour.
So, great, what's the catch? Your use of these Spot Instances can be interrupted (with a pre-warning). If another company needs to reserve that kind of instance for a dedicated reason, your instance will get a two minute pre-notification the instance you're using will be interrupted, and typically you would handle that notification to gracefully stop. Therefore, the use of spot instances is really, really cheap, but best suited for situations where the interruption of the server's activity would be fine (or can be mitigated), or a situation where you know the process won't run long enough to be potentially interrupted.
Now, at first glance, it sounds like an interruption could happen quite a lot and is thus a major downside, but these kinds of interruptions are not necessarily that often. If you take a look at the AWS instance advisor, most instance types are interrupted less than 5% of the time over the course of a month. So, while it's a possibility, you can at least make predictions on how likely it actually would be, and balance that against up to 90% in costs you're saving in the meantime.
The use of spot instances, while not applicable in every situation, is an often overlooked cost advantage. You can use spot instance directly when you ask for a server, or for some of the managed services like Fargate or Gamelift, you can tell it to use spot instances under the hood even if you never interact with those server instances yourself. Do it on the cheap!
At the heart, the approach of AWS is one of being for builders. There are over 200 different products in AWS covering compute, storage, databases, networking, developer tools, analytics, mobile and so forth.
At the lowest level, you can think of many of these products acting as building blocks -much like LEGO- where you can assemble and combine these to create whatever platform you have in mind. And for innovative games studios, they very often do have a need to be creating something never seen before.
To help with your team doing the building this cool new stuff, there's plenty of training and resources to get you up to speed, no matter what part of the game development and release pipeline you're at. And while you're at it, talk to your AWS for Games account team about the possibility of getting Proof of Concept credits, and getting more direct hands-on workshops with your team. There are many ways of ramping up your builder skills fast.
So, AWS very much encourages the builder culture, getting hands-on, and developing the cool new features and products of the future.
Side Quest: AWS Heroes and AWS Builders Communities
However, while building things from scratch is often needed to be doing something new and exciting, it's very often the case that you're not building something new, you're doing something that is already well known and not worth your effort to re-invent from scratch and manage. Very few studios want to build a custom, in-house source control system. That's plumbing that is widely available.
To that end, when thinking of things you assume are solved but you don't want to build, you have the options of booting up an AWS templated solution, or simply buying and deploying a well-tested commercial solution into your own AWS account.
A "package" of technologies in AWS can be described using Infrastructure as Code (IaC). IaC, if you're not familiar, is basically a descriptive way of describing a set of cloud components to be deployed. There are many IaC providers like Cloudformation, Terraform, Pulumi, etc, and these can (and should) be used in your normal deployment processes.
Side Quest: Best practices for IaC in AWS
When you're developing your studio's abilities and the game itself, there are many cases where the problem you're addressing has been solved already, and therefore are available as deployable solutions, rather than you building them.
For example, say you are wanting to collect real-time data from your games (player behavior, logs, monetization numbers, game level design metrics, etc) and use that data for analytics. Rather than build it yourself from scratch, you can deploy and use the existing Game Analytics Pipeline solution.
Or say you need a game backend solution handling identity, login, player data. You can deploy and use the Custom Game Backend framework.
But, what does using these mean? A IaC solution is a definition of a set of interconnected AWS products, and really all it is doing is creating in one swoop all of the necessary pre-defined AWS products needed to support its purpose. When you deploy the solution, all of those products are deployed as described and begin running, just as if you had manually created it piece by piece yourself. Therefore, while you get the immediate benefit of having the entire solution up and running, it is also active and begins -as you might expect- incurring cost. And if you don't like it, you just un-deploy it.
This is a good option when you need something that is "well-known and solved", and is perhaps relatively complicated, and you don't want to build it all yourself or even want to customize or add on to the solution. So, this path is completely relevant for a wide number of scenarios. If this fits your case, you can see pre-created solutions in the AWS Solutions repos.
AWS is not shy about working with external technology partners who provide a solution that runs on AWS. There are game technology partners that provide game backends, social solutions, build servers, logging, source control, studio-in-a-box, and it's very possible you simply want to use those and not build anything at all. Yet, those solutions need to run somewhere.
In these cases, it's very easy to buy the technology solution you prefer and deploy it on AWS. Some key examples of AWS technology partners are: Accelbyte (Gaming backend services) solution, Databricks (AI, data engineering, ML) , Incredibuild (Optimized build technology ) , Revolgy's Remangu (Virtual game studio in the cloud) , Perforce's Helix Core (Version Control) and many, many more.
An extensive list of partners is on the AWS partner page , and if you can't find what you're looking for in that list, reaching out to that provider directly will show you how to deploy it on AWS.
In fact, whenever you have a technology product in mind, it's very much worth first looking at the AWS Marketplace which allows you to find a technology you're interested in, and then easily deploy that into your own AWS account with the press of a button. There are real financial, billing, and organizational benefits to doing so, and worth discussing with your AWS for Games Account Team.
So, alright, this has been my quick(?) romp through the overall concepts you should have in mind as you start using AWS : management approach, your costs and your overall technology approach. I would absolutely love to hear more from small game studios about the kinds of general cloud concepts that seem mysterious, so drop me a line or comment if you have something to add.
As a next step, we will go into the actual, practical nuts and bolts of setting up an account and key considerations you should have as a games studio. Along the way, we'll also cover things like account strategies, access considerations, logging, and so forth. So stay tuned!
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.