I've seen indie teams get destroyed by their own success. They launch, the game goes viral over a weekend, 15,000 players pile in, and Monday morning they wake up to a $12,000 AWS bill and $800 in revenue. Nobody warned them. The multiplayer tutorials all stop at "deploy your server." Nobody does the math out loud. So let's do it.
This isn't a scare piece. It's the calculation you should run before you build, not after you've already committed to an architecture. The numbers are more manageable than most indie developers fear, but only if you plan for them.
The Unit Economics of a Game Server
Everything starts with one question: how many players can one server handle?
The answer depends entirely on your game type. A 10-player match game runs one match per server instance. A 100-player battle royale also runs one match per server, just a bigger one with more CPU and bandwidth. A persistent MMO zone might handle 200-500 players on a single instance. Social games (idle, async, turn-based) can pack thousands of players on one server because most players aren't generating real-time inputs.
Here's a rough breakdown by game type:
- Real-time shooter (10-player matches): 10 CCU per server instance
- Battle royale (100 players, 20-min matches): 100 CCU per instance, but you only need it for 20 minutes at a time
- MOBA / 5v5 (30-40 minute sessions): 10 CCU per instance
- Survival / open world (32-64 players per server): 32-64 CCU per instance
- MMO zone server: 200-500 CCU per instance
- Turn-based / async multiplayer: 5,000-50,000 CCU per instance
Once you know your players-per-instance number, the math is straightforward: instances needed = CCU / players-per-instance. Round up, add 20% headroom for matchmaking buffers and partial fills.
Actual Instance Costs in 2026
On AWS, the workhorse instance for game servers is the c6g family (Graviton, ARM-based, best price/performance ratio for CPU-bound workloads):
// AWS instance costs (on-demand, us-east-1, 2026 approx.)
c6g.medium → 1 vCPU, 2GB RAM → ~$0.034/hour → $24/month
c6g.large → 2 vCPU, 4GB RAM → ~$0.068/hour → $49/month
c6g.xlarge → 4 vCPU, 8GB RAM → ~$0.136/hour → $98/month
c6g.2xlarge → 8 vCPU, 16GB RAM → ~$0.272/hour → $196/month
// Egress bandwidth: ~$0.09/GB after first 100GB
// (1,000 CCU streaming 50KB/s state = ~180GB/day = $16/day in egress alone)For a 10-player shooter with 100 concurrent matches (1,000 CCU), you need 100 server instances. At c6g.large, that's 100 × $49 = $4,900/month in compute, plus egress. Call it $5,500-6,000/month total for 1,000 CCU.
That works out to roughly $5.50-6.00 per monthly active player if those 1,000 CCU represent 1,000 different players. More realistically, if 5,000 players take turns playing across the day to average 1,000 CCU, it's about $1.10-1.20 per MAU.
The Breakeven Problem
Now you can ask the real question: does your monetization cover server costs?
If you sell the game for $10 and have no recurring revenue, server costs drain your upfront money permanently. A game that generates $10 × 5,000 sales = $50,000 one-time while costing $6,000/month in servers will burn through its revenue in about 8 months, then you're losing money every month while players continue playing a game they already paid for.
The math that actually works:
// Monthly revenue must cover monthly server costs
// At $1.10/MAU in server costs:
Paid game ($10, one-time): Need players to recoup over ~10 months
→ Breakeven if ARPU/10 > $1.10 per month ✓ (barely)
F2P with $2 ARPU/month: $2 - $1.10 = $0.90 gross margin per player ✓
F2P with $0.25 ARPU/month: $0.25 - $1.10 = -$0.85 per player ✗
Subscription ($5/month): $5 - $1.10 = $3.90 margin per player ✓✓The worst business model for a server-heavy multiplayer game is free-to-play with low ARPU. The best is subscription or premium pricing. Games like World of Warcraft ($15/month subscription) and many co-op games ($20-30 upfront) were accidentally well-designed for server economics.
The Viral Spike Problem
Here's the scenario that kills indie teams: you launch, you get featured somewhere, traffic spikes 50x over a weekend, and AWS auto-scaling does exactly what it's supposed to, spins up 50x as many servers, and sends you a bill that's 50x your normal cost. Except revenue didn't spike 50x, because 80% of those players were just curious and never paid.
The death spiral looks like this:
- Weekend spike: 10,000 CCU instead of normal 200 CCU
- Server bill for the weekend: ~$3,000
- Revenue from weekend: 200 new purchases × $10 = $2,000
- Net: -$1,000 for your "successful" viral moment
Three ways to protect yourself from this:
Hard CCU caps: Set a maximum concurrent player limit. When the server is full, new players join a waitlist. You lose viral momentum but protect your finances. Minecraft famously used this in its early days. It turned scarcity into hype.
Spot instances / preemptible VMs: AWS Spot, GCP Preemptible, and Azure Spot instances cost 60-90% less than on-demand but can be terminated with 2-minute notice. For batch-style game servers (a match finishes in 20 minutes anyway), this is usually acceptable. A terminated server means the match ends early; players re-queue. Not ideal, but manageable for games that aren't competitive-ranked.
Serverless game hosting: Platforms like Fly.io Machines, Railway, and Cloudflare Durable Objects bill by the millisecond, you only pay while a match is active. For a 10-player match that lasts 15 minutes, you pay for 15 minutes of compute, not 24 hours. At 100 matches/day with 15-minute sessions, that's 25 instance-hours versus 2,400 instance-hours for an always-on server. The per-instance-hour cost is higher, but the total cost can be 10x lower for bursty workloads.
Managed Multiplayer Platforms: Paying for Simplicity
Raw cloud infrastructure is the cheapest option at scale. Below a certain scale, managed platforms are often cheaper once you factor in engineering time. Running your own dedicated servers on AWS means someone has to manage auto-scaling, health checks, regional deployment, and failover. That's real engineering hours, every month.
The managed multiplayer landscape in 2026:
- Photon (PUN/Fusion): $95/month for 100 CCU, $350/month for 500 CCU. Includes matchmaking, relay, and SDKs for Unity and Unreal.
- Nakama (self-hosted or cloud): Open-source with commercial support. Self-hosted on a $50/month VPS works well below 500 CCU.
- AWS GameLift: Managed game server hosting on AWS. ~20-30% markup over raw EC2 but handles fleet management automatically.
- Edgegap: Edge-based game servers with 1,000+ deployment locations. Good for games where latency variance across regions is the primary problem.
No-code and AI platforms like Chatforce help with the earliest part of this process: turning an idea into something playable enough to evaluate. Developer-focused options like Nakama and Colyseus Cloud take over when the prototype needs a real server model. If you're testing a multiplayer concept, do not buy infrastructure complexity before you know the loop deserves it.
Regional Deployment: The Hidden Cost
Your server in us-east-1 has great latency for North American players and terrible latency for everyone else. A player in São Paulo connecting to Virginia gets ~130ms. In Tokyo, ~230ms. For most games, this is the difference between playable and unplayable.
The responsible approach is to deploy in at least 3 regions: North America, Europe, and Asia-Pacific. That triples your infrastructure costs. For an early-stage game with mostly North American players, you can defer this, but you need to plan for it in your budget.
A practical compromise: deploy your matchmaking and lobby services globally (these are lightweight), but deploy game servers only in regions where you have meaningful player populations. Don't spend $1,500/month on empty Asian servers because you might get Asian players. Deploy when you have the data showing the demand.
The Budget Framework
Here's the back-of-envelope calculation I use when someone asks me to sanity-check their server budget:
// Inputs
const targetCCU = 1000; // Your peak concurrent users
const playersPerServer = 10; // Depends on your game type
const instanceCostPerMonth = 49; // c6g.large on AWS
const egressCostPerPlayer = 2; // ~$2/player/month for typical game
const managedOverhead = 1.2; // 20% overhead for load balancers, databases
// Monthly compute cost
const serversNeeded = Math.ceil(targetCCU / playersPerServer) * 1.2;
const computeCost = serversNeeded * instanceCostPerMonth;
const egressCost = targetCCU * egressCostPerPlayer;
const totalMonthly = (computeCost + egressCost) * managedOverhead;
// → 1000 CCU × $0.30-0.40 = $300-400/month... not $12,000Wait, $300-400/month for 1,000 CCU? That's way less than the horror story numbers you hear. The difference is between peak CCU and total players. Most games have a peak-to-MAU ratio around 5-10%, meaning 1,000 CCU might represent 10,000-20,000 MAUs. At $350/month, that's $0.02-0.03 per MAU per month. Very manageable.
The horror stories come from teams who don't cap their auto-scaling, deploy in too many regions before they need to, choose over-provisioned instances, or forget that bandwidth costs money. Do the math first. The numbers are usually fine.
What to Actually Do
For most indie multiplayer teams, this is the right progression:
- Start with a managed platform (Photon, Nakama Cloud, or similar). $100-200/month gets you to 200-500 CCU without managing infrastructure. Validate your game's fun before optimizing costs.
- At 500+ CCU, run your own servers on a single VPS provider (Hetzner is 40% cheaper than AWS for raw compute, and great for EU players). Migrate the pieces you understand first.
- At 2,000+ CCU, architect for AWS/GCP with auto-scaling, spot instances, and proper fleet management. Now you have the revenue to justify the engineering time.
Server costs only bankrupt you if you don't plan for them. Run the numbers now, while you still have choices about how to design your architecture. The math is on your side, you just have to actually do it.