Clarifying GameLift pricing, costs, and best practices for saving money

Hello everyone, I wanted to try clearing things up about costs with regards to GameLift. According to the GameLift pricing page,

Amazon GameLift charges for instances by duration of use and bandwidth by quantity of data transferred.

After reading the pricing example, I have this question. How is instance usage exactly quantified? Because technically an instance will always be running x amount of server processes depending on how you configure your fleet. A lot of times, there will be no active game sessions nor players in these server processes. However, the processes will still be running if I am not mistaken. So I guess what I am trying to ask here is, are we being charged for whenever GameLift is running? For example, making GameLift AWS SDK API calls and having active game sessions/player sessions?

I have also read this article as well as this forum post that both recommend having a spot fleet as well as an on-demand fleet. So my other question is what is the benefit of doing this and if possible, could anyone provide a real-life example that would help visualize the advantages of this approach? Because I am not sure why we need on-demand fleets at all. How often are spot instances actually unavailable?

Lastly, I read this article about target-tracking auto scaling policies. In the article, they set the targeted server capacity to be 20% available game sessions. However, doesn’t this ultimately waste money if you don’t have that much traffic to your game, which results in a lot of unused game sessions? Or am I misunderstanding terms?

Thanks in advance, since as usual, this is a lot.

Instance usage is billed from the time your server is ACTIVE (ie ready to host game sessions) to the time you terminate it in GameLift (TERMINATED)

  • For Linux this is per second billing.
  • For Windows this is to the nearest hour
    https://aws.amazon.com/gamelift/faq/
    “Billing begins when you allocate Amazon GameLift capacity and Amazon GameLift launches your game’s server binary for the first time on each instance. Billing concludes when you stop instances. For Windows instances, which are billed per instance-hour, partial instance-hours consumed are billed as full hours. For Linux instances, which are billed per instance-second, there is a 1 minute minimum charge per-instance.”

So if you have a server thats in an ACTIVE state in GameLift, you are paying for it even if its idle waiting for GameSessions.

Use of spot fleets is entirely about your acceptance of risk. Spot instances are EC2 selling its spare capacity in a region, as demand grows, this spare capacity will be absorbed and Spot instances will be harder to get and potentially subject to termination.

If you are using FleetIQ it will prioritize placement on the Spot fleets (as long as GameLift is not seeing interruptions on that instance type in the regions). But at some point Spot interruptions may occur.

If you have an OnDemand Fleet then FleetIQ will potentially start placing on that fleet and so in this way you are sheltered from Spot instance interruptions.

Luckily games demand runs counter to business demands (high in the day, low in the evenings mostly) so theres generally a decent amount of Spot capacity unless you are using very large instances. Not sure what the official data shows, but for many developers interruption rates are very low (I thought there was a GDC talk related to this but I can’t find it right now that has someone’s actual data)

  • The best thing to do is measure this yourself and see (easier said than done of course) but GameLift provides interruption metrics on the dashboard.

I wish there was a perfect formula here as in if you are doing x then use y. I know, GameLift wants to make it easy to use Spot and take some of the guesswork out of this so I would suspect more changes would be coming in the future in this space.

tldr: you save a huge amount of money using Spot + Linux + Concurrent Executions.

The amount of spare capacity you carry in your fleets is really up to you and how quickly traffic ramps up for you. The first useful metric is to work out how long a new server takes to activate for you. If you’re out of capacity this is the worst case time for players to wait for a new session.

If you are small developer, this may be a trade off you are willing to take/have to take because you don’t want to pay for that spare capacity (again Spot makes that a little easier to swallow).

Hope that makes some sense. I don’t officially represent the GameLift service and if you have further questions, you should feel to reach out to them via AWS Support esp if you want the official GameLift answers on these things.

I am happy to keep answering your questions thought :wink:

1 Like

I think I have thanked you so many times, but thank you again Pip. When you say “server”, do you mean the server process/game session, the instance that holds these processes, or the fleet that holds these instances?

If “server” means instance, then aren’t we technically being charged for 24 hour usage by default if we have at least one fleet? Because the default auto-scaling policy sets the “Manually adjust the desired instance count” to 1.

Sorry for my lack of clarity here. By server I really mean the underlying EC2 instance, which can host many copies of your game server.

You are changed for the EC2 instance(s) from the time the first game server process goes active on that instance until the time all of your game server processes are terminated on that instance (basically for all the time an instance could be used to host a game session).

If a fleet has a desired set to 1 (and an instance hosted server process that went ACTIVE) then you will be charged for it. You cannot create a fleet without 1 ACTIVE instance, but you can always scale a fleet to zero desired.

And yes, Gamelift has that annoying issue where you can’t autoscale up from zero, so if you need autoscaling then you need to have at least active instance. You could of course you a secondary process like a Lambda or similar to manually scale during tests/known periods of zero traffic) or in response to event (such as player login etc).

Hope that makes sense.

1 Like