How to size bandwidth for live streaming

The first calculation is simple: expected concurrent viewers multiplied by stream bitrate. A 6 Mbps stream watched by 1,000 people creates a 6 Gbps base egress load before overhead.

Use the busiest expected window, not the monthly average. Streaming infrastructure usually fails during peaks, cache misses, or popular events rather than during normal traffic.

Leave capacity for protocol overhead, player retries, origin fetches, monitoring, OS traffic, and growth. A port that looks sufficient on a spreadsheet may still be uncomfortable if it runs close to saturation every evening.

If normal peak demand sits above roughly two thirds of the port, compare the next bandwidth tier or split the workload across a pool.

Bandwidth is only one constraint. Disk read throughput, cache hit ratio, CPU, GPU, middleware behavior, and viewer ISP paths can all limit delivery.

For direct streaming, storage and network usually dominate. For transcoding, CPU or GPU capacity often becomes the first limit.

If the server sends every viewer an 8 Mbps stream, the video payload is 1,500 × 8 ÷ 1,000 = 12 Gbps. To keep one quarter of a port free, divide by 0.75: the payload alone needs a 16 Gbps port budget. Add measured audio and protocol traffic if your bitrate excludes them.

That rules out a single 10 Gbps port for this example. A 20 Gbps server is a candidate, not a promise of 1,500 sessions. If a CDN serves the viewers, replace viewer egress with the traffic the edges actually fetch from the origin.