The core problem is that there's no metrics being emitted if there's no capacity and no game sessions, hence there's no data to autoscale on. I'd be interested in hearing more about how you're thinking about this use case.
If you really do want to autoscale down to zero, the current workaround to get back above zero is to have a separate system like an AWS Lambda function, or maybe your matchmaking system have the credentials to scale up from zero when needed, then the GameLift autoscaling rules would kick back in again since they'll have metrics data to scale on again.
I don't think I follow what you mean. If you have auto-scaling policies set up, GameLift would automatically scale up/down based on the rules that you have set up.
I hope that answers your question. Let us know if you need more information on how to set up auto-scaling policies.
Thanks for the heads up on AWS Lambda, im not very familiar with it but sounds awesome, i was about to start coding my node.js master server but this should do it!
Im also more familiar with GameLift after i messed around with it for a month, i think a combination of a Lambda and a T2 fleet as a bare minimum while C3 fleets adds capacity would work in my use case (low player base with huge bursts)
Is it still the case that Gamelift cannot autoscale from 0 instances? I have been trying to work with the QueueDepth metric thinking that the queue would be holding that information but it does not seem to be spinning up a new instance.
Sorry to necro, but I think this is important. At least one active instance incurs costs (got caught by this recently), so it would be nice if we could scale up from zero without an AWS lambda instance or something.
As for the QueueDepth metric, what I noticed is that there is two versions of it: one for the overall queue and one for the fleet. The rule-based metric goes off the fleet one, which for some reason remains at zero. This is what I mean: (dark blue is Queue depth and cyan is fleet Queue depth)
This is the configuration that I would like:
Ideally the process would be client calls
StartGameSessionPlacement -> policy
scale goes into effect -> add 1 new instance
Then, when active sessions drop to zero, we scale down until eventually zero instances (and no costs :slight_smile:)
With regards to your issue with QueueDepth metric: The queue depth metric for the fleet that is positioned first in the queue should match that of the queue itself. (see screenshot below).
If this is not the case, then please share your QueueArn / FleetArn and we can investigate what is going on.
Hi, sorry for the late response. I'm not sure I understand - what you have pictured looks like the queue depth of two different fleets to me.
This is what I see:
The queue depth metric for the fleet looks like it is above the queue depth of the queue itself
How exactly does target-based auto-scaling work?asked 2 years ago
ECS Capacity Provider Scale In Timeasked 3 months ago
Auto scaling from zero capacity?Accepted Answerasked 6 years ago
Auto scaling questionAccepted Answerasked 4 years ago
Clarifying GameLift pricing, costs, and best practices for saving moneyAccepted Answer
How to Make a Game Server Activate Itself?asked 8 months ago
Should ECS/EC2 ASGProvider Capacity Provider be able to scale-up from zero, 0->1Accepted Answerasked a year ago
How to create a client authoritive player for a multiplayer gameAccepted Answerasked 5 years ago
How to deal with terminating game sessions with zero players in themAccepted Answer
How GameLift Local works with game sessionsAccepted Answerasked a year ago