VPS Bandwidth Explained: How Much Do You Need?

The Network Graph Rose, but Bandwidth Wasn’t the Problem

One night, a network graph on a VPS started climbing in a way I did not like. I blamed a traffic spike first. Then mailq showed a growing queue, and the cron logs exposed my mistake: I had added an extra star to a backup job, so it ran every minute.

The backup script was creating work faster than the server could finish it. The lesson stayed with me: a busy network graph tells you how much data is moving, not why it is moving. That distinction matters when you choose a VPS.

CPU cores and RAM usually get your attention first. Bandwidth sits quietly in the plan table until traffic grows, a backup runs at the wrong time, or somebody shares a large file widely.

Two Numbers Hide Behind “Bandwidth”

VPS bandwidth usually refers to the amount of data your server can send to and receive from the internet over a given period. Providers normally describe this with two separate figures: connection speed in Mbps or Gbps, and a monthly data transfer allowance in GB or TB.

They are related, but they are not the same thing. Keep them separate when you estimate what you need.

You might have a 1 Gbps port with a monthly transfer limit of 2 TB. You might also get a generous monthly allowance while the connection is capped at 100 Mbps. The first number affects how quickly data can move at a particular moment; the second limits how much can move during the billing period.

Mbps and Monthly Traffic Measure Different Things

The first confusion usually comes from the units. Mbps means megabits per second. MB, which we use for file sizes, means megabytes. One byte is eight bits, so 100 Mbps theoretically equals 12.5 MB per second.

I say theoretically because TCP/IP and TLS headers, retransmissions, disk speed, and the other side’s connection all reduce the result. The speed a user actually sees is normally lower than the port capacity. For a rough calculation, this conversion is enough:

100 Mbps / 8 = 12.5 MB/s
12.5 MB/s × 3,600 = 45,000 MB/hour
45,000 MB × 24 × 30 = 32,400,000 MB/month
≈ 32.4 TB/month

This assumes a 100 Mbps connection stays fully occupied for 30 days. A website, API, or game server does not produce data continuously at that rate. Port speed is not a monthly traffic forecast.

Monthly transfer is the total amount of data sent and received during a particular month. Some providers count outbound traffic only. Others count inbound and outbound traffic together, or charge according to whichever direction is higher. Before you buy, check how traffic is defined and what happens when you exceed the allowance.

Inbound and Outbound Traffic

If a visitor downloads 3 MB of JavaScript and images from your website, that adds 3 MB to the server’s outbound traffic. The HTTP request sent by the browser is inbound traffic. On a conventional website, the request is usually much smaller than the response.

Uploading backups to the VPS increases inbound traffic. Sending them from the VPS to remote storage increases outbound traffic. Database replication, Docker image pulls, operating system updates, and video uploads belong in the calculation too. Visitor count alone is not enough.

Start With Measurements, Not a Guess

For a running VPS, I prefer measurements. For a new project, where an estimate is unavoidable, I write down each source of traffic separately. These are the categories I normally track:

• Outbound traffic from web pages, APIs, and static files
• File uploads and downloads
• Database replication and remote backups
• Operating system updates and container image downloads
• Monitoring, log shipping, and administration traffic
• Persistent connections such as game servers, media servers, and live streams
• Unexpected bot, scanning, and attack traffic

For each item, record the daily average, the busy-hour value, and unusual days in the month. An e-commerce site behaves differently during a campaign, an education platform during exam week, and a game server at the weekend.

The average alone is not enough. Peaks matter.

A Website Calculation

Suppose your site receives 100,000 page views per month. If each page produces an average of 4 MB, including HTML, CSS, JavaScript, and images, the rough calculation is:

100,000 × 4 MB = 400,000 MB
400,000 MB / 1,024 ≈ 390.6 GB/month

That is only the approximate cost of page views. Bots, repeated downloads without caching, the administration panel, API calls, and backups must be added separately. I normally leave at least 30 to 50 percent for operations; for a new project with uncertain traffic, I use a wider margin.

Adding a 50 percent margin to 390 GB gives approximately 585 GB of monthly web traffic. I would not choose a plan that matches that number exactly. Leave room for a busy day.

File Downloads Are Easier to Estimate

For an application that distributes files, the formula is more direct. Consider the file size, monthly download count, and repeat downloads together.

File size × monthly downloads = base transfer

If a 2 GB image file is downloaded 4,000 times per month, the base outbound traffic is 8,000 GB, or roughly 7.8 TiB. Headers and retries add some margin. Here, the provider’s monthly outbound traffic policy matters just as much as the port speed.

For very large files, consider object storage and a CDN. A CDN can serve content from locations closer to users, but the first fetches from the origin, cache expiry, and cache misses still generate traffic. A CDN does not make VPS traffic disappear.

Port Speed Depends on Your Busy Hour

Estimating the monthly allowance is one task. Estimating how many users you will serve at the same time is another. A site that consumes 500 GB per month does not automatically need a 1 Gbps port. If that traffic is spread across the day, a 100 Mbps connection may be sufficient.

For a rough busy-hour estimate, use this approach:

Data sent during the busy hour / 3,600 = required average MB/s
Required MB/s × 8 = required Mbps

For example, assume the server sends 18 GB during a busy hour:

18 GB × 1,024 = 18,432 MB
18,432 / 3,600 ≈ 5.12 MB/s
5.12 × 8 ≈ 41 Mbps

The average is approximately 41 Mbps. Because of bursts, concurrent downloads, and protocol overhead, I would not choose a 41 Mbps port with no headroom. The goal is not to keep the port full; it is to stop short peaks from building a queue.

The user’s connection can be the limiting factor too. A VPS with a 1 Gbps port cannot send a file to somebody on a 20 Mbps mobile connection at 1 Gbps. The bottleneck is not always on the server.

Connection Count Is Not Bandwidth

A web server accepting thousands of simultaneous connections does not mean thousands of high-speed transfers are happening. Keep-alive connections can remain open for a long time while carrying very little data. With WebSocket applications, game servers, and live streams, examine connection duration and data per second together.

For example, if 2,000 online users each receive 20 KB per second:

2,000 × 20 KB = 40,000 KB/s
40,000 × 8 / 1,000 ≈ 320 Mbps

Packet headers, message direction, and additional data sent by the server are not included in that rough calculation. If your game protocol uses UDP, packet loss and retransmission behaviour may also differ. For games and real-time applications, ask the provider about port capacity and network policy, not only the monthly TB figure.

Numbers help. Traffic patterns decide.

Measure VPS Traffic on Linux

Estimates are necessary for a new project. On a running VPS, though, I would rather stop guessing and measure. I use vnstat on most machines to see daily totals. The package version can differ between distributions, but the commands below are suitable for Debian and Ubuntu systems.

sudo apt update
sudo apt install vnstat
sudo systemctl enable --now vnstat
vnstat -d
vnstat -m

vnstat -d shows daily traffic, while vnstat -m shows monthly traffic. Do not expect useful history immediately after installation; its database needs time to collect measurements. The output separates RX and TX. If your provider counts total traffic, add the two values together.

When I need the current state, I check sar or the interface counters:

ip -s link show eth0
sar -n DEV 1 5

The RX and TX byte counters in ip -s link show totals since the interface came up. sar samples network statistics for five seconds. Your interface may not be called eth0; newer distributions often use a name such as ens3.

That extra star in my cron entry taught me not to diagnose from one graph. When the network rises, I now check the port, the queue, the cron logs, and the process producing the work.

Find the Process Behind the Traffic

Total traffic is only half the answer if you do not know where it comes from. For current connections, you can use iftop or nload. A simple starting point is:

sudo apt install iftop
sudo iftop -i eth0

iftop shows current connections, remote addresses, and transfer rates. The -i option selects the correct network interface (that flag matters). You will not see the contents of encrypted HTTP traffic, but you can see its source, destination, and rate.

For long-term observation, Prometheus and Grafana are more useful. In my Proxmox lab, node_exporter collects network counters from every machine. Comparing the daily TX increase with the CPU graph has helped me catch cases where a “slow site” complaint was actually a replication job running overnight.

Backups, Updates, and Logs Count Too

When a VPS has little web traffic, backups can account for most of its total transfer. Sending an 80 GB disk to remote storage every night represents roughly 2,400 GB of outbound traffic per month if the full amount is transferred each time. Compression and changed-data patterns can make the real figure lower.

rsync is useful when only changed files need to be transferred. If a large database dump is recreated from scratch every time, the savings are limited. borgbackup can reduce repeated data through deduplication and compression. I still measure the actual transfer instead of assuming compression means no bandwidth is being used.

Operating system updates and Docker images accumulate too, especially on servers that are rebuilt frequently. If every staging deployment pulls hundreds of megabytes of images, the monthly total may surprise you. Moving CI/CD work to a separate runner or using an image cache can reduce VPS traffic.

Sending logs to an external service consumes bandwidth as well. An application accidentally left at debug level creates unnecessary load on disk and network. Lower the log level, configure rotation, and forward only the records you need.

Backups are data movement. Treat them that way.

Read the VPS Plan Carefully

These terms do not describe the same thing:

When you see “unlimited,” read the terms of service before deciding. Some providers limit the port after high usage; others review unusual traffic. Acceptable-use rules matter particularly if you plan to run a backup server, proxy, or file distribution service.

Include overage costs in the price calculation. If your traffic is around 600 GB, the difference between a 1 TB and 2 TB plan is not only the monthly fee. It is also the safety margin left for a campaign day. The resource-planning approach in How to Reduce Cloud Costs: 10 Practical Optimization Tips applies here too.

Fix the Source Before Buying More Capacity

If you are approaching the traffic limit, do not automatically move to a more expensive VPS. First find out what is leaving the server. Converting large images to WebP or AVIF, fixing cache headers, reducing unnecessary API responses, and adding a CDN can produce a more direct result than adding CPU or RAM.

On a CMS such as WordPress, without page caching, every request runs through PHP and the database. That does not reduce bandwidth by itself, but it makes it harder for the same server to handle more requests. The caching and static-file approach in Tuning WordPress, Joomla & Drupal Speed & Performance is useful alongside bandwidth planning.

For file delivery, consider a CDN or object storage. For an API, consider response compression and pagination. For backups, use incremental transfers. Increasing capacity and reducing waste are separate tools.

Attack traffic should not be part of your normal usage estimate. Bad application-layer bots, an exposed proxy, or a UDP flood may not be solved by buying a larger port. I covered connection counters, upstream filtering, and rate limiting in What Is a DDoS Attack? A Practical VPS Protection Guide.

When One VPS Stops Being the Right Place

A content-heavy service can grow into a system where one VPS carries high outbound traffic all the time. Keeping the VPS for the application and API while moving large files to separate storage may be the more sensible design. You may not need to move the entire project elsewhere.

When comparing service models, also consider the division of responsibilities described in IaaS vs PaaS vs SaaS: Key Differences Explained. Operating effort, monitoring, and backup responsibility belong in the decision alongside network limits.

A Practical VPS Bandwidth Estimate

For your own project, I would work through these steps:

1. Measure the average size of a page or API response.
2. Determine the monthly number of requests, views, or downloads.
3. Add uploads, backups, updates, and log traffic.
4. Estimate data volume and concurrent users during the busiest hour.
5. Convert busy-hour data into seconds and calculate the required Mbps.
6. Leave room for protocol overhead, retries, campaigns, and growth.
7. Confirm how the provider counts RX and TX, and check overage rules and port sharing.
8. After the VPS is running, compare the estimate with measurements from vnstat and your monitoring system.

If you estimate 700 GB per month, do not plan to sit exactly on a 700 GB limit. Record the daily average, highest day, and busiest hour separately. If the estimate still disagrees with measurements after three months, revise your assumptions rather than blindly changing the formula.

For me, a useful capacity plan comes from knowing when traffic rises and which process caused it, not from choosing the largest number on a product page. Watch the counters for a week before changing the server. They usually have a better explanation than the plan table.

Frequently Asked Questions

Is VPS bandwidth the same as internet speed?

No. Internet speed usually refers to the port’s instantaneous capacity, while a bandwidth allowance describes the total amount of data that can be transferred during the month. A VPS with a 1 Gbps port can still have a low monthly transfer limit.

How much VPS bandwidth does a website need?

It depends on page size, monthly visitors, image and video usage, bot traffic, and your backup schedule. Multiply page size by monthly views, then add backups and a safety margin for a starting estimate.

Will a VPS be shut down if I exceed the monthly traffic allowance?

That depends on the provider’s policy. They may charge an overage fee, reduce your speed, suspend the connection, or review the traffic manually. Read the overage terms and acceptable-use rules behind any “unlimited traffic” claim before choosing a plan.

How can I monitor VPS traffic on Linux?

vnstat shows daily and monthly RX/TX totals, ip -s link shows interface counters, and iftop shows current connections. For long-term comparisons, sending these measurements to tools such as Prometheus and Grafana is more useful.