Bandwidth is the specification people worry about least and get billed for most unexpectedly. A game server's traffic is small per player and relentless, which is a shape that catches out anyone reasoning from web hosting.
The arithmetic
A game server sends every connected player a stream of updates, many times a second, forever. The per-player rate is what matters, and it is set by the game's tick rate and how much state each update carries.
Rough per-player figures, both directions combined:
| Game | Per player | 32 players, sustained |
|---|---|---|
| Counter-Strike 2 (64 tick) | 60–120 kbps | ~2–4 Mbps |
| Team Fortress 2 | 40–80 kbps | ~1.5–2.5 Mbps |
| Minecraft (vanilla) | 20–60 kbps | ~1–2 Mbps |
| Rust | 100–200 kbps | ~4–6 Mbps |
| FiveM roleplay | 80–150 kbps | ~3–5 Mbps |
| Squad / Hell Let Loose | 150–250 kbps | ~6–8 Mbps |
Those are averages under normal play. Peaks run considerably higher — a firefight with everyone visible to everyone is the worst case, and Minecraft's worst case is a player flying across unexplored terrain pulling chunks.
The headline number is small. A busy 32-slot shooter is a few megabits. Almost any connection can carry that.
Where the bill comes from
The problem is not the rate; it is the integral. A few megabits, continuously, for a month, is a large number of gigabytes.
A server averaging 3 Mbps both ways for 30 days is roughly 950 GB. Sustained 6 Mbps is closer to 1.9 TB. Neither is exotic for a mid-sized community, and both exceed the included transfer on a surprising number of budget VPS plans.
This is the mechanism behind the "cheap VPS that got expensive" story. The plan advertised 1 TB, the server used 1.4, and the overage was billed per gigabyte at a rate set for people who never hit it. It is worth checking the transfer allowance with the same attention as the CPU, which is otherwise the specification that actually matters most.
What is not in that arithmetic
Three things add traffic the per-player estimate misses.
Downloads. Any game where the server ships custom content to clients — Source games with FastDL, Garry's Mod addons, Minecraft resource packs — moves far more data on join than in play. A Garry's Mod server with a large addon set can send a new player several hundred megabytes before they have moved. With turnover, that dwarfs the gameplay traffic. This is why FastDL on a separate host exists at all.
Queries. Every directory, monitoring tool and server browser asks your server for its status on a schedule. Individually tiny; collectively, on a well-listed server, a constant background hum. It is small enough not to matter for cost and large enough to matter for rate limiting, which is a different problem with the same cause.
Attack traffic. A denial-of-service attempt is billed as transfer on most providers, and it does not care that you did not want it. This is the single largest unbudgeted bandwidth event most operators ever see, and it is the reason DDoS protection is worth having as insurance against the invoice as much as the downtime.
Upload is the constraint, not download
For a server the direction that matters is outbound: the server sends world state to every player, and receives comparatively little back. A player sends their inputs; the server sends everybody else's consequences.
That asymmetry is why home hosting fails on connections that feel fast. A domestic line advertised as 500 down and 20 up has plenty of headroom to watch things and very little to serve them, and it is the upload figure that caps how many players a home server can carry. Anyone weighing that option should check the upload figure on their own line before buying anything, because it is the number that caps the room.
Latency is not bandwidth
The two get conflated constantly and they are unrelated.
Bandwidth is how much data fits through per second. Latency is how long a single packet takes to arrive. A server with abundant bandwidth and poor routing feels terrible; a server on a modest pipe with a direct route feels excellent.
Adding bandwidth does not reduce ping. What it prevents is the specific failure where the pipe saturates and packets queue — which players experience as everything being fine until a busy moment, then everything being briefly awful. That is the signature worth learning, because it points at bandwidth when almost every other lag complaint points somewhere else. Where the milliseconds actually go covers the rest of that diagnosis.
Estimating for a plan you have not bought
A workable method:
- Take the per-player figure for your game from the table above, or measure it on a test server with two people
- Multiply by your slot count, not your average population — you are sizing for the peak
- Double it, for downloads, queries and headroom
- Multiply by 2.6 million to get monthly gigabytes from megabits per second
A 32-slot CS2 server: 100 kbps × 32 = 3.2 Mbps, doubled is 6.4, which is about 2 TB a month. That is a very different plan from the 1 TB one that looked sufficient.
Most operators over-buy CPU and under-buy transfer, because the CPU number is on the front of the listing and the transfer number is in a footnote.
A saturated pipe is also one of the few lag causes that a listing's uptime figure will not show you: the server stays up and answers queries fine while play degrades.
Measuring what you actually use
Do not guess after the first month. vnstat on Linux gives per-interface monthly totals for essentially no overhead and is the simplest honest answer. Most control panels expose a graph, though the granularity is often too coarse to see a spike.
What you want to know is two figures: the monthly total, and the peak sustained rate. The first tells you whether the plan fits; the second tells you whether you will saturate at prime time. A server that averages 2 Mbps and peaks at 9 has a different problem from one that averages 8 flat.
The short version
A game server is a small, constant stream, and the cost is in the duration rather than the rate. Size for slots rather than average players, double the estimate for downloads and overhead, and check the transfer allowance as carefully as the processor.
Upload is the direction that limits you, latency is a separate axis entirely, and the bill that surprises people is almost always either custom content or an attack — neither of which appears in any per-player table.
Published · 5 min read