# Customize to your game hosting solution
With a basic game hosting solution in place, use the following topics to customize and enhance it to improve the player experience, optimize costs, and add advanced functionality. This section covers various customization options organized by the component they primarily affect. Choose the customizations that best fit your game's requirements and player base.
**Topics**
+ [Game server build customizations](customize-game-server-builds.md)
+ [Connect your Amazon GameLift Servers hosted game server to other AWS resources](gamelift-sdk-server-resources.md)
+ [Let your game server access Amazon GameLift Servers fleet data](gamelift-sdk-server-fleetinfo.md)
+ [Set up VPC peering for Amazon GameLift Servers](vpc-peering.md)
+ [Player sessions and matchmaking customizations](customize-player-sessions-matchmaking.md)
+ [Generate player IDs](player-sessions-player-identifiers.md)
+ [Add FlexMatch matchmaking to Amazon GameLift Servers](gamelift-match-intro.md)
+ [Game session placement customizations](customize-game-session-placement.md)
+ [Customize a game session queue](queues-design.md)
+ [Prioritize game session placement](queues-design-priority.md)
+ [Build a queue for Spot Instances](spot-tasks.md)
+ [Hosting resource customizations](fleets-design.md)
+ [Choose compute resources for a managed fleet](gamelift-compute.md)
+ [Customize an Amazon GameLift Servers container fleet](containers-design-fleet.md)
+ [Reduce game hosting costs with Spot fleets](fleets-spot.md)
+ [Optimize game server runtime configuration on managed Amazon GameLift Servers](fleets-multiprocess.md)
+ [Work with the Amazon GameLift Servers Agent](integration-dev-iteration-agent.md)
+ [Abstract an Amazon GameLift Servers fleet designation with an alias](aliases-intro.md)
# Game server build customizations
Game server build customizations offer opportunities to enhance functionality to the game server, including taking advantage of other AWS services. These customizations extend your game server capabilities beyond basic hosting to support advanced features and integrations.
# Connect your Amazon GameLift Servers hosted game server to other AWS resources
When you're creating a game server build for deployment on Amazon GameLift Servers fleets, you might want the applications in your game build to communicate directly and securely with other AWS resources that you own. Because Amazon GameLift Servers manages your game hosting fleets, you must give Amazon GameLift Servers limited access to these resources and services.
Some example scenarios include:
+ Use an Amazon CloudWatch agent to collect metrics, logs, and traces from managed EC2 fleets and Anywhere fleets.
+ Send instance log data to Amazon CloudWatch Logs.
+ Obtain game files stored in an Amazon Simple Storage Service (Amazon S3) bucket.
+ Read and write game data (such as game modes or inventory) stored in an Amazon DynamoDB database or other data storage service.
+ Send signals directly to an instance using Amazon Simple Queue Service (Amazon SQS).
+ Access custom resources that are deployed and running on Amazon Elastic Compute Cloud (Amazon EC2).
Amazon GameLift Servers supports these methods for establishing access:
+ [Access AWS resources with an IAM role](#gamelift-sdk-server-resources-roles)
+ [Access AWS resources with VPC peering](#gamelift-sdk-server-resources-vpc)
## Access AWS resources with an IAM role
Use an IAM role to specify who can access your resources and set limits on that access. Trusted parties can "assume" a role and get temporary security credentials that authorize them to interact with the resources. When the parties make API requests related to the resource, they must include the credentials.
To set up access controlled by an IAM role, do the following tasks:
1. [Create the IAM role](#gamelift-sdk-server-resources-roles-create)
1. [Modify applications to acquire credentials](#gamelift-sdk-server-resources-roles-apps)
1. [Associate a fleet with the IAM role](#gamelift-sdk-server-resources-roles-fleet)
### Create the IAM role
In this step, you create an IAM role, with a set of permissions to control access to your AWS resources and a trust policy that gives Amazon GameLift Servers rights to use the role's permissions.
For instructions on how to set up the IAM role , see [Set up an IAM service role for Amazon GameLift Servers](setting-up-role.md). When creating the permissions policy, choose specific services, resources, and actions that your applications need to work with. As a best practice, limit the scope of the permissions as much as possible.
After you create the role, take note of the role's Amazon Resource Name (ARN). You need the role ARN during fleet creation.
### Modify applications to acquire credentials
In this step, you configure your applications to acquire security credentials for the IAM role and use them when interacting with your AWS resources . See the following table to determine how to modify your applications based on (1) the type of application, and (2) the server SDK version your game uses to communicate with Amazon GameLift Servers.
| | Game server applications | Other applications |
| --- | --- | --- |
| **Using server SDK version 5.x** | Call the server SDK method `GetFleetRoleCredentials()` from your game server code. | Add code to the application to pull credentials from a shared file on the fleet instance. |
| **Using server SDK version 4 or earlier** | Call AWS Security Token Service (AWS STS) `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)` with the role ARN. | Call AWS Security Token Service (AWS STS) `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)` with the role ARN. |
**Note**
For container fleets, `FleetRoleArn` credentials are injected into each container. Your applications can use the default AWS credentials provider to access these credentials. You can still call `GetFleetRoleCredentials()`, which returns the same credentials. These fleet role credentials are only accessible inside containers.
For games integrated with server SDK 5.x, this diagram illustrates how applications in your deployed game build can acquire credentials for the IAM role.
![\[Game executables call GetFleetRoleCredentials(). Other files use locally stored shared credentials.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/instance-role-creds_vsd.png)
#### Call `GetFleetRoleCredentials()` (server SDK 5.x)
In your game server code, which should already be integrated with the Amazon GameLift Servers server SDK 5.x, call `GetFleetRoleCredentials` ([C\$1\$1](integration-server-sdk5-cpp-actions.md#integration-server-sdk5-cpp-getfleetrolecredentials)) ([C\$1](integration-server-sdk5-csharp-actions.md#integration-server-sdk5-csharp-getfleetrolecredentials)) ([Unreal](integration-server-sdk5-unreal-actions.md#integration-server-sdk5-unreal-getfleetrolecredentials)) ([Go](integration-server-sdk-go-actions.md#integration-server-sdk-go-getfleetrolecredentials)) to retrieve a set of temporary credentials. When the credentials expire, you can refresh them with another call to `GetFleetRoleCredentials`.
#### Use shared credentials (server SDK 5.x)
For non-server applications that are deployed with game server builds using server SDK 5.x, add code to get and use credentials stored in a shared file. Amazon GameLift Servers generates a credentials profile for each fleet instance. The credentials are available for use by all applications on the instance. Amazon GameLift Servers continually refreshes the temporary credentials.
You must configure a fleet to generate the shared credentials file on fleet creation.
In each application that needs to use the shared credentials file, specify the file location and profile name, as follows:
Windows:
```
[credentials]
shared_credential_profile= "FleetRoleCredentials"
shared_credential_file= "C:\\Credentials\\credentials"
```
Linux:
```
[credentials]
shared_credential_profile= "FleetRoleCredentials"
shared_credential_file= "/local/credentials/credentials"
```
**Example: Set up a CloudWatch agent to collect metrics for Amazon GameLift Servers fleet instances**
If you want to use an Amazon CloudWatch agent to collect metrics, logs, and traces from your Amazon GameLift Servers fleets, use this method to authorize the agent to emit the data to your account. In this scenario, take the following steps:
1. Retrieve or write the CloudWatch agent `config.json` file.
1. Update the `common-config.toml` file for the agent to identify the credentials file name and profile name, as described above.
1. Set up your game server build install script to install and start the CloudWatch agent.
#### Use `AssumeRole()` (server SDK 4)
Add code to your applications to assume the IAM role and get credentials to interact with your AWS resources. Any application that runs on an Amazon GameLift Servers fleet instance with server SDK 4 or earlier can assume the IAM role.
In the application code, before accessing an AWS resource, the application must call the AWS Security Token Service (AWS STS) `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)` API operation and specify the role ARN. This operation returns a set of temporary credentials that authorizes the application to access to the AWS resource. For more information, see [Using temporary credentials with AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) in the *IAM User Guide*.
### Associate a fleet with the IAM role
After you've created the IAM role and updated the applications in your game server build to get and use the access credentials, you can deploy a fleet. When you configure the new fleet, set the following parameters.
For container fleets:
+ [FleetRoleArn](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateContainerFleet.html#gameliftservers-CreateContainerFleet-request-FleetRoleArn) – Set this parameter to the ARN of the IAM role.
For other fleet types:
+ [ InstanceRoleArn](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_FleetAttributes.html#gamelift-Type-FleetAttributes-InstanceRoleArn) – Set this parameter to the ARN of the IAM role.
+ [ InstanceRoleCredentialsProvider](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_FleetAttributes.html#gamelift-Type-FleetAttributes-InstanceRoleCredentialsProvider) – To prompt Amazon GameLift Servers to generate a shared credentials file for each fleet instance, set this parameter to `SHARED_CREDENTIAL_FILE`.
You must set these values when you create the fleet. They can't be updated later.
## Access AWS resources with VPC peering
You can use Amazon Virtual Private Cloud (Amazon VPC) peering to communicate between applications running on a Amazon GameLift Servers instance and another AWS resource. A VPC is a virtual private network that you define that includes a set of resources managed through your AWS account. Each Amazon GameLift Servers fleet has its own VPC. With VPC peering, you can establish a direct network connection between the VPC for your fleet and for your other AWS resources.
Amazon GameLift Servers streamlines the process of setting up VPC peering connections for your game servers. It handles peering requests, updates route tables, and configures the connections as required. For instructions about how to set up VPC peering for your game servers, see [Set up VPC peering for Amazon GameLift Servers](vpc-peering.md).
**Note**
VPC peering is not supported for container fleets.
# Let your game server access Amazon GameLift Servers fleet data
There are some situations where your custom game build or Amazon GameLift Servers Realtime script may require information about the Amazon GameLift Servers fleet. For example, your game build or script might include code to:
+ Monitor activity based on fleet data.
+ Roll up metrics to track activity by fleet data. (Many games use this data for LiveOps activities.)
+ Provide relevant data to custom game services, such as for matchmaking, additional capacity scaling, or testing.
Fleet information is available as a JSON file on each instance in the following locations:
+ Windows: `C:\GameMetadata\gamelift-metadata.json`
+ Linux: `/local/gamemetadata/gamelift-metadata.json`
The `gamelift-metadata.json` file includes the [attributes of an Amazon GameLift Servers fleet resource](https://docs.aws.amazon.com/gamelift/latest/apireference/API_FleetAttributes.html).
Example JSON file:
```
{
"buildArn":"arn:aws:gamelift:us-west-2:123456789012:build/build-1111aaaa-22bb-33cc-44dd-5555eeee66ff",
"buildId":"build-1111aaaa-22bb-33cc-44dd-5555eeee66ff",
"fleetArn":"arn:aws:gamelift:us-west-2:123456789012:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"fleetDescription":"Test fleet for Really Fun Game v0.8",
"fleetId":"fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"name":"ReallyFunGameTestFleet08",
"fleetType":"ON_DEMAND",
"instanceRoleArn":"arn:aws:iam::123456789012:role/S3AccessForGameLift",
"instanceType":"c5.large",
"serverLaunchPath":"/local/game/reallyfungame.exe"
}
```
# Set up VPC peering for Amazon GameLift Servers
This topic provides guidance on how to set up a VPC peering connection between your Amazon GameLift Servers-hosted game servers and your other non-Amazon GameLift Servers resources. Use Amazon Virtual Private Cloud (VPC) peering connections to enable your game servers to communicate directly and privately with your other AWS resources, such as a web service or a repository. You can establish VPC peering with any resources that run on AWS and are managed by an AWS account that you have access to.
**Note**
VPC peering is an advanced feature. To learn about preferred options for enabling your game servers to communicate directly and privately with your other AWS resources, see [Connect your Amazon GameLift Servers hosted game server to other AWS resources](gamelift-sdk-server-resources.md).
If you're already familiar with Amazon VPCs and VPC peering, understand that setting up peering with Amazon GameLift Servers game servers is somewhat different. You don't have access to the VPC that contains your game servers—it is controlled by the Amazon GameLift Servers service—so you can't directly request VPC peering for it. Instead, you first pre-authorize the VPC with your non-Amazon GameLift Servers resources to accept a peering request from the Amazon GameLift Servers service. Then you trigger Amazon GameLift Servers to request the VPC peering that you just authorized. Amazon GameLift Servers handles the tasks of creating the peering connection, setting up the route tables, and configuring the connection.
## To set up VPC peering for an existing fleet
1.
**Get AWS account ID(s) and credentials.**
You need an ID and sign-in credentials for the following AWS accounts. You can find AWS account IDs by signing into the [AWS Management Console](https://console.aws.amazon.com/) and viewing your account settings. To get credentials, go to the IAM console.
+ AWS account that you use to manage your Amazon GameLift Servers game servers.
+ AWS account that you use to manage your non-Amazon GameLift Servers resources.
If you're using the same account for Amazon GameLift Servers and non-Amazon GameLift Servers resources, you need ID and credentials for that account only.
1.
**Get identifiers for each VPC.**
Get the following information for the two VPCs to be peered:
+ VPC for your Amazon GameLift Servers game servers – This is your Amazon GameLift Servers fleet ID. Your game servers are deployed in Amazon GameLift Servers on a fleet of EC2 instances. A fleet is automatically placed in its own VPC, which is managed by the Amazon GameLift Servers service. You don't have direct access to the VPC, so it is identified by the fleet ID.
+ VPC for your non-Amazon GameLift Servers AWS resources – You can establish a VPC peering with any resources that run on AWS and are managed by an AWS account that you have access to. If you haven't already created a VPC for these resources, see [Getting started with Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html). Once you have created a VPC, you can find the VPC ID by signing into the [AWS Management Console](https://console.aws.amazon.com/) for Amazon VPC and viewing your VPCs.
**Note**
When setting up a peering, both VPCs must exist in the same region. The VPC for your Amazon GameLift Servers fleet game servers is in the same region as the fleet.
1.
**Authorize a VPC peering.**
In this step, you are pre-authorizing a future request from Amazon GameLift Servers to peer the VPC with your game servers with your VPC for non-Amazon GameLift Servers resources. This action updates the security group for your VPC.
To authorize the VPC peering, call the service API [ CreateVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateVpcPeeringAuthorization.html) or use the AWS CLI command `create-vpc-peering-authorization`. Make this call using the account that manages your non-Amazon GameLift Servers resources. Identify the following information:
+ Peer VPC ID – This is for the VPC with your non-Amazon GameLift Servers resources.
+ Amazon GameLift Servers AWS account ID – This is the account that you use to manage your Amazon GameLift Servers fleet.
Once you've authorized a VPC peering, the authorization remains valid for 24 hours unless revoked. You can manage your VPC peering authorizations using the following operations:
+ [DescribeVpcPeeringAuthorizations()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeVpcPeeringAuthorizations.html) (AWS CLI `describe-vpc-peering-authorizations`).
+ [DeleteVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeleteVpcPeeringAuthorization.html) (AWS CLI `delete-vpc-peering-authorization`).
1.
**Request a peering connection.**
With a valid authorization, you can request that Amazon GameLift Servers establish a peering connection.
To request a VPC peering, call the service API [CreateVpcPeeringConnection()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateVpcPeeringConnection.html) or use the AWS CLI command `create-vpc-peering-connection`. Make this call using the account that manages your Amazon GameLift Servers game servers. Use the following information to identify the two VPCs that you want to peer:
+ Peer VPC ID and AWS account ID – This is the VPC for your non-Amazon GameLift Servers resources and the account that you use to manage them. The VPC ID must match the ID on a valid peering authorization.
+ Fleet ID – This identifies the VPC for your Amazon GameLift Servers game servers.
1.
**Track the peering connection status.**
Requesting a VPC peering connection is an asynchronous operation. To track the status of a peering request and handle success or failure cases, use one of the following options:
+ Continuously poll with `DescribeVpcPeeringConnections()`. This operation retrieves the VPC peering connection record, including the status of the request. If a peering connection is successfully created, the connection record also contains a CIDR block of private IP addresses that is assigned to the VPC.
+ Handle fleet events associated with VPC peering connections with [DescribeFleetEvents()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeFleetEvents.html), including success and failure events.
Once the peering connection is established, you can manage it using the following operations:
+ [DescribeVpcPeeringConnections()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeVpcPeeringConnections.html) (AWS CLI `describe-vpc-peering-connections`).
+ [DeleteVpcPeeringConnection()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeleteVpcPeeringConnection.html) (AWS CLI `delete-vpc-peering-connection`).
## To set up VPC peering with a new fleet
You can create a new Amazon GameLift Servers fleet and request a VPC peering connection at the same time.
1.
**Get AWS account ID(s) and credentials.**
You need an ID and sign-in credentials for the following two AWS accounts. You can find AWS account IDs by signing into the [AWS Management Console](https://console.aws.amazon.com/) and viewing your account settings. To get credentials, go to the IAM console.
+ AWS account that you use to manage your Amazon GameLift Servers game servers.
+ AWS account that you use to manage your non-Amazon GameLift Servers resources.
If you're using the same account for Amazon GameLift Servers and non-Amazon GameLift Servers resources, you need ID and credentials for that account only.
1.
**Get the VPC ID for your non-Amazon GameLift Servers AWS resources.**
If you haven't already created a VPC for these resources, do so now (see [Getting started with Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html)). Be sure that you create the new VPC in the same region where you plan to create your new fleet. If your non-Amazon GameLift Servers resources are managed under a different AWS account or user/user group than the one you use with Amazon GameLift Servers, you'll need to use these account credentials when requesting authorization in the next step.
Once you have created a VPC, you can locate the VPC ID in Amazon VPC console by viewing your VPCs.
1.
**Authorize a VPC peering with non-Amazon GameLift Servers resources.**
When Amazon GameLift Servers creates the new fleet and a corresponding VPC, it also sends a request to peer with the VPC for your non-Amazon GameLift Servers resources. You need to pre-authorize that request. This step updates the security group for your VPC.
Using the account credentials that manage your non-Amazon GameLift Servers resources, call the service API [ CreateVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateVpcPeeringAuthorization.html) or use the AWS CLI command `create-vpc-peering-authorization`. Identify the following information:
+ Peer VPC ID – ID of the VPC with your non-Amazon GameLift Servers resources.
+ Amazon GameLift Servers AWS account ID – ID of the account that you use to manage your Amazon GameLift Servers fleet.
Once you've authorized a VPC peering, the authorization remains valid for 24 hours unless revoked. You can manage your VPC peering authorizations using the following operations:
+ [DescribeVpcPeeringAuthorizations()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeVpcPeeringAuthorizations.html) (AWS CLI `describe-vpc-peering-authorizations`).
+ [DeleteVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeleteVpcPeeringAuthorization.html) (AWS CLI `delete-vpc-peering-authorization`).
1. Follow the instructions for [creating a new fleet using the AWS CLI](fleets-creating.md). Include the following additional parameters:
+ *peer-vpc-aws-account-id* – ID for the account that you use to manage the VPC with your non-Amazon GameLift Servers resources.
+ *peer-vpc-id* – ID of the VPC with your non-Amazon GameLift Servers account.
A successful call to [create-fleet](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-fleet.html) with the VPC peering parameters generates both a new fleet and a new VPC peering request. The fleet's status is set to **New** and the fleet activation process is initiated. The peering connection request's status is set to **initiating-request**. You can track the success or failure of the peering request by calling [describe-vpc-peering-connections](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-vpc-peering-connections.html).
When requesting both a new fleet and a VPC peering connection, both actions either succeed or fail. If a fleet fails during the creation process, the VPC peering connection will not be established. Likewise, if a VPC peering connection fails for any reason, the new fleet will fail to move from status **Activating** to **Active**.
**Note**
The new VPC peering connection is not completed until the fleet is ready to become active. This means that the connection is not available and can't be used during the game server build installation process.
The following example creates both a new fleet and a peering connection between a pre-established VPC and the VPC for the new fleet. The pre-established VPC is uniquely identified by the combination of your non-Amazon GameLift Servers AWS account ID and the VPC ID.
```
$ AWS gamelift create-fleet
--name "My_Fleet_1"
--description "The sample test fleet"
--ec2-instance-type "c5.large"
--fleet-type "ON_DEMAND"
--build-id "build-1111aaaa-22bb-33cc-44dd-5555eeee66ff"
--runtime-configuration "GameSessionActivationTimeoutSeconds=300,
MaxConcurrentGameSessionActivations=2,
ServerProcesses=[{LaunchPath=C:\game\Bin64.dedicated\MultiplayerSampleProjectLauncher_Server.exe,
Parameters=+sv_port 33435 +start_lobby,
ConcurrentExecutions=10}]"
--new-game-session-protection-policy "FullProtection"
--resource-creation-limit-policy "NewGameSessionsPerCreator=3,
PolicyPeriodInMinutes=15"
--ec2-inbound-permissions "FromPort=33435,ToPort=33435,IpRange=0.0.0.0/0,Protocol=UDP"
"FromPort=33235,ToPort=33235,IpRange=0.0.0.0/0,Protocol=UDP"
--metric-groups "EMEAfleets"
--peer-vpc-aws-account-id "111122223333"
--peer-vpc-id "vpc-a11a11a"
```
*Copyable version:*
```
AWS gamelift create-fleet --name "My_Fleet_1" --description "The sample test fleet" --fleet-type "ON_DEMAND" --metric-groups "EMEAfleets" --build-id "build-1111aaaa-22bb-33cc-44dd-5555eeee66ff" --ec2-instance-type "c5.large" --runtime-configuration "GameSessionActivationTimeoutSeconds=300,MaxConcurrentGameSessionActivations=2,ServerProcesses=[{LaunchPath=C:\game\Bin64.dedicated\MultiplayerSampleProjectLauncher_Server.exe,Parameters=+sv_port 33435 +start_lobby,ConcurrentExecutions=10}]" --new-game-session-protection-policy "FullProtection" --resource-creation-limit-policy "NewGameSessionsPerCreator=3,PolicyPeriodInMinutes=15" --ec2-inbound-permissions "FromPort=33435,ToPort=33435,IpRange=0.0.0.0/0,Protocol=UDP" "FromPort=33235,ToPort=33235,IpRange=0.0.0.0/0,Protocol=UDP" --peer-vpc-aws-account-id "111122223333" --peer-vpc-id "vpc-a11a11a"
```
## Troubleshooting VPC peering issues
If you're having trouble establishing a VPC peering connection for your Amazon GameLift Servers game servers, consider these common root causes:
+ An authorization for the requested connection was not found:
+ Check the status of a VPC authorization for the non-Amazon GameLift Servers VPC. It might not exist or it might have expired.
+ Check the regions of the two VPCs you're trying to peer. If they're not in the same region, they can't be peered.
+ The CIDR blocks (see [ Invalid VPC peering connection configurations](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#overlapping-cidr)) of your two VPCs are overlapping. The IPv4 CIDR blocks that are assigned to peered VPCs cannot overlap. The CIDR block of the VPC for your Amazon GameLift Servers fleet is automatically assigned and can't be changed, so you'll need to change the CIDR block for of the VPC for your non-Amazon GameLift Servers resources. To resolve this issue:
+ Look up this CIDR block for your Amazon GameLift Servers fleet by calling `DescribeVpcPeeringConnections()`.
+ Go to the Amazon VPC console, find the VPC for your non-Amazon GameLift Servers resources, and change the CIDR block so that they don't overlap.
+ The new fleet did not activate (when requesting VPC peering with a new fleet). If the new fleet failed to progress to **Active** status, there is no VPC to peer with, so the peering connection cannot succeed.
# Player sessions and matchmaking customizations
Player session and matchmaking customizations give you the opportunity to develop sophisticated player management workflows, including a nuanced matchmaking system that helps you deliver balanced, engaging multiplayer experiences.
# Generate player IDs
Amazon GameLift Servers uses a player session to represent a player connected to a game session. Amazon GameLift Servers creates a player session each time a player connects to a game session using a game client integrated with Amazon GameLift Servers. When a player leaves a game, the player session ends. Amazon GameLift Servers doesn't reuse player sessions.
**Important**
When using FlexMatch matchmaking, if you create a new matchmaking request that contains a player ID that is already included in an existing active matchmaking request, the existing request is automatically cancelled. However, a `MatchmakingCancelled` event is not sent for the cancelled request. To monitor the status of existing matchmaking requests, use [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) to poll the request status at infrequent intervals (30-60 seconds). The cancelled request will show a status of `CANCELLED` with the reason `Cancelled due to duplicate player`.
The following code example randomly generates unique player IDs:
```
bool includeBrackets = false;
bool includeDashes = true;
string playerId = AZ::Uuid::CreateRandom().ToString(includeBrackets, includeDashes);
```
For more information about player sessions, see [Game and player sessions in the Amazon GameLift Servers console](gamelift-console-game-player-sessions-metrics.md).
# Add FlexMatch matchmaking to Amazon GameLift Servers
Use Amazon GameLift Servers FlexMatch to add player matchmaking functionality to your Amazon GameLift Servers hosted games. You can use FlexMatch with either custom game servers or Amazon GameLift Servers Realtime.
FlexMatch pairs the matchmaking service with a customizable rules engine. You design how to match players together based on player attributes and game modes that make sense for your game. FlexMatch manages the nuts and bolts of evaluating players who are looking for a game, forming matches with one or more teams, and starting game sessions to host the matches.
To use the full FlexMatch service, you must have your hosting resources set up with queues. Amazon GameLift Servers uses queues to locate the best possible hosting locations for games across multiple regions and computing types. In particular, Amazon GameLift Servers queues can use latency data, when provided by game clients, to place game sessions so that players experience the lowest possible latency when playing.
For more information on FlexMatch including detailed help with integrating matchmaking into your games, see these [Amazon GameLift Servers FlexMatch Developer Guide](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/) topics:
+ [How Amazon GameLift Servers FlexMatch works](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/match-intro.html)
+ [FlexMatch integration steps](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/match-tasks.html)
# Game session placement customizations
Game session placement customizations give you the opportunity to fine-tune your placement system to give your player base the best possible gameplay experience. You can optimize placement for player compatibility and preferences, as well as for operational considerations such as cost efficiency, geographic distribution, and resilience against service disruptions.
# Customize a game session queue
This topic describes how to customize your game session queues to make the best possible decisions about game session placement. For more information about game session queues and how they work, see [Configure game session placement](queues-intro.md).
These Amazon GameLift Servers features require queues:
+ [Matchmaking with FlexMatch](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-tasks.html)
+ [Build a queue for Spot Instances](spot-tasks.md)
**Topics**
+ [Define a queue's scope](queues-design-scope.md)
+ [Build a multi-location queue](queues-design-multiregion.md)
+ [Evaluate queue metrics](queues-design-metrics.md)
# Define a queue's scope
Your game's player population might have groups of players who shouldn't play together. For example, if you publish your game in two languages each language should have its own game servers.
To set up game session placement for your player population, create a separate queue for each player segment. Scope each queue to place players into the correct game servers. Some common ways to scope queues include:
+ **By geographic locations.** When deploying your game servers in multiple geographic areas, you might build queues for players in each location to reduce player latency.
+ **By build or script variations.** If you have more than one variation of your game server, you might be supporting player groups that can't play in the same game sessions. For example, game server builds or scripts might support different languages or device types.
+ **By event types.** You might create a special queue to manage games for participants in tournaments or other special events.
## Design multiple queues
Depending on your game and players, you might want to create more than one game session queue. When your game client service requests a new game session, it specifies which game session queue to use. To help you determine whether to use multiple queues, consider:
+ Variations of your game server. You can create a separate queue for each variation of your game server. All fleets in a queue must deploy compatible game servers. This is because players who use the queue to join games must be able to play on any of the queue's game servers.
+ Different player groups. You can customize how Amazon GameLift Servers places game sessions based on player group. For example, you might need queues customized for certain game modes that require a special instance type or runtime configuration. Or, you might want a special queue to manage placements for a tournament or other event.
+ Game session queue metrics. You can set up queues based on how you want to collect game session placement metrics. For more information, see [Amazon GameLift Servers metrics for queues](monitoring-cloudwatch.md#gamelift-metrics-queue).
# Build a multi-location queue
We recommend a multi-location design for all queues. This design can improve placement speed and hosting resiliency. A multi-location design is required to use player latency data to put players into game sessions with minimal latency. If you're building multi-location queues that use Spot Instance fleets, follow the instructions in [Reduce game hosting costs with Spot fleets](fleets-spot.md).
One way to create a multi-location queue is to add a [multi-location fleet](gamelift-regions.md#gamelift-regions-hosting) to a queue. That way, the queue can place game sessions in any of the fleet's locations. You can also add other fleets with different configurations or home locations for redundancy. If you're using a multi-location Spot Instance fleet, follow best practices and include an On-Demand Instance fleet with the same locations.
The following example outlines the process of designing a basic multi-location queue. In this example, we use two fleets: one Spot Instance fleet and one On-Demand Instance fleet. Each fleet has the following AWS Regions for placement locations: `us-east-1`, `us-east-2`, `ca-central-1`, and `us-west-2`.
**To create a basic multi-location queue with multi-location fleets**
1. Choose a location to create the queue in. You can minimize request latency by placing the queue in a location near where you deployed the client service. In this example, we create the queue in `us-east-1`.
1. Create a new queue and add your multi-location fleets as queue destinations. The destination order determines how Amazon GameLift Servers places game sessions. In this example, we list the Spot Instance fleet first and the On-Demand Instance fleet second.
1. Define the queue's game session placement priority order. This order determines where the queue searches first for an available game server. In this example, we use the default priority order.
1. Define the location order. If you don't define the location order, Amazon GameLift Servers uses the locations in alphabetical order.
![\[A console screenshot that illustrates the example queue's locations and destination order.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/queue-multi-location-1.png)
![\[A console screenshot that illustrates the example queue's placement priority and Location order.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/queue-multi-location-2.png)
# Evaluate queue metrics
Use metrics to evaluate how well your queues are performing. You can view metrics related to queues in the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift) or in Amazon CloudWatch. For a list and descriptions of queue metrics, see [Amazon GameLift Servers metrics for queues](monitoring-cloudwatch.md#gamelift-metrics-queue).
Queue metrics can provide insight about the following:
+ **Overall queue performance** – Queue metrics indicate how successfully a queue responds to placement requests. These metrics can also help you identify when and why placements fail. For queues with manually scaled fleets, the `AverageWaitTime` and `QueueDepth` metrics can indicate when you should adjust capacity for a queue.
+ **FleetIQ algorithm performance** – For placement requests using the FleetIQ algorithm, metrics show how often the algorithm finds ideal game session placement. The placement may prioritize using resources with the lowest player latency or resources with the lowest cost. There are also error metrics that identify common reasons why Amazon GameLift Servers can't find an ideal placement. For more information about metrics, see [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Location specific placements** – For multi-location queues, metrics show successful placements by location. For queues that use the FleetIQ algorithm, this data provides useful insight into where player activity occurs.
When evaluating metrics for FleetIQ algorithm performance, consider the following tips:
+ To track the queue's rate of finding an ideal placement, use the `PlacementsSucceeded` metric in combination with the FleetIQ metrics for lowest latency and lowest price.
+ To boost a queue's rate of finding an ideal placement, review the following error metrics:
+ If the `FirstChoiceOutOfCapacity` is high, adjust capacity scaling for the queue's fleets.
+ If the `FirstChoiceNotViable` error metric is high, look at your Spot Instance fleets. Spot Instance fleets are considered not viable when the interruption rate for a particular instance type is too high. To resolve this issue, change the queue to use Spot Instance fleets with different instance types. We recommend that you include Spot Instance fleets with different instance types in each location.
# Prioritize game session placement
Amazon GameLift Servers uses an algorithm to determine how to prioritize a queue's destinations and determine where to place a new game session. The algorithm is based on an ordered set of criteria. You can use the default priority order, or you can customize the order. You can edit a queue's priority order at any time.
**Default priority order**
1. **Latency** – If the game session placement request includes location-specific latency data for players, Amazon GameLift Servers calculates the average player latency in each location and attempts to place a game session in a fleet location with the lowest average.
1. **Cost** – If a request doesn't include latency data, or if multiple fleets have equal latency, then Amazon GameLift Servers evaluates the hosting cost of each fleet. A fleet's hosting cost varies based on fleet type (Spot or On-Demand), instance type, and location.
1. **Destination** – If multiple fleets have equal latency and costs, then Amazon GameLift Servers prioritizes fleets based on the destination order as listed in the queue configuration.
1. **Location** – For queues with multi-location fleets, if all other criteria are equal, then Amazon GameLift Servers prioritizes the fleet's locations based on alphabetical order.
## Customize how a queue prioritizes game session placements
You can choose to customize how a queue prioritizes the placement criteria. The queue applies the custom prioritization to all game session placement requests that it receives.
**Note**
If you create a custom priority configuration and don't include all four criteria, Amazon GameLift Servers automatically appends any missing criteria in the default order.
**To customize a queue’s priority configuration**
Use the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/) or the AWS Command Line Interface (AWS CLI) to create a custom priority configuration.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), you can customize a queue's priorities when creating a new queue or updating an existing queue. Select an AWS Region to work in.
Open the console’s left navigation bar and choose **Queues**. On the Queues page, select an existing queue and choose **Edit**.
1. Go to the section **Game session placement priority**. Drag and drop each priority criteria to create the order you want.
1. Go to the section **Location order**. Add any locations that you want to prioritize. This list is useful when the queue has fleets with multiple locations. At a minimum, you must specify one location. The locations you specify here are prioritized first, followed by all other locations in the queue's destinations.
1. Choose **Save changes**.
------
#### [ AWS CLI ]
Use the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/update-game-session-queue.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/update-game-session-queue.html) command with the `--priority-configuration` option to customize a queue's priority order. Amazon GameLift Servers updates a queue in your current default AWS Region, or you can add a `--region` tag to specify a different AWS Region.
The following example request adds or updates the priority configuration for a specified queue
```
aws gamelift update-game-session-queue \
--name "example-queue-with-priority"
--priority-configuration PriorityOrder="COST','LOCATION","DESTINATION",LocationOrder="us-east-1","us-east-2","ca-central-1","us-west-2" \
```
------
## Prioritize placements by player latency
If you want to give your players the best possible player experience and ensure minimal latency, take the following steps when setting up your game session placement system:
+ Set your queue to prioritize latency when choosing where to place game sessions. Latency is at the top of the priority list by default. You can also customize your queue's priority configuration and choose where to put latency in priority order.
+ Set up player latency policies for your queue. Latency policies let you set hard limits on the amount of latency to allow in a game session placement. If Amazon GameLift Servers can't place a game session without exceeding the limits, the placement request will time out and fail. You can set up a single latency policy, or you can create a series of policies that gradually relax the latency limit over time. With a series of policies, you can specify very low initial latency limits, and still accommodate players with higher latencies after a short delay. For details on creating latency policies, see [Create a player latency policy](queues-design-latency.md).
+ When making game session placement requests (see [StartGameSessionPlacement](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html)), include latency data for each player. Player latency data includes a value for every possible location where a game session might be placed. For example, for a queue that places game sessions in AWS Regions us-east-2 and ca-central-1, latency data might look like this:
```
"PlayerLatencies": [
{ "LatencyInMilliseconds": 100, "PlayerId": "player1", "RegionIdentifier": "us-east-2" },
{ "LatencyInMilliseconds": 100, "PlayerId": "player1", "RegionIdentifier": "ca-central-1" },
{ "LatencyInMilliseconds": 150, "PlayerId": "player2", "RegionIdentifier": "us-east-2" },
{ "LatencyInMilliseconds": 150, "PlayerId": "player2", "RegionIdentifier": "ca-central-1" }
]
```
To obtain accurate latency measurements, use Amazon GameLift Servers's UDP ping beacons. These endpoints enable you to measure actual UDP network latency between player devices and each of the potential hosting locations, resulting in more accurate placement decisions than using ICMP pings. For more information on using UDP ping beacons to measure latency, refer to [UDP ping beacons](reference-udp-ping-beacons.md).
## Prioritize placements by location
You can configure a queue to make game session placements based on a prioritized list of geographic locations. Location is one of the criteria that determines how a queue chooses where to place a new game session. By default, location is prioritized fourth, after latency, cost, and destination.
For game session placement, destination and location have somewhat different meanings:
+ *Destination* refers to a specific fleet and includes all the fleet's hosting resources, wherever they're deployed. When prioritizing by destination, Amazon GameLift Servers might make a placement with any location in the fleet. Multi-location managed fleets and Anywhere fleets can have hosting resources that are deployed to one or more locations.
+ *Location* refers to a specific geographic position where a fleet's hosting resources are deployed. A fleet can have multiple locations, which might include AWS Regions, Local Zones, or custom locations (for an Anywhere fleet). A single-location managed fleet has one location and it is always an AWS Region. A multi-location managed fleet has a home Region and can have remote locations. An Anywhere fleet has one or more custom locations.
When prioritizing placements by location, Amazon GameLift Servers looks for any queue destinations that include the priority location and searches them for an available hosting resource. If there are multiple destinations with the priority location, Amazon GameLift Servers moves on to the next priority criteria (cost, latency, destination).
There are several ways that you can influence how a queue's locations are prioritized
+ Configure how the queue handles all game session placement requests:
+ **Add a priority configuration to the queue.** A queue's priority configuration includes an ordered list of locations. You can specify one or more locations to prioritize. This list doesn't exclude any locations, it simply tells Amazon GameLift Servers where to look first for an available hosting resource. A common use for an ordered location list is when you want to funnel most traffic to one or more specific geographic locations and use additional locations as backup capacity. Add a priority configuration by calling [UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html).
+ **Add a filter configuration to the queue.** A filter configuration is an allow list for the queue. It tells Amazon GameLift Servers to ignore any locations that aren't on the list when looking for an available hosting resource. There are two common uses for a filter configuration. First, for fleets with multiple locations, you might use a filter to exclude some of the fleet's locations. Second, you might want to temporarily disallow placements on a certain location; for example, a location might be experiencing transitory issues. Because you can update a queue's filter configuration at any time, you can easily add and remove locations as needed. Add a filter configuration by calling [UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html).
+ Use special instructions for individual placement requests:
+ **Include a priority override list in a game session placement request.** You can provide an alternate priority list of locations with any [StartGameSessionPlacement](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html) request. This list effectively replaces the queue's configured prioritization for locations for that one request only. It doesn't impact any other requests. This override feature has a few requirements:
+ Use an override list only with a queue that has a priority configuration in place with `LOCATION` as the first priority.
+ Don't include player latency data in the same placement request. Including latency data sets up conflicts when prioritizing locations that Amazon GameLift Servers can't resolve.
+ Decide how you want Amazon GameLift Servers to proceed if it can't find an available resource on the priority override list. Choose between falling back to the queue's other locations, or limit placements to the override list. By default, Amazon GameLift Servers falls back to attempt placement on the queue's other locations.
+ Update the queue's filter configuration as needed, such as adding locations on the override list. The override list doesn't invalidate the filter list.
# Create a player latency policy
If your placement requests include player latency data, Amazon GameLift Servers finds game sessions in locations with the lowest average latency for all players. Placing game sessions based on average player latency prevents Amazon GameLift Servers from placing most players in games with high latency. However, Amazon GameLift Servers still places players with extreme latency. To accommodate these players, create player latency policies.
A player latency policy prevents Amazon GameLift Servers from placing a requested game session anywhere that players in the request would experience latency over the maximum value. Player latency policies can also prevent Amazon GameLift Servers from matching game session requests with higher latency players.
**Tip**
To manage latency specific rules, such as requiring similar latency across all players in a group, you can use [Amazon GameLift Servers FlexMatch](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-intro.html) to create latency-based matchmaking rules.
For example, consider this queue with a 5-minute timeout and the following player latency policies:
1. Spend 120 seconds searching for a location where all player latencies are less than 50 milliseconds.
1. Spend 120 seconds searching for a location where all player latencies are less than 100 milliseconds.
1. Spend the remaining queue time until timeout searching for a location where all player latencies are less than 200 milliseconds.
![\[A console screen shot that illustrates the example latency policies that gradually relax.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/queue-latency-policy.png)
# Build a queue for Spot Instances
You can achieve of potentially significant savings in hosting costs by using Spot fleets. For more details about Spot fleets and how to use them, see [On-Demand Instances versus Spot Instances](gamelift-compute.md#gamelift-compute-spot).
If your game hosting solution includes Spot fleets, you must use a game session placement queue. Amazon GameLift Servers uses queues to search across multiple game hosting resources and select the best one available to host a new game session. With Spot fleets, queues are particularly important for minimizing hosting costs and avoiding possible Spot interruptions. This topic helps you set up a resilient queue that can continue to host games for players even in the event of interruptions, slowdowns and outages. You can customize how the queue prioritizes available hosting resources based on several factors including hosting cost.
Are you using FlexMatch for matchmaking? You can use a queue with Spot fleets to make game session placements for your matches.
## Implementation tasks for Spot fleets
When creating or updating your game hosting solution to use Spot fleets, complete the following tasks. For more detailed guidance on how to build a queue that optimizes Spot availability and resiliency, see [Reduce game hosting costs with Spot fleets](fleets-spot.md).
1. **Choose and create a set of fleet destinations for your game session queue.**
Start by deciding where you want your queue to place game sessions. A queue can search across multiple fleets to find the best possible placement. Each fleet has one instance type but can have multiple geographic locations. Queues with fleets that offer variety in both location and instance type are more likely to make successful placements. See these best practices for designing an effective and resilient Spot-optimized queue.
1. **Create your Spot-optimized game session queue.**
Create a queue and configure it for your Spot fleets. See [Create a game session queue](queues-creating.md) for help creating and configuring the new queue. You can use the Amazon GameLift Servers console or the AWS CLI to create or edit a queue.
+ Add the fleet destinations from Step 1.
+ Prioritize the destination order as appropriate. By default, Amazon GameLift Servers prioritizes by cost before destination, so destination order is used only when the lowest costs between destinations are equal.
+ If you want to prioritize game hosting cost before player latency, provide a custom placement priority. See [Prioritize game session placement](queues-design-priority.md).
1. **Update other components in your solution to use the new queue.**
When your solution uses a Spot-optimized queue to start new game sessions, the queue automatically avoids placing game sessions with fleets that have a high likelihood of interruption. It instead searches all viable fleets for resources that match your defined priorities, including player latency, hosting cost, and destination order.
+ If you're not using FlexMatch – Update your backend service to specify the new Spot-optimized queue in game session requests. The backend service makes API requests to Amazon GameLift Servers on behalf of your game client (using `StartGameSessionPlacement()`), and each request must specify a queue name. For help implementing game session placements in your game client, see [Create game sessions](gamelift-sdk-client-api.md#gamelift-sdk-client-api-create).
+ If you are using FlexMatch – Update your matchmaking configuration to send game session requests to the new Spot-optimized queue. When the matchmaking system forms a player match, it sends a game session placement request to the designated queue to start a new game session for the match. Only matchmaking configurations with FlexMatch mode set to "Managed" can designate a placement queue. You can update a matchmaking configuration using the AWS CLI or the Amazon GameLift Servers console (see [Edit a matchmaking configuration](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-create-configuration-edit.html)).
1. **Review the performance of your Spot fleets and queues.**
View Amazon GameLift Servers metrics in the Amazon GameLift Servers console or with Amazon CloudWatch to review performance. For more information about Amazon GameLift Servers metrics, see [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md). Key metrics include:
+ Interruption rate – Use the `InstanceInterruptions` and `GameSessionInterruptions` metrics to track the number and frequency of Spot-related interruptions for instances and game sessions. Game sessions on reclaimed instances have a status of `TERMINATED` and a status reason of `INTERRUPTED`.
+ Queue effectiveness – Track placement success rates, average wait time, and queue depth to confirm that Spot fleets don't impact your queue performance.
+ Fleet usage – Monitor data on instances, game sessions and player sessions. Usage for your On-Demand fleets can be an indicator that queues are avoiding placements into your Spot fleets to avoid disruption.
## Best practices for queues with Spot fleets
Use the following best practices when creating fleets and queues for Spot instances.
+ **Expand your queue's geographic coverage.** Even if your players are clustered in a single AWS Region, add adjacent locations to your Spot fleet. This approach improves the queue's ability to maintain capacity during regional slowdowns, outages, and Spot interruptions. Multi-location fleets work with both Spot and On-Demand instances.
+ **Diversify your queue's instance type coverage.** Amazon GameLift Servers evaluates Spot viability based on instance type, so having Spot fleets with a variety of instance types reduces the chance that multiple Spot fleets are nonviable at the same time. Include at least two Spot fleets with different instances types each location.
**Note**
Pricing is based on the instances you use, not the number of fleets. Running five fleets with 10 instances each is the same as running one fleet with 50 instances of similar cost. Pricing varies by instance type, size, and location.
Tips for grouping Spot instance types:
+ Use instance types in the same family, such as `m6g.medium`, `m6g.large`, and `m6g.xlarge`. Larger instance types cost more, but can also host more game sessions at a time.
+ Select widely available instances types. Typically, older generation families (such as C5, M5, and R5) and common sizes (such as .large, .xlarge, and .2xlarge) have better availability.
+ Check the 30-90 day pricing history in the Amazon GameLift Servers console. Look for instance types with consistent availability patterns.
+ Use the Amazon GameLift Servers console, fleet creation tool, to explore location coverage for instance types.
+ **Add On-Demand fleets for backup capacity.** Game hosting can switch to On-Demand fleets whenever Spot fleets are unavailable. Put at least one On-Demand fleet in each location to maintain low player latency. Add auto-scaling to your backup On-Demand fleets, so you can keep them scaled down until they're needed.
+ **Assign aliases to all fleet destinations.** Create aliases for each of your queue's destinations. Aliases make it easier and more efficient whenever you need to replace fleets.
+ **Apply a queue prioritization strategy.** You can customize how a queue prioritizes where to place game sessions (see [Prioritize game session placement](queues-design-priority.md) for more details). For Spot-optimized queues, prioritizing by cost ensures that low-cost Spot fleets are used whenever possible.
You can also prioritize certain fleets by specifying a destination order. For example, some users designate a set of primary fleets for regular use and also a set of secondary fleets as backup. In this scenario, set the queue's destination order to list the primary fleets first. Then configure the queue's priority order with destination followed by cost.
# Hosting resource customizations
This section provides advanced options for configuring and managing your Amazon GameLift Servers infrastructure to meet specific performance, cost, and operational requirements. In particular, the topics in this section describe how you can customize your Amazon GameLift Servers managed hosting resources to best fit your game and your players.
Some of the decisions you want to consider:
+ Where to deploy hosting resources for your players? Gameplay latency is a major factor in selecting your fleet's geographic locations, but there are other factors that vary by location, including resource type availability and cost.
+ What EC2 instance types will best support your game? Choose from available instance types that use the best combination of compute architecture, memory, storage, and networking capacity.
+ What size of instance type do you need? Choose an instance type size based on the resource requirements (memory and CPU) of your game server software and other factors.
+ Should your fleet use On-Demand or Spot Instances? Consider whether you can take advantage of lower Spot pricing, and whether Amazon GameLift Servers sufficiently mitigates the chance of Spot interruptions to your game sessions.
+ How do you want your game server software to run on each fleet instance? The runtime configuration tells Amazon GameLift Servers what server software to run and how.
+ For container fleets, does the default configuration work for your game? Amazon GameLift Servers does a lot of the work for you to optimize your container fleet configurations, but you can customize most configuration settings.
# Choose compute resources for a managed fleet
For Amazon GameLift Servers managed hosting, including managed EC2 and managed containers, the service deploys your game servers to fleets of computing resources in the AWS Cloud. When you create a managed fleet, you want to configure the hosting resources to best suit your game. This topic discusses key decision points when choosing and configuring your game hosting fleets.
**Note**
If you're building a hybrid solution with both Anywhere and Amazon GameLift Servers managed fleets, use these topics to design managed fleets to supplement your own self-managed resources. See [Deploy hosting fleets for Amazon GameLift Servers](fleets-intro.md).
**Topics**
+ [Geographic locations](#gamelift-compute-location)
+ [Operating systems](#gamelift-compute-os)
+ [Instance types](#gamelift-compute-instance)
+ [On-Demand Instances versus Spot Instances](#gamelift-compute-spot)
+ [Service quotas](#gamelift-service-limits)
## Geographic locations
Consider where you plan to deploy your game servers. In general, you want to put your game servers as close as possible to your players to deliver the best possible player experience. For Amazon GameLift Servers managed hosting, you can choose to put game servers in any of the supported AWS Regions and Local Zones. If you're building a hybrid solution, consider how managed fleet deployment can supplement the locations of your self-managed Amazon GameLift Servers Anywhere fleets.
For most development and testing scenarios, deploying to a single location makes sense. As you prepare for launch and beyond, there are many reasons to deploy across multiple geographic locations. These include supporting a widespread group of players and improving overall game hosting resilience and reliability. Multiple locations can also boost player experience by speeding up game session placement and enabling more choices when optimizing placements for latency and cost.
For a list of locations that are supported by Amazon GameLift Servers and more information about locations for all fleet types, see [Amazon GameLift Servers service locations](gamelift-regions.md).
Multi-location fleets
A single managed fleet can deploy resources to multiple locations. You can manually set capacity for each individual location in a multi-location fleet.
Advantages of using a multi-location fleet:
+ Simplified fleet deployment and management – You supply the game server software and fleet configuration, and Amazon GameLift Servers deploys it to fleet instances across multiple locations (build once, deploy anywhere). In a production fleet, you can view and manage all locations in a fleet instead of having to manage multiple fleets each located in a different region.
+ Local Zone availability – If you want to use a Local Zone you must create a multi-location fleet with an AWS Region home location and Local Zones as remote locations. Local Zones are extensions of AWS Regions that can deliver even lower latency to areas and customers that need it. You can add a Local Zone to any multi-location fleet; you don't need to include the Local Zone's parent AWS Region.
+ Compatibility with game session queues – You can build game session placement queues with one or more multi-location fleets. This approach gives the queue flexibility when prioritizing and choosing locations to host a new game session.
+ Efficient resource utilization – With auto-scaling turned on, Amazon GameLift Servers can better optimize capacity scaling across all locations in a fleet.
Tips for using multi-location fleets:
+ Check for quotas on the number of locations per AWS Region or fleet. See [Amazon GameLift Servers service quotas](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift).
+ Not all instance types are available in all locations. Depending on your chosen locations, you might have limited instance type options. The Amazon GameLift Servers console provides useful tools to help you find the right balance of locations and instance types.
+ Consider using [UDP ping beacons](reference-udp-ping-beacons.md) to collect player latency data for all your fleet locations. Amazon GameLift Servers can use this data to optimize game sessions for low latency and prevent players from joining sessions with unacceptably high latency. These special endpoints accept UDP messages instead of traditional ICMP pings, providing accurate latency measurements to help you select optimal fleet locations.
## Operating systems
All instances in a managed fleet are deployed with an Amazon machine image (AMI) that provides a complete runtime environment for your game server software. For managed EC2 fleets, you specify the game server build's operating system when you upload the build to Amazon GameLift Servers. For managed container fleets, you specify the operating system in the container group definition. For more information about the latest AMI versions, see [Amazon GameLift Servers AMI versions](reference-ec2-ami-version-history.md).
AMI versions are regularly updated. When you create a new fleet, Amazon GameLift Servers assigns the latest available version of the AMI you selected for your game build. All instances that are deployed in that fleet use the same version. To keep your AMI version up to date with the latest security and software updates, you need to regularly replace your fleets. As a best practice, we recommend replacing your managed fleets every 30 days to maintain the runtime environment for your game servers. For guidance, see [Security best practices for Amazon GameLift Servers](security-best-practices.md).
## Instance types
A managed fleet's instance type determines the kind of hardware that is deployed for all fleet instances, and instance types are generally available in various sizes. All Amazon GameLift Servers managed fleet use Amazon EC2 instances, and support a wide range of instance types that offer different combinations of computing power, memory, storage, and networking capabilities. The availability of instance types varies depending on the locations you choose.
The Amazon GameLift Servers console provides useful tools to help you find the right instance types for your game build and your deployment locations. For managed container fleets, the console also offers guidance on your game's CPU power and memory requirements.
When choosing from available instance types for your game, consider:
+ The compute architecture of your game server: x64 or Arm (AWS Graviton).
**Note**
Graviton Arm instances require a server build for a Linux AMI. Server SDK 5.1.1 or newer is required for C\$1\$1 and C\$1. Server SDK 5.0 or newer is required for Go. These instances do not provide out-of-the-box support for Mono installation on Amazon Linux 2023 (AL2023) or Amazon Linux 2 (AL2).
+ The computing, memory, and storage requirements of your game server build.
+ The size of your instance type. In addition to meeting the requirements of your game server software executables, larger instance type sizes can run multiple game server processes and/or containers on each instance. Factors to consider include cost (is it cheaper to run a few large instances or many small instances). Also consider how game session capacity might be impacted by adding or removing instances during fleet scaling events or when shutting down unhealthy instances. If each instance runs many game server processes concurrently, adding or removing an instance can significantly affect ame hosting capacity.
For more information about instance types, see [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
## On-Demand Instances versus Spot Instances
Amazon EC2 On-Demand Instances and Spot Instances offer the same hardware and performance, but they differ in availability and cost.
**On-Demand Instances**
You can acquire an On-Demand Instance when you need it and keep it for as long as you want. On-Demand Instances have a fixed cost, meaning you pay only for the amount of time that you use them. There are no long-term commitments.
**Spot Instances**
Spot Instances can offer a cost-efficient alternative to On-Demand Instances by utilizing unused AWS computing capacity. Spot Instance prices fluctuate based on the supply and demand for each instance type in each location. AWS can reclaim Spot Instances with a two-minute notification whenever it needs the capacity back, and game sessions actively running on a reclaimed instance are interrupted.
Amazon GameLift Servers offers several tools to help mitigate the likelihood of Spot interruptions to your game sessions. A spot viability algorithm tracks instance type historical data to anticipate when the risk of interruption reaches a critical point and avoids placing new game sessions on Spot Instances of that type. If an interruption does occur, your game servers can use the notification to gracefully end a game session for players.
Game hosting with Spot fleets must use a queue for game session placement. A queue is able to prioritize game session placements based on Spot fleet viability, cost, and other factors. See these topics for more information about how to take advantage of Spot for your game server hosting:
+ [Reduce game hosting costs with Spot fleets](fleets-spot.md)
+ [Build a queue for Spot Instances](spot-tasks.md)
## Service quotas
You can view default service quotas for Amazon GameLift Servers and current quota status for your AWS account using the following tools:
+ For general service quota information for Amazon GameLift Servers, see [Amazon GameLift Servers endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/gamelift.html) in the *AWS General Reference*.
+ For a list of available instance types per location for your account, open the [Service quotas](https://console.aws.amazon.com/gamelift/service-quotas) page of the Amazon GameLift Servers console. This page also displays your account's current usage for each instance type in each location.
+ For a list of your account's current quotas for instance types per Region, run the AWS Command Line Interface (AWS CLI) command [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-ec2-instance-limits.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-ec2-instance-limits.html). This command returns the number of active instances that you have in your default Region (or in another Region that you specify).
As you prepare to launch your game, fill out a launch questionnaire in the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/). The Amazon GameLift Servers team uses the launch questionnaire to determine the correct quotas and limits for your game.
# Customize an Amazon GameLift Servers container fleet
The topics in this section describe some of the optional features for Amazon GameLift Servers managed containers. You can choose to use any or all of these features.
**Topics**
+ [Set resource limits](#containers-design-fleet-limits)
+ [Understand container fleet memory allocation](#containers-design-fleet-memory-allocation)
+ [Configuring NVMe Drive Access](#containers-design-fleet-nvme)
+ [Designate essential containers](#containers-design-fleet-essential)
+ [Configure network connections](#containers-custom-network)
+ [Set up health checks for containers](#containers-design-fleet-health)
+ [Set container dependencies](#containers-design-fleet-dependencies)
+ [Configure a container fleet](#containers-design-fleet-config)
## Set resource limits
For each container group, you can determine how much memory and computing power the container group needs to run its software. Amazon GameLift Servers relies on this information to manage resources across the container group. It also uses this information to calculate how many game server container groups a fleet image can hold. You can also set limits for individual containers.
You can set a maximum limit on memory and computing power for a container group. By default, these resources are shared by all containers in the group. You can further customize resource management by setting limits for individual containers.
**Set optional limits for individual containers**
Setting container-specific resource limits allows you to exert greater control over how individual containers can use the group’s resources. If you don’t set container-specific limits, all containers in the group share the group resources. Sharing offers greater flexibility to use resources where they're needed. It also increases the potential for processes to compete with each other and result in container failure.
Set any of the following `ContainerDefinition` properties for any container.
+ `MemoryHardLimitMebibytes` – Set a maximum memory limit for the container. If the container exceeds this limit, it results in a restart.
+ `Vcpu` limit – Reserve a minimum amount of vCPU resources for the container's exclusive use. The container always has the reserved amount available to it. It can exceed this minimum at any time, if additional resources are available. (1024 CPU units is the equivalent of 1 vCPU.)
**Set total resource limits for a container group**
If you set limits for individual containers, you might need to modify how much memory and vCPU resources the container group needs. The goal is to allocate enough resources to optimize game server performance. Amazon GameLift Servers uses these limits to calculate how to pack game server container groups on a fleet instance. You’ll also use them when choosing an instance type for a container fleet.
Calculate the total memory and vCPU needed for a container group. Consider the following:
+ What are all the processes that run across all containers in the container group? Add up the resources required for these processes. Take note of any container-specific limits.
+ How many concurrent game server processes do you plan to run in each container group? You determine this in your game server container image.
Based on your estimate of container group requirements, set the following `ContainerGroupDefinition` properties:
+ `TotalMemoryLimitMebibytes` – Set a maximum memory limit for the container group. All containers in the group share allocated memory. If you set individual container limits, the total memory limit must be equal to or greater than the highest container-specific memory limit.
+ `TotalVcpuLimit` – Set a maximum vCPU limit for the container group. All containers in the group share allocated CPU resources. If you set individual container limits, the total CPU limit must be equal to or greater than the sum of all container-specific CPU limits. As a best practice, consider setting this value to double the sum of the container CPU limits.
**Example scenario**
Let’s say we’re defining a game server container group with the following three containers:
+ Container A is our game server container. We estimate the resource requirements for one game server at 512 MiB and 1024 CPU. We plan to have the container run 1 server process. Because this container runs our most critical software, we set no memory limit or vCPU reserve limit.
+ Container B is a support container with resource requirements estimated at 1024 MiB and 1536 CPU. We set a memory limit of 2048 MiB, and a CPU reserve limit of 1024 CPU.
+ Container C is another support container. We set a hard memory limit of 512 MiB and a CPU reserve limit of 512 CPU.
Using this information, we set the following total limits for the container group:
+ Total memory limit: 7680 MiB. This value exceeds the highest memory limit (1024 MiB).
+ Total CPU limit: 13312 CPU. This value exceeds the sum of the CPU limit (1024\$1512 CPU).
## Understand container fleet memory allocation
When Amazon GameLift Servers deploys container groups on a fleet instance, not all of the instance's memory is available for your containers. Amazon GameLift Servers reserves a portion of the instance memory for the operating system, the Amazon ECS agent, and other supporting services. The amount of reserved memory varies based on the instance type's total memory. Understanding this overhead helps you configure your container group definitions to fully utilize the available resources.
### Memory overhead formula
Amazon GameLift Servers calculates the memory available for your container groups using the following steps:
1. **Determine the memory buffer percentage.** Amazon GameLift Servers reserves a percentage of the instance's total memory based on the following tiers:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/containers-design-fleet.html)
1. **Calculate available memory.** Subtract the reserved memory from the total instance memory:
`AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)`
1. **Subtract per-instance container group memory.** If your fleet uses a per-instance container group, subtract its `TotalMemoryLimitMebibytes` from the available memory. One per-instance container group runs on each fleet instance.
`AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes`
1. **Account for log router overhead.** If logging is enabled for the fleet, Amazon GameLift Servers reserves an additional 50 MiB per game server container group for the log router.
1. **Calculate maximum game server container groups.** The maximum number of game server container groups that fit on the instance by memory is:
`MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))`
Where `LogRouterMemory` is 50 MiB if logging is enabled, or 0 if logging is disabled.
**Note**
Memory is only one factor that determines how many game server container groups fit on an instance. Amazon GameLift Servers also considers vCPU capacity and available connection ports, and uses the minimum of all three calculations.
### Example memory calculation
Consider a fleet using a `c5.xlarge` instance (8,192 MiB total memory) with logging enabled:
1. Instance memory is 8,192 MiB, which falls in the 5,000–9,999 tier (6% buffer)
1. Reserved memory = round(8,192 × 0.06) = 492 MiB
1. Available memory = 8,192 - 492 = 7,700 MiB
1. If using a per-instance container group with `TotalMemoryLimitMebibytes` of 512: Available memory = 7,700 - 512 = 7,188 MiB
1. If each game server container group has `TotalMemoryLimitMebibytes` of 1,024: MaxGroupsByMemory = floor(7,188 / (1,024 \$1 50)) = floor(7,188 / 1,074) = 6
### Available memory by instance type
The following table shows the total memory and available memory (after the Amazon GameLift Servers buffer) for commonly used instance types. Use these values as a starting point when configuring your container group definitions. The *Available memory* column shows the memory available for all container groups on the instance, before subtracting any per-instance container group or log router overhead.
| Instance type | Total memory (MiB) | Buffer percentage | Available memory (MiB) |
| --- | --- | --- | --- |
| c5.large | 4,096 | 8% | 3,768 |
| c5.xlarge | 8,192 | 6% | 7,700 |
| c5.2xlarge | 16,384 | 5% | 15,565 |
| c5.4xlarge | 32,768 | 5% | 31,130 |
| c5.9xlarge | 73,728 | 5% | 70,042 |
| c5.12xlarge | 98,304 | 4% | 94,372 |
| c5.18xlarge | 147,456 | 4% | 141,558 |
| c5.24xlarge | 196,608 | 4% | 188,744 |
| m5.large | 8,192 | 6% | 7,700 |
| m5.xlarge | 16,384 | 5% | 15,565 |
| m5.2xlarge | 32,768 | 5% | 31,130 |
| m5.4xlarge | 65,536 | 5% | 62,259 |
| m5.8xlarge | 131,072 | 4% | 125,829 |
| m5.12xlarge | 196,608 | 4% | 188,744 |
| r5.large | 16,384 | 5% | 15,565 |
| r5.xlarge | 32,768 | 5% | 31,130 |
| r5.2xlarge | 65,536 | 5% | 62,259 |
| r5.4xlarge | 131,072 | 4% | 125,829 |
| c6i.large | 4,096 | 8% | 3,768 |
| c6i.xlarge | 8,192 | 6% | 7,700 |
| c6i.2xlarge | 16,384 | 5% | 15,565 |
| c6i.4xlarge | 32,768 | 5% | 31,130 |
| c6i.8xlarge | 65,536 | 5% | 62,259 |
| c7i.large | 4,096 | 8% | 3,768 |
| c7i.xlarge | 8,192 | 6% | 7,700 |
| c7i.2xlarge | 16,384 | 5% | 15,565 |
| c7i.4xlarge | 32,768 | 5% | 31,130 |
| c7i.8xlarge | 65,536 | 5% | 62,259 |
| m7i.large | 8,192 | 6% | 7,700 |
| m7i.xlarge | 16,384 | 5% | 15,565 |
| m7i.2xlarge | 32,768 | 5% | 31,130 |
| m7i.4xlarge | 65,536 | 5% | 62,259 |
| m7i.8xlarge | 131,072 | 4% | 125,829 |
| m7i.12xlarge | 196,608 | 4% | 188,744 |
| r7i.large | 16,384 | 5% | 15,565 |
| r7i.xlarge | 32,768 | 5% | 31,130 |
| r7i.2xlarge | 65,536 | 5% | 62,259 |
| r7i.4xlarge | 131,072 | 4% | 125,829 |
For instance types not listed here, you can calculate the available memory using the formula described above. Check the [Amazon EC2 instance types documentation](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) for the total memory of your chosen instance type.
## Configuring NVMe Drive Access
On d-type instances, the NVMe drive automatically mounts to the `/data` directory during host startup. To enable containers to access the SSD storage, set the following `ContainerGroupDefinition` property `MountPoints`:
+ `InstancePath` – Set to `/data` to reference the auto-mounted NVMe drive on the host instance.
+ `AccessLevel` – Choose the appropriate access level for your container's needs (e.g., READ\$1ONLY or READ\$1WRITE).
+ `ContainerPath` – (Optional) Specify the path where the instance path will be mounted inside the container. If not specified, it defaults to the instance path.
For more information about mount points, see [ContainerMountPoint](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerMountPoint.html) in the Amazon GameLift Servers API Reference.
## Designate essential containers
For a per-instance container group, designate each container as essential or non-essential. Per-instance container groups must have at least one essential support container. The essential container does the critical work of the container group. The essential container is always expected to be running. If it fails, the entire container group restarts.
Set the `ContainerDefinition` property `Essential` to either true or false for each container.
## Configure network connections
You can customize network access to allow external traffic connect to any container in a container fleet. For example, you must establish network connections to the container that runs your game server processes, so that game clients can join and play your game. Game clients connect to game servers using ports and IP addresses.
In a container fleet, the connection between a client and server is not direct. Internally, a process in a container listens on a *container port*. Externally, incoming traffic connects to a fleet instance using a *connection port*. Amazon GameLift Servers maintains the mappings between internal container ports and external-facing connection ports, so that incoming traffic gets routed to the correct process on the instance.
Amazon GameLift Servers provides an extra layer of control for your network connections. Each container fleet has an *inbound permissions* setting, which allows you to control access to each external-facing connection port. For example, you could remove permissions for all connection ports to shut off all access to the fleet's containers.
You can update a fleet's inbound permissions, connection ports, and container ports.
**Warning**
If you provide a custom InstanceConnectionPortRange or InstanceInboundPermissions, Amazon GameLift Servers will no longer manage either value for your fleet. You must set both fields to avoid undefined behavior.
**Set container port ranges**
Configure container port ranges as part of each container definition. This is a required parameter for a container group definition. You need to configure enough ports to accommodate all concurrently running processes that need external access. Some containers will not need any ports.
Your game server container, which runs your game servers, needs a port for every concurrently running game server process. The game server process listens on the assigned port and reports it to Amazon GameLift Servers.
**Set connection port ranges**
Configure your container fleet with a set of connection ports. Connection ports provide external access to the fleet instances that are running your containers. Amazon GameLift Servers assigns connection ports and maps them to container ports as needed.
By default, Amazon GameLift Servers calculates the number of ports required for all container groups and sets a port range to accommodate them. We highly recommend you use Amazon GameLift Servers calculated values, which are updated when you deploy updates to a container group definition. If you do need to customize connection port ranges, use the following guidance.
When you create a container fleet, define a connection port range (see [ ContainerFleet:InstanceConnectionPortRange](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html)). Make sure that the range has enough ports to map to every container port that's defined across all containers in both container groups in the fleet. To calculate the minimum connection ports needed, use the following formula:
`[Total number of container ports defined for containers in the game server container group] * [Number of game server container groups per instance] + [Total number of container ports defined for containers in the per-instance container group]`
As a best practice, double the minimum number of connection ports.
The number of connection ports can potentially limit the number of game server container groups per instance. If a fleet has only enough connection ports for one game server container group per instance, Amazon GameLift Servers will deploy only one game server container group, even if the instances have enough compute power for multiple game server container groups.
**Set inbound permissions**
Inbound permissions control external access to a container fleet by specifying which connection ports to open for incoming traffic. You can use this setting to turn a fleet's network access on and off as needed.
By default, Amazon GameLift Servers calculates the number of ports required for all container groups and sets a port range to accommodate them. We highly recommend you use Amazon GameLift Servers calculated values, which are updated when you deploy updates to a container group definition. If you do need to customize connection port ranges, use the following guidance.
When you create a container fleet, define a set of inbound permissions (see [ ContainerFleet:InstanceInboundPermissions](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html)). Inbound permission ports should match with the fleet's connection port ranges.
Since container ports are selected randomly from the InstanceConnectionPortRange, in order to guarantee that session connections can be made, all ports in InstanceConnectionPortRange should be covered by ports in InstanceInboundPermissions
**Example scenario**
This example illustrates how to set all three network connection properties.
+ Our fleet's game server container group has 1 container, which runs 1 game server process.
In the game server container group definition, we set the `PortConfiguration` parameter for this container as follows:
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ] }
```
+ Our fleet also has a per-instance container group with 1 container. It has 1 process that needs network access. In the per-instance container definition, we set the `PortConfiguration` parameter for this container as follows:
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ] }
```
+ Our fleet is configured with 20 game server container groups per fleet instance. Given this information, we can use the formula to calculate the number of connection ports we need:
+ Minimum: **21 ports** [1 game server container ports \$1 20 game server container groups per instance \$1 1 per-instance container port]
+ Best practice: **42 ports** [minimum ports \$1 2]
When creating the container fleet, we set the `InstanceConnectionPortRange` parameter as follows:
```
"InstanceConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }
```
+ We want to allow access to all available connection ports. When creating the container fleet, we set the `InstanceInboundPermissions` parameter as follows:
```
"InstanceInboundPermissions": [
{"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]
```
## Set up health checks for containers
A container automatically restarts if it experiences a terminal failure and stops running. If a container is considered essential, it prompts the entire container group to restart.
All game server containers are automatically considered essential. Support containers can be designated essential, but they need to have a mechanism to report health. You can set health checks for non-essential support containers as well.
You can define additional custom criteria to measure container health and use a health check to test that criteria. To set up a container health check, you can define it in a Docker container image or in your container definition. If you set a health check in the container definition, it overrides any settings in the container image.
Set the following `SupportContainerDefinition` properties for a container health check:
+ `Command` — Provide a command that checks some aspect of the container’s health. You decide what criteria to use to measure health. The command must result in an exit value of 1 (unhealthy) or 0 (healthy).
+ `StartPeriod` — Specify an initial delay before health check failures start counting. This delay gives the container time to bootstrap its processes.
+ `Interval` — Decide how often to run the health check command. How quickly do you want to detect and resolve a container failure?
+ `Timeout` — Decide how long to wait for success or failure before retrying the health check command. How long should the health check command take to complete?
+ `Retries` — How many times should the health check command be retried before registering a failure?
## Set container dependencies
Within each container group you can set dependencies between containers based on container status. A dependency impacts when the dependent container can start or shut down based the status of another container.
A key use case for dependencies is to create startup and shutdown sequences for the container group.
For example, you might want Container A to start first and complete successfully before Containers B and C start. To achieve this, first create a dependency for Container B on Container A, with the condition that Container A must complete successfully. Then create a dependency for Container C on Container A with the same condition. Startup sequences occur in reverse order for shutdown.
## Configure a container fleet
When you create a container fleet, consider the following decision points. Most of these points are dependent on your container architecture and configuration.
**Decide where you want to deploy your fleet**
In general, you want to deploy your fleets geographically near your players to minimize latency. You can deploy your container fleet to any AWS Region that Amazon GameLift Servers supports. If you want to deploy the same game server to additional geographic locations, you can add remote locations to the fleet including AWS Regions and Local Zones. For a multi-location fleet, you can adjust capacity independently in each fleet location. For more information about supported fleet locations, see [Amazon GameLift Servers service locations](gamelift-regions.md).
Consider using [UDP ping beacons](reference-udp-ping-beacons.md) to collect network latency data in various geographical locations to anticipate the latency between player devices and potential fleet locations. These special endpoints accept UDP messages instead of traditional ICMP pings, providing accurate latency measurements to help you select optimal fleet locations.
**Choose an instance type and size for your fleet**
Amazon GameLift Servers supports a wide range of Amazon EC2 instances types, all of which are available for use with a container fleet. Instance type availability and price varies by location. You can view a list of supported instance types, filtered by location, in the Amazon GameLift Servers console (under **Resources, Instance and service quotas**).
When choosing an instance type, first consider the instance family. Instance families offer various combinations of CPU, memory, storage, and networking capabilities. Get more information on [EC2 instance families](https://aws.amazon.com/ec2/instance-types/). Within each family you have a range of instance sizes to choose from. Consider the following issues when selecting an instance size:
+ What's the minimum instance size that can support your workload? Use this information to eliminate any instance types that are too small.
+ What instance type sizes are a good fit for your container architecture? Ideally, you want to choose a size that can accommodate multiple copies of your game server container group with minimal wasted space.
+ What scaling granularity makes sense for your game? Scale fleet capacity involves adding or removing instances, and each instance represents the ability to host a specific number of game sessions. Consider how much capacity you want to add or remove with each instance. If player demand varies by thousands from minute to minute, then it might make sense to use very large instances that can host hundreds or thousands of game sessions. By contrast, you might prefer more fine-grained scaling control with smaller instance types.
+ Are there cost savings available based on size? You might find that the cost of certain instance types vary by location due to availability.
**Set other optional fleet settings**
You can use the following optional features when configuring a container fleet:
+ Set up your game servers to access other AWS resources. See [Connect your Amazon GameLift Servers hosted game server to other AWS resources](gamelift-sdk-server-resources.md).
+ Protect game sessions with active players from terminating prematurely during a scale-down event.
+ Limit the number of game sessions that one individual can create on the fleet within a limited span of time.
# Reduce game hosting costs with Spot fleets
When hosting multiplayer game servers using Amazon GameLift Servers managed hosting, Spot instances can provide a cost-effective alternative to On-Demand instances. The Spot pricing model offers the same hardware and performance as On-Demand but at potentially significant cost savings (up to 70-90%). However, they come with a limitation: when AWS needs capacity back, it can reclaim these instances with a two-minute interruption notification.
Amazon GameLift Servers mitigates the risk of interruptions for game server hosting. Amazon GameLift Servers predicts the likelihood of interruptions on Spot instance types and avoids placing game sessions on any instances at risk. If a rare interruption does occur, the notification allows you to gracefully end a game session for players.
## How Amazon GameLift Servers works with Spot fleets
When you set up Spot fleets for game hosting, Amazon GameLift Servers continually evaluates your Spot fleet instance types and locations for game hosting viability.
+ The Spot viability algorithm analyzes recent availability patterns and historical interruption rates of Spot instance types by location.
+ Based on this analysis, Amazon GameLift Servers identifies Spot instance types and locations where there's an unacceptable potential for game session interruption. It takes the following actions:
+ It marks the combination of instance type and location as temporarily non-viable.
+ It removes any non-viable Spot fleet location from consideration when placing new game sessions. As a result, game sessions are only placed in Spot fleet locations that have a high likelihood of uninterrupted game server hosting.
+ It drains the Spot fleet location of existing instances, even if AWS doesn't reclaim them, so you're not paying for instances that can't be used for game hosting. If game session protection is turned on, instances are shut down only after active game sessions are completed.
+ Amazon GameLift Servers continually re-evaluates your Spot fleet instance types and locations for game hosting viability. When a previously non-viable instance type becomes viable again based on updated historical data, you can scale up the Spot fleet again, and Amazon GameLift Servers will resume placing game sessions with it.
## Design considerations
When designing your solution to use Spot fleets, consider the following issues:
+ **Assess game session length** – The average length of your game sessions can impact how well Spot works for your game. With shorter game sessions, the faster turnaround keeps game sessions running on viable instance types based on the latest historical data. Longer game sessions continue to run on instance types without evaluating recent viability data, running a greater risk of interruption over time.
+ **Evaluate instance type availability** – Not every fleet location offers every instance type as Spot. When choosing an instance type for your Spot fleet, use the Amazon GameLift Servers console fleet creation tool to help you find Spot instance types in the locations you need. With this tool, you can select your fleet locations and then view instance type availability across those locations.
+ **Create multi-location Spot fleets** – You can create Spot fleets with multiple locations. A single multi-location Spot fleet deploys instances with the same instance type to multiple AWS Regions or Local Zones. The Spot viability algorithm evaluates viability based on both instance type and location. If a Spot fleet location is evaluated as nonviable, it doesn't impact other locations in the fleet, which can still be used to host game sessions.
+ **Create queues with Spot fleet diversity** – If you're using Spot fleets for game hosting, you need to set up a game session placement queue. For each new game session request, the queue looks for available game hosting resources and selects the best possible option. With Spot fleets, you want a queue that can search across multiple fleets that vary in both locations and instance types, and you want to include at least one On-Demand fleet as backup capacity. A well-designed multi-fleet queue that offers diverse placement options is highly resilient against interruptions, slowdowns, and outages. For additional guidance on designing a queue for Spot, see [Build a queue for Spot Instances](spot-tasks.md).
+ **Handle interruptions gracefully** – Set up your game server to minimize player impact in the event of a Spot interruption. When AWS reclaims a Spot instance, Amazon GameLift Servers passes the termination notification to all affected server processes using the server SDK callback function `onProcessTerminate()`. Your game needs to implement this callback to end the game session gracefully. For more information, see [Respond to a server process shutdown notification](gamelift-sdk-server-api.md#gamelift-sdk-server-terminate).
**Note**
AWS makes every effort to provide the notification before it reclaims an instance, but it's possible that AWS reclaims the Spot Instance before the warning arrives. You should also prepare your game server to handle unexpected interruptions.
+ **Configure auto-scaling for your backup fleets to maintain service during a Spot interruption.** Target-tracking auto-scaling maintains a capacity buffer and scales automatically with demand. With auto-scaling, backup fleets (Spot or On-Demand) will begin increasing capacity whenever they start receiving more game session requests.
To quickly replace lost capacity when a Spot fleet becomes non-viable, a custom scaling mechanism can use available queue and fleet metrics to initiate a rapid scale-out of backup fleets. Detect when Spot fleets become non-viable with metrics such as `FirstChoiceOutOfCapacity`, `FirstChoiceNotViable`, and `PercentAvailableGameSessions`. Estimate replacement capacity needs by analyzing recent `PlacementsStarted` metric data. After scaling backup fleets to handle immediate demand, normal auto-scaling can take over.
+ **Integration with FlexMatch** – If your solution uses a FlexMatch matchmaker, there are no special requirements for Spot fleets. You can configure a matchmaker to use a queue with Spot fleets. Amazon GameLift Servers automatically prioritizes match placements across Spot and On-Demand fleets, including when placing new game sessions and when backfilling empty player slots in existing game sessions.
# Optimize game server runtime configuration on managed Amazon GameLift Servers
You can set up an managed EC2 fleet's runtime configuration to run multiple game server processes per instance. This uses your hosting resources more efficiently.
## How a fleet manages multiple processes
Amazon GameLift Servers uses a fleet's runtime configuration to determine the type and number of processes to run on each instance. A runtime configuration contains at least one server process configuration that represents one game server executable. You can define additional server process configurations to run other types of processes related to your game. Each server process configuration contains the following information:
+ The file name and path of an executable in your game build.
+ (Optional) Parameters to pass to the process on launch.
+ The number of processes to run concurrently.
When an instance in the fleet activates, it launches the set of server processes defined in the runtime configuration. With multiple processes, Amazon GameLift Servers staggers the launch of each process. Server processes have a limited life span. As they end, Amazon GameLift Servers launches new processes to maintain the number and type of server processes defined in the runtime configuration.
You can change the runtime configuration at any time by adding, changing, or removing server process configurations. Each instance regularly checks for updates to the fleet's runtime configuration to implement the changes. Here's how Amazon GameLift Servers adopts runtime configuration changes:
1. The instance sends a request to Amazon GameLift Servers for the latest version of the runtime configuration.
1. The instance compares its active processes to the latest runtime configuration, and then does the following:
+ If the updated runtime configuration removes a server process type, then active server processes of this type continue to run until they end. The instance doesn't replace these server processes.
+ If the updated runtime configuration decreases the number of concurrent processes for a server process type, then excess server processes of this type continue to run until they end. The instance doesn't replace these excess server processes.
+ If the updated runtime configuration adds a new server process type or increases the concurrent processes for an existing type, then the instance starts new server processes, up to the Amazon GameLift Servers maximum. In this case, the instance launches new server processes as existing processes end.
## Optimize a fleet for multiple processes
To use multiple processes on a fleet, do the following:
+ [Create a build](gamelift-build-intro.md) that contains the game server executables that you want to deploy to a fleet, and then upload the build to Amazon GameLift Servers. All game servers in a build must run on the same platform and use the server SDK for Amazon GameLift Servers.
+ Create a runtime configuration with one or more server process configurations and multiple concurrent processes.
+ Integrate game clients with the AWS SDK version 2016-08-04 or later.
To optimize fleet performance, we recommend that you do the following:
+ Handle server process shutdown scenarios so that Amazon GameLift Servers can recycle processes efficiently. For example:
+ Add a shutdown procedure to your game server code that calls the server API `ProcessEnding()`.
+ Implement the callback function `OnProcessTerminate()` in your game server code to handle termination requests from Amazon GameLift Servers.
+ Make sure that Amazon GameLift Servers shuts down and relaunches unhealthy server processes. Report the health status back to Amazon GameLift Servers by implementing the `OnHealthCheck()` callback function in your game server code. Amazon GameLift Servers automatically shuts down server processes that are reported unhealthy for three consecutive reports. If you don't implement `OnHealthCheck()`, then Amazon GameLift Servers assumes that a server process is healthy, unless the process fails to respond to a communication.
## Choose the number of processes per instance
When deciding on the number of concurrent processes to run on an instance, keep in mind the following:
+ Amazon GameLift Servers limits each instance to a [maximum number of concurrent processes](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift). The sum of all concurrent processes for a fleet's server process configurations can't exceed this quota.
+ To maintain acceptable performance levels, the Amazon EC2 instance type might limit the number of processes that can run concurrently. Test different configurations for your game to find the right number of processes for your preferred instance type.
+ Amazon GameLift Servers doesn't run more concurrent processes than the total number configured. This means that the transition from the previous runtime configuration to the new configuration might happen gradually.
# Work with the Amazon GameLift Servers Agent
The Amazon GameLift Servers Agent oversees the running of game server processes on your Amazon GameLift Servers fleets. The Agent is deployed to each compute in a fleet, and it provides automated process management, hosting management, and logging for the compute. To use the Agent, you must have your game server build integrated with the server SDK for Amazon GameLift Servers version 5.x or later.
The Amazon GameLift Servers Agent is externally available for use with Amazon GameLift Servers fleets that are not managed EC2 fleets. (Managed EC2 fleets handle the Agent's tasks automatically.) You can opt to run Amazon GameLift Servers fleets, including Anywhere fleets, with or without the Agent. Without the Agent, you must provide an alternative solution to completing the required tasks.
When deployed to a compute, the Amazon GameLift Servers Agent should be launched before any game server processes are started. On launch, the Agent completes the following tasks:
+ Registers the compute with an Amazon GameLift Servers Anywhere fleet using the [RegisterCompute](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_RegisterCompute.html) API.
+ Calls the [GetComputeAuthToken](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_GetComputeAuthToken.html) API to fetch an authorization token and stores it for use by server processes that are running on the compute.
+ Sets the WebSocket URL environment variable for the compute, and establishes a WebSocket connection to the Amazon GameLift Servers service.
+ Requests the latest version of the fleet's runtime configuration from the Amazon GameLift Servers service.
+ Starts and stops server processes according to the runtime configuration instructions.
Source code and build instructions for the Amazon GameLift Servers Agent are available in the [Amazon GameLift Servers Agent](https://github.com/aws/amazon-gamelift-agent) GitHub.
## About the Agent
The Amazon GameLift Servers Agent is designed to handle the following tasks for your fleets:
**Process management**
+ Starts new server processes as defined in runtime instructions. The Agent might use a custom runtime configuration that is deployed with the Agent. Alternatively, you can provide a `RuntimeConfiguration` as part of your fleet definition. This approach has an advantage in that you can modify the fleet's runtime configuration at any time. The Agent periodically requests updated runtime configurations from the Amazon GameLift Servers service.
+ Monitors server process activations and terminates processes when they don't activate in time.
+ Sends heartbeats to Amazon GameLift Servers. If the Agent fails to send heartbeats, the compute might be marked as stale.
+ Reports to Amazon GameLift Servers when a server process ends. Amazon GameLift Servers uses this information to monitor game server availability for game session placement.
+ Emits fleet events for server processes, including:
+ `SERVER_PROCESS_INVALID_PATH`: The game server process launch parameters were incorrectly configured.
+ `SERVER_PROCESS_TERMINATED_UNHEALTHY`: The game server process did not report a valid health check within 3 minutes of activating and was therefore terminated.
+ `SERVER_PROCESS_FORCE_TERMINATED`: The game server process did not exit cleanly after `OnProcessTerminate()` was sent within 30 seconds.
+ `SERVER_PROCESS_CRASHED`: A game server process crashed for some reason.
**Compute management**
+ Receives messages from the Amazon GameLift Servers service to shut down the compute.
+ Prompts the compute to be terminated by Amazon GameLift Servers.
**Logging**
+ Uploads logs to an Amazon S3 bucket in your AWS account.
# Abstract an Amazon GameLift Servers fleet designation with an alias
An Amazon GameLift Servers *alias* is used to abstract a hosting destination. Hosting destinations tell Amazon GameLift Servers where to look for available resources to host a new game session for players. Aliases are useful in the following scenarios:
+ If your game doesn't use multi-fleet queues for game session placement, it requests new game sessions by specifying an Amazon GameLift Servers fleet ID. During the life of a game, you'll replace the fleet multiple times, to update a server build, update hosting hardware and operating system, or resolve performance issues. Use an alias to abstract the fleet ID so that you can seamlessly switch player traffic from an existing fleet to the new one.
+ If you want to do something other than create a new game session when a game client requests one. For example, you might want to direct players who are using an out-of-date client to an upgrade website.
An alias must specify a routing strategy. There are two types. A *simple* routing strategy routes player traffic to a specified fleet ID, which you can update to redirect traffic. A *terminal* routing strategy passes a message back to the client instead of creating a new game session. You can change an alias's routing strategy at any time.
If you use a queue for game session placement, you don't need an alias to redirect traffic when replacing a fleet. With a queue, you can simply add the new fleet and remove the old fleet. This action is not visible to players, because new game session requests are automatically fulfilled using the new fleet. It doesn't impact existing game sessions. You can identify queues destinations by using either a fleet ID or alias.
**Topics**
+ [Create an Amazon GameLift Servers alias](aliases-creating.md)
# Create an Amazon GameLift Servers alias
This topic describes how to create an Amazon GameLift Servers alias for use with game session placement.
**To create an alias**
Use either the Amazon GameLift Servers console or the AWS Command Line Interface (AWS CLI) to create an alias.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), use the navigation pane to open the **Aliases** page.
1. Choose **Create alias**.
1. Enter an alias **Name**. We recommend including meaningful characteristics in the alias name to help when viewing a list of aliases.
1. Enter an alias **Description** as needed.
1. Choose a **Routing strategy** for the alias.
1. If you choose a **Simple** routing strategy, select a fleet ID from the list to associate with this alias. The list includes all fleets in eith currently selected AWS Region. You must create an alias in the same Region as the fleet.
1. If you choose a **Terminal** routing strategy, enter a string value that you want Amazon GameLift Servers to return to a game client in response to a game session request. A request with a terminal alias throws an exception with the message embedded.
1. (Optional) Add **Tags** to the alias resource. Each tag consists of a key and an optional value, both of which you define. Assign tags to AWS resources that you want to categorize in useful ways, such as by purpose, owner, or environment. Choose **Add new tag** for each tag that you want to add.
1. When you're ready to deploy the new fleet, choose **Create**.
------
#### [ AWS CLI ]
Use the [https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-alias.html](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-alias.html) command to create an alias. .Amazon GameLift Servers creates the alias resource in your current default AWS Region (or you can add a --region tag to specify a different AWS Region).
At minimum, include an alias name and routing strategy. For a simple routing strategy, specify the ID of a fleet in the same Region as the alias. For a terminal routing strategy, provide a message string.
------