Running a multiplayer game server used to mean renting a bare-metal box, writing your own matchmaking glue, and staying up at 2 a.m. when a session spike knocked a fleet offline. Amazon GameLift has quietly become the default way to skip that work: it handles fleet provisioning, session placement, and autoscaling for dedicated game servers, and as of August 2026 it sits inside a single AWS service that also covers GPU-based game streaming through GameLift Streams. This tutorial walks through deploying a real, working multiplayer game server on GameLift Servers, from packaging your build to load-testing session placement, with the exact CLI commands, IAM policies, and troubleshooting steps you need to get a fleet from “created” to “active” without guessing.
By the end you will have a deployable game server build running on a managed AWS fleet, a working game client that can request a session and connect to it, and a monitoring setup that tells you when something is about to break. We will also cover GameLift Anywhere for hosting on your own hardware while still using GameLift’s matchmaking and session APIs, since that free tier is one of the easiest ways to test this workflow without spinning up EC2 instances.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Amazon GameLift Actually Is in 2026
Amazon GameLift is AWS’s managed game backend service, and it now covers two distinct capabilities under one brand. GameLift Servers is the original dedicated-server hosting product: you upload a game server build, AWS provisions a fleet of EC2 instances (or lets you register your own hardware through GameLift Anywhere), and the service handles session placement, matchmaking, and autoscaling. GameLift Streams, added in March 2025, is a separate capability that streams games at up to 1080p and 60 frames per second to any device with a WebRTC-enabled browser, running on GPU instances instead of CPU-bound game server fleets.
This tutorial focuses on GameLift Servers, since that is the piece developers actually need when they are hosting a multiplayer game with authoritative server logic (think a battle royale, an FPS, or a co-op survival game). If you are building a game-streaming platform instead of a dedicated multiplayer backend, GameLift Streams is the relevant service, and AWS’s own reference architecture combines it with Lambda, API Gateway, S3, and CloudFront to deliver AAA titles in the browser.
GameLift Servers pricing was refreshed on AWS’s pricing pages as of August 20, 2026, and the GameLift Anywhere free tier currently includes 3,000 game sessions placed and 500,000 server connection minutes per month for 12 months, aggregated across all regions. That free tier is generous enough to build and test a complete multiplayer flow before you spend anything on managed EC2 fleets, which is why the steps below start with GameLift Anywhere before moving to a fully managed fleet.
Prerequisites and Versions
Before starting, get these tools and accounts in place. Version mismatches are the single biggest source of confusing GameLift errors, so pin these exactly where possible.
- An AWS account with billing enabled and an IAM user or role that is not the root account
- AWS CLI v2 (2.31 or later) installed and configured with
aws configure - Python 3.11+ or Node.js 20+ for the sample game server logic (this tutorial uses Python)
- The Amazon GameLift Server SDK for C++, C#, or Go, version 5.x (this tutorial uses the GameLift Server SDK 5 for a Linux Anywhere fleet)
- Docker 24+ if you plan to containerize the build for GameLift Anywhere or a managed Linux fleet
- A game client capable of making an HTTPS or WebSocket call (a simple Python or Node.js script is enough to test session requests)
- An AWS region that supports GameLift Servers — us-east-1, us-west-2, eu-west-1, ap-northeast-1, and ap-southeast-2 are common choices with full feature parity
You do not need a full game engine for this tutorial. GameLift only cares that your build is an executable that opens a network port, so we will use a minimal Python TCP echo-style server to demonstrate the full session lifecycle. Once the plumbing works, swapping in your actual Unreal Engine or Unity dedicated server build is a matter of pointing GameLift at a different executable, following the same lifecycle described in AWS’s GameLift developer guide.
Step 1: Set Up IAM Permissions for GameLift
Create a dedicated IAM policy rather than granting AdministratorAccess. GameLift needs permission to create fleets, builds, aliases, and game session queues, plus S3 access if you are uploading builds through the console rather than the CLI.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"gamelift:*",
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket",
"cloudwatch:PutMetricData",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}Save this as gamelift-policy.json and attach it to a new IAM user or role dedicated to this project:
aws iam create-policy \
--policy-name GameLiftTutorialPolicy \
--policy-document file://gamelift-policy.json
aws iam attach-user-policy \
--user-name gamelift-tutorial-user \
--policy-arn arn:aws:iam::YOUR_ACCOUNT_ID:policy/GameLiftTutorialPolicyScoping gamelift:* to a wildcard is acceptable for a tutorial project but tighten it before production. In a real deployment, split this into separate policies for build upload, fleet management, and session placement, and attach them to different roles so a compromised client credential cannot spin up new fleets.
Step 2: Write a Minimal GameLift-Aware Server
Every GameLift-hosted server process must call the GameLift Server SDK to signal readiness, accept player connections, and report health. Below is a minimal Python server using the GameLift Server SDK 5 that starts a process, registers it with GameLift, and activates a game session when GameLift assigns one.
import gamelift_server_sdk as gamelift
import socket
import threading
def on_start_game_session(game_session):
print(f"Starting session {game_session.game_session_id}")
gamelift.activate_game_session()
def on_process_terminate():
print("GameLift requested termination")
gamelift.process_ending()
def on_health_check():
return True
def run_tcp_listener(port):
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind(("0.0.0.0", port))
sock.listen(8)
while True:
conn, addr = sock.accept()
threading.Thread(target=handle_client, args=(conn,)).start()
def handle_client(conn):
data = conn.recv(1024)
conn.sendall(data)
conn.close()
if __name__ == "__main__":
PORT = 7777
params = gamelift.ServerParameters()
gamelift.init_sdk(params)
process_params = gamelift.ProcessParameters(
on_start_game_session=on_start_game_session,
on_process_terminate=on_process_terminate,
on_health_check=on_health_check,
port=PORT,
log_parameters=gamelift.LogParameters(["/local/game/logs"])
)
gamelift.process_ready(process_params)
run_tcp_listener(PORT)The important callbacks are on_start_game_session, which must call activate_game_session() within your configured timeout or GameLift will mark the process unhealthy, and on_health_check, which GameLift polls periodically to decide whether to keep routing sessions to this process. If your real game engine already runs its own game loop, wrap these calls around your existing server startup rather than replacing it.
Step 3: Package the Build
GameLift builds are zip archives (or, for containerized fleets, container images) containing your server executable and any dependencies it needs at runtime. Structure your build directory like this:
gamelift-build/
├── server.py
├── gamelift_server_sdk/
├── requirements.txt
└── install.shinstall.sh runs once when GameLift provisions a new instance, so use it to install Python dependencies rather than bundling a full virtual environment:
#!/bin/bash
pip3 install -r requirements.txtZip the directory and upload it to GameLift directly through the CLI, which uploads to an AWS-managed S3 bucket behind the scenes:
aws gamelift upload-build \
--name "tutorial-echo-server" \
--build-version "1.0.0" \
--build-root ./gamelift-build \
--operating-system AMAZON_LINUX_2023 \
--region us-east-1Watch for the returned BuildId in the JSON response. Builds move through a READY status once GameLift finishes validating and storing them, which usually takes one to three minutes for a small archive like this one. Check status with aws gamelift describe-builds --build-id YOUR_BUILD_ID before moving on.
Step 4: Create a Fleet
A fleet is the pool of EC2 instances that will run your build. GameLift Servers pricing is billed per instance-hour based on the instance type you choose, and AWS refreshed its published instance pricing page on August 20, 2026, so check current per-hour rates for your region before committing to a large fleet.
aws gamelift create-fleet \
--name "tutorial-echo-fleet" \
--build-id YOUR_BUILD_ID \
--ec2-instance-type c5.large \
--fleet-type ON_DEMAND \
--runtime-configuration '{
"ServerProcesses": [
{
"LaunchPath": "/local/game/server.py",
"Parameters": "",
"ConcurrentExecutions": 4
}
]
}' \
--ec2-inbound-permissions '[
{"FromPort": 7777, "ToPort": 7781, "IpRange": "0.0.0.0/0", "Protocol": "TCP"}
]' \
--region us-east-1ConcurrentExecutions controls how many game server processes run per instance. Four processes on a c5.large is a reasonable starting point for a lightweight server; CPU-heavy game logic will need fewer processes per instance and a larger instance type. Fleet creation typically takes 8 to 12 minutes as GameLift provisions instances, downloads your build, and runs health checks before flipping the fleet to ACTIVE.
Step 5: Try GameLift Anywhere Before Scaling Up
If you want to validate the full session flow without paying for managed EC2 instances, GameLift Anywhere lets you register your own machine (a laptop, a home server, or an existing container host) as a GameLift compute resource while still using GameLift’s matchmaking and session placement APIs. This is where that 3,000-session, 500,000-minute free tier applies.
aws gamelift create-location \
--location-name "custom-us-east-1"
aws gamelift create-fleet \
--name "tutorial-anywhere-fleet" \
--compute-type ANYWHERE \
--anywhere-configuration '{"Cost": "0.5"}' \
--locations '[{"Location": "custom-us-east-1"}]' \
--region us-east-1
aws gamelift register-compute \
--fleet-id YOUR_ANYWHERE_FLEET_ID \
--compute-name "dev-laptop-01" \
--ip-address "YOUR_PUBLIC_IP" \
--location "custom-us-east-1"Once registered, run your server executable locally and it behaves exactly like a managed instance from GameLift’s perspective: it calls the same SDK functions, accepts the same session activation calls, and shows up in the same monitoring dashboards. This is the fastest way to debug session activation logic before you pay for a fleet of EC2 instances that might just surface the same bug more slowly.
Step 6: Create an Alias
Aliases decouple your client-facing fleet reference from a specific fleet ID, which matters when you deploy a new build version and want to switch traffic without changing client code. Create one pointing at your active fleet:
aws gamelift create-alias \
--name "tutorial-production-alias" \
--routing-strategy '{"Type": "SIMPLE", "FleetId": "YOUR_FLEET_ID"}' \
--region us-east-1For blue-green style deployments, use a TERMINAL or weighted routing strategy instead of SIMPLE so you can shift a percentage of new sessions to a fresh fleet before fully cutting over. This matters more once you have real players connected, since a bad build push to a SIMPLE alias sends 100% of new sessions to the broken fleet immediately.
Step 7: Request a Game Session From the Client
Your game client calls the GameLift API (through the AWS SDK, not the Server SDK) to request a session and get connection info. This typically happens through a lightweight backend service rather than directly from the client, since exposing GameLift credentials in a game binary is a security risk.
import boto3
gl = boto3.client("gamelift", region_name="us-east-1")
response = gl.create_game_session(
AliasId="YOUR_ALIAS_ID",
MaximumPlayerSessionCount=8,
Name="match-001"
)
session = response["GameSession"]
print(f"IP: {session['IpAddress']}, Port: {session['Port']}")
player_response = gl.create_player_session(
GameSessionId=session["GameSessionId"],
PlayerId="player-12345"
)
print(f"PlayerSessionId: {player_response['PlayerSession']['PlayerSessionId']}")The client uses the returned IP address, port, and player session ID to connect directly to the game server process. GameLift’s job ends once it hands back connection info; the actual gameplay traffic goes straight between the client and your server instance, not through any GameLift proxy.
Step 8: Set Up FlexMatch for Skill-Based Matchmaking
Manually creating sessions works for testing, but real multiplayer games need matchmaking that groups players by skill, latency, or party size. FlexMatch, GameLift’s built-in matchmaker, handles this with a rule set you define in JSON.
{
"name": "tutorial-skill-match",
"ruleLanguageVersion": "1.0",
"playerAttributes": [
{"name": "skill", "type": "number", "default": 50}
],
"teams": [
{"name": "all", "minPlayers": 2, "maxPlayers": 8}
],
"rules": [
{
"name": "SkillGap",
"type": "distance",
"measurements": ["teams[all].players[*].attributes[skill]"],
"referenceValue": "avg(teams[all].players[*].attributes[skill])",
"maxDistance": 15
}
]
}aws gamelift create-matchmaking-rule-set \
--name "tutorial-skill-match" \
--rule-set-body file://ruleset.json
aws gamelift create-matchmaking-configuration \
--name "tutorial-matchmaker" \
--rule-set-name "tutorial-skill-match" \
--game-session-queue-arns "arn:aws:gamelift:us-east-1:YOUR_ACCOUNT:gamesessionqueue/tutorial-queue" \
--request-timeout-seconds 60 \
--acceptance-required falseThis ruleset groups two to eight players into a team, allowing a maximum skill gap of 15 points between any player and the team average. FlexMatch will keep searching for matches until the timeout expires, at which point it either widens acceptable ranges (if you configure expansion rules) or fails the match request back to your client.
Step 9: Configure Autoscaling
Autoscaling policies keep your fleet sized to actual demand rather than running a fixed number of instances around the clock. GameLift supports target-based scaling on the percentage of available game sessions.
aws gamelift put-scaling-policy \
--name "tutorial-autoscale" \
--fleet-id YOUR_FLEET_ID \
--policy-type TargetBased \
--target-configuration '{"TargetValue": 20}' \
--metric-name PercentAvailableGameSessionsA target value of 20 tells GameLift to keep roughly 20% of your fleet’s game session capacity free at all times, scaling instances up when utilization climbs above that and down when it drops. Set this lower (around 10%) for cost-sensitive workloads with predictable traffic, and higher (30% or more) for games with sudden spikes, like a launch event or a tournament, where you need headroom before new instances finish booting.
Step 10: Monitor With CloudWatch
GameLift publishes fleet metrics to CloudWatch automatically, including active game sessions, current player sessions, and instance count. Set an alarm on PercentAvailableGameSessions dropping too low, which signals your fleet is about to reject new session requests.
aws cloudwatch put-metric-alarm \
--alarm-name "gamelift-capacity-low" \
--namespace "AWS/GameLift" \
--metric-name "PercentAvailableGameSessions" \
--dimensions Name=FleetId,Value=YOUR_FLEET_ID \
--statistic Average \
--period 60 \
--evaluation-periods 3 \
--threshold 5 \
--comparison-operator LessThanThreshold \
--alarm-actions arn:aws:sns:us-east-1:YOUR_ACCOUNT:gamelift-alertsPair this with GameLift’s own server-side logging, which writes to the log paths you configured in ProcessParameters, and pull those logs into CloudWatch Logs for centralized debugging across every instance in the fleet. If GameLift Streams is also part of your architecture, note that AWS added AWS Health integration for GameLift Streams in November 2025, which sends automated notifications when a stream group is aging out and approaching its 365-day expiration.
Step 11: Test With Load Simulation
Before opening a fleet to real players, simulate concurrent session requests to confirm your autoscaling policy and instance sizing hold up. A simple loop against the CreateGameSession API is enough to validate this:
import boto3
import concurrent.futures
gl = boto3.client("gamelift", region_name="us-east-1")
def create_session(i):
try:
resp = gl.create_game_session(
AliasId="YOUR_ALIAS_ID",
MaximumPlayerSessionCount=8,
Name=f"load-test-{i}"
)
return resp["GameSession"]["Status"]
except Exception as e:
return str(e)
with concurrent.futures.ThreadPoolExecutor(max_workers=20) as executor:
results = list(executor.map(create_session, range(100)))
print(f"Active: {results.count('ACTIVE')}, Failed: {len(results) - results.count('ACTIVE')}")Watch for FULL or throttling errors, which indicate your fleet ran out of capacity faster than autoscaling could react. If that happens consistently, lower your target-based scaling threshold or increase your fleet’s minimum instance count so there is always spare capacity for a burst.
Step 12: Set Up a Deployment Pipeline for New Builds
Once the fleet works, automate build uploads so a new server version does not require manually repeating steps 3 through 6 every time. A basic shell script wired into CI covers the common case:
#!/bin/bash
set -e
VERSION=$(git describe --tags)
BUILD_ID=$(aws gamelift upload-build \
--name "prod-server" \
--build-version "$VERSION" \
--build-root ./gamelift-build \
--operating-system AMAZON_LINUX_2023 \
--query "Build.BuildId" --output text)
echo "Waiting for build $BUILD_ID to become READY..."
aws gamelift wait build-ready --build-id "$BUILD_ID"
NEW_FLEET_ID=$(aws gamelift create-fleet \
--name "prod-fleet-$VERSION" \
--build-id "$BUILD_ID" \
--ec2-instance-type c5.large \
--fleet-type ON_DEMAND \
--runtime-configuration file://runtime-config.json \
--query "FleetAttributes.FleetId" --output text)
echo "New fleet: $NEW_FLEET_ID — verify health before updating alias"Note that aws gamelift wait build-ready is a real waiter command that polls until the build reaches READY status, which avoids the common mistake of creating a fleet against a build that has not finished processing. Update your alias to the new fleet only after confirming the fleet reaches ACTIVE status and passes a smoke test.
Container-Based Fleets: An Alternative to Zip Builds
Everything above uses a zip-based build, which is the simplest path for a tutorial project. GameLift also supports container fleets, where your game server ships as a Docker image instead of a zip archive plus an install script. For teams that already containerize the rest of their backend, this removes the install.sh step entirely and gives you the same image in every environment, from a developer’s laptop through CI to the production fleet.
When to Use Containers Instead of Zip Uploads
Container fleets make the most sense once your game server has non-trivial system dependencies, like a specific native library version or a compiled binary with OS-level requirements that are painful to express in a shell script. They also help if your studio already runs a container registry and CI pipeline for other services, since the game server build can reuse that same pipeline instead of a separate zip-and-upload flow. For a small tutorial project or an early prototype, the zip-based build in Step 3 is faster to iterate on, since you skip the image build and push step on every change.
Building and Pushing a Container Image
A minimal Dockerfile for the same Python server from Step 2 looks like this:
FROM public.ecr.aws/amazonlinux/amazonlinux:2023
RUN yum install -y python3 python3-pip
COPY . /local/game
WORKDIR /local/game
RUN pip3 install -r requirements.txt
EXPOSE 7777-7781
CMD ["python3", "server.py"]Build the image, push it to Amazon ECR, and reference it when creating a container-type fleet instead of a build-based one:
docker build -t gamelift-tutorial-server .
aws ecr create-repository --repository-name gamelift-tutorial-server
docker tag gamelift-tutorial-server:latest \
YOUR_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/gamelift-tutorial-server:latest
aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin YOUR_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com
docker push YOUR_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/gamelift-tutorial-server:latestFrom there, create a container group definition pointing at the pushed image, then create a fleet with --compute-type CONTAINER referencing that group definition instead of a build ID. The rest of the workflow, from aliases through autoscaling and CloudWatch monitoring, works identically regardless of whether the fleet runs a zip-based build or a container image.
Securing Your GameLift Deployment
A GameLift fleet that works is not automatically a GameLift fleet that is safe to expose to real players. Three areas deserve attention before you open a fleet to production traffic.
First, lock down your inbound security group rules to the narrowest port range your ConcurrentExecutions setting actually needs, rather than opening a wide range “to be safe.” An open port that no process is listening on is still an open port an attacker can probe. Second, never embed long-lived AWS credentials in a game client binary. Session requests should flow through a backend service that holds the GameLift permissions, with the client only ever receiving a short-lived connection IP, port, and player session ID. Anyone who extracts credentials from a client binary can otherwise create unlimited sessions on your account and run up your bill. Third, enable VPC peering or a private fleet configuration if your game server needs to reach other AWS resources, like a database or a matchmaking service, so that internal traffic never has to leave AWS’s network to reach a public endpoint.
It is also worth auditing who can call CreateFleet and UpdateFleetCapacity in your AWS account. Both actions can generate real EC2 spend quickly if triggered by a compromised CI credential or a misconfigured Lambda function, so treat them with the same access controls you would apply to any action that can provision paid infrastructure on its own.
GameLift Servers Pricing and Region Availability
GameLift Servers bills per EC2 instance-hour at rates similar to standard EC2 pricing for the same instance type, plus a GameLift service fee layered on top. GameLift Anywhere fleets, by contrast, only charge for the orchestration (session placement, matchmaking) since you supply your own compute. The table below summarizes the practical differences developers weigh when choosing a hosting path.
| Hosting Option | Compute Source | Free Tier | Best For | Setup Complexity |
|---|---|---|---|---|
| GameLift Servers (managed EC2) | AWS-provisioned instances | None (pay per instance-hour) | Production fleets needing autoscaling | Medium |
| GameLift Anywhere | Your own hardware/containers | 3,000 sessions + 500K connection minutes/month for 12 months | Development, testing, on-prem hybrid | Low |
| GameLift Streams | Managed GPU instances | None (consumption-based, GPU + storage) | Browser-based game streaming, not dedicated multiplayer | Medium-High |
| Self-managed on raw EC2 | Your own EC2 fleet | Standard EC2 free tier only | Full control, custom orchestration | High |
Regional availability also matters for latency-sensitive games. GameLift Servers is available in most standard AWS commercial regions, while GameLift Streams launched in a smaller initial set (US East N. Virginia, US East Ohio, US West Oregon, Asia Pacific Tokyo, Europe Frankfurt, and Europe Ireland in March 2025) and has since expanded to include Mumbai, Sydney, Stockholm, and London. If your player base is concentrated outside these regions, confirm current Streams availability before designing around it, since GameLift Servers has broader regional reach.
GameLift vs Azure PlayFab vs Google Cloud + Agones
GameLift is not the only managed path to hosting multiplayer game servers in the cloud. Azure PlayFab Multiplayer Servers offers a comparable managed dedicated-server product tightly integrated with Azure and commonly used by Xbox-adjacent titles. On Google Cloud, the standard approach is Agones, an open-source project originally built by Google Cloud and Ubisoft that runs dedicated game servers as workloads on Kubernetes, typically on Google Kubernetes Engine.
| Platform | Provider | Orchestration Model | Matchmaking Included | Typical Fit |
|---|---|---|---|---|
| Amazon GameLift | AWS | Fully managed fleets or Anywhere hybrid | Yes (FlexMatch) | Teams already on AWS wanting a managed, low-DevOps path |
| Azure PlayFab Multiplayer Servers | Microsoft Azure | Fully managed VM/container pools | Yes (PlayFab Matchmaking) | Xbox-linked titles and Azure-native studios |
| Agones on GKE | Google Cloud (open source) | Kubernetes-native, self-operated | No (bring your own or pair with Open Match) | Teams with existing Kubernetes expertise wanting full control |
The practical decision usually comes down to what your team already operates. If you run Kubernetes clusters for other services, Agones lets you host game servers alongside them using the same tooling, at the cost of managing scaling policies yourself. GameLift and PlayFab both trade that control for a managed experience where AWS or Microsoft handles fleet health and scaling, which is the better default for small teams without dedicated infrastructure engineers.
Common Pitfalls When Deploying to GameLift
Most GameLift deployment failures trace back to a small set of recurring mistakes. Check these before assuming you have hit a platform bug.
- Forgetting to call activate_game_session() in time. If your
on_start_game_sessioncallback does not activate the session within the configured game session activation timeout (300 seconds by default), GameLift marks the process as failed and tries another instance, silently eating capacity. - Security groups blocking the wrong port range. Your
--ec2-inbound-permissionsmust cover every port yourConcurrentExecutionsprocesses actually bind to, not just the first one. Four concurrent processes need four open ports, not one. - Uploading a build with a broken install.sh. GameLift runs your install script silently during instance bootstrap; a failing pip install here does not throw an obvious error, it just leaves your instance stuck in a non-ready state indefinitely.
- Using SIMPLE routing for production aliases. A single bad build push to a SIMPLE-routed alias sends every new session to the broken fleet at once. Use weighted routing during rollouts.
- Setting autoscaling targets too low. A 5% target-based scaling buffer looks efficient on a cost report but leaves no room for a sudden spike, causing session placement failures during exactly the moments (launches, tournaments) when you need capacity most.
- Ignoring instance type mismatches between build and fleet. A build compiled or tested for a different OS or architecture than your fleet’s EC2 instance type will fail health checks after passing the initial upload validation.
- Hardcoding a single region. Fleets without multi-location configuration cannot serve players closer to other regions, adding latency that is invisible in local testing but obvious in production ping times.
- Leaving GameLift Anywhere compute registered after testing. Deregistered but still-billed connection minutes on an Anywhere fleet can quietly eat into your free tier allowance if you forget to run
deregister-computeafter a test session.
Output Examples
A successful describe-fleet-attributes call after your fleet activates should return something close to this:
{
"FleetAttributes": [
{
"FleetId": "fleet-1a2b3c4d-5e6f-7890-abcd-ef1234567890",
"FleetType": "ON_DEMAND",
"Status": "ACTIVE",
"BuildId": "build-a1b2c3d4",
"OperatingSystem": "AMAZON_LINUX_2023",
"Name": "tutorial-echo-fleet"
}
]
}A successful session creation call returns connection details your client needs immediately:
{
"GameSession": {
"GameSessionId": "arn:aws:gamelift:us-east-1::gamesession/fleet-1a2b3c4d/gsess-9876",
"Status": "ACTIVE",
"IpAddress": "203.0.113.45",
"Port": 7777,
"CurrentPlayerSessionCount": 0,
"MaximumPlayerSessionCount": 8
}
}Troubleshooting Guide
Work through this list in order when a fleet or session isn’t behaving as expected.
- Fleet stuck in NEW or DOWNLOADING status for over 20 minutes. Check your build’s install.sh for silent failures by reviewing the instance’s UserData logs via GameLift’s fleet event history (
aws gamelift describe-fleet-events --fleet-id YOUR_FLEET_ID). - CreateGameSession returns a FULL error immediately. Your fleet has zero available capacity. Check current instance count against your minimum/maximum autoscaling bounds, and confirm scaling policies were actually attached, not just created.
- Client connects but the server never receives data. Confirm your inbound security group rule’s port range matches the actual bound port, and that your server binds to 0.0.0.0, not 127.0.0.1 or a specific private IP.
- Health checks failing despite the process running. Your
on_health_checkcallback must return quickly (under a few seconds) or GameLift treats a timeout as a failure. Do not put blocking I/O inside this callback. - FlexMatch requests time out with no match found. Your rule set’s constraints may be too tight for current player pool size. Test with a wider
maxDistancevalue first, then tighten once volume is confirmed. - Anywhere compute shows as UNHEALTHY. Confirm the machine’s firewall allows outbound connections to GameLift’s service endpoints, and that the SDK’s
init_sdk()call is not silently failing due to missing AWS credentials on the host. - Build upload hangs at 0% for a large archive. Very large zip files (over 1 GB) can exceed default upload timeouts; split assets between the build itself and content pulled from S3 at runtime instead of bundling everything into the initial upload.
- Alias update doesn’t seem to take effect. Existing active sessions stay on the old fleet; only new session requests route to the updated fleet target. This is expected — it is not a bug.
- CloudWatch alarms never trigger despite visible capacity issues. Double-check the namespace is exactly
AWS/GameLiftand theFleetIddimension matches exactly, including any region-qualified ARN formatting differences.
Advanced Tips for Production Fleets
Once the basic flow works, a few adjustments make a meaningful difference at real player volume. First, use game session queues with multi-region, multi-fleet destinations rather than pointing a client directly at one fleet’s alias. Queues let GameLift automatically fail over to a healthy fleet or a different region if your primary fleet runs out of capacity, which is a much better failure mode than a hard session-creation error reaching the player.
Second, if your game has predictable daily or weekly traffic patterns, layer scheduled scaling on top of target-based scaling rather than relying on target-based scaling alone. Target-based scaling reacts to current demand, but it still takes several minutes for new instances to boot and pass health checks, so pre-warming capacity ahead of a known peak (a weekend evening, a scheduled in-game event) avoids that lag entirely.
Third, separate your build pipeline’s staging and production fleets into different AWS accounts using AWS Organizations, not just different fleet IDs in the same account. This limits the blast radius of a misconfigured IAM policy or an accidental fleet termination to whichever environment it happens in, and it makes cost attribution between testing and live traffic far easier to audit at the end of the month.
Finally, if you are running a Kubernetes-based backend for matchmaking or player services alongside GameLift, keep GameLift itself out of that cluster. GameLift’s fleet management already replicates most of what a Kubernetes operator like Agones would give you, and running both stacks in parallel just doubles your operational surface area without adding a corresponding benefit for a GameLift-hosted title.
Complete Working Project Structure
Putting every step together, a finished, deployable project looks like this:
gamelift-tutorial/
├── gamelift-build/
│ ├── server.py # Step 2
│ ├── requirements.txt
│ └── install.sh # Step 3
├── ruleset.json # Step 8 (FlexMatch)
├── runtime-config.json # Step 4/12
├── gamelift-policy.json # Step 1 (IAM)
├── deploy.sh # Step 12 (CI pipeline)
├── client/
│ ├── request_session.py # Step 7
│ └── load_test.py # Step 11
└── monitoring/
└── cloudwatch-alarm.json # Step 10Run deploy.sh to push a new build, confirm the fleet transitions to ACTIVE, run load_test.py against the new alias to validate capacity, and only then update production traffic. This is the same shape of pipeline studios use for real titles; the only thing that changes at scale is the complexity of the actual game server binary being packaged, not the GameLift orchestration around it.
Quick Reference: Core GameLift CLI Commands
Keep this table handy while working through the steps above; it maps each command to the step where it is used and what it actually does.
| Command | Used In | Purpose |
|---|---|---|
| aws gamelift upload-build | Step 3 | Package and upload a zip-based server build |
| aws gamelift create-fleet | Steps 4, 5, 12 | Provision a managed EC2, Anywhere, or container fleet |
| aws gamelift register-compute | Step 5 | Register your own hardware with an Anywhere fleet |
| aws gamelift create-alias | Step 6 | Create a stable client-facing pointer to a fleet |
| aws gamelift create-game-session | Step 7 | Request a new session and get connection details |
| aws gamelift create-matchmaking-configuration | Step 8 | Wire a FlexMatch rule set to a session queue |
| aws gamelift put-scaling-policy | Step 9 | Attach target-based autoscaling to a fleet |
| aws gamelift describe-fleet-events | Troubleshooting | Inspect why a fleet is stuck or failing health checks |
Frequently Asked Questions
Does GameLift Servers require Unreal Engine or Unity?
No. GameLift only requires an executable that opens a network port and calls the GameLift Server SDK’s lifecycle functions. Both major engines have official plugins that wrap this integration, but a custom engine or a plain socket server, like the Python example in this tutorial, works identically from GameLift’s perspective.
What is the difference between GameLift Servers and GameLift Streams?
GameLift Servers hosts dedicated multiplayer game server processes for real-time gameplay with authoritative server logic. GameLift Streams, added in March 2025, streams a full game session from a GPU instance to a browser at up to 1080p and 60 fps, aimed at click-to-play distribution rather than multiplayer session hosting. They solve different problems and can be used together in some architectures but are billed and configured separately.
Is GameLift Anywhere free forever?
No. The free tier covers 3,000 game sessions placed and 500,000 server connection minutes per month for the first 12 months, aggregated across all AWS regions. After that period, or beyond those limits, standard GameLift Anywhere orchestration charges apply, though you still avoid EC2 instance-hour costs since you supply your own compute.
Can I use GameLift with a game built in Godot?
Yes, as long as you can compile a dedicated server build and link or call the GameLift Server SDK from it. Godot does not ship an official first-party GameLift plugin the way Unreal and Unity do, so most Godot studios wrap the SDK’s C interface themselves or use a community-maintained binding.
How long does it take for a new fleet to become active?
Typically 8 to 12 minutes for a standard managed EC2 fleet, covering instance provisioning, build download, install script execution, and health check validation. GameLift Anywhere fleets activate almost immediately since there is no EC2 instance to provision.
What happens to active player sessions when I update a fleet’s alias?
Nothing changes for players already connected to an existing session; alias updates only affect where new CreateGameSession requests are routed. You still need a separate process, like a scheduled maintenance window or a graceful session drain, to move existing players off a fleet you plan to retire.
Do I need FlexMatch, or can I build my own matchmaking?
FlexMatch is optional. Many smaller titles call CreateGameSession directly and handle lobby formation in their own backend, only adopting FlexMatch once skill-based or latency-based matching becomes worth the added configuration complexity.
Which regions support GameLift Servers versus GameLift Streams?
GameLift Servers is available in most standard AWS commercial regions. GameLift Streams launched in a narrower set in March 2025 (US East N. Virginia and Ohio, US West Oregon, Asia Pacific Tokyo, Europe Frankfurt and Ireland) and has since expanded to additional regions including Mumbai, Sydney, Stockholm, and London, so check current availability if Streams is part of your architecture.
Related Coverage
- How to Deploy AWS ECS Fargate: 12 Steps, 90 Min [2026]
- AWS Systems Manager Azure Setup: 12 Steps, 90 Min [2026]
- Migrate AWS App Runner to ECS Express Mode: 12 Steps [2026]
- How to Set Up AWS IAM Identity Center: 12 Steps [2026]
- AWS Step Functions Terraform Tutorial: 12 Steps, 90 Min [2026]
