FleetIQ was named after the Spot viability logic from GameLift Queues and Fleets. This feature is for customers looking for a less managed version of GameLift where customers have more control of the AutoScalingGroup and what happens on the instances. A GameServerGroup creates an AutoScalingGroup in your account. At that point, you can directly update the launch template on the ASG, add scaling policies, SSH onto your EC2 instances, whatever you need to run your game.
The main benefits a GameServerGroup provides:
- Spot viability management. GameLift will continuously monitor the instance types / availability zones for Spot viability and modify your AutoScalingGroup so players are less likely to see Spot interruptions, but still utilizing Spot for cost savings.
- Game server management. When server processes are ready to host a game session, they should register with GameLift via RegisterGameServer. When your matchmaker is ready to place a match, it can call ClaimGameServer in order to get an available game server (including any ConnectionInfo or GameSessionData you want to provide) and connect players to that process.
- ClaimGameServer also performs AutoScaling instance protection (if enabled) and game session packing to make sure your instances are full rather than spreading game sessions across all instances. This provides more cost savings since AutoScaling can scale in faster as player traffic comes down.
What happens on each instance is up to you. As you mentioned, with more control comes more responsibility with this feature. You can use Kubernetes/Agones (Introducing the Amazon GameLift FleetIQ adapter for Agones | AWS Game Tech Blog), other 3rd party process management, or create your own process manager to run on each instance. If you want GameLift to manage processes on each instance, that’s more in-line with what a GameLift Fleet provides.
I would recommend reading EC2 metadata to get the IP address/port your process is using and provide that info in RegisterGameServer as the ConnectionInfo. When your matchmaker calls ClaimGameServer, it will then have the IP/port needed for players to connect to the process.
GameServerData can be used either as a way for your server process to send data to your backend service when it calls ClaimGameServer, or your backend service can pass GameServerData in the ClaimGameServer request to the server process on the instance.
Hopefully that clears up this feature for you, let me know if you have any more questions.