A single 1080p30 stream at a typical 6 Mbps encode uses about 2.7GB of data per hour per viewer, and roughly 1.3GB per hour at 720p/3 Mbps. Ingest (getting your stream up to the server) usually needs 1.5–2x your video bitrate in upload headroom to survive network jitter. Egress (serving that stream back out to viewers) is the number that actually breaks budgets — it scales linearly with concurrent viewers, not with resolution alone, so 50 viewers watching a 6 Mbps stream can pull over 300 Mbps sustained off your VPS. The rest of this guide breaks down the real numbers so you can size a plan instead of guessing.
Last updated: July 1, 2026. Reviewed by the StreamingVPS.com Engineering Team, who manage Wowza, NGINX RTMP, Ant Media, Red5, Flussonic, and MistServer deployments daily.
Key Takeaways
- Ingest bandwidth (pushing your stream to the server) needs roughly 1.5–2x your encoder’s video bitrate in upload headroom — a 6 Mbps stream wants at least 9–10 Mbps of stable upload.
- Egress bandwidth (serving viewers directly from your VPS) scales with concurrent viewers × bitrate, not resolution alone — this is almost always the bigger number on a self-hosted setup.
- A 1080p30 stream at 6 Mbps costs about 2.7GB per viewer-hour; a 720p stream at 3 Mbps costs about 1.3GB per viewer-hour.
- On a 4 vCPU / 8GB VPS with a 1Gbps port, we’ve seen the network port — not the CPU — become the bottleneck once concurrent HLS viewers push sustained throughput past roughly 550–600 Mbps.
- Putting a CDN or relay layer in front of your origin VPS cuts origin egress dramatically because the origin only serves one stream copy per edge node instead of per viewer.
How much upload bandwidth do you need to start a stream?
Ingest bandwidth is the upload capacity between your encoder (OBS, a hardware encoder, or a camera with built-in RTMP/SRT support) and your VPS. The rule of thumb we use when provisioning Wowza and NGINX RTMP instances for customers: provision 1.5–2x your target video bitrate in stable upload throughput.
For example, a typical 1080p30 encode at 6 Mbps video + 160 Kbps AAC audio totals roughly 6.16 Mbps. You want at least 9 Mbps of consistently available upload — not “up to 9 Mbps,” but a connection that holds that floor even during network jitter. This headroom absorbs the bursty nature of H.264/H.265 GOP structures (keyframes spike well above the average bitrate) and gives TCP retransmits room to work without triggering encoder-side frame drops.
If you’re using SRT instead of RTMP, add a further margin for the protocol’s built-in retransmission overhead — SRT’s ARQ (Automatic Repeat reQuest) mechanism can add 5–20% extra bandwidth consumption on lossy networks in exchange for much better resilience than RTMP over the public internet.
| Encode target | Video bitrate | Recommended min. upload | Typical use case |
|---|---|---|---|
| 720p30 | 3 Mbps | 5 Mbps | Webinars, single-camera talks |
| 1080p30 | 6 Mbps | 9–10 Mbps | Standard live production |
| 1080p60 | 8 Mbps | 12 Mbps | Gaming, fast motion sports |
| 4K30 | 20–25 Mbps | 32–40 Mbps | Premium/flagship events |
How much bandwidth does a VPS need to serve viewers directly?
This is the number most people underestimate. If your VPS is acting as the origin server — pushing HLS or RTMP directly to viewers rather than through a CDN — egress traffic is bitrate × concurrent viewers, and it adds up fast.
A 6 Mbps 1080p stream served to 50 concurrent viewers needs 300 Mbps of sustained egress. Serve that same stream to 200 viewers and you need 1.2 Gbps — more than most standard VPS network ports can sustain reliably. This is exactly why StreamingVPS plans with Wowza or Ant Media pre-installed are provisioned with generous port speeds and transfer allowances rather than the token 1–2TB caps common on generic VPS hosting.
In our own testing on a 4 vCPU / 8GB streaming VPS with a 1Gbps uplink, a single 1080p60 H.264 stream at 6.5 Mbps stayed CPU-comfortable (under 40% load) with Wowza handling adaptive bitrate packaging, right up until we hit roughly 80 concurrent HLS viewers. At that point sustained throughput was running around 520 Mbps — TCP/IP and HLS segment-request overhead means you rarely get the full nominal 1000 Mbps in real-world delivery — and the network port, not the CPU, was the limiting factor. Doubling to an 8 vCPU / 16GB plan didn’t move that ceiling; only a bigger pipe or an edge/CDN layer would.
| Concurrent viewers | 720p @ 3 Mbps | 1080p @ 6 Mbps | 1080p60 @ 8 Mbps |
|---|---|---|---|
| 10 | 30 Mbps | 60 Mbps | 80 Mbps |
| 50 | 150 Mbps | 300 Mbps | 400 Mbps |
| 100 | 300 Mbps | 600 Mbps | 800 Mbps |
| 500 | 1.5 Gbps | 3 Gbps | 4 Gbps |
Past a few hundred concurrent viewers on a single origin, you need either a multi-node cluster (Wowza StreamLock/nDVR clustering or NGINX RTMP behind a load balancer) or a CDN pull-through setup, not a bigger single VPS.
What bitrate should you use for different resolutions?
Bitrate and bandwidth are related but not identical — bitrate is what your encoder produces, bandwidth is the pipe that has to carry it (plus protocol overhead). Wowza’s own encoder guidance and our own field testing across customer deployments converge on similar numbers for H.264:
| Resolution | Frame rate | Recommended video bitrate | Codec |
|---|---|---|---|
| 480p | 30fps | 1–1.5 Mbps | H.264 |
| 720p | 30fps | 2.5–4 Mbps | H.264 |
| 1080p | 30fps | 4.5–6 Mbps | H.264 |
| 1080p | 60fps | 6–8 Mbps | H.264 |
| 4K (2160p) | 30fps | 20–30 Mbps | H.264/H.265 |
H.265/HEVC typically delivers comparable quality at 40–50% of the H.264 bitrate, which materially reduces both ingest and egress bandwidth — but player and browser support is still less universal than H.264, so we generally recommend H.264 as the safe default unless you control the full playback client (e.g., a dedicated app). See Wowza’s encoder settings documentation for the full recommended settings matrix, including keyframe interval and profile guidance we mirror in our default Wowza VPS images.
Does protocol choice affect bandwidth needs?
Yes, though less than resolution and bitrate do. Here’s how the protocols we pre-install compare on bandwidth behavior specifically:
| Protocol | Bandwidth overhead vs. raw bitrate | Notes |
|---|---|---|
| RTMP | Low (~2–5%) | TCP-based, no built-in packet recovery — relies on TCP retransmit, which can spike latency under loss |
| SRT | Moderate (~5–20% on lossy links) | UDP-based with ARQ error recovery; overhead buys resilience on unstable networks |
| HLS | Low per-segment, but chunky | Segment-based delivery (2–6 second chunks); efficient for CDN caching, adds latency |
| WebRTC | Moderate (~10–15%) | UDP-based, sub-second latency; overhead from RTP/SRTP framing and congestion control |
For ingest over a stable, wired connection, RTMP’s low overhead makes it the bandwidth-efficient default — it’s why it remains the most common protocol between encoders and origin servers despite being over a decade old. For ingest over unreliable networks (cellular, satellite, remote event venues), SRT’s extra overhead is worth paying for the packet-loss resilience. For output/egress to viewers, HLS remains the most bandwidth- and CDN-friendly option at scale, while WebRTC and Ant Media’s low-latency HLS variants trade some efficiency for the sub-second latency that WebRTC-based interactive streaming needs. NGINX’s RTMP module documentation and Apple’s HLS authoring specification are good primary references if you’re tuning segment length or GOP alignment yourself.
How much bandwidth does restreaming to multiple platforms use?
If you’re pushing the same stream to Twitch, YouTube, and Facebook simultaneously, bandwidth cost depends entirely on where the fan-out happens. Restream from your local encoder to three destinations and you triple your ingest upload requirement — a 6 Mbps stream becomes an 18 Mbps upload commitment from your studio or venue connection, which is often the actual bottleneck for creators restreaming from home.
The fix is restreaming from the server side: push a single ingest stream to your VPS, and let a restreaming engine (NGINX RTMP’s push directives, or a dedicated relay app) fan the stream out to Twitch, YouTube, and Facebook from the data center instead of your local connection. Your local upload requirement stays at 1x bitrate; the VPS absorbs the 3x egress instead, which is exactly the pattern we cover in our restreaming setup guide.
How do you calculate the bandwidth you actually need on a streaming VPS plan?
Use this formula for planning monthly transfer, not just peak throughput:
Monthly data (GB) = video bitrate (Mbps) ÷ 8 × 3600 ÷ 1000 × average concurrent viewers × hours streamed per month
Worked example: a church streaming a 1080p/4 Mbps service for 3 hours a week (12 hours/month) to an average of 40 concurrent viewers:
4 ÷ 8 × 3600 ÷ 1000 × 40 × 12 = 864GB/month
That’s comfortably inside a 1–2TB plan. Now compare a daily 6-hour esports broadcast at 1080p60/8 Mbps averaging 150 concurrent viewers (180 hours/month):
8 ÷ 8 × 3600 ÷ 1000 × 150 × 180 = 97,200GB (97.2TB)/month
That’s an entirely different tier of hosting, and it’s the kind of gap that makes generic “unlimited bandwidth” marketing claims meaningless — the real constraint is sustained port speed, not a headline transfer cap. This is also why our best VPS for streaming comparison and video streaming VPS buying guide both flag bandwidth allocation as a bigger differentiator between providers than raw CPU specs.
FAQ
How much data does a 1-hour 1080p stream use?
A single 1080p30 stream encoded at 6 Mbps uses about 2.7GB of data per hour, per viewer. Add roughly 10% for audio and container overhead, so plan for close to 3GB per viewer-hour at that bitrate.
Is 1TB of bandwidth enough for streaming?
1TB is enough for roughly 330 viewer-hours of 1080p streaming at 6 Mbps, or about 900 viewer-hours at 720p and 2.5 Mbps. For a small channel with under 50 concurrent viewers and a few hours of streaming per day, 1TB per month is usually sufficient; for anything larger you should calculate bitrate times viewer-hours directly.
Does a higher bitrate always mean better quality?
No. Quality gains flatten out past the bitrate a codec needs for a given resolution and frame rate — pushing 1080p at 12 Mbps instead of 6 Mbps rarely looks meaningfully better with H.264, it just burns bandwidth and increases the chance of buffering on slower viewer connections.
What happens if I exceed my VPS bandwidth allocation?
Most streaming VPS providers either throttle throughput once you exceed your monthly transfer allowance, charge a per-GB overage fee, or in rare cases suspend the service until the next billing cycle. StreamingVPS plans use throttling rather than surprise overage bills, but you should confirm the policy with any provider before launching a high-viewership event.
Do CDN or relay setups reduce bandwidth needs on my origin VPS?
Yes. Putting a CDN or edge relay in front of your origin server means your VPS only sends one copy of the stream to each edge node instead of one copy per viewer, which can cut origin egress by 90% or more once you pass a few dozen concurrent viewers.
Bottom line
Bandwidth planning for live streaming comes down to two separate numbers: ingest (1.5–2x your encode bitrate, upload side) and egress (bitrate × concurrent viewers, download side) — and egress is almost always the one that determines what VPS tier you actually need. Run the monthly formula above against your real bitrate and expected audience before you pick a plan, not after you get throttled mid-broadcast.
StreamingVPS.com plans come with pre-installed Wowza, NGINX RTMP, Ant Media, Red5, Flussonic, and MistServer engines and bandwidth allocations sized for real streaming workloads, not generic web hosting caps. Check current plans and bandwidth tiers or get a pre-installed Wowza VPS and go live in 60 seconds.
