Guide to the Pre-Production Stage for a Successful Game Launch with Amazon GameLift Servers - Part 1

In the pre-production stage, four things must be solidified first: game server testing, session lifecycle, session placement queue, and observability. To reduce the operational burden right before launch, the hosting method and monitoring system should be established together starting from the initial design.

Testing should be validated locally first, then run on an Amazon GameLift Servers fleet with actual traffic. The article recommends container fleets, advising you to measure CPU/memory consumption, the number of servers/containers per instance, and the maximum player load in order to choose C/M/R family and AWS Graviton instances. The key is to keep a separate development AWS account and attach bots or actual testers from multiple regions to check even network latency.

The server lifecycle is managed by starting with InitSDK, followed in order by ProcessReady, OnHealthCheck, OnStartGameSession, ActivateGameSession, and ProcessEnding. ProcessReady should be called only once after initialization is complete, player connections should only be opened after OnStartGameSession, and once a session ends the process should not be reused but terminated so a new process can be launched. Even in situations where placement waits for days, OnHealthCheck should continue to check normal status.

Using a GameLift queue for session placement enables failover, multi-fleet placement, latency/cost prioritization, and receiving placement events.

• Use only StartGameSessionPlacement, and set the queue timeout and player latency policies realistically.
• Receive events via SNS or EventBridge, and update the backend and player state using Lambda with DynamoDB or WebSocket.
• Even without a latency policy, location priority can be given via Priority Configuration Override, and it is also integrated by default with FlexMatch.
• If you want to use Amazon GameLift Anywhere resources first, set that Destination as the first priority.

For observability, CloudWatch Logs, metrics, and alarms are key.

• Container fleets should send logs to CloudWatch or S3, while EC2 fleets should use the CloudWatch Agent or download logs within 14 days after the session ends.
• Key metrics include CPUUtilization, MemoryUtilization, NetworkIn, NetworkOut, PercentAvailableGameSessions, AvailableGameSessions, UnhealthyInstanceReplaced, ServerProcessAbnormalTerminations, AverageWaitTime, PlacementsFailed, and PlacementsTimeOut.
• Apply detailed log levels and structured logging, and integrate with external observability tools using sidecars or agents.

The next installment will cover preparations for 2-3 months before launch.