No event after PotentialMatchCreated

I’m relying on event notifications instead of calling DescribeMatchmaking (will that work?).

Yes, that's the recommended way. Check out the architecture diagram for one of our example backend infrastructure: https://github.com/aws-samples/amazon-gamelift-persistent-sample

After calling StartMatchmaking for two users, events MatchmakingSearching and PotentialMatchCreated are received, and some time after it, MatchmakingTimedOut events.

Why wasn’t a MatchmakingSucceeded event received?

The Matchmaking timed out, and therefore it didn't succeed.

1. Is your matchmaking configuration timeout set at a reasonable value? (e.g. >30 seconds)
2. Are you using standalone flexmatch (i.e. you don't have to create fleet, it simply just sends you a message in SQS without trying to place players into game sessions) or queue flexmatch? If queue flexmatch, is your queue timeout set at a reasonable value? (e.g. >30 seconds)
3. If using queue flexmatch, do you have any location filter or player latency filter setup to prevent players from being placed into your fleets?
4. If using queue flexmatch, is there enough capacity in your fleet? I.e. does the fleet have an active instance with at least 1 available process?
5. Are you calling StartMatchmaking twice with 1 players in each request, or StartMatchmaking once with 2 players in the request?

I'm using queue FlexMatch. The timeouts are big enough. No latency filter setup. Currently the fleets (spot and on-demand) have no instance running, although they are configured to maintain a buffer of 20% of game session availability. StartMatchmaking was called once for each player.

Currently the fleets (spot and on-demand) have no instance running

I see. This is the issue. If you are using FlexMatch with queues, then FlexMatch will ensure that your players are placed into a server process before calling the matchmaking "successful", otherwise, it'll continue to wait for a server process to be available until it times out.

If you look at DescribeMatchmaking API, you'll see that it returns the IP address, DnsName and port of the server process that your players are placed in: https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html

although they are configured to maintain a buffer of 20% of game session availability.

Autoscaling should have scaled up the fleet for you since your available is at 0% (because there is no instances running). Did you by any chance set the min/max/desired fleet capacity to 0? Or [stopped fleet autoscaling action](https://docs.aws.amazon.com/cli/latest/reference/gamelift/stop-fleet-******

If you want to simply test out your ruleset without having your players placed into any instances (and therefore save some cost on running instances), you can use Standalone mode on your matchmaking configuration instead, see: https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateMatchmakingConfiguration.html#gamelift-CreateMatchmakingConfiguration-request-FlexMatchMode. With this mode selected, matchmaking will not try to place game session into instances, and immediately send you successful events if players are matched.

NOTE: there is some charges for standalone flexmatch, see pricing plan, but for development purposes it should be cheap (if not for free with free tier)

The fleets were created via CloudFormation/CDK with MinSize: 1 and MaxSize: 10, and no manual change was done after creation. Strangely enough, the max size of 10 can't be seen anywhere in the Console. Right after deploying the fleet, we can see that it has one instance running. After some minutes, it has no instances, even with the 20% buffer configuration. What I want to test is the full matchmaking + session placement flow, with the proper auto scaling of game servers.

Could you try removing the autoscaling configuration and see if that resolves the "instance scaling down" issue?

If scaling policy was the issue, could you share how you setup the scaling policy? Was it via console or AWS CLI/SDK? If you believe you've setup everything correctly and it's still not working, you could provide us with the fleet id and the GameLift team can take a look.

Strangely enough, the max size of 10 can’t be seen anywhere in the Console

Is should be under the fleet details page > "Scaling" tab: REMOVEDUPLOAD

I realized that, when deploying via CDK, the values in that area of the Console is always 0 for Min and 1 for Max! (just like in your snapshot) That's why I though the Max fleet size were nowhere in Console.

The fleet is created this way:

new gamelift.CfnFleet(this, "Fleet", {
  ...
  minSize: 1,
  maxSize: 10,
  ...
});

Manually setting the Min value in console seems to force the instance creation, and then it seems that the autoscaling works as expected.

What defines the value in the "Available" column? I see varying values here, and right now it is zero. Does it relate to the fleet type (spot vs on-demand)?

Glad that you got unblocked! "Available" column shows your account's available allowance on how many EC2 instances it can still allocate in a remote location for the current AWS region. If you run out of "Available" instances, you can either create a new remote location and put the fleet behind a queue so it automatically puts game sessions in one of the locations for you, or you could go through request for a limit increase on the AWS GameLift console.

We have plans to make this concept more clear in the console.

This is actually intentional.

From our docs on the MinSize field and MaxSize field:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-gamelift-fleet.html#cfn-gamelift-fleet-******

MaxSize: The maximum value that is allowed for the fleet's instance count. When creating a new fleet, GameLift automatically sets this value to "1". 
MinSize: The minimum value allowed for the fleet's instance count. When creating a new fleet, GameLift automatically sets this value to "0". 

Sorry if this was confusing. We'll see if we can make this experience better, e.g. actually making it work as intended, or at least show a warning if non-default values were provided. (We cannot disallow these fields anymore for backwards compatibility reasons)

I've created this as a feature request.

GLIFT-15365