Game infrastructure

What a multiplayer game backend costs

Two numbers, not one — what it costs to build, and what it costs every month afterwards.

Short answer. A multiplayer backend is quoted against your peak concurrent players, not your registered users or your monthly actives — those are different numbers, frequently two orders of magnitude apart, and only the first one decides what has to be built. There are two costs to plan for. The build runs $40,000–$90,000, priced by development time — the architecture at 1,000 CCU and at 50,000 CCU are different systems rather than different sizes of one, so the target sets the scope, the scope sets the weeks, and the price follows the weeks. And the monthly infrastructure run cost, which is calculable in advance and which most studios underestimate by a factor of three. So it is calculated below rather than described: on AWS list prices, a server-authoritative backend at 30 Hz costs roughly $1,200 a month at 500 peak concurrent players, $6,900 at 5,000, and $48,000 at 50,000 — and at the top of that range egress alone is more than half the bill. Below is how both numbers are put together, so you can sanity-check any quote you receive — from us or from anyone else.

Why nobody can quote this from a one-line brief

Ask five studios what a multiplayer backend costs and you get five ranges so wide they are useless, for one honest reason: the same phrase covers a turn-based card game synchronising four players every few seconds and a shooter reconciling authoritative state for sixty players at 30 Hz. Those differ by two orders of magnitude in engineering effort and in running cost.

So the first job of a scoping conversation is not to produce a number. It is to establish four facts, after which a number is straightforward:

Any quote produced without those four is a guess dressed as an estimate, and it will be revised upward.

What the build is actually made of

Within that $40,000–$90,000, a backend quote decomposes into work packages that are individually easy to reason about — and because the price tracks development time, a package you drop is weeks you do not pay for. Roughly in order of size:

PackageWhat it isWhat makes it bigger
Session and state authority The services that own game state and are the only writers to it Update rate, authority model, number of distinct stateful entities
Matchmaking Queueing, skill or party constraints, region and latency awareness Constraint count. Skill plus party plus region plus mode is not four times one constraint, it is worse
Persistence and economy Inventory, progression, purchases, anything a player would file a ticket about Idempotency and audit requirements, storefront and platform integrations
Live ops surface Events, seasons, remote config, the tools the ops team uses at 3am How much can be changed without a client patch
Scale and reliability work Autoscaling, load simulation, connection draining, observability The CCU target, almost entirely
Platform and compliance Console certification, store integration, age gating, data residency Console platforms specifically — certification is a fixed, non-negotiable cost

The package studios most often cut and most often regret cutting is the fifth. It is the one with no visible feature attached to it, and it is the one that decides whether launch week is a celebration or an incident. On the project behind our 52,000 peak CCU case study, load simulation ran every sprint from the first vertical slice, which is the direct reason the first real traffic peak was uneventful.

What it costs to run, per month

Run cost is the number that gets left out of budgets, and unlike build cost it is genuinely calculable in advance. It has three dominant components:

Compute for the session tier

Scales with concurrency and update rate. A stateless edge tier plus authoritative session services is cheap per player at low update rates and expensive at high ones — the difference between a 1 Hz turn-based sync and a 30 Hz authoritative simulation is thirty times the message volume before you have written a line of game logic.

The in-memory event fabric

Sized by the working set of live sessions rather than by total players. Because it holds only what is currently in flight, it typically stays modest even at high CCU — provided nobody has quietly started using it as a database, which is the failure mode to watch for.

Egress bandwidth — the one people forget

This is the line item that surprises studios, because it does not appear until there is real traffic and it scales with the product of player count and update rate. The arithmetic is message size times update rate times concurrent players times seconds in a month, against your provider's per-gigabyte rate — and it is worth doing once, early, because the answer usually changes at least one design decision: the update rate, or how much state is delta-encoded rather than sent whole. It is done below.

What that comes to, in dollars

The three components above, priced. Every figure is AWS EU (Frankfurt) on-demand list price, read on 28 August 2026 from the price files AWS publishes itselfEC2 on-demand for the nodes and the AWS data transfer price list for egress. This is not a quote from us. It is the bill a cloud provider sends you, in your own account, before anybody's fee.

Five assumptions carry the model, and they are the part worth arguing with:

Per month500 peak CCU5,000 peak CCU50,000 peak CCU
Session tier (autoscaled)$240$1,690$16,850
Stateless edge$120$240$960
Redis event fabric$190$380$1,130
PostgreSQL$190$380$1,130
Observability$60$120$360
Egress at 12 kB/s per player$430$4,070$27,540
Total~$1,230~$6,880~$47,980

The fleet behind those numbers, at 50,000 peak CCU: 35 x c7g.4xlarge for the session tier, 8 x c7g.xlarge on the edge, 3 x r7g.2xlarge each for Redis and PostgreSQL, 3 x c7g.xlarge for metrics and logs, and 462 TB of egress. At 500 peak CCU it is two c7g.xlarge, two c7g.large, and two r7g.large each for Redis and PostgreSQL — sized for a second node rather than for load, because one node is not a tier.

Notice which line grows fastest. Compute rises 70-fold between the first column and the last; egress rises 64-fold and ends up larger than everything else combined. That is why the update rate is a budget decision and not only a gameplay one:

Egress alone, by outbound per player500 peak CCU5,000 peak CCU50,000 peak CCU
2 kB/s — turn-based, ~1 Hz$71$710$6,340
4 kB/s — 10 Hz, small sessions$142$1,390$11,780
12 kB/s — 30 Hz, 60-player sessions$430$4,070$27,540
24 kB/s — 60 Hz or thin delta encoding$850$7,440$51,200

A turn-based title at 50,000 peak CCU therefore runs at roughly $27,000 a month rather than $48,000, on identical compute. Halving the update rate is the single cheapest lever on the monthly bill, and it is available for free at design time and expensive afterwards.

Two sanity checks against numbers that are not ours, because a cost model published by the party selling the work deserves them. KinematicSoup measured about $1,465 a month for a 32-player 3D shooter at roughly 1,000 peak CCU, which sits just above our 500-CCU column, as it should. AWS's own GameLift pricing example, at 50,000 peak CCU and the same 30% average, lands well above our 50,000 column — managed orchestration costs more than running your own, which is the trade that page exists to describe.

What the table excludes, deliberately: our fee or anyone else's, game-client and patch distribution, console platform costs, third-party services such as anti-cheat, analytics and crash reporting, and committed-use discounts. On-demand list price is the ceiling; a one-year commitment on the steady part of the fleet is the obvious first cut, and reserved capacity does not apply to egress at all, which is the line you would most want it to.

The three decisions that move both numbers most

  1. The CCU target you commit to on day one. Designing for 50,000 when your realistic first-year peak is 5,000 inflates the build and the monthly bill together. Design for the peak you will actually hit, with a clean path to the next tier — see what breaks, in order, on the way to 50k.
  2. Whether the client or the server is authoritative. Client authority is dramatically cheaper and is the right answer for co-operative and casual titles. For anything competitive it is not a cost decision at all — it is a decision about whether the game is cheatable, and retrofitting server authority afterwards is close to a rewrite.
  3. How much live ops can change without a patch. Remote config and server-driven content cost real money to build and pay it back in every subsequent season. Studios that skip this pay for it in engineering time for the life of the title.

Getting a real number for your title

We quote managed backend delivery per project against your concurrency target, and we publish what we can: our pricing page carries the bands for the work that can honestly be banded, and states plainly which work cannot. A free 30-minute call establishes the four facts at the top of this article, and a written scope with a fixed price against it follows within 48 hours.

If the honest answer is that your title does not need a custom backend — and for a meaningful share of projects a managed service is the correct call — we will say so on the call rather than in month three.

Common questions

Three that come up as soon as the figures above are read as a quote.

By peak concurrent players. Registered users and monthly actives do not determine what has to be built; the number of players connected at the same moment does. A title with two million registered players and a 3,000 peak CCU needs a smaller backend than a title with 80,000 registered players and a 12,000 peak CCU during a scheduled event.
On AWS EU (Frankfurt) on-demand list prices, a server-authoritative backend at 30 Hz costs about $1,200 a month at 500 peak concurrent players, about $6,900 at 5,000, and about $48,000 at 50,000. The dominant line items are compute for the session tier and egress bandwidth: at 50,000 peak CCU egress is roughly $27,500 of that $48,000, and it is the item most often left out of estimates entirely because it scales with the product of player count and update rate. A turn-based title moving 2 kB/s per player instead of 12 kB/s pays about $6,300 of egress at the same concurrency, which brings the total nearer $27,000. The arithmetic assumes average concurrency at 30 per cent of peak, 1.5x headroom, 40 players per vCPU, and Redis and PostgreSQL self-hosted rather than managed.
Partly. Scaling from 500 to 5,000 concurrent players is usually a matter of adding capacity. Scaling from 5,000 to 50,000 generally is not: it means moving session state out of process and off the relational database, which is a re-architecture of the service boundary rather than a change to it. The cheap decision to make early is to keep state ownership clean; the expensive one is to build for a peak you will not reach for two years.

Want the number for your title?

Tell us your peak CCU target, update rate, and launch window. We will come back with a scope and a fixed price inside 48 hours, or tell you that an off-the-shelf service does the job.

Message received

We’ll review your enquiry and respond within one business day.

Related reading