Prioritize backfill AND lowest latency region - doesn't seem to be possible?

We have long-running drop-in game sessions with up to 30 players - basically a social hangout space. The session ends whenever the last player decides to leave.
Our matchmaking requirements:

  1. Players should only join sessions in a region where they have low latency
  2. Backfill should be prioritized so players join sessions with large populations rather than starting a new session alone
  3. If there are no active sessions in their region, it’s ok to start a new session alone

The problem we’re having is if you set minPlayers to 1, matchmaking requests always start a new session instead of matching with a backfill request (even with backfillPriority set to high).

We also tried setting minPlayers to 2, and relaxing it to 1 after 10 seconds. This does fix the first issue - players match with backfill requests before starting a new session. But it causes a new issue - the latency rule is ignored (presumably because minPlayers takes priority) so players end up in regions where they have poor latency.

Overall it feels like FlexMatch isn’t really designed for this kind of long-running drop-in game, but we’d really like to avoid writing a custom matchmaker, even if it means doing something hacky to make FlexMatch work.

Our configuration looks like this:

  "name": "OurRuleSet",
  "ruleLanguageVersion": "1.0",
  "teams": [{ "name": "Red", "minPlayers": 1, "maxPlayers": 30 }],
  "rules": [
      "name": "FastConnection",
      "description": "Prefer matches with fast player connections first",
      "type": "latency",
      "maxLatency": 50
  "algorithm": { "backfillPriority": "high", "strategy": "exhaustiveSearch" },
  "expansions": [
      "target": "rules[FastConnection].maxLatency",
      "steps": [
          "waitTimeSeconds": 10,
          "value": 100
          "waitTimeSeconds": 20,
          "value": 300
          "waitTimeSeconds": 30,
          "value": 10000

Backfill is set to manual and we start backfill at the start of the session and whenever a player leaves.


I’m considering having separate matchmaking configs for each region - then do region/config selection on the game client. That way we can set minPlayers to 2 (relaxing to 1) and be sure players will be confined to their lowest latency region. Is this a good workaround or are we missing a better approach?

Hi @lebek

Sorry for the very late reply.

  1. If there are no active sessions in their region, it’s ok to start a new session alone

Seems like you are not going to use the cross-region placement features of FlexMatch, so your per-region configuration idea seems like the best approach if you want to continue using FlexMatch.

An alternative to this flow is to ditch FlexMatch altogether and use SearchGameSessions:

  1. Create a Mutli-Region fleet
  2. Create an alias for it (strongly recommended)
  3. Create game sessions on the multi-region fleets in various locations
  4. Call gamelift:SearchGameSessions with FilterExpression CurrentPlayerSessionCount<MAX_PLAYER_SESSION_COUNT
  5. This would return game sessions info (IP/Port) with at least 1 slot across all your locations
  6. Ping each of the available locations, and select the lowest to join as long as it is below an acceptable threshold. If no such game session is available, call CreateGameSession on the alias to create a new game session

Downsides to this:

  1. You won’t be granted the same level of API throttling limit for SearchGameSessions as StartMatchmaking. If you want to explore this approach, please reach out to GameLift early with the launch questionnaire (see Prepare for Launch - Amazon GameLift) and provide an estimate on player traffic. This would help us understand how much limit we can provide and whether if SearchGameSessions would be viable.
  2. If you have multiple fleets (e.g. 2 SPOT, 1 ON_DEMAND), you may have to call SearchGameSessions multiple times with different fleet aliases (you are essentially making a lighter weight version of GameLift Queues). This could be cumbersome. However, if you are using aliases, you can swap out the underlying fleet without changing code