# Deploy hosting fleets for Amazon GameLift Servers
Deploying hosting resources involves creating and configuring the compute infrastructure that will run your game servers. Amazon GameLift Servers offers several fleet types to match different hosting needs, from fully managed AWS Cloud resources to hybrid solutions that combine cloud and on-premises infrastructure.
Choose the fleet type that best fits your requirements for cost, control, scalability, and geographic distribution. You can also combine multiple fleet types in a single hosting solution to optimize for different scenarios or player populations.
## Fleet characteristics
An Amazon GameLift Servers fleet is a collection of computing resources that run your game servers and host game sessions for players. Fleets can vary in the type of compute resources you use and how the fleet is managed. A fleet's size—the number of game sessions and players that it can support—depends on the number of compute resources that you give it. All Amazon GameLift Servers fleets have the following characteristics:
+ The game server processes that run on all fleets are integrated with the server SDK for Amazon GameLift Serversand communicate with the Amazon GameLift Servers service in the same way. Game servers report their availability to host game sessions and players, respond to prompts to start or stop game sessions, and other interactions.
+ Amazon GameLift Servers handles game session placement for all fleets in the same way. Amazon GameLift Servers keeps track of a fleet's game server status and chooses from available game servers to host a new game session. This process is used whether your game places game sessions on a single fleet or uses a [game session queue](queues-intro.md) to balance hosting across multiple fleets. With a queue, you can also customize placement decisions to consider factors such as resource cost and latency.
+ All fleets support the use of a FlexMatch matchmaker in collaboration with a game session placement queue. The Amazon GameLift Servers service receives player match requests, forms the matches, and passes them to the game session queue to find available game servers.
+ Amazon GameLift Servers collects a wide range of fleet metrics. These include status metrics for computes and server processes, as well as usage metrics for game sessions and player activity. See the complete list of available metrics at [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md).
**Topics**
+ [Fleet characteristics](#fleets-intro-common)
+ [Decision guide: Choose a hosting option](fleets-decision-guide.md)
+ [Amazon GameLift Servers managed EC2 fleets](fleets-intro-managed.md)
+ [Amazon GameLift Servers managed container fleets](fleets-intro-containers.md)
+ [Amazon GameLift Servers Anywhere fleets](fleets-intro-anywhere.md)
+ [Build a hybrid hosting solution](hybrid-solution-guide.md)
# Decision guide: Choose a hosting option
Amazon GameLift Servers offers several hosting options, each designed for different hosting scenarios and requirements. This guide helps you choose the type of fleet based on your game's technical needs, operational preferences, and business constraints. For high-level descriptions, see [Amazon GameLift Servers game hosting options](gamelift-intro-flavors.md).
## Fleet comparison
The following table compares the key characteristics of each hosting option:
| Hosting option | Best For | Management Level | Key Benefits |
| --- | --- | --- | --- |
| Managed EC2 | Production hosting with full AWS management | Fully managed | Auto-scaling, global reach, minimal operational overhead |
| Managed containers | Containerized applications requiring orchestration | Fully managed | Container orchestration, resource efficiency, modern deployment |
| Anywhere | On-premises, hybrid, or development environments | Self-managed | Hardware control, compliance requirements, cost optimization |
## Key decision factors
Consider these factors when choosing your hosting option:
Operational complexity
How much infrastructure management do you want to handle? Managed fleets require minimal operational overhead, while Anywhere fleets give you full control but require more management.
Scalability requirements
Do you need automatic scaling based on player demand? Managed fleets provide built-in auto-scaling, while Anywhere fleets require manual capacity management.
Geographic distribution
Where are your players located? Managed fleets can be deployed across multiple AWS Regions globally, while Anywhere fleets depend on your own infrastructure locations.
Compliance and security
Do you have specific compliance requirements or need to keep data on-premises? Anywhere fleets allow you to maintain full control over your infrastructure and data location.
Cost considerations
What's your budget and cost optimization strategy? Consider both infrastructure costs and operational overhead when comparing options.
## Hybrid solutions
You don't have to choose just one type of fleet for your game hosting solution. Many games use a hybrid approach that combines multiple fleet types to optimize for different scenarios:
+ **Development and testing**: Use Anywhere fleets for development and testing, then deploy to managed fleets for production.
+ **Regional optimization**: Use managed fleets in AWS Regions with high player density and Anywhere fleets in regions where you have existing infrastructure.
+ **Cost optimization**: Use managed fleets for baseline capacity and Anywhere fleets for overflow or specific workloads.
# Amazon GameLift Servers managed EC2 fleets
Amazon GameLift Servers managed EC2 fleets provide cloud-based resources for production hosting. With a managed fleet, you get the flexibility, security, and reliability of AWS Cloud resources optimized for multiplayer game hosting. Amazon GameLift Servers provides robust host management tools.
A managed EC2 fleet is a set of Amazon Elastic Compute Cloud (Amazon EC2) instances that Amazon GameLift Servers owns and operates based on your configuration. These instances are physically located in supported AWS Regions or Local Zones. When you create a fleet, you choose an EC2 instance type that meets your game server's requirements for computing power, memory, storage, networking capabilities.
When starting each instance in the fleet, Amazon GameLift Servers deploys your game server build with the required runtime environment. The runtime environment uses the latest Amazon Machine Image (AMI) version available when the fleet is created. All instances in the fleet use the same AMI version.
**Note**
As a best practice, we recommend replacing your fleets every 30 days to maintain a secure and up-to-date runtime environment for your hosted game servers. This requires creating a new fleet and migrating player traffic to it. For more guidance, see [Security best practices for Amazon GameLift Servers](security-best-practices.md).
After installing the runtime environment and your game server build on an instance, Amazon GameLift Servers starts launching game server processes. Each game server process establishes a connection to the Amazon GameLift Servers service, reports readiness to host a game session, and begins communicating health status. Amazon GameLift Servers can then prompt the server process to start a game session.
In addition to fleet deployment, Amazon GameLift Servers handles the following host management tasks so you don't have to:
+ Tracks the status of all computes in the fleet and replaces stale or unhealthy computes.
+ Handles authentication for communication between server processes and the Amazon GameLift Servers service.
+ Automatically starts and stops game server processes on each compute, based on your runtime configuration.
+ Offers auto scaling tools to adjust fleet capacity dynamically to meet player demand.
+ Reports performance metrics for the fleet's EC2 instances.
See these topics about how to set up and maintain managed EC2 fleets:
+ [Development roadmap for hosting with Amazon GameLift Servers managed EC2](gamelift-roadmap-managed.md)
+ [Create an Amazon GameLift Servers managed EC2 fleet](fleets-creating.md)
+ [Scaling game hosting capacity with Amazon GameLift Servers](fleets-manage-capacity.md)
+ [Hosting resource customizations](fleets-design.md)
+ [Update an Amazon GameLift Servers fleet configuration](fleets-editing.md)
## Managed EC2 fleet creation workflow
For managed fleets, Amazon GameLift Servers sets up the fleet resource and also deploys a set of compute resources with your game server software installed and running. When the creation workflow is complete and successful, the fleet has one active EC2 instance in the fleet home Region and one each in the fleet's remote locations. All instances have game are ready to host game sessions.
1. Amazon GameLift Servers creates the fleet resource in the fleet's home Region and sets desired capacity in each location to one (1) instance. Fleet and location status is set to **New**.
1. Amazon GameLift Servers begins writing events to the fleet event log.
1. Amazon GameLift Servers sets fleet status to **Downloading** and begins preparing the game server software for deployment.
1. Gets the uploaded game server build and extracts the compressed files.
1. Runs install scripts, if provided.
1. Sets fleet status to **Validating** and begins verifying that no errors occurred when downloading and installing the build files.
1. Amazon GameLift Servers sets the fleet status to **Building**, configures fleet hardware, and allocates one EC2 instance for each fleet instance.
1. Amazon GameLift Servers sets the fleet status to **Activating**. Launches a game server process on each instance (based on the fleet's runtime instructions) and tests connectivity between the build and the Amazon GameLift Servers service.
1. When game server processes on each instance establish a connection and report readiness to host game sessions, Amazon GameLift Servers sets fleet and location statuses to **Active**. At this point, the fleet is considered ready to host game sessions.
# Create an Amazon GameLift Servers managed EC2 fleet
This topic describes how to create an Amazon GameLift Servers managed EC2 fleet. Managed fleets use Amazon Elastic Compute Cloud (Amazon EC2) compute instances that are optimized for multiplayer game hosting. You can create managed fleets that deploy computes to globally to AWS Regions and Local Zones supported by Amazon GameLift Servers.
When you create a new managed EC2 fleet resource, you immediately initiate the first phase of fleet creation. Managed fleet creation passes through several phases as Amazon GameLift Servers deploys an EC2 instance, installs a runtime environment and your game server build on the instance, and begins launching game servers. Depending on the runtime environment your game server build requires, Amazon GameLift Servers deploys the latest version of the Amazon Machine Image (AMI) at the time of fleet creation (and all future instances in the fleet will use the same version).You can monitor a fleet's status in the console or using the AWS Command Line Interface (AWS CLI). When a fleet is ready to host game sessions, the status changes to `ACTIVE`. For more information about managed fleet creation, see these topics:
**Note**
As a best practice, we recommend replacing your fleets every 30 days to maintain a secure and up-to-date runtime environment for your hosted game servers. This requires creating a new fleet and migrating player traffic to it. For more guidance, see [Security best practices for Amazon GameLift Servers](security-best-practices.md).
**To create a managed EC2 fleet**
Use either the Amazon GameLift Servers console or the AWS Command Line Interface (AWS CLI) to create a managed EC2 fleet.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), use the navigation pane to open the **Managed EC2, Fleets** page. Choose **Create managed EC2 fleet** to start the fleet creation workflow.
**Step 1 Define managed EC2 fleet details**
**For a minimal fleet configuration:**
+ Provide a fleet name.
+ Choose **Binary type: Build**. Choose a build from the list of server builds that you've previously uploaded to Amazon GameLift Servers.
+ Skip the Additional details and Tags sections to use default settings.
1. Fill out the **Fleet details** section:
1. Enter a fleet **Name**. Fleet names are descriptive only, useful for sorting or filtering a list of fleets. They don't need to be unique.
1. Provide a short fleet **Description** to include any custom information you want to capture about the fleet.
1. Select **Binary type, Build**, and use the dropdown list to choose a game server build that you've previously uploaded to Amazon GameLift Servers.
1. Set **Additional details** as needed.
1. If your game server executable needs to access other AWS resources in your account, specify an IAM **Instance role** with the necessary permissions. For more information, including how to authorize other server-side applications (such as CloudWatch agent), see [Connect your Amazon GameLift Servers hosted game server to other AWS resources](gamelift-sdk-server-resources.md). This setting can't be changed after you create the fleet.
You must create the role before you create a fleet that uses it. In addition, to create a fleet with an instance role, your AWS user must have IAM `PassRole` permission (see [IAM permission examples for Amazon GameLift Servers](gamelift-iam-policy-examples.md)).
1. Turn on the **Generate a TLS certificate** option to set up authentication and encryption for your game, Game clients use this certificate to authenticate a game server when connecting and encrypt all client/server communication. For each instance in a TLS-enabled fleet. Amazon GameLift Servers also creates a new DNS entry with the certificate. This setting can't be changed after you create the fleet.
1. Amazon GameLift Servers emits metric data for each individual fleet. If you want to combine metric data for multiple fleets, specify a **Metric group** name. Use the same metric group name for all fleets that you want to combine metrics for. Use CloudWatch to view the aggregated metric group data.
1. Add **Tags** to the fleet 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, such as by purpose, owner, or environment. Choose **Add new tag** for each tag that you want to add.
1. Choose **Next** to continue the workflow.
**Step 2 Define instance details**
In this step, select the type of hardware resources to use for your game servers and specify where you want to deploy them. By choosing multiple locations, you can deploy your game server to a wider geographical location, which puts them closer to your players and minimizes latency. All EC2 instances in a fleet must be the same type. Not all instance types are available in all locations.
**For a minimal fleet configuration:**
+ Start with deploying to the home location only. You don't need to add remote locations for initial development and testing.
+ Set fleet type set to "On-Demand". Spot fleets require additional setup work.
+ Set instance type to "c5.large". This commonly used instance type is available in all AWS Regions. You can optimize your hardware usage later.
1. In **Instance deployment**, specify fleet locations and type.
1. Select one or more additional **Locations** where you want to deploy fleet instances. These remote locations are added to the fleet's home location (which is pre-selected), which is the AWS Region where you're creating this fleet. You can select remote locations from all AWS Regions and Local Zones that Amazon GameLift Servers supports.
To learn more about supported locations, including how to use an AWS Region that isn't enabled by default, see [Amazon GameLift Servers service locations](gamelift-regions.md) for managed hosting. Also review Amazon GameLift Servers [quotas](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift) on locations per fleet.
1. Choose to use either **On-demand** or **Spot** instances for this fleet. For more information about fleet types, see [On-Demand Instances versus Spot Instances](gamelift-compute.md#gamelift-compute-spot).
1. Choose an Amazon EC2 **Instance configuration** that meets your needs and is available in all your selected locations. This list is filtered based on your current location and fleet type selections. You can filter it further by other factors such as instance type family and architecture. After you create the fleet, you can't change the instance type.
Some locations have limited instance type options. If your preferred instance type is not available for all locations, choose the location availability value to view full details. To accommodate all locations, you might need to create separate fleets with different instance types.
For more information about choosing an instance type, see [Instance types](gamelift-compute.md#gamelift-compute-instance). To learn more about Amazon EC2 Arm architectures, see [AWS Graviton Processor](https://aws.amazon.com/ec2/graviton/) and [Amazon EC2 instance types](https://aws.amazon.com/ec2/instance-types/). For a complete list of instance types supported by Amazon GameLift Servers, see the API reference for [EC2InstanceType](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateFleet.html#gamelift-CreateFleet-request-EC2InstanceType) (`CreateFleet()`).
**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).
1. Choose **Next** to continue the workflow.
**Step 4 Configure runtime**
In this step, describe how you want each instance in the fleet to run your game server software. Define a separate server process line item for each executable to run on an instance, and decide how many of each server process to run concurrently. Open ports on each instance to allow players to connect directly to game servers. You can update these fleet settings at any time.
**For a minimal fleet configuration:**
+ Define a single server process line item for your game server executable. If your game server requires other processes to be running, create a definition for each of these as well.
+ Use the default number of concurrent processes (1) for each line item.
+ Skip game session activation settings.
+ Specify a single port number.
+ Skip game session resource settings.
1. Create a **Runtime configuration** to instruct Amazon GameLift Servers on how to run server processes on each instance in the fleet. You can change a fleet's runtime configuration at any time after deployment.
1. Enter the **Launch path** to an executable file in your build. On Windows instances, game server executables are built to the path `C:\game`. On Linux instances, game servers are built to `/local/game`. Examples: **C:\$1game\$1MyGame\$1server.exe** or **/local/game/MyGame/server.exe**.
1. Enter optional **Launch parameters** to pass to your game executable. Example: **\$1sv\$1port 33435 \$1start\$1lobby**.
1. Specify the number of **Concurrent processes** to run on each instance. For a game server executable, each process can host one game session, so concurrent processes determines the number of game sessions the instance can host simultaneously.
Review the Amazon GameLift Servers [ quotas](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift) on server processes per instance. These quotas apply to the total concurrent processes for all configurations. If you configure the fleet to exceed them, the fleet can't activate.
1. Use the **Game session activation** defaults or customize them for your game. If the runtime configuration calls for multiple concurrent game server process per instance, these settings determine how quickly new game sessions can start up.
1. Set **Max concurrent game session activation** to limit the number of game servers on an instance that are preparing a new game session. This setting is useful when launching multiple new game sessions is resource-intensive and might impact the performance of other running game sessions.
1. Set the **New activation timeout** to reflect the maximum amount of time a new game session should take to complete activation and report ready to host players. Amazon GameLift Servers terminates a game session activation if it exceeds this value.
1. Open **EC2 port settings** to allow inbound traffic to access server processes on the fleet. These settings aren't required to create a fleet, but you do need set them before players can connect to game sessions on the fleet.
For each port setting, choose the **Type** of data transfer protocol to use for communication between your game client and game server. Provide a **Port range** (in format `nnnnn[-nnnnn]`) and an **IP address range ** using CIDR notation (such as **0.0.0.0/0** which allows access to anyone).
If you need to set multiple non-consecutive ranges, create multiple port settings.
1. Specify optional **Game session resource settings**. You can update these settings any time after deployment.
1. Turn **Game scaling protection policy** on or off for all instances in the fleet. During a scale-down event, Amazon GameLift Servers won't terminate protected fleet instances if they're hosting active game sessions.
1. Set a maximum **Resource creation limit** if you want to restrict the number of game sessions that one player can create during a specified time span.
1. Choose **Next** to continue the workflow.
**Step 5 Review and create**
Review your settings before creating the fleet. Although some settings can be updated later (see [Update an Amazon GameLift Servers fleet configuration](fleets-editing.md)), changes to the following settings aren't allowed after the fleet has been created:
+ Compute type: You can't convert a managed EC2 fleet to an Anywhere fleet.
+ Game server binary: To deploy an update to your game server build, you must create a new fleet.
+ Additional options, including instance role and TLS certificate generation.
+ Instance details, including fleet type (Spot or On-Demand) and EC2 instance type.
When you're ready to deploy the new fleet, choose **Create**. Amazon GameLift Servers immediately begins the fleet activation process, assigning a unique ID and placing the fleet in `NEW` status. Track the fleet's progress from the **Fleets** page.View the details page for the fleet and go to the **Events** tab.
You can adjust a fleet's hosting capacity after the fleet reaches ACTIVE status. Amazon GameLift Servers initially deploys a fleet with a single instance in each fleet location. and you adjust capacity by adding instances to each location. For more information, see [Scaling game hosting capacity with Amazon GameLift Servers](fleets-manage-capacity.md).
------
#### [ AWS CLI ]
Use the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-fleet.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-fleet.html) command to create a fleet of compute type `EC2`. Amazon GameLift Servers creates the fleet resource in your current default AWS Region (or you can add a --region tag to specify a different AWS Region).
**Create a minimal managed fleet**
The following example request creates a new fleet with the minimal settings that are required to deploy a fleet with running game servers that game clients can connect to. The new fleet has these characteristics:
+ It specifies a game server build, which has been uploaded to Amazon GameLift Servers and in `READY` status.
+ Is uses c5.large On-Demand Instances with an operating system that matches the selected game build.
+ It sets the fleet's home AWS Region to `us-west-2` and deploys instances to that Region only.
+ Based on the runtime configuration, each compute in the fleet runs one game server process, which means that each compute can host only one game session at a time. Game session activation timeout is set to the default value of 300 seconds, and there's no limit on the number of concurrent activations.
+ Players can connect to game servers using a single port setting of `33435`.
+ All other features are either turned off or use default settings.
```
aws gamelift create-fleet \
--name MinimalFleet123 \
--description "A basic test fleet" \
--region us-west-2 \
--ec2-instance-type c5.large \
--fleet-type ON_DEMAND \
--build-id build-1111aaaa-22bb-33cc-44dd-5555eeee66ff \
--runtime-configuration "ServerProcesses=[{LaunchPath=C:\game\Bin64.dedicated\MultiplayerSampleProjectLauncher_Server.exe, ConcurrentExecutions=10}]" \
--ec2-inbound-permissions "FromPort=33435,ToPort=33435,IpRange=0.0.0.0/0,Protocol=UDP"
```
**Create a fully configured managed fleet**
The following example request creates a production fleet with settings for all optional features. The new fleet has these characteristics:
+ It specifies a game server build, which has been uploaded to Amazon GameLift Servers and in `READY` status.
+ It uses c5.large On-Demand Instances with the operating system that matches the selected game build.
+ It sets the fleet's home AWS Region to `us-west-2` and deploys instances to the home Region and one remote location `sa-east-1`.
+ Based on the runtime configuration:
+ Each compute in the fleet runs 10 game server processes with the same launch parameters, which means that each compute can host up to 10 game sessions simultaneously.
+ On each compute, only two game sessions can be activating at the same time. Activating game sessions must be ready to host players within 300 seconds (5 minutes) or be terminated.
+ Players can connect to game servers using a port in the following range `33435 to 33535`.
+ It generates a TLS certificate for encrypted communication between game client and server.
+ All game sessions in the fleet have game session protection turned on.
+ Individual players are limited to creating three new game sessions within a 15-minute period.
+ Metrics for this fleet are included in the metric group `AMERfleets`, which (for this example) aggregates metrics for a group of fleets in North, Central, and South America.
```
aws gamelift create-fleet \
--name ProdFleet123 \
--description "A fully configured prod fleet" \
--ec2-instance-type c5.large \
--region us-west-2 \
--locations "Location=sa-east-1" \
--fleet-type ON_DEMAND \
--build-id build-1111aaaa-22bb-33cc-44dd-5555eeee66ff \
--certificate-configuration "CertificateType=GENERATED" \
--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=33535,IpRange=0.0.0.0/0,Protocol=UDP" \
--metric-groups "AMERfleets"
```
If the create-fleet request is successful, Amazon GameLift Servers returns a set of fleet attributes that includes the configuration settings you requested and a new fleet ID. Amazon GameLift Servers then initiates the fleet activation process and sets the fleet status and the location statuses to **New**. You can track the fleet's status and view other fleet information using these CLI commands:
+ [describe-fleet-events](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-events.html)
+ [describe-fleet-attributes](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-attributes.html)
+ [describe-fleet-capacity](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-capacity.html)
+ [describe-fleet-port-settings](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-port-settings.html)
+ [describe-fleet-utilization](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-utilization.html)
+ [describe-runtime-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-runtime-configuration.html)
+ [describe-fleet-location-attributes](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-location-attributes.html)
+ [describe-fleet-location-capacity](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-location-capacity.html)
+ [describe-fleet-location-utilization](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-location-utilization.html)
You can change the fleet's capacity and other configuration settings as needed using these commands:
+ [update-fleet-attributes](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-fleet-attributes.html)
+ [update-fleet-capacity](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-fleet-capacity.html)
+ [update-fleet-port-settings](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-fleet-port-settings.html)
+ [update-runtime-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-runtime-configuration.html)
+ [create-fleet-locations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-fleet-locations.html)
+ [delete-fleet-locations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-fleet-locations.html)
------
# Amazon GameLift Servers managed container fleets
Amazon GameLift Servers managed container fleets provide cloud-based resources for hosting your containerized game server software. With a managed container fleet, you get the flexibility, security, and reliability of AWS Cloud resources, optimized for multiplayer game hosting. Amazon GameLift Servers provides robust host management tools.
**Speed up onboarding with these tools for managed containers:**
The [containers starter kit](https://github.com/aws/amazon-gamelift-toolkit/tree/main/containers-starter-kit) streamlines integration and fleet setup. It adds essential game session management features to your game server, and uses pre-configured templates to build a container fleet and an automated deployment pipeline for your game server. After deployment, use the Amazon GameLift Servers console and API tools to monitor fleet performance, manage game sessions, and analyze metrics.
For Unreal Engine or Unity developers, use the game engine [Amazon GameLift Servers plugins and server SDKs](https://github.com/amazon-gamelift/) to integrate your game server and build a container fleet from inside your game engine's development environment. The plugin's guided workflows help you create a fast, simple solution with cloud-based hosting using managed containers. You can build on this foundation to create a custom hosting solution for your game.
A managed container fleet is a set of Amazon Elastic Compute Cloud (Amazon EC2) instances running Linux, which Amazon GameLift Servers owns and operates based on your configuration. These instances are physically located in supported AWS Regions or Local Zones. When you create a container fleet, you choose an EC2 instance type that meets your game server's requirements for computing power, memory, storage, networking capabilities.
For a managed container fleet, you store Linux-based container images in an Amazon Elastic Container Registry (Amazon ECR) repository and create a container group definition to describe your container architecture. When you create a fleet, Amazon GameLift Servers provisions a fleet instance with the latest version of the Linux Amazon Machine Image (AMI) and uses the container group definition to deploy your container images. All instances in a container fleet will use the same AMI version, even if you update a container group definition or change a container image.
**Note**
As a best practice, we recommend replacing your fleets every 30 days to maintain a secure and up-to-date runtime environment for your hosted game servers. This requires creating a new fleet and migrating player traffic to it. For more guidance, see [Security best practices for Amazon GameLift Servers](security-best-practices.md).
After deploying the containerized instance, containers start launching game server processes. Each game server process establishes a connection to the Amazon GameLift Servers service, reports readiness to host a game session, and begins communicating health status. Amazon GameLift Servers can then prompt the server process to start a game session.
In addition to fleet deployment, Amazon GameLift Servers handles the following host management tasks so you don't have to:
+ Tracks the status of all containers in the fleet and replaces stale or unhealthy ones.
+ Handles authentication for communication between server processes and the Amazon GameLift Servers service.
+ Offers auto scaling tools that adjust fleet capacity dynamically to meet player demand.
+ Reports performance metrics for the fleet's EC2 instances, containers, and server processes.
See these topics about how to set up and maintain managed container fleets:
+ [Development roadmap for hosting with Amazon GameLift Servers managed containers](gamelift-roadmap-containers.md)
+ [Create an Amazon GameLift Servers managed container fleet](containers-build-fleet.md)
+ [Customize an Amazon GameLift Servers container fleet](containers-design-fleet.md)
+ [Scaling game hosting capacity with Amazon GameLift Servers](fleets-manage-capacity.md)
+ [Update an Amazon GameLift Servers managed container fleet](containers-update-fleet.md)
# How containers work in Amazon GameLift Servers
Amazon GameLift Servers container fleets are designed to give you flexibility in how you deploy and scale your containerized applications. It uses the Amazon Elastic Container Service (Amazon ECS) to manage task deployment and execution for your Amazon GameLift Servers fleets. This topic describes the basic structural elements for running containers on an Amazon GameLift Servers managed fleet, illustrates common architectures, and outlines some core concepts.
**Speed up onboarding with these tools for managed containers:**
The [containers starter kit](https://github.com/aws/amazon-gamelift-toolkit/tree/main/containers-starter-kit) streamlines integration and fleet setup. It adds essential game session management features to your game server, and uses pre-configured templates to build a container fleet and an automated deployment pipeline for your game server. After deployment, use the Amazon GameLift Servers console and API tools to monitor fleet performance, manage game sessions, and analyze metrics.
For Unreal Engine or Unity developers, use the [Amazon GameLift Servers plugins](https://github.com/amazon-gamelift/) to integrate your game server and build a container fleet from inside your game engine's development environment. The plugin's guided workflows help you create a fast, simple solution with cloud-based hosting using managed containers. Then build on this foundation to create a custom hosting solution for your game.
## Container fleet components
**Fleet**
A container fleet is a collection of Amazon EC2 instances to host your containerized game servers. These instances are managed by Amazon GameLift Servers on your behalf. When you create a fleet, you configure how the container architecture with your game server software is deployed to each fleet instance. You can create a container fleet with instances in one or multiple geographic locations. You can use Amazon GameLift Servers scaling tools to automatically scale a container fleet's capacity to host game sessions and players.
**Instance**
An Amazon EC2 instance is the virtual server that provides compute capacity for game hosting. With Amazon GameLift Servers, you can choose from a range of instance types. Each instance type offers a different combination of CPU, memory, storage, and networking capacity.
When you create a container fleet, Amazon GameLift Servers deploys your containers based on the instance type you choose and your fleet configuration. Each deployed fleet instance is identical and runs your containerized game server software in the same way. The number of instances in a fleet determines the fleet's size and game hosting capacity.
**Container group**
Amazon GameLift Servers uses the concept of a container group to describe and manage a set of containers. A container group is similar to a container "task" or "pod". Within each container group, you can define how containers behave, set up dependencies, and share available CPU and memory resources.
Each fleet instance can have the following types of container groups:
+ A **game server container group** manages the containers that run your game server application and supporting software. A container fleet must have one of this type of container group to host game sessions and players. A game server container group can be replicated across a fleet instance. The number of game server group replicas per fleet instance depends on your software's compute requirements and the compute resources available on the instance.
+ A **per-instance container group**, which is optional, gives you the ability to run additional software on each fleet instance. They are useful for running background services or utility programs, such as for monitoring. Your game server software doesn't directly depend on processes in a per-instance group. Only one copy of a per-instance container group is deployed to each fleet instance.
Each container group in a container fleet has one container that's designated "essential". An essential container drives the lifecycle of a container group. If the essential container fails, the entire container group restarts.
**Container**
The container is the most basic element of a container-based architecture. It includes a container image with software executables and dependent files. Define a container to configure how the software runs and interacts with Amazon GameLift Servers.
Amazon GameLift Servers defines two types of containers:
+ A **game server container** includes everything you need to run your game server processes and host game sessions for players. It includes your game server build and dependent software. Define one game server container for a fleet's game server container group. The game server container is automatically considered essential to the container group.
+ A **support container** runs additional software to support your game server. It is similar to the concept of a "sidecar" container. It gives you the option to run and scale supporting software alongside your game servers but manage as separate containers. In a game server container group, you can define zero or more support containers. In a per-instance container group, all containers are support containers. Any support container can be designated essential.
**Compute**
A compute represents a copy of a game server container group on a fleet instance.
## Common architectures
The following diagram illustrates the simplest container fleet structure. In this structure, each instance in the fleet maintains one copy of the game server container group. The container group has a single game server container that runs one game server process. In this example, the container fleet is configured to place one copy of the game server container group per instance. With this architecture, each instance runs one game server process.
![\[An example of a simple container architecture, with a single game server container in the game server container group.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/container_architecture_simple.png)
This second diagram illustrates a more complex container fleet architecture. In this structure, the fleet has a both a game server container group and a per-instance container group. The game server container group has separate containers for the game server process and a support process. The fleet is configured to place three copies of the game server container group on each fleet instance. The per-instance container group is never replicated. In this example, the container fleet is configured to place three copies of the game server container group per instance. With this architecture, each instance runs three game server process.
![\[An example of a container architecture with multiple containers in the game server container group and one container in the per-instance container group.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/container_architecture_complex.png)
## Core features
This section summarizes how Amazon GameLift Servers implements some basic container concepts. For instructions on how to work with container fleets, see the relevant topics in this guide.
### Active fleet updates
Managed containers provides advanced support to help you manage the life cycle of your hosted software and container architecture. You can update your container definitions, including container images, and deploy changes to your existing fleets. This feature makes it faster and easier to iterate changes to your containers during development. It also provides features to help you build, deploy, and track your software version updates over time. These features include:
+ Manage container group definition updates and versioning. You can update nearly all properties of a container group definition, including container images and configuration settings. Whenever you update a container, Amazon GameLift Servers automatically assigns a version number to the update and by default maintains all versions. You can access any specific version, and you can delete versions as desired. When creating a container fleet, you can specify the container group definition and version to deploy.
+ Update existing container fleets with new container group definitions and configuration settings. You can deploy container updates to fleets that are already deployed to fleet instances. You can track the status of update deployments across each fleet location using the AWS Management Console or the AWS SDK and CLI.
+ Configure how you want fleet updates to deploy across an active fleet.
+ Game session protection. Choose to protect fleet instances with active game sessions until after the game sessions end (safe deployment). Or choose to replace fleet instances regardless of game session activity (unsafe deployment). Use unsafe deployments during development and testing phases to reduce deployment time.
+ Minimum healthy percentage. Specify the percentage of healthy tasks that you want to maintain during deployment. This feature lets you decide how many fleet instances are impacted during a deployment. A low value prioritizes deployment speed, while a high value ensures that game server availability remains high throughout the deployment.
+ Deployment failure strategy. Decide what actions to take if a deployment fails. A deployment failure means that some of the updated containers have failed status checks and are considered impaired. You can set deployments to automatically roll back all fleet instances to the previously deployed state. Alternatively you can choose to maintain some of the impaired fleet instances for use in debugging.
The ability to update active fleets is highly useful when you want to deploy an update to your game server software. After you've built a new container image for your game server, deploying it is a two-step process: first, update the container group definition with the new image, and second, update the container fleet. Amazon GameLift Servers handles all other tasks as needed.
### Container packing
When developing your container structure for deployment in a container fleet, a common goal is to optimize your use of available computing power. To achieve this goal, you want to pack as many game server container groups as possible onto each fleet instance.
Amazon GameLift Servers helps you do this by calculating the maximum game server container groups per instance, based on the following information:
+ The fleet's instance type and its vCPU and memory resources.
+ The vCPU and memory requirements for all containers in the game server container group.
The vCPU and memory requirements for all containers in a per-instance container group, if there is one.
When you create a container fleet, you can use the calculated maximum or you can specify a desired number. As a best practice, plan to experiment with your containerized game server software to determine resource requirements for optimal game server performance.
### Capacity scaling
Fleet capacity measures the number of game sessions that a fleet can host concurrently. You can also measure capacity based on the number of concurrent players that a fleet can support. To increase or decrease a fleet's hosting capacity, you add or remove fleet instances.
A container fleet is configured to run a specific number of concurrent game server processes on each fleet instance. (You can calculate this based on (1) the game server container groups per instance and (2) the number of game server processes that run in each container group.) The number of cncurrent game servers per instance tells you what the impact is of adding or removing each fleet instance. For example, if your container fleet runs 1 game server process in each game server container group, and each fleet instance holds 100 game server containers groups, you increase or decrease your fleet's capacity to host concurrent game sessions by increments of 100. If each game session has 10 player slots, then you increase or decrease your fleet's capacity to host players by increments of 1000.
With container fleets, you can use any of the capacity scaling methods provided by Amazon GameLift Servers. These include:
+ Set fleet capacity manually by setting a desired fleet instance count.
+ Set up automatic scaling by targeting a desired buffer of available instances (target tracking). This method automatically maintains a certain amount of idle hosting resources so that incoming players can get into games quickly. As player demand increases or decreases, the size of this buffer is continually adjusted.
+ Set up automatic scaling with custom scaling rules (advanced feature). This method lets you scale based on fleet metrics that you choose.
### Game client/server connections
With Amazon GameLift Servers managed fleets, game clients connect directly to your cloud-hosted game servers. When a game client asks to join a game, Amazon GameLift Servers finds a game session and provides connection information (IP and port) to the game client. You can control external access to fleet instances by opening certain port ranges (inbound permissions) for the fleet. Inbound permissions determine which ports are open to incoming traffic. You can quickly shut down all ports, limit to a few, or open all ports.
Managed container fleets require an additional setting that allows access to processes that are running in a container. When you create a container definition, you specify a set of ports, one for each process that takes a connection. This includes:
+ All game server processes that will run concurrently in the game server container. All game server processes must allow game clients to connect in order to join a game session.
+ Any process in a support container that an external source needs to connect to. For example, you could remotely connect to a testing app.
When you set the internal-facing container port settings, Amazon GameLift Servers uses them to calculate the external-facing inbound permissions that game clients and other applications can connect to. Amazon GameLift Servers also manages the mapping between inbound permissions and individual container ports that gives players access to a game session in a container. This internal mapping provides a layer of security by protecting your game servers from direct access to the container ports. You have the option to customize a fleet's external-facing port settings as needed. For more information about manually setting container fleet ports, see [Configure network connections](containers-design-fleet.md#containers-custom-network).
You can modify a container fleet's port settings at any time. This change requires a fleet update deployment.
The following diagram illustrates the role of port connections across a container fleet. As shown, you set ports on individual containers, and Amazon GameLift Servers uses this information to configure enough ports on the fleet instance to map to each container port. Both the external-facing instance inbound permissions and the internal-facing connection ports are calculated by Amazon GameLift Servers for your fleet, unless you choose to set them manually.
![\[An illustration of port settings for a container fleet. Port mappings enable external traffic to connect to a fleet instance and get access to an individual container on the instance.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/container_design_networking.png)
### Container logging
In managed container fleets, the standard output (and standard error) streams are captured for all containers. This includes your game server's game session logs. You can configure a container fleet to use one of several options to handle output streams:
+ Save container output as an Amazon CloudWatch log stream. Each log stream references the fleet ID and container. If you choose this logging option for the fleet, you specify a CloudWatch log group, which organizes all the log streams from the fleet. You can then use CloudWatch features to search and analyse log data as needed.
+ Save container output to an Amazon Simple Storage Service (Amazon S3) storage bucket. You can view, share, or download the content as needed.
+ Turn off logging. In this scenario, container output isn't saved.
Amazon GameLift Servers sends log data from managed container fleets to the CloudWatch or Amazon S3 services in your AWS account. To view your data, use the AWS Management Console or other tools by signing in to your AWS account and working with the individual services. You extend limited access to Amazon GameLift Servers to take these actions by creating a service role for your container fleets.
You can modify a container fleet's logging configuration at any time. This change requires a fleet update deployment.
### Container fleets and the Amazon GameLift Servers Agent
A commonly used container architecture runs a single process in each container. In an Amazon GameLift Servers container fleet, the game server container group has one game server container, which runs one game server process. With this architecture, Amazon GameLift Servers manages the lifecycle of the single game server process in each game server container group on a fleet instance.
If you opt to build a container architecture that runs multiple game server processes in each game server container group, you need a way to manage the lifecycle of all processes. This includes tasks such as starting, shutting down, and replacing processes as needed, managing a desired number of processes to run concurrently, and handling failure states.
You can choose to use the Amazon GameLift Servers Agent for these tasks. For a container fleet, the Agent implements runtime instructions that specify which executables to run (and how many), provide launch parameters, and set rules around game server activation. For example, runtime instructions might tell the Agent to maintain ten game server processes for production use, and one game server process with special launch parameters for testing.
To use the Agent with your container fleets, add the Agent to your container image and include a set of runtime instructions. For more information about the Agent, see [Work with the Amazon GameLift Servers Agent](integration-dev-iteration-agent.md).
# Create an Amazon GameLift Servers managed container fleet
Create an Amazon GameLift Servers managed container fleet to deploy and host your containerized game server in the AWS Cloud. When you create a container fleet, specify container group definitions that specify one or more container images (at least one that includes your game server build) and configuration settings.
When you create a new managed container fleet resource, you immediately initiate the first phase of fleet creation. Managed fleet creation passes through several phases as Amazon GameLift Servers provisions an EC2 instance, installs a runtime environment, deploys your container groups onto the instance, and begins launching game server processes. Depending on the runtime environment your game server build requires, Amazon GameLift Servers deploys the latest version of the Amazon Machine Image (AMI) at the time of fleet creation (and all future instances in the fleet will use the same version). You can monitor a fleet's status in the console or using the AWS Command Line Interface (AWS CLI). When a fleet is ready to host game sessions, the status changes to `ACTIVE`. For help with fleet creation issues, see [Debug Amazon GameLift Servers fleet issues](fleets-creating-debug.md).
You can opt to create an empty container fleet and then add or update the fleet's container group definitions later. If you create a fleet without a container group definition, the fleet will not reach active status.
**Note**
As a best practice, we recommend replacing your fleets every 30 days to maintain a secure and up-to-date runtime environment for your hosted game servers. This requires creating a new fleet and migrating player traffic to it. For more guidance, see [Security best practices for Amazon GameLift Servers](security-best-practices.md).
Use the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/) or the AWS Command Line Interface (AWS CLI) to create a container fleet.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), select the AWS Region where you want to create the fleet. The container group definitions must be in the same region where you want to create the fleet.
Open the console’s left navigation bar and choose **Managed containers: Fleets**. On the Fleets page, choose **Create container fleet**.
**Step 1: Define managed container fleet details**
1. In the **Container fleet details** section, enter a fleet description.
1. Specify an **IAM role** for the fleet. This role has permissions that Amazon GameLift Servers must have to manage the container fleet on your behalf. For help creating the required service role, see [Set up an IAM service role for Amazon GameLift Servers](setting-up-role.md).
1. Choose a **Log configuration** option. The CloudWatch option is selected by default. Provide the required information based on your selected option.
1. Add container groups to the fleet. This is an optional step. You can choose to create a fleet without a container group with a plan to add them later. A fleet without any container groups won't deploy any fleet instances and can't host any games yet, but the fleet resource is created.
+ Select a game server container group definition. Optionally specify the version of the definition that you want to deploy. If you don’t specify the version number, Amazon GameLift Servers automatically uses the latest version.
+ Optionally add a per-instance container group definition and version. If you don’t specify the version number, Amazon GameLift Servers automatically uses the latest version.
1. In the **Additional details**, you can set some optional customizations. None of these settings are required to create the container fleet.
**Step 2: Define instance details**
1. In **Instance deployment**, select one or more remote locations to deploy instances to. The home Region is automatically selected (this is the Region that you're creating the fleet in). If you select additional locations, fleet instances are also deployed in these locations.
**Important**
To use Regions that aren't enabled by default, enable them in your AWS account.
Fleets with Regions that aren't enabled that you created before February 28, 2022 are not affected by this requirement.
To create new multi-location fleets or to update existing multi-location fleets, first enable any Regions or Local Zones that you choose to use.
For more information about Regions that aren't enabled by default and how to enable them, see [Managing AWS Regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) in the *AWS General Reference*. See [Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) in the *AWS Local Zones User Guide*.
1. Select an **Instance configuration** for the fleet. The console automatically calculates the minimum vCPU and memory required (based on the total limits you set for each container group). It filters the complete list of available instance types base on resource requirements and the locations you entered. You can add additional filters as needed.
For more information about choosing an instance type, see [Configure a container fleet](containers-design-fleet.md#containers-design-fleet-config). The size of the instance type you choose will impact how game server container groups are packed onto each fleet instance. Depending on your choice, consider reviewing your setting for desired game server container groups per instance.
**Step 4: Review and create**
+ Review your fleet configuration settings.
You can update the fleet's metadata and configuration at any time, regardless of fleet status. For more information, see [Update an Amazon GameLift Servers fleet configuration](fleets-editing.md). You can update fleet capacity after the fleet has reached ACTIVE status. For more information, see [Scaling game hosting capacity with Amazon GameLift Servers](fleets-manage-capacity.md). You can also add or remove remote locations.
When you're finished reviewing, choose **Create**.
If your request is successful, the console displays the detail page for the new fleet resource. Initially the status is `NEW`, as Amazon GameLift Servers starts the fleet creation process. You can track the new fleet's status on the **Fleets** page. A fleet is ready to host game sessions when it reaches status `ACTIVE`.
------
#### [ AWS CLI ]
To create a container fleet with the AWS CLI, open a command line window and use the `create-container-fleet` command. For more information about this command, see [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-container-fleet.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-container-fleet.html) in the *AWS CLI Command Reference*.
The example `create-container-fleet` request shown below creates a new container fleet with the following characteristics:
+ The ContainerGroupsConfiguration specifies a game server container group definition only: `MyAdventureGameContainerGroup`. The number of game server container groups that will be deployed to each fleet instance is calculated by Amazon GameLift Servers.
+ The fleet uses c5.large On-Demand instances by default.
+ By default, the fleet opens a set of connection ports and inbound permissions ports as calculated by Amazon GameLift Servers. It deploys container groups to the following locations:
```
aws gamelift create-container-fleet \
--fleet-role-arn arn:aws:iam::MyAccount:role/MyContainersRole \
--game-server-container-group-definition-name "rn:aws:gamelift:us-west-2:111122223333:containergroupdefinition/MyAdventureGameContainerGroup:2" \
```
If the create-fleet request is successful, Amazon GameLift Servers returns a set of fleet attributes that includes the configuration settings you requested and a new container fleet ID. Amazon GameLift Servers then sets the fleet status and location statuses to **New** and initiates the fleet activation process. You can track the fleet's status and view other fleet information using these CLI commands:
+ [describe-fleet-events](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-events.html)
+ [describe-container-fleet](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-container-fleet.html)
+ [describe-fleet-capacity](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-capacity.html)
+ [describe-fleet-port-settings](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-port-settings.html)
+ [describe-fleet-utilization](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-utilization.html)
+ [describe-fleet-location-capacity](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-location-capacity.html)
+ [describe-fleet-location-utilization](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-location-utilization.html)
You can change the fleet's capacity and other configuration settings as needed using these commands:
+ [update-container-fleet](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-container-fleet.html)
+ [update-fleet-capacity](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-fleet-capacity.html)
+ [update-fleet-port-settings](https://docs.aws.amazon.com/cli/latest/reference/gamelift/update-fleet-port-settings.html)
+ [create-fleet-locations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-fleet-locations.html)
+ [delete-fleet-locations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-fleet-locations.html)
------
# Create a container group definition for an Amazon GameLift Servers container fleet
A container group definition describes how to deploy your containerized game server applications to a container fleet. It's a blueprint that tells Amazon GameLift Servers what container images to deploy to the fleet and how to run them. When you create a container fleet, you specify the container group definitions to deploy to the fleet. For more information about container groups, see [Container fleet components](containers-howitworks.md#containers-howitworks-components).
## Before you start
Tips on what to do before you start creating a container group definition:
+ Finalize your container images and push them to an Amazon Elastic Container Registry (Amazon ECR) repository in the same AWS Region where you plan to create the container group. Amazon GameLift Servers captures a snapshot of each image at the time you create container group definition, and uses the snapshot when deploying to a container fleet. See [Build a container image for Amazon GameLift Servers](containers-prepare-images.md).
+ Create your container definitions as JSON files. A container group definition includes one or more container definitions. You can use the JSON files if you create a container group definition using the AWS CLIfor Amazon GameLift Servers.
+ Verify that your AWS user has IAM permissions to access the Amazon ECR repository. See [IAM permission examples for Amazon GameLift Servers](gamelift-iam-policy-examples.md).
## Create a game server container group definition
A game server container group runs your game server software. A game server container group has one game server container, which runs the game server executable. It can also have one or more support containers to run additional software to support your game server. (These are sometimes referred to as “sidecar” containers.)
This topic describes how to create a simple game server container group definition using the Amazon GameLift Servers console or AWS CLI tools. For more detailed information on optional features, see [Customize an Amazon GameLift Servers container fleet](containers-design-fleet.md).
**Note**
You can change most container group definition and container definition settings after creating them. If you make changes to a container definition, Amazon GameLift Servers captures a new snapshot of the updated container images.
**To create a simple game server container group definition:**
The following instructions describe how to create a container group definition with the minimal required parameters and using the Amazon GameLift Servers default values.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), select the AWS Region where you want to create the container group.
Open the console’s left navigation bar and choose **Managed containers: Group definitions**. On the Container groups definition page, choose **Create group definition**.
**Step 1: Define container group definition details**
1. Enter a container group definition name. The name must be unique to the AWS account and Region.
1. Select the **Game server** container group type.
1. For **Total memory limit**, enter the maximum memory resources to make available for all containers in the container group. For help calculating this value, see [Set resource limits](containers-design-fleet.md#containers-design-fleet-limits).
1. For **Total vCPU limit**, enter the maximum computing power to make available for all containers in the container group. For help calculating this value, see [Set resource limits](containers-design-fleet.md#containers-design-fleet-limits).
**Step 2: Add container definitions**
At minimum, a game server container group has one game server container. In the console, the first container definition you create is the game server container. This step describes how to define the minimum required settings for a game server container definition.
1. Enter a container definition **Name**. Each container defined for the group must have a unique name value.
1. Link to a container image with your game server build. Enter the **Amazon ECR image URI** for a container image in a public or private repository. You can use any of the following formats:
+ Image URI only: `[AWS account].dkr.ecr.[AWS Region].amazonaws.com/[repository ID]`
+ Image URI \$1 digest: `[AWS account].dkr.ecr.[AWS Region].amazonaws.com/[repository ID]@[digest]`
+ Image URI \$1 tag: `[AWS account].dkr.ecr.[AWS Region].amazonaws.com/[repository ID]:[tag]`
1. Specify the Amazon GameLift Servers **Server SDK version** that the game server build uses. For a container fleet, this value must be 5.2.0 or greater.
1. In **Internal container port range**, set the protocol and define a port range. The range size must be greater than the number of concurrent game server processes that will run in this container. If the game server container runs only one server process per container, this port range only needs a few ports. For more details, see [Configure network connections](containers-design-fleet.md#containers-custom-network).
1. Add more containers as needed to run additional support software. Additional containers are automatically designated support containers. A game server container group can have only one game server containers and up to eight support containers. Provide the following minimal required settings:
+ Container definition **Name**
+ **ECR image URI**.
+ **Internal container ports** (Include this only if the container has processes that need network access.)
**Step 3: Configure dependencies**
+ If your container group definition has more than one container, you can optionally set dependencies between the containers. For more information, see [Set container dependencies](containers-design-fleet.md#containers-design-fleet-dependencies).
**Step 3: Review and create**
1. Review all your container group definition settings. Use **Edit** to make changes to any section, including each of your container definitions for the group.
1. When you're finished reviewing, choose **Create**.
If your request is successful, the console displays the detail page for the new container group definition resource. Initially the status is `COPYING`, as Amazon GameLift Servers starts taking snapshots of all the container images for the group. When this phase is complete, the container group definition status changes to `READY`. A container group definition must be in `READY` status before you can create a container fleet with it.
------
#### [ AWS CLI ]
When you use the AWS CLI to create a container group definition, maintain your container definition configurations in a separate `JSON` file. You can reference the file in your CLI command. See [Create a container definition `JSON` file](#containers-definitions-create) for schema examples.
**Create a container group definition**
To create a new container group definition, use the `create-container-group-definition` CLI command. For more information about this command, see [create-container-group-definition](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-container-group-definition.html) in the *AWS CLI Command Reference*.
This example illustrates a request for a game server container group definition. It assumes that you’ve created a JSON file with the container definitions for this group.
```
aws gamelift create-container-group-definition \
--name MyAdventureGameContainerGroup \
--operating-system AMAZON_LINUX_2023 \
--container-group-type GAME_SERVER \
--total-memory-limit-mebibytes 4096 \
--total-vcpu-limit 1 \
--game-server-container-definition file://MyAdventureGameContainers.json
```
------
## Create a container definition `JSON` file
When you create a container group definition, you also define the containers for the group. A container definition specifies the Amazon ECR repository where the container image is stored, and optional configurations for network ports, limits for CPU and memory usage, and other settings. We recommend creating a single `JSON` file with the configurations for all the containers in a container group. Maintaining a file is useful for storing, sharing, version tracking these critical configurations. If you use the AWS CLI to create your container group definitions, you can reference the file in the command.
**To create a container definition**
1. Create and open a new `.JSON` file. For example:
```
[~/work/glc]$ vim SimpleServer.json
```
1. Create a separate container definition for each of the containers for the group. Copy the following example content and modify it as needed for your containers. For details on the syntax of a container definition, see [ContainerDefinitionInput](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerDefinitionInput.html) in the *Amazon GameLift Servers API Reference*.
1. Save the file locally so that you can refer to it in an AWS CLI command.
### Example: Game server container definition
**Example**
This example describes the essential container for your game server container group. The essential replica container includes your game server application, the Amazon GameLift Servers Agent, and can include other supporting software for your game hosting. The definition must include a name, image URI, and a port configuration. This example also sets some container-specific resource limits.
```
{
"ContainerName": "MyAdventureGameServer",
"ImageUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/gl-containers:myadventuregame-server",
"PortConfiguration": {
"ContainerPortRanges": [
{
"FromPort": 2000,
"Protocol": "TCP",
"ToPort": 2010
}
]
},
"ServerSdkVersion": "5.2.0"
}
```
# Amazon GameLift Servers Anywhere fleets
Use Anywhere fleets when you want to take advantage of Amazon GameLift Servers features with your own hosting resources. Anywhere fleets are commonly used as test environments for iterative development or alongside managed fleets in a hybrid hosting solution.
An Anywhere fleet consists of a set of compute resources (virtual or physical) that you supply and manage. Computes can reside in any geographic location with connectivity, from a local laptop to remote outposts. When setting up an Anywhere fleet, you add computes to the fleet by registering them through Amazon GameLift Servers. Each compute is registered with its IP address (or DNS name) so that Amazon GameLift Servers can establish a connection with it.
You deploy game server software to an Anywhere fleet by installing it on each compute and launching game server processes. Each launched game server process establishes a connection to the Amazon GameLift Servers service and reports readiness to host a game session. You can use your existing configuration management and deployment tooling to handle initial deployment and host management tasks. There are a few additional tasks required for use with Amazon GameLift Servers, including:
+ Register and deregister computes to add or remove them from the fleet.
+ Maintain up-to-date authentication tokens on all computes. Server processes on the compute use them when connecting to the Amazon GameLift Servers service.
**Note**
Optionally deploy your Anywhere fleet with the Amazon GameLift Servers Agent to automate these key management tasks. See [Work with the Amazon GameLift Servers Agent](integration-dev-iteration-agent.md).
See these topics about how to set up and maintain Anywhere fleets:
+ [Development roadmap for hosting with Amazon GameLift Servers Anywhere](gamelift-roadmap-anywhere.md)
+ [Development roadmap for hybrid hosting with Amazon GameLift Servers](gamelift-roadmap-hybrid.md)
+ [Set up for iterative development with Amazon GameLift Servers Anywhere](integration-dev-iteration.md)
+ [Create an Amazon GameLift Servers Anywhere fleet](fleets-creating-anywhere.md)
+ [Update an Amazon GameLift Servers fleet configuration](fleets-editing.md)
## Anywhere fleet creation workflow
For Anywhere fleets, Amazon GameLift Servers sets up the fleet resource only. You set up and register computes with the fleet, and you install game server software and start game server processes to host game sessions.
1. Amazon GameLift Servers creates the fleet resource in the fleet's home Region. Fleet status and custom location status are set to **New**.
1. Amazon GameLift Servers begins writing events to the fleet event log.
1. After the fleet resource is created. Amazon GameLift Servers sets the fleet status to **Active**. At this point, you can register new computes with the fleet.
# Create an Amazon GameLift Servers Anywhere fleet
This topic describes how to create an Amazon GameLift Servers Anywhere fleet. With an Anywhere fleet, you can use core Amazon GameLift Servers game session management features while hosting game sessions with your own compute resources. Create an Anywhere fleet for your on-premises hardware or other cloud-based resources.
Anywhere fleets are commonly used alongside Amazon GameLift Servers managed fleets in a hybrid hosting solution. They also provide useful test environments when developing a game for hosting with Amazon GameLift Servers. See these topics to learn more about when and how to incorporate Amazon GameLift Servers Anywhere fleets into a game hosting solution:
+ [Hybrid hosting](gamelift-intro-flavors.md#gamelift-intro-flavors-hosting-hybrid)
+ [Deploy hosting fleets for Amazon GameLift Servers](fleets-intro.md)
+ [Set up for iterative development with Amazon GameLift Servers Anywhere](integration-dev-iteration.md)
Because Anywhere fleets are self-managed, setting up a fleet requires some additional work. To get an Anywhere fleet ready to host game sessions and players, you need to complete the following tasks:
**Topics**
+ [Before you start](#fleet-anywhere-start)
+ [Create a custom location](#fleet-anywhere-location)
+ [Create an Anywhere fleet](#fleet-anywhere-create)
+ [Add a compute to the fleet](#fleet-anywhere-compute)
+ [Start a game server](#fleet-anywhere-process)
## Before you start
Before creating an Anywhere fleet, do the following tasks. For more detailed guidance, see the [Development roadmap for hosting with Amazon GameLift Servers Anywhere](gamelift-roadmap-anywhere.md) or [Development roadmap for hybrid hosting with Amazon GameLift Servers](gamelift-roadmap-hybrid.md).
+ **Integrate your game server code with the Amazon GameLift Servers server SDK version 5.x (or higher).** You don't need to complete all game integration tasks, just those required for a game server build. A common practice is to set up your local machine as an Anywhere fleet and use a command line interface to test your game server integration (see [Set up local testing with Amazon GameLift Servers Anywhere](integration-testing.md)). You can incorporate additional components (such as an Amazon GameLift Servers enabled game client) as your develop them.
+ **Package your game server software for installation onto your Anywhere fleet computes.** The package should include your integrated game server build and all support software needed to run your game server.
+ **Decide whether to use the Amazon GameLift Servers Agent with your Anywhere fleet.** The Agent is an on-compute process management tool that automates some of the key tasks related to managing server processes and computes for use with Amazon GameLift Servers. For more information, see [Work with the Amazon GameLift Servers Agent](integration-dev-iteration-agent.md).
## Create a custom location
Create a custom location to represent the physical location of your compute resources. When creating an Anywhere fleet, you must have at least one custom location already defined. You can create additional custom locations and add them to an existing fleet at any time.
**To create a custom location**
Use either the Amazon GameLift Servers console or the AWS Command Line Interface (AWS CLI) to create a custom location.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), use the navigation pane to open the **Locations** page. Choose **Create location** to open the Create dialog box.
1. In the dialog box, enter a **Location name**. As a best practice, use a name that describes a meaningful location for a set of compute resources. It might be geographic locations, a data center name, or other location identifier. Amazon GameLift Servers appends the name of your custom location with **custom-**.
1. (Optional) Add tags to your custom location. 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. Choose **Create**.
------
#### [ AWS CLI ]
Create a custom location using the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-location.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-location.html) command. Provide a `location-name` value, which must start with `custom-`. As a best practice, use a name that describes a meaningful location for a set of compute resources. It might be geographic locations, a data center name, or other location identifier.
```
aws gamelift create-location \
--location-name custom-location-1
```
Output
```
{
"Location": {
"LocationName": "custom-location-1",
"LocationArn": "arn:aws:gamelift:us-east-1:111122223333:location/custom-location-1"
}
}
```
------
## Create an Anywhere fleet
Create an Anywhere fleet for a set of compute resources that you own. A new Anywhere fleet starts empty; you add computes to the fleet by registering them.
On creation, a new Anywhere fleet quickly moves through fleet statuses from `NEW` to `ACTIVE`. You can add computes to the fleet after it reaches `ACTIVE`.
**To create an Anywhere fleet**
Use either the Amazon GameLift Servers console or the AWS Command Line Interface (AWS CLI) to create an Anywhere fleet.
------
#### [ Console ]
In the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift/), use the navigation pane to open the **Fleets** page. Choose **Create fleet** to start the fleet creation workflow.
**Step 1 Choose compute type**
Select the **Anywhere** option and choose **Next**.
**Step 2 Define fleet details**
In this step, specify some key fleet-wide settings.
1. Fill out the **Fleet details** section:
1. Enter a fleet **Name**. We recommend using a fleet naming pattern that makes it easier to identify fleet types when viewing lists of fleets.
1. Provide a short **Description** of the fleet.
1. Set these optional **Additional details** as needed. You can update these fleet settings later.
1. When creating a fleet for production or pre-prod testing, use this setting to specify a per-hour **Cost** value for the fleet's computes. Amazon GameLift Servers can use this information during the game session placement process to select hosting resources based on cost.
1. If you want to combine metric data for this fleet and others, specify a **Metric group** name. Use the same metric group name for all fleets that you want to combine together. View metrics for the metric group to see the aggregated data.
1. Add optional tags to your custom location. 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. Choose **Next** to continue the workflow.
**Step 3 Select custom locations**
In this step, identify the physical location of the computes that you plan to add to this fleet. You can specify one or more locations now, and you can add or remove locations later as needed.
1. In **Custom locations**, select one or more locations for the fleet's computes. The list includes all custom locations that have been defined in your currently selected AWS Region. To define a new custom location that you want to add to the fleet, choose **Create location**.
1. Choose **Next** to continue the workflow.
**Step 4 Review and create**
Review your settings before creating the fleet.
When you're ready to deploy the new fleet, choose **Create**. Amazon GameLift Servers immediately begins the fleet activation process, assigning a unique ID and placing the fleet in `NEW` status. You can track the fleet's progress on the **Fleets** page.
------
#### [ AWS CLI ]
Use the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-fleet.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-fleet.html) command to create a fleet of compute type `ANYWHERE`. Provide a name and at least one custom location. Amazon GameLift Servers creates the Anywhere fleet resource in your current default AWS Region (or you can add a --region tag to specify a different AWS Region).
The following example request creates a new fleet with the minimal required settings. Replace `FleetName` and `custom-location` with your own information.
```
aws gamelift create-fleet \
--name FleetName \
--compute-type ANYWHERE \
--locations "Location=custom-location"
```
Example response
```
{
"FleetAttributes": {
"FleetId": "fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"FleetArn": "arn:aws:gamelift:us-west-2:111122223333:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"Name": "HardwareAnywhere",
"CreationTime": "2023-02-23T17:57:42.293000+00:00",
"Status": "ACTIVE",
"MetricGroups": [
"default"
],
"CertificateConfiguration": {
"CertificateType": "DISABLED"
},
"ComputeType": "ANYWHERE"
}
}
```
On creation, a new Anywhere fleet quickly moves to fleet status `ACTIVE`. You can add computes to the fleet after it reaches `ACTIVE`.
Notice that the response doesn't include the fleet locations. You can retrieve full fleet details by calling [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-attributes.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-attributes.html) and [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-location-attributes.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-location-attributes.html).
------
## Add a compute to the fleet
To add a compute resource to a fleet and get it ready to host game sessions, do the following tasks:
+ Register the compute with the fleet. Registration tells Amazon GameLift Servers what physical hosting resources are part of the fleet.
+ Request an authentication token for the compute. Each game server that runs on the compute needs this token to connect to the Amazon GameLift Servers service. Authentication tokens are temporary and must be regularly refreshed.
**Note**
If you're deploying your game server software with the Amazon GameLift Servers Agent, you can skip this step. The Agent automatically registers each compute and maintains a valid authentication token for the compute. See [Work with the Amazon GameLift Servers Agent](integration-dev-iteration-agent.md).
You can register a compute and request an authentication token by using the AWS CLI or making programmatic calls to the AWS SDK for Amazon GameLift Servers. These actions are not available through the Amazon GameLift Servers console.
As a best practice, we recommend automating both of these tasks by adding a startup script to each compute. The startup script automatically calls both the `register-compute` and `get-compute-auth-token` commands. You can also automate tasks to regularly refresh the auth token throughout the life of the compute and deregister the compute on shut down.
Each of the startup actions returns compute-specific values that you need to store on the compute. When a game server process launches on the compute, it must pass these values as server parameters when initializing a connection with the Amazon GameLift Servers service (see [ServerParameters](integration-server-sdk5-cpp-datatypes.md#integration-server-sdk5-cpp-dataypes-serverparameters) in the server SDK reference). We recommend that you set these compute-specific values (or their stored locations) as environment variables. If you're using the Amazon GameLift Servers Agent, this task is handled for you. The compute-specific values are as follows:
+ `register-compute` returns a value for `GameLiftServiceSdkEndpoint`. Set this value to the `webSocketUrl` server parameter.
+ `compute-auth-token` returns the authentication token. Set this value to the `authToken` server parameter.
------
#### [ AWS CLI ]
The following instructions describe how manually submit each request using the AWS CLI.
**To register a compute**
Call [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/register-compute.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/register-compute.html) to register a compute. Identify the ID of the fleet to add the compute to. Provide the following compute information: a meaningful name, IP address, and location. The compute's location must be a custom location that's already associated with the fleet. If you want to use a different custom location, use the Amazon GameLift Servers console to update the fleet or call the AWS CLI command [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-fleet-locations.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-fleet-locations.html) to add a custom location to the fleet.
In the following example, replace the placeholder values for your compute and fleet. The `fleet-id` value is returned when you create an Anywhere fleet. You can retrieve full fleet details by calling [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-attributes.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-attributes.html) and [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-location-attributes.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-location-attributes.html).
```
aws gamelift register-compute \
--compute-name HardwareAnywhere \
--fleet-id arn:aws:gamelift:us-east-1:111122223333:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa \
--ip-address 10.1.2.3 \
--location custom-location-1
```
Example output
```
{
"Compute": {
"FleetId": "fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"FleetArn": "arn:aws:gamelift:us-west-2:111122223333:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"ComputeName": "HardwareAnywhere",
"ComputeArn": "arn:aws:gamelift:us-west-2:111122223333:compute/HardwareAnywhere",
"IpAddress": "10.1.2.3",
"ComputeStatus": "Active",
"Location": "custom-location-1",
"CreationTime": "2023-02-23T18:09:26.727000+00:00",
"GameLiftServiceSdkEndpoint": "wss://us-west-2.api.amazongamelift.com"
}
}
```
**To request an authentication token**
Call [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/get-compute-auth-token.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/get-compute-auth-token.html) to request a valid authentication token. register a compute. Identify the fleet ID and compute name.
In the following example, replace the placeholder values for your compute and fleet. The `fleet-id` value is returned when you create an Anywhere fleet. You can retrieve full fleet details by calling [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-attributes.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-fleet-attributes.html). To find compute information, call [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/list-compute.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/list-compute.html) with the fleet ID to see all computes that are registered to the fleet.
```
aws gamelift get-compute-auth-token \
--fleet-id arn:aws:gamelift:us-east-1:111122223333:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa \
--compute-name HardwareAnywhere
```
Example output
```
{
"FleetId": "fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"FleetArn": "arn:aws:gamelift:us-east-1:111122223333:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"ComputeName": "HardwareAnywhere",
"ComputeArn": "arn:aws:gamelift:us-east-1:111122223333:compute/HardwareAnywhere",
"AuthToken": "0c728041-3e84-4aaa-b927-a0fb202684c0",
"ExpirationTimestamp": "2023-02-23T18:47:54+00:00"
}
```
------
## Start a game server
After you've created an Anywhere fleet and added one or more computes to the fleet, you're ready to start running your game servers.
**Step 1 Install your game server software**
Get your game server build and all dependent software installed onto each compute in your Anywhere fleet. The game server build must be integrated with Amazon GameLift Servers server SDK version 5.x (or higher) with the minimum required functionality to communicate with the Amazon GameLift Servers service.
**Step 2 Get your computes ready to run a game server**
Ensure that each compute is registered and has a valid authentication token. If you're using scripts to manage these tasks, make sure that the scripts run on each compute before starting any game server processes.
If you've deployed the Amazon GameLift Servers Agent with your game server software, make sure that the Agent executable launches.
**Step 3 Launch a game server process**
Run an instance of your game server executable on a compute. If your game server build is properly integrated, the game server process calls the server SDK action `InitSDK()` with a set of valid server parameters. When the server process is ready to host a game session, it calls `ProcessReady()`.
If you deployed your game server software with the Amazon GameLift Servers Agent, you can skip this step. The Agent automatically launches game server processes based on the runtime instructions you provide.
You can monitor progress by viewing server process metrics for activating and active server processes. See [Amazon GameLift Servers metrics for fleets](monitoring-cloudwatch.md#gamelift-metrics-fleet). If your game server process fails to initialize, verify that the process is retrieving the right server parameter values for the compute it's running on.
# Build a hybrid hosting solution
A hybrid hosting solution combines multiple sources of game hosting resources to host your game, including Amazon GameLift Servers managed fleets that run in the AWS Cloud and resources that you supply and manage on your own. This topic describes some common patterns for building a hybrid solution, and provides tips on how to successfully combine self-managed game hosting with cloud-based game hosting managed by Amazon GameLift Servers.
## Common hybrid patterns
+ **Cost optimization**: Use the most cost-effective fleet type for each scenario, such as Anywhere fleets for baseline capacity and managed fleets for peak demand.
+ **Geographic flexibility**: Deploy managed fleets in high-traffic AWS Regions and Anywhere fleets where you have existing infrastructure or specific compliance requirements.
+ **Risk mitigation**: Reduce dependency on any single hosting approach by distributing load across multiple fleet types and providers.
+ **Gradual migration**: Transition from on-premises or other hosting solutions to AWS gradually while maintaining service continuity.
**Development and production split**
Use different fleet types for development and production environments:
+ **Development**: Anywhere fleets for cost-effective development and testing
+ **Production**: Managed Amazon EC2 or container fleets for scalable, reliable production hosting
### Regional optimization
Optimize fleet types based on AWS Regions characteristics:
+ **High-traffic AWS Regions**: Managed fleets with auto-scaling for variable demand
+ **Specialized AWS Regions**: Anywhere fleets for compliance, data sovereignty, or existing infrastructure
### Capacity tiering
Use different fleet types for different capacity tiers:
+ **Baseline capacity**: Anywhere fleets or reserved instances for predictable load
+ **Burst capacity**: Managed fleets with auto-scaling for peak demand
+ **Overflow capacity**: Spot instances or additional AWS Regions for extreme peaks
## Implementation considerations
When building a hybrid solution, consider these key factors:
Game session queue configuration
Configure your game session queues to include all fleet types and set appropriate priorities and latency preferences to ensure optimal placement across your hybrid infrastructure.
Monitoring and observability
Implement comprehensive monitoring across all fleet types to maintain visibility into performance, capacity, and costs across your hybrid solution.
Operational complexity
Account for the increased operational complexity of managing multiple fleet types, including different deployment processes, monitoring tools, and troubleshooting procedures.
Network connectivity
Ensure reliable network connectivity between your different hosting environments, especially for Anywhere fleets that may be on-premises or in different cloud providers.
## Getting started with hybrid hosting
To implement a hybrid hosting solution:
1. **Start simple**: Begin with a single fleet type and add others gradually as your requirements become clearer.
1. **Plan your architecture**: Design your hybrid architecture based on your specific requirements for cost, performance, compliance, and operational complexity.
1. **Configure queues**: Set up game session queues that span your different fleet types with appropriate priorities and placement strategies.
1. **Test thoroughly**: Test game session placement and failover scenarios across your hybrid infrastructure before going to production.
1. **Monitor and optimize**: Continuously monitor performance and costs across all fleet types and adjust your configuration as needed.
Tips
+ Use the same game client and server components with both managed and self-managed hosting resources. Provide a unified player experience across all hosting resources.
+ Use the same FlexMatch matchmakers to place matches across all hosting resources.
+ Centrally manage your hybrid hosting resources together while you deploy them across the globe.
+ As player demand fluctuates, manage game session loads seamlessly across managed and self-managed resources.
+ With the Amazon GameLift Servers Agent, you can use the same tools to manage game server life cycles on all types of hosting resources.
+ Gather game and player metrics and logs across all hosting resources. Take advantage of Amazon GameLift Servers features and other AWS services to combine data and develop cohesive observability solutions.