Sourcewalker — English

Does GameLift Really Run Itself? (1) — Why We Chose GameLift

I gave a talk at Games on AWS 2026. The topic was how we redesigned the global game servers for FreeStyle Football 2. The talk went fine. Now I want to write it down. Some points went by quickly in the talk. I will explain them in more detail here. This first post is about why we chose GameLift.

Where our servers started

For a long time, I built game servers on Windows with IOCP and RIO. IOCP and RIO are Windows APIs for high-performance network I/O. I built this game server the same way. I did not split the server by role. One binary did all the work.

Unreal Dedicated Server ran the actual matches. An Agent that I wrote started and stopped the dedicated server processes. The Agent was the only part we separated from the game server.

We ran our closed beta test (CBT) on this structure. Then we analyzed the CBT data. Our conclusion was simple: "This structure will not work."

Player count and match count are different

The game server accepts connected players. The dedicated server accepts matches. You count them in different ways.

Here is an example. One person joins a match. AI players in the game can fill the other nine slots. That is still one match. One match needs one dedicated server process.

So we could not size our servers from player count alone. If many players join matches alone, the match count goes up with them. Also, our game runs all match simulation on the dedicated server. So we could not put many processes on one host.

The work we had to manage ourselves

If we scaled this structure as it was, I would have to manage all of this:

Each item is possible on its own. But our goal was one simultaneous service for the whole world. Europe, Asia, and the Americas have different peak hours. If people turn servers on and off region by region, nobody sleeps. The problem was not any single task. The problem was doing all of it every day, in every region.

So we chose GameLift and FlexMatch

Managed hosting in Amazon GameLift Servers starts and manages game server processes. It can also scale capacity to match demand. It also decides which server gets each new game session. (Amazon GameLift Servers overview)

FlexMatch is the matchmaking feature. You write your own matchmaking rules based on player attributes and latency. The match result goes on to GameLift game session placement. (FlexMatch overview)

This part mattered to us. Players from many countries end up in one match. We must choose a server where all of them can play with good quality. Matchmaking rules must filter out groups with too much latency. We could give this decision to FlexMatch and game session placement instead of our own matchmaking server.

I did not choose GameLift for its feature list. I chose it because of the repeated operations work above. We could hand off starting and stopping, capacity scaling, and match server placement. It also mattered that we could manage one region or many regions in the same way.

Version management was another reason. You upload a new build to GameLift. Then you create a fleet from that build. The deployment flow was already standard. So it was easy to build our own deployment tools on top of it. I also hoped that my teammates and I could go home on time.

Some work still stays with us

This does not mean everything is automatic. GameLift handles repeated work inside a fixed frame. We still have to fill that frame for our own service.

The series is called "Does GameLift Really Run Itself?" I will answer that question step by step through the series.

Next post

The next post is about how we turned separate continental services into one global service.