Riot Games runs VALORANT and League of Legends match servers across 17 AWS Local Zones worldwide, and the payoff shows up directly in player ping: sub-35ms for VALORANT and sub-70ms for League of Legends in supported metro areas, according to AWS’s own Riot Games case study. That is not the result of a bigger EC2 instance or a smarter matchmaker. It is the result of moving the dedicated game server physically closer to the player, inside AWS infrastructure that sits in the middle of a metro area instead of a distant regional data center.
As of October 2026, Amazon GameLift Servers supports deployment across 26 AWS Regions and 9 AWS Local Zones on five continents, following a September 2026 expansion that added five new regions and eight new Local Zones, including Atlanta, Chicago, Houston, Miami, Phoenix, New York City, Buenos Aires, and Lima. That expansion matters for any studio shipping a session-based multiplayer game in 2026, because latency, not raw server horsepower, is usually the thing that makes a shooter or a racer feel broken. This tutorial walks through exactly how to stand up a dedicated game server on AWS Local Zones using Amazon GameLift Servers, from account setup to a working fleet pinging under 35ms for nearby players, plus the networking, pricing, and troubleshooting details most getting-started guides skip.
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 AWS Local Zones Actually Are (and Why They Beat a Regional Fleet)
An AWS Local Zone is an extension of a parent AWS Region, placed physically inside or near a major metropolitan area instead of in one of AWS’s big regional data center campuses. AWS’s own infrastructure documentation describes Local Zones as built for workloads that need single-digit-millisecond proximity to end users, which is a very different design goal than a standard Availability Zone optimized for throughput and redundancy. A game server running in a Local Zone subnet in, say, Los Angeles answers a request from a player in LA without that request first bouncing out to us-west-2 in Oregon and back.
AWS’s published Riot Games case study is the clearest real-world proof this matters at scale: Riot strategically adopted Local Zones, which AWS says are available in over 30 metropolitan areas worldwide, specifically to shrink the distance between its match servers and players. The result, per that same case study, is that Riot now runs latency-sensitive game servers across 17 AWS Local Zones globally. That’s not a pilot or a proof of concept; it’s production infrastructure behind two of the highest-concurrency competitive multiplayer games on the planet.
AWS currently lists Local Zones as available in more than 30 metropolitan areas globally, spanning US cities such as Atlanta, Boston, Chicago, Dallas, Denver, Houston, Las Vegas, Los Angeles, Miami, Minneapolis, New York City, Phoenix, Philadelphia, Portland, Salt Lake City, and Washington, D.C., alongside international metros including Buenos Aires and Lima. Amazon GameLift Servers, specifically, currently exposes 9 of those Local Zones for dedicated game server fleets, a number that grew from a single Dallas Local Zone added in September 2025 to the current footprint after the September 2026 region expansion. For a dedicated game server tutorial, that distinction matters: not every Local Zone supports every AWS service, and GameLift’s supported-zone list is narrower than the full Local Zone catalog.
There is also a complementary AWS product worth knowing before you start: Amazon GameLift Anywhere, which lets you register and manage game servers running on your own hardware (on-premises, colocation, or another edge location) under the same GameLift control plane that manages your Local Zone fleets. A hybrid backend might keep matchmaking, player accounts, and persistence in a standard AWS Region while running the actual game session on Local Zone compute near the player and GameLift Anywhere compute at a site AWS doesn’t reach yet.
| Deployment Type | Where It Runs | Typical Latency Profile | Best Fit |
|---|---|---|---|
| Standard AWS Region fleet | Large regional data center (e.g., us-east-1) | Higher and more variable for distant players | Global matchmaking, backend services, non-latency-critical sessions |
| AWS Local Zone fleet | Metro-area extension of a parent Region | Single-digit to tens of ms for nearby players | Competitive shooters, racers, fighting games, regional tournaments |
| AWS Wavelength Zone | Inside a telecom carrier’s 5G network | Very low latency for users on that carrier’s 5G | Mobile multiplayer games on supported carriers |
| GameLift Anywhere | Customer-controlled hardware (on-prem, colo, edge) | Depends entirely on the site and network | Specialized edge capacity AWS doesn’t cover yet |
Prerequisites and Versions
Before touching the AWS console, get these in place. None of this is optional, and skipping the IAM step in particular is the single most common reason this setup fails halfway through.
- An AWS account with billing enabled and an IAM user or role with
GameLiftFullAccessplus EC2 and VPC permissions (not the root account). - AWS CLI v2 installed locally (version 2.17 or newer recommended for current GameLift subcommands).
- A built, headless-capable game server executable for your engine. This tutorial uses a generic Linux x86_64 build; the same steps apply to Windows builds with path adjustments.
- The Amazon GameLift Server SDK integrated into your game server code (version 5.x for the current SDK generation). Unreal Engine and Unity both have official GameLift plugins.
- Python 3.10+ if you want to run the included test client script.
- Terraform 1.7+ or the AWS CDK, optional but recommended for the Local Zone subnet and VPC work in Step 6.
- A target Local Zone that’s both GameLift-supported and physically close to your player base. Check the current list before committing capacity.
Step 1: Confirm Your Target Local Zone Is GameLift-Supported
Not every AWS Local Zone supports Amazon GameLift Servers, and not every GameLift-supported Local Zone offers the same EC2 instance catalog. Pull the current list with the AWS CLI before you design anything else:
aws gamelift describe-ec2-instance-limits \
--region us-east-1 \
--output tableCross-reference the output against the GameLift service locations documentation, which lists zone identifiers such as us-east-1-atl-2a for Atlanta and us-west-2-lax-1 for Los Angeles. GameLift’s own FAQ names C5d.2xlarge and R5d.2xlarge as the baseline supported instance types for Local Zone fleets, which is narrower than the full EC2 Local Zone catalog of C6i, C6gn, C6in, C7i, M6i, M6g, M8g, R5d, R6i, and in select locations G4dn or P5 GPU instances for non-GameLift workloads. If your game needs a GPU-backed server, verify GPU-instance availability in your specific Local Zone before you build the rest of the pipeline around it.
Step 2: Set Up IAM Permissions for GameLift
Create a dedicated IAM role for GameLift rather than reusing an existing admin role. Attach the AWS-managed GameLiftFullAccess policy, plus a trust policy that allows the GameLift service principal to assume the role for fleet operations:
aws iam create-role \
--role-name GameLiftLocalZoneRole \
--assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy \
--role-name GameLiftLocalZoneRole \
--policy-arn arn:aws:iam::aws:policy/GameLiftFullAccessWhere trust-policy.json grants gamelift.amazonaws.com permission to assume the role. If you plan to use AWS CLI’s upload-build command later, also attach S3 read/write permissions scoped to the bucket GameLift uses internally for build storage; GameLift’s documentation notes that the CLI’s upload-build command is the fastest path for getting a build into the service without manually zipping and uploading through the console.
Step 3: Prepare Your Game Server Build
Your build folder needs the compiled server executable, all runtime dependencies, and any configuration files your server reads at startup. AWS’s Unreal Engine integration guide specifies that the build directory should include the server binary, the associated .pak or content files, and any third-party shared libraries the executable links against dynamically. Zip the folder and keep the structure flat relative to the executable’s expected working directory, since GameLift unpacks the build onto each fleet instance exactly as uploaded.
mkdir gamelift-build
cp ./build/linux/MyGameServer gamelift-build/
cp -r ./build/linux/dependencies gamelift-build/
cp ./install.sh gamelift-build/
aws gamelift upload-build \
--name "my-game-server-v1" \
--build-version "1.0.0" \
--build-root ./gamelift-build \
--operating-system AMAZON_LINUX_2023 \
--region us-east-1The upload returns a build ID in the form build-xxxxxxxx-xxxx. Save it; you’ll need it to create the fleet in Step 5. Build upload typically takes two to ten minutes depending on build size, and GameLift validates the OS and architecture match before marking the build READY.
Step 4: Integrate the GameLift Server SDK Into Your Game Code
Your server executable needs to call the GameLift Server SDK at three points: initialization, when it’s ready to accept a game session, and when a session ends. This is the piece that lets GameLift’s health checks and session placement actually talk to your process instead of just launching a black box.
#include <aws/gamelift/server/GameLiftServerAPI.h>
Aws::GameLift::Server::InitSDK();
auto onStartGameSession = [](Aws::GameLift::Server::Model::GameSession gameSession) {
// Load map, spawn players, mark server active
Aws::GameLift::Server::ActivateGameSession();
};
auto onProcessTerminate = []() {
Aws::GameLift::Server::ProcessEnding();
};
auto onHealthCheck = []() -> bool {
return true; // return false if the server is unresponsive
};
Aws::GameLift::Server::ProcessParameters params(
onStartGameSession, nullptr, onProcessTerminate, onHealthCheck,
7777, Aws::GameLift::Server::LogParameters({"/local/game/logs/"})
);
Aws::GameLift::Server::ProcessReady(params);The port you pass to ProcessReady (7777 in this example) is what GameLift maps to a public connection endpoint for players. If you’re running multiple server processes per EC2 instance to pack capacity more efficiently, each process needs its own port, and your fleet’s runtime configuration (Step 5) has to declare every concurrent process explicitly.
Step 5: Create a Fleet Targeting Your Local Zone
This is the step where Local Zone deployment diverges from a standard regional GameLift tutorial. You create the fleet in the parent Region as usual, but you explicitly pin the fleet’s location to the Local Zone identifier rather than letting GameLift pick a general Availability Zone.
aws gamelift create-fleet \
--name "lz-atlanta-fleet" \
--build-id build-xxxxxxxx-xxxx \
--ec2-instance-type c5d.2xlarge \
--fleet-type ON_DEMAND \
--ec2-inbound-permissions FromPort=7777,ToPort=7777,IpRange=0.0.0.0/0,Protocol=UDP \
--locations Location=us-east-1-atl-2a \
--runtime-configuration ServerProcesses=[{LaunchPath=/local/game/MyGameServer,Parameters="",ConcurrentExecutions=4}] \
--region us-east-1Fleet creation in a Local Zone typically takes 10 to 20 minutes to move from NEW through ACTIVATING to ACTIVE, since GameLift needs to provision the instance, run validation, and confirm your server process reports healthy. Poll status with:
aws gamelift describe-fleet-location-attributes \
--fleet-id fleet-xxxxxxxx-xxxx \
--locations us-east-1-atl-2a \
--region us-east-1Expected output once the fleet is healthy shows "Status": "ACTIVE" under the location block, with an instance count matching your desired capacity. If it sits in ACTIVATING past 25 minutes, check CloudWatch logs for your fleet before assuming it’s stuck; a health check that never returns true is the most common cause.
Step 6: Extend Your VPC Into the Local Zone Subnet
A Local Zone is not a separate network boundary from your parent Region’s VPC; it’s a subnet association. AWS’s Local Zones documentation describes the workflow as: enable the Local Zone for your account, create (or reuse) a VPC in the parent Region, create a subnet explicitly associated with the Local Zone, then launch resources into that subnet. GameLift handles the EC2 provisioning itself when you specify a Local Zone in create-fleet, but if you’re also running backend services (matchmaking proxies, session brokers) that need to sit physically close to the fleet, you’ll want to extend your own VPC manually.
aws ec2 create-subnet \
--vpc-id vpc-0123456789abcdef0 \
--availability-zone us-east-1-atl-2a \
--cidr-block 10.0.4.0/24 \
--region us-east-1
aws ec2 create-route-table --vpc-id vpc-0123456789abcdef0 --region us-east-1
aws ec2 associate-route-table \
--subnet-id subnet-xxxxxxxx \
--route-table-id rtb-xxxxxxxx \
--region us-east-1Route traffic between the Local Zone subnet and the parent Region’s resources through the VPC’s main route table as you normally would; the Local Zone is reachable through the same VPC peering, Transit Gateway, or internet gateway paths as any other subnet. Keep authoritative game-server processes in the Local Zone subnet and non-latency-critical services (player accounts, matchmaking logic, analytics) in the parent Region.
Step 7: Set Up a Game Session Queue for Latency-Based Placement
A single Local Zone fleet only helps players near that one metro. Production deployments combine multiple Local Zone fleets under one game session queue, and GameLift’s placement algorithm picks the lowest-latency destination based on round-trip-time measurements your client reports.
aws gamelift create-game-session-queue \
--name "lz-regional-queue" \
--destinations fleet-atlanta-id fleet-dallas-id fleet-miami-id \
--player-latency-policies MaximumIndividualPlayerLatencyMilliseconds=100,PolicyDurationSeconds=60 \
--region us-east-1On the client side, measure RTT to each candidate region/Local Zone endpoint before requesting placement, and pass those measurements into the start-game-session-placement call under PlayerLatencies. GameLift uses that data to route the player to whichever fleet in the queue produces the lowest measured latency, falling back to the next-best destination if the closest fleet is at capacity.
Step 8: Launch a Test Game Session and Validate Connectivity
With the fleet active and the queue configured, request a placement and confirm a player can actually connect:
aws gamelift start-game-session-placement \
--placement-id test-placement-001 \
--game-session-queue-name lz-regional-queue \
--maximum-player-session-count 8 \
--player-latencies PlayerId=tester1,RegionIdentifier=us-east-1-atl-2a,LatencyInMilliseconds=12 \
--region us-east-1Poll describe-game-session-placement until status reads FULFILLED, then pull the IpAddress and Port from the response and connect a test client directly. Expected output for a healthy placement looks like:
{
"GameSessionPlacement": {
"Status": "FULFILLED",
"IpAddress": "54.23.xx.xx",
"Port": 7777,
"GameSessionArn": "arn:aws:gamelift:us-east-1::gamesession/fleet-xxxx/..."
}
}If status instead returns TIMED_OUT, your fleet most likely has zero available server processes, or your runtime configuration’s ConcurrentExecutions value doesn’t match what’s actually running on the instance.
Step 9: Measure Real Player Latency From the Local Zone
Don’t take “single-digit-millisecond” marketing language at face value; measure it. Run a simple UDP echo or ICMP test from a residential or mobile connection physically near your Local Zone against both the Local Zone fleet and a regional fleet for comparison:
ping -c 50 54.23.xx.xx # Local Zone fleet endpoint
ping -c 50 34.201.xx.xx # Parent region fleet endpoint, for comparisonExpect meaningfully lower and more stable ping from the Local Zone endpoint for players physically near that metro, but treat AWS’s single-digit-millisecond figure as an infrastructure-placement target rather than a guaranteed end-to-end number. Last-mile ISP routing, peering agreements, and your game’s own tick rate all factor into what the player actually feels. Riot’s reported figures (sub-35ms VALORANT, sub-70ms League of Legends) are the most concrete real-world benchmark currently published for this architecture.
Step 10: Configure Auto-Scaling for the Local Zone Fleet
Local Zone capacity should scale with regional demand, not global demand, since a Local Zone only serves players near that metro. Set a target-based scaling policy keyed to available server process count rather than a flat instance count:
aws gamelift put-scaling-policy \
--name "lz-atlanta-scaling" \
--fleet-id fleet-xxxxxxxx-xxxx \
--policy-type TargetBased \
--target-configuration TargetValue=75 \
--metric-name PercentAvailableGameSessions \
--region us-east-1A target of 75% available game sessions leaves headroom for sudden regional spikes (a popular streamer going live in that metro, a weekend tournament) without over-provisioning idle capacity around the clock. GameLift Spot instances can cut costs by roughly 50% to 85% versus On-Demand pricing for the same instance type, according to AWS’s published GameLift pricing page, but Spot interruptions carry real risk for live sessions, so reserve Spot capacity for non-critical or easily-restartable server types rather than ranked competitive matches.
Monitoring, Logging, and Cost Visibility for Local Zone Fleets
A Local Zone fleet that’s active and healthy isn’t automatically a fleet you can trust in production. Because Local Zones carry a different pricing profile than their parent Region and a smaller Spot capacity pool, treat observability as a first-class part of this setup rather than something to bolt on after launch.
Start with GameLift’s built-in CloudWatch metrics, which report per-fleet and per-location data separately once a fleet spans multiple Local Zones. Pull ActiveInstances, PercentAvailableGameSessions, and CurrentPlayerSessions scoped to each Local Zone location, not just the fleet as a whole, so a problem in one metro doesn’t hide behind healthy numbers from the others:
aws cloudwatch get-metric-statistics \
--namespace AWS/GameLift \
--metric-name PercentAvailableGameSessions \
--dimensions Name=FleetId,Value=fleet-xxxxxxxx-xxxx Name=Location,Value=us-east-1-atl-2a \
--start-time 2026-10-09T00:00:00Z \
--end-time 2026-10-10T00:00:00Z \
--period 300 \
--statistics Average \
--region us-east-1For cost visibility, tag every Local Zone fleet with a consistent Metro and Environment tag at creation time, then build a Cost Explorer report grouped by those tags. Because Local Zone EC2 pricing runs higher than the parent Region for the same instance type, and the premium varies by location rather than following one flat multiplier, tagging is the only reliable way to see which specific metro is actually driving your bill up versus which one is just handling more traffic. Teams running FinOps tooling such as Kubecost or CloudZero for their broader Kubernetes and cloud spend should extend the same tag taxonomy to GameLift resources so Local Zone premiums show up in the same dashboards as the rest of cloud spend, instead of living in a GameLift-specific blind spot that only surfaces at the end of the month.
Step 11: Add a Second Local Zone and Compare Costs
Once Atlanta is proven out, repeat Steps 5 through 7 for a second metro, say Dallas (us-east-1-dfw-2), which AWS added as a GameLift Local Zone in September 2025 with support for C6gn, C6i, C6in, M6g, M6i, M6in, M8g, and R6i instances. Pricing in Local Zones generally runs higher per-instance-hour than the equivalent capacity in the parent Region, though AWS doesn’t charge anything extra just to enable a Local Zone; you only pay for what you actually run there. Run the EC2 pricing calculator for your specific instance type and Local Zone before committing to steady-state capacity, since the premium varies by location and instance family rather than following one fixed multiplier.
| Local Zone | Zone Identifier | Parent Region | Added |
|---|---|---|---|
| Atlanta | us-east-1-atl-2a | US East (N. Virginia) | Pre-2026 |
| Los Angeles | us-west-2-lax-1 | US West (Oregon) | Pre-2026 |
| Dallas | us-east-1-dfw-2 | US East (N. Virginia) | September 2025 |
| Chicago | us-east-1-chi-2a | US East (N. Virginia) | September 2026 expansion |
| Houston | us-east-1-hou-2a | US East (N. Virginia) | September 2026 expansion |
| Miami | us-east-1-mia-2a | US East (N. Virginia) | September 2026 expansion |
| Phoenix | us-west-2-phx-2a | US West (Oregon) | September 2026 expansion |
| Buenos Aires | sa-east-1-bue-2a | South America (SÃĢo Paulo) | September 2026 expansion |
Step 12: Consider AWS Wavelength for Mobile Multiplayer
If your audience is primarily on mobile over 5G rather than fixed broadband, AWS Wavelength is the more relevant edge product, not Local Zones. Wavelength embeds AWS compute directly inside a telecom carrier’s 5G network, so traffic from a player on that carrier never has to leave the carrier’s network to reach your game server. AWS’s current Wavelength partner list includes Verizon in the US, plus Vodafone and BT in Europe, Orange in Morocco and Senegal, KDDI in Japan, SK Telecom in South Korea, and Bell in Canada. Verizon’s Wavelength Zones span US metros including Boston, Atlanta, Washington D.C., New York City, Miami, Dallas, Houston, and Chicago, parented to US East (N. Virginia).
The fleet-creation mechanics are nearly identical to Local Zones, swapping the zone identifier for a Wavelength Zone ID such as us-east-1-wl1-atl-wlz-1. The catch is that Wavelength only helps players connected through that specific carrier’s 5G network; a player on Wi-Fi or a competing carrier gets no benefit and should fall back to your nearest Local Zone or regional fleet through the same game session queue from Step 7.
Step 13: Automate the Whole Stack With Terraform
Manually running CLI commands for every new Local Zone doesn’t scale past two or three metros. AWS’s own documentation points to Terraform and Pulumi, run through AWS Cloud Control, as the supported path for codifying GameLift resources alongside the rest of your infrastructure. A minimal fleet resource looks like this:
resource "aws_gamelift_fleet" "lz_fleet" {
name = "lz-${var.metro}-fleet"
build_id = aws_gamelift_build.server_build.id
ec2_instance_type = "c5d.2xlarge"
fleet_type = "ON_DEMAND"
ec2_inbound_permission {
from_port = 7777
to_port = 7777
ip_range = "0.0.0.0/0"
protocol = "UDP"
}
runtime_configuration {
server_process {
launch_path = "/local/game/MyGameServer"
concurrent_executions = 4
}
}
}Parameterize var.metro and the Local Zone identifier, then loop the module across your target metros with Terraform’s for_each. This turns “add a new Local Zone” from a half-day manual process into a one-line variable addition and a terraform apply.
Common Pitfalls When Deploying Game Servers to AWS Local Zones
- Assuming every Local Zone supports GameLift. AWS’s broader Local Zones footprint (30+ metros) is much larger than GameLift’s supported subset (9 Local Zones as of October 2026). Always check the GameLift-specific list, not the general Local Zones page.
- Treating “single-digit-millisecond” as a guarantee. That figure describes the infrastructure’s proximity design goal. Actual player latency still depends on their ISP, last-mile connection, and routing.
- Forgetting the instance-type ceiling. GameLift’s FAQ names C5d.2xlarge and R5d.2xlarge as baseline-supported Local Zone instance types; don’t design a fleet around a GPU or memory-optimized instance without first confirming it’s actually available in that specific zone.
- Running ranked or competitive sessions on Spot capacity. The 50-85% savings are real, but a Spot interruption mid-match in a Local Zone with limited fallback capacity is a worse outcome than the cost savings justify.
- Skipping the latency-based queue. A single Local Zone fleet with no queue just moves the “wrong region” problem to a smaller radius. Multi-fleet queues with player latency policies are what actually route players correctly.
- Not extending the VPC subnet correctly. A Local Zone is a subnet association, not a new VPC. Teams that create a brand-new isolated VPC per Local Zone end up fighting their own routing tables instead of using Transit Gateway or peering through their existing network.
- Ignoring Wavelength vs. Local Zone fit. Deploying a mobile-first game to Local Zones instead of Wavelength Zones means fixed-broadband-style latency gains with none of the carrier-network benefit mobile players actually need.
- Under-provisioning health check tolerance. A health check callback that’s too strict (e.g., failing on momentary GC pauses) causes GameLift to cycle processes, which looks like capacity problems but is actually a false-positive health signal.
Troubleshooting Guide
- Fleet stuck in ACTIVATING past 25 minutes: Check CloudWatch Logs under the GameLift log group for the fleet; a server process that never calls
ProcessReadyor fails its first health check will block activation indefinitely. - describe-fleet-location-attributes returns ERROR status: The Local Zone identifier is likely misspelled or not enabled on your account. Run
aws ec2 describe-availability-zones --all-availability-zonesto confirm the zone is opted in. - Game session placement times out: The fleet has zero available processes. Check
ConcurrentExecutionsin your runtime configuration against what’s actually launched, and confirm your health check callback isn’t returning false. - Players still see high latency after moving to a Local Zone: Confirm your client is measuring RTT to the correct endpoint and passing it into
PlayerLatencies. A queue misconfiguration will silently route to the parent Region fleet instead. - build upload fails with an OS mismatch error: The
--operating-systemflag must exactly match what your binary was compiled for. AMAZON_LINUX_2023 builds will not run against an AMAZON_LINUX_2 fleet definition. - VPC subnet creation fails with “InvalidParameterValue”: The Local Zone must be explicitly opted in for your account first via the EC2 console’s Zones settings before you can create a subnet associated with it.
- Spot instances interrupted frequently in a specific Local Zone: Spot capacity pools are smaller in Local Zones than in parent Regions. If interruptions spike, shift that fleet to On-Demand or add a second Local Zone as a fallback destination in your queue.
- Terraform apply fails on aws_gamelift_fleet with a region/zone mismatch: The provider’s region must match the fleet’s parent Region, with the Local Zone specified separately in the fleet’s location block, not in the provider block.
What AWS’s Own Documentation Says About GameLift Integration
Most of the friction in a Local Zone deployment doesn’t come from the Local Zone piece itself; it comes from getting the base GameLift server integration right first. AWS’s documentation is blunt about what that integration actually requires. Per AWS’s GameLift Servers FAQ, “Amazon GameLift Servers is a capability for deploying, operating, and scaling dedicated game servers for session-based multiplayer games,” and the first real step is explicit: “First, integrate Amazon GameLift Servers into your game back-end and game server using the AWS SDK and the Amazon GameLift Servers SDK.” Skipping straight to fleet creation without that SDK integration (Step 4 above) is the single most common reason a Local Zone fleet activates successfully but never shows a healthy server process.
For teams that don’t want to hand-roll the SDK calls, AWS’s GameLift Servers developer guide describes a wrapper tool built for exactly this problem: “This tool is the quickest and easiest way to get your game server hosted and running game sessions with Amazon GameLift Servers, with no changes to game code required.” That wrapper is worth using for a first Local Zone proof-of-concept before committing engineering time to a full native SDK integration, since it validates the fleet, networking, and queue setup independently of your actual game logic.
On the build-upload step specifically, AWS’s own wrapper tutorial confirms the CLI path used in Step 3 above is the recommended one: “The quickest way to upload your game build is by using the AWS CLI command upload-build as shown in the following example.” And for engine-specific build packaging, AWS’s Unreal Engine integration documentation is explicit that “the build should include” the server binary and its associated content and dependency files, which is why Step 3’s build folder keeps everything flat and self-contained rather than relying on paths outside the uploaded directory.
Advanced Tips for Production Deployments
Once the basic Local Zone fleet is stable, a few refinements separate a demo from a production backend. First, instrument your server process to emit custom CloudWatch metrics for actual observed player RTT, not just fleet-level health, so you can validate the latency promise per metro over time rather than trusting a one-time test. Second, if you’re running tournaments or scheduled events with predictable regional spikes, pair target-based auto-scaling with a scheduled scaling action that pre-warms capacity 15-30 minutes before a known event start, since cold-start provisioning in a Local Zone can lag behind a sudden demand spike. Third, for studios running both Local Zones and GameLift Anywhere sites, keep a consistent fleet alias naming scheme across both so your matchmaking and queue logic can treat them as interchangeable destinations differentiated only by latency, not by deployment type. Finally, revisit your Local Zone footprint roughly every quarter; AWS has added Local Zones to GameLift’s supported list multiple times in the past 13 months, and a metro that wasn’t supported when you launched may be supported now.
Complete Working Project: Multi-Metro Latency-Routed Fleet
Putting the full sequence together, a production-ready Local Zone deployment looks like this end to end:
# 1. Upload build
BUILD_ID=$(aws gamelift upload-build --name prod-server --build-version 2.0.0 \
--build-root ./gamelift-build --operating-system AMAZON_LINUX_2023 \
--region us-east-1 --query 'Build.BuildId' --output text)
# 2. Create fleets in three Local Zones
for ZONE in us-east-1-atl-2a us-east-1-dfw-2 sa-east-1-bue-2a; do
aws gamelift create-fleet --name "prod-fleet-$ZONE" --build-id $BUILD_ID \
--ec2-instance-type c5d.2xlarge --fleet-type ON_DEMAND \
--ec2-inbound-permissions FromPort=7777,ToPort=7777,IpRange=0.0.0.0/0,Protocol=UDP \
--locations Location=$ZONE \
--runtime-configuration ServerProcesses=[{LaunchPath=/local/game/MyGameServer,ConcurrentExecutions=4}] \
--region us-east-1
done
# 3. Build the latency-based queue across all three
aws gamelift create-game-session-queue --name prod-regional-queue \
--destinations fleet-atl fleet-dfw fleet-bue \
--player-latency-policies MaximumIndividualPlayerLatencyMilliseconds=80,PolicyDurationSeconds=60 \
--region us-east-1
# 4. Apply target-based scaling to each fleet
for FLEET in fleet-atl fleet-dfw fleet-bue; do
aws gamelift put-scaling-policy --name "$FLEET-scale" --fleet-id $FLEET \
--policy-type TargetBased --target-configuration TargetValue=75 \
--metric-name PercentAvailableGameSessions --region us-east-1
doneThat script, run end to end against an already-uploaded, SDK-integrated build, stands up a three-metro latency-routed fleet in roughly 30-40 minutes, with Atlanta and Dallas covering US East Coast and Central players and Buenos Aires covering South American players, all routed through a single game session queue that picks the lowest-latency destination per player automatically.
Frequently Asked Questions
How many AWS Local Zones does Amazon GameLift Servers support?
As of October 2026, Amazon GameLift Servers supports 9 AWS Local Zones across 5 continents, following a September 2026 expansion that added eight new Local Zones, including Atlanta, Chicago, Houston, Miami, Phoenix, New York City, Buenos Aires, and Lima, alongside five new AWS Regions. This is separate from AWS’s broader Local Zones footprint, which spans more than 30 metropolitan areas worldwide but isn’t all GameLift-enabled.
What EC2 instance types work in AWS Local Zones for game servers?
Amazon GameLift’s FAQ names C5d.2xlarge and R5d.2xlarge as the baseline-supported instance types for Local Zone fleets. The broader EC2 Local Zones catalog includes C6i, C6gn, C6in, C7i, M6i, M6g, M8g, R5d, and R6i families, with select newer Local Zones such as Atlanta also offering P5 GPU instances, though GPU availability is location-specific and should be confirmed before building around it.
Is AWS Local Zones more expensive than a standard AWS Region?
There’s no charge just to enable a Local Zone; you pay only for the services you actually consume there. EC2 instance pricing in Local Zones is generally higher than equivalent capacity in the parent Region, but the exact premium varies by instance type, location, and pricing model (On-Demand, Spot, or Savings Plan), so check the location-specific EC2 pricing page rather than assuming a flat percentage. Separately, GameLift Spot instances can offer 50% to 85% savings versus On-Demand pricing regardless of whether you’re in a Local Zone or a standard Region.
What’s the difference between AWS Local Zones and AWS Wavelength for games?
Local Zones are metro-area AWS infrastructure reachable over standard fixed broadband, ISP, or general internet connectivity, best suited for PC and console multiplayer. Wavelength embeds AWS compute directly inside a telecom carrier’s 5G network, so it only benefits players connected through that specific carrier’s mobile network, making it the better fit for mobile multiplayer games where most players are on cellular data rather than Wi-Fi.
Which game studios actually use AWS Local Zones in production?
Riot Games is the most concrete published case study, running latency-sensitive dedicated servers for VALORANT and League of Legends across 17 AWS Local Zones worldwide, with AWS reporting sub-35ms latency for VALORANT and sub-70ms for League of Legends in supported metro areas. AWS’s game backend documentation also positions Local Zones generally for session-based multiplayer games that need lower latency than a standard Region can provide.
Does Amazon GameLift Anywhere replace the need for Local Zones?
No, they’re complementary. GameLift Anywhere lets you register customer-controlled hardware (on-premises, colocation, or another edge site) under the GameLift control plane, which is useful for locations AWS doesn’t operate a Local Zone in. Local Zones are AWS-owned and -managed infrastructure that requires no hardware of your own. A hybrid backend can mix both, routing players to whichever destination (AWS Region, Local Zone, or Anywhere site) produces the lowest measured latency through the same game session queue.
Do I need a separate VPC for every Local Zone fleet?
No. A Local Zone is an extension of your existing parent-Region VPC, accessed by creating a subnet explicitly associated with that Local Zone. There’s no need to spin up an isolated VPC per metro; the standard approach is one VPC per parent Region with multiple Local Zone subnets attached, connected through your existing route tables, Transit Gateway, or VPC peering.
How long does it take to add a new Local Zone to an existing GameLift deployment?
Assuming the target Local Zone is already on GameLift’s supported list and your build is already uploaded, creating and activating a new fleet in that zone typically takes 10 to 20 minutes, plus a few more minutes to add the new fleet as a destination in your existing game session queue. Using Terraform or Pulumi with a parameterized module, as shown in Step 13, reduces the manual work to a single variable change and a deploy.
