Amazon Web Services says GameLift can support up to 100M concurrent users per game


Amazon Web Services (AWS) said it has benchmark tested support for up to 100 million concurrent users (CCU) for a single game.

Using Amazon GameLift, AWS can alleviate a developers’ game server hosting concerns by dynamically scaling backend resources. The test also showcased how Amazon GameLift can add 100,000 players to a game each second and spin up more than 9,000 new compute instances each minute. This offers developers the ability to scale their games far beyond what’s been previously possible.

Amazon GameLift is a cloud-based service that helps developers add game servers for multiplayer games. It’s built on top of AWS.

The company noted online game developers pour tremendous resources and passion into bringing new games and updates to life. On launch days, those efforts are put to the ultimate test as players flood the system, but developers don’t necessarily know how many players to expect. What developers do know is that the backend infrastructure supporting incoming traffic must be able to scale instantly without compromising player interactions, or the entire experience falls apart.

Chris Byskal, general manager of AWS Game Services/Game Tech, said in a statement, “While most developers don’t publish CCU numbers, unofficial tracking data indicates that the most popular games in the world today top out around 14 million CCU, and the latest SteamDB reporting puts the CCU for the entire platform at not quite 40 million. We choose 100 million CCU as our goal metric to highlight how Amazon GameLift can easily handle even the biggest games, several times over.”

Estimating CCU is a starting point for developers to determine game scaling needs prior to launch. Additional scaling considerations include how to quickly handle spikes in traffic, as well as game session allocation and player geography.

The AWS team behind Amazon GameLift has nearly a decade of experience helping customers run their games at scale while avoiding launch day missteps. This includes putting the solution through extreme scenarios. For a step-by-step guide on how they scaled for 10 million CCU and 100 million CCU, check out the following demonstration.

Preparing for scale

Developers can use projected CCU to determine the required virtual machine (VM) capacity for optimal game performance. For example, here’s how to calculate VM requirements to support 10 million CCU for a game, assuming one VM can support 12 game sessions before performance starts to degrade.

Total VMs = CCU / (players per game session x game sessions per VM)
Total VMs = 10,000,000 / (10 x 12) = 83,333

Amazon GameLift has capacity available in 23 AWS regions and nine local zones, allowing it to comfortably scale to the 83,333 VMs needed to support 10 million CCU. Amazon GameLift can bring virtual machines into service in a matter of minutes, enabling developers to smoothly and quickly increase capacity from zero to ten million players. This autoscaling functionality minimizes idle capacity—keeping the overall costs down.

Creating game sessions quickly and sensibly

AWS allocates players to spare game server capacity. All game sessions must be run on a game server process, and developers must avoid assigning multiple games to the same process. Consider the throughput of these allocation requests:

Allocation requests/second = CCU / (players per game session x seconds per game session)
Allocation requests/second = 10,000,000 / (10 * 900) = 1112 (rounding up)

Here are other considerations:

Game sessions: Having each session assigned to a single game process.
Location: Assigning a game server with low latency to the game session’s players.
Cost: If multiple hardware options are available, using the lower cost capacity first.
Capacity: Leveraging autoscaling to avoid paying for more capacity than needed.
Virtual machine usage: Monitoring which VMs have live games on them so they are not accidently terminated—interrupting players’ games.
Capacity health: Validating that the capacity allocated is healthy (for example, avoiding non-responsive server processes).
Number of VM game sessions: Starting too many game sessions on the same VM in a short period of time might exceed compute capabilities of the VM if there are computationally heavy actions, like loading a map or initializing game state.

Many of these considerations can narrow down suitable VM choices for a specific game session. At this level of scale, it’s possible to have 100 game sessions wanting to start in a single AWS Region during the same second. Developers could try to pack these 100 game sessions onto two idle game server processes on a single VM. However, this means 98 of them are going to fail and need to locate new idle capacity. Meanwhile, more game sessions may have arrived and are waiting to start, compounding the problem.

These types of problems are minimal at low rates of throughput, but quickly become a huge issue as rates increase. This can lead to anything from elevated game start times to a complete collapse of availability, potentially ruining launch day.

Scaling with Amazon GameLift

Once devs have integrated the game server with Amazon GameLift, upload the game server executable and any dependent assets as a Build and create a Fleet to run in AWS.



Leave a Comment