How much it costs to run an online game

A game with 10,000 players does not need 10,000 servers

The first mistake in estimating an online game’s cost is starting with total users.

A game might have one million registered accounts, 100,000 monthly players and only 2,000 people online during its busiest hour. Server infrastructure cares much more about that last number.

Concurrent users — usually shortened to CCU — are the players demanding capacity at the same time.

Even CCU is not enough by itself.

Two games with identical concurrency can have radically different infrastructure requirements. A turn-based card game may put dozens of simultaneous matches on one modest machine. A competitive shooter may need much more CPU and network activity for every match because the server is continuously processing movement, physics, hits and state updates.

Amazon’s own current GameLift pricing examples show how wide that difference can become.

AWS worked example	Peak CCU	Sessions per instance	Monthly game-server compute
1v1 card game	10,000	24	about $3,237
5v5 competitive shooter	50,000	8	about $111,567
Large battle-royale example	100,000	4	about $165,217

These are Amazon’s calculator examples, not universal industry prices. They use specific AWS instances, regions, utilization assumptions and capacity buffers.

That is exactly why they are useful.

There is no meaningful answer to “what does an online game server cost?” without also asking what the server is doing.

At the smallest end, the direct server bill can be close to zero

Not every multiplayer game runs its simulation on studio-owned dedicated servers.

A small co-op title can use peer-to-peer networking, where one player’s machine effectively hosts the session and the developer provides only the surrounding services needed to help players find and connect to each other.

Epic Online Services currently offers peer-to-peer connectivity, sessions, lobbies and voice chat, and Epic says the vast majority of its online services are available without royalty or hosting fees.

That can make the developer’s direct multiplayer infrastructure bill extremely small.

It does not make networking free in an economic sense. The players supply the machines and internet connections, while the developer accepts an architecture with different limits around host migration, cheat resistance, latency and game authority.

For the right game, that trade can be excellent.

For a serious competitive shooter, it may be unacceptable.

One modest dedicated machine is still cheap. A fleet is not.

To see the next step up, take the c6a.large Linux instance in Amazon’s current GameLift card-game example.

AWS prices it at $0.099 per hour in the example’s Ohio region.

Running one continuously for an average 730-hour month is:

$0.099 × 730 = $72.27

So the raw compute behind a very small dedicated multiplayer service can genuinely begin in the tens of dollars a month.

But that $72 machine is not “the cost of running the game.”

It is one machine.

A production service may need several geographic regions, spare capacity for sudden demand, a database, authentication, player inventories, matchmaking, storage, metrics, backups, patch distribution and monitoring. A launch may also require far more capacity than an ordinary Tuesday afternoon.

The interesting part begins when one server becomes a fleet.

The real multiplication happens at concurrency

Suppose one server process can support 20 players.

At 100 concurrent players, the game needs capacity for roughly five server processes before allowing for unused slots and launch headroom.

At 10,000 concurrent players, it needs roughly 500.

Improve the server software enough to host 40 players on the same compute and much of that requirement can theoretically be cut in half. Make the simulation twice as expensive and the opposite can happen.

This is why optimization work on a live game can have unusually direct financial consequences.

The important variables include:

• how many players share a session;
• how many sessions can run on one machine;
• CPU and memory used by each session;
• average versus peak concurrency;
• how much spare capacity must remain ready;
• how quickly additional servers can start.

Game-server economics are partly a software-efficiency problem.

You deliberately pay for servers nobody is using

A perfectly efficient fleet would have every available slot occupied at all times.

It would also be miserable during a sudden player spike.

When an online game fills its existing capacity, new machines do not materialize instantly. AWS notes that starting new instances and game-server processes can take minutes. Its target-based GameLift autoscaling therefore allows developers to keep a percentage of sessions available as a buffer.

AWS explicitly describes the trade-off: a larger buffer reduces the chance that players wait for capacity, but increases the amount of infrastructure being paid for while idle.

That means some unused capacity is not waste.

It is inventory.

A launch-day fleet with no headroom can be cheaper right until thousands of paying customers arrive and cannot play.

More regions buy lower latency — and create more infrastructure

A multiplayer game does not only care about how much capacity exists. It cares where that capacity exists.

A player in Toronto, Frankfurt and Sydney cannot all be equally close to one data centre.

Competitive games therefore deploy fleets across multiple regions so that matchmaking can put players somewhere with acceptable latency. AWS and PlayFab both support geographically distributed game-server capacity for exactly this reason.

Every additional region complicates the efficiency problem.

A globally popular game may keep its North American fleet busy while a smaller regional fleet has spare capacity most of the day. Removing that quieter region saves money but gives its players worse latency.

There is no cloud setting that makes geography disappear.

Bandwidth can be either a major cost or nearly invisible on the invoice

Real-time games constantly transmit information between clients and servers.

The amount varies enormously.

A card game can send occasional actions and state changes. A fast server-authoritative action game may continuously send position, movement and combat information to every connected player.

Providers also bill networking differently.

Amazon currently says network bandwidth is free for generation-six and newer GameLift instance types. Microsoft’s PlayFab model, by contrast, explicitly meters both multiplayer VM instance hours and network egress, with prices depending on the server and datacentre involved.

So two technically similar fleets can produce different-looking invoices because one provider bundles a cost that another meters separately.

There is another form of bandwidth players notice much more clearly: downloading the game.

Patch day is infrastructure too

A 30 GB update downloaded by hundreds of thousands of players is not the same workload as a few kilobytes of gameplay state moving between players.

Game files, patches and large assets are normally distributed through content-delivery networks rather than directly from the machines running matches. AWS’s game architecture guidance explicitly places a CDN such as CloudFront in front of downloadable game clients, assets and other content.

That creates another cost curve:

players downloading update × update size = data that must be delivered

Ten thousand players downloading a 500 MB patch represents roughly 5 TB of downloads.

The same ten thousand players downloading a 20 GB patch represents roughly 200 TB.

The game’s CCU did not change at all.

Its distribution workload changed by a factor of 40.

This is why AWS separately recommends optimizing internet data-transfer costs with caching and CDN delivery rather than treating all network traffic as one bucket.

The “game server” is usually surrounded by another game

Persistent online games need systems that exist before and after the actual match.

A typical production backend can include:

System	What it is doing
Authentication	Identifying players and sessions
Matchmaking and lobbies	Deciding who plays together
Dedicated game servers	Running authoritative matches
Player database	Saving progress, inventories and account state
Economy services	Tracking currencies, items and purchases
APIs / server logic	Processing actions outside the match
Analytics	Recording events and diagnosing behaviour
Storage	Holding configurations, logs and content
CDN	Delivering patches and assets
Monitoring	Detecting failures and performance problems

This is why backend platforms charge for more than VMs.

PlayFab’s current pricing model meters categories including server instance hours, network traffic, server-side CloudScript execution and analytics consumption. It also separately meters services such as matchmaking and lobbies depending on the product and billing arrangement.

A game can therefore optimize its match servers beautifully and still create a surprisingly expensive backend by making enormous numbers of database, analytics or server-function calls.

Then there are the costs cloud calculators do not understand

Infrastructure calculators are good at multiplying instance-hours.

They do not run an online game.

Someone still has to:

• deploy updates;
• investigate outages;
• respond to abuse;
• handle support;
• maintain databases;
• monitor cheating;
• investigate exploits;
• review logs;
• restore broken services;
• prepare capacity for launches and events;
• keep old systems working after the engineers who built them have moved on.

A service with a $500 cloud invoice can still be expensive to operate if it repeatedly consumes engineering time.

At larger scale, the distinction becomes even more important. Running hundreds or thousands of server instances efficiently is itself a technical system. Autoscaling, observability, regional capacity and failure recovery require work regardless of whether the underlying machines are inexpensive.

The cloud bill is the easiest cost to see because it arrives as an invoice.

Human operational cost is easier to hide.

Why successful games can become cheaper per player

Scale does not only make bills larger.

It can make each player cheaper.

A studio can reduce cost per player by packing more simultaneous sessions onto each machine, using cheaper interruptible or Spot capacity where interruptions are tolerable, switching to more efficient processors, scaling quiet regions down, optimizing network traffic and moving suitable backend tasks to serverless infrastructure.

Amazon’s GameLift examples show this directly through Spot pricing. Its lightweight card-game model mixes On-Demand and Spot instances, while its published examples also calculate substantial potential savings from different capacity choices for larger games.

The basic metric is:

infrastructure cost per player-hour = monthly infrastructure cost ÷ monthly player-hours

That number is far more informative than simply reporting that “the servers cost $20,000.”

Twenty thousand dollars supporting a tiny audience is a disaster.

Twenty thousand dollars supporting millions of hours of play may be extremely efficient.

So how much does an online game actually cost?

The honest range is enormous.

A peer-hosted multiplayer game using free online-service infrastructure can have almost no direct game-server cost.

One modest always-on dedicated instance can cost tens of dollars per month before the rest of the stack is added.

At scale, published cloud-provider examples move quickly into thousands, tens of thousands and more than $100,000 per month for the game-server fleet alone.

And none of those numbers automatically includes the people operating the service.

The useful budget therefore starts with five questions:

1. What is the expected average and peak CCU?
2. How many players can one server instance support?
3. How many regions need acceptable latency?
4. How much data does each player generate and download?
5. What persistent services must exist around the match?

Once those numbers exist, “server cost” stops being a mysterious tax attached to online games.

It becomes capacity math.

And for a live game, capacity is something you can design.