How exactly does target-based auto-scaling work?

@REDACTEDUSER

1. You asked the fleet to scale to zero as the min instance count is set to zero " Under Instance Limits , check that the minimum and maximum limits are appropriate for the fleet. With auto-scaling enabled, capacity may adjust to any level between these two limits."

See https://docs.aws.amazon.com/gamelift/latest/developerguide/fleets-autoscaling-target.html

There is a natural tension about what todo with fleets scaled to zero. For some developers a fleet scaled to zero should remain there because you know there should be no traffic to fleet, why pay for empty instance hours during game development? There are also lots of fleets deliberately shut off like this.

For other developers, esp during alpha/betas, you want the fleets to be available at all times so you expect traffic to drop to zero and then start up again.

For now, GameLift respects the hard stop of fleets at zero, even if target tracking is on. I know GameLift has been looking at how to support both, but for now you need to maintain some active buffer for GameLift to autoscale your fleet or a process to kick off scaling again.

2. Metrics propagation is relatively fast but scaling up new instances is expensive (takes x minutes depending on instance type, region and OS). Your build needs to be dropped onto the machine, spun up and then connected to GameLift. I'd recommend tracking metrics on instance creation time as this will help you understand what spare capacity you might need and also enables you to tune your server launch time.

3. I don't know the internals here. But downscaling requires stopping existing resources which can take time esp if resources are slow to respond. In addition EC2 instances do not stop instantly, your game server also needs to shut down when it gets that termination signal, logs need to be uploaded etc (https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift-sdk-interactions.html#gamelift-sdk-interactions-shutdown-request).
   GameLift generally considers capacity gone once a server / session has been successfully terminated (or force terminated if your process will not exit cleanly).

You should ideally track / measure metrics around the time to shutdown for your server and ensure you shutdown correctly (to avoid hitting the time delays around forced shutdowns).

4. You reduce player wait times by having some spare capacity in your fleet. First, you maximize your server costs by: packing as many servers per instance as you can, use Linux servers and use spot. Second, you understand the cost of scaling up new servers based on your metrics. Thirdly, you have some data that helps drive where your scaling needs to be (ie expected load, peak loads etc).

Then you work out what spare capacity/buffer is sufficient for your needs.

"Choosing a buffer size depends on how you want to prioritize minimizing player wait time against controlling hosting costs. With a large buffer, you minimize wait time but you also pay for extra resources that may not get used. If your players are more tolerant of wait times, you can lower costs by setting a small buffer. "

Some folks do manual scaling to really control costs (which is tricky) or use Lambdas/processes to handle some aspects of their scaling (ie scale up fleets on weekend in region x, or move fleet from zero based on some metrics).

Hope that helps somewhat.

Thanks @REDACTEDUSER