Bandwidth Calculators: How Pooled Allowances and Overage Actually Work

A bandwidth calculator exists because bandwidth is rarely billed per server: allowances pool across your account, only outbound traffic counts, and the overage rate applies to the total rather than to any one machine.

That pooling is the part people get wrong, and it works in your favour. Ten small instances each with a modest allowance do not each get metered separately; their allowances add up into one account pool, and you pay overage only if the combined outbound transfer exceeds the combined allowance.

So a busy server sitting next to nine quiet ones may cost nothing extra. Understanding the arithmetic is what turns a bandwidth line from a surprise into a number you can predict.

What counts, and what does not
Estimating your own transfer
Where unexpected bandwidth actually comes from
Reading your actual usage rather than estimating
Reducing bandwidth, in order of return
How this fits the rest of the stack
FAQ

What counts, and what does not

The single most useful thing to know is that inbound traffic is generally free and outbound traffic is what you pay for. That asymmetry shapes everything.

Typically billable:

Responses your server sends to the public internet: HTML, images, JavaScript, API payloads, file downloads, video.
Traffic from object storage out to the internet, which is often billed on a separate meter with its own allowance.
Traffic between regions, even between machines you own.

Typically not billable:

Inbound requests and uploads from users to your server.
Traffic on a private network between machines in the same datacentre, which is the reason to put your database on the private interface rather than reaching it over its public address.
Traffic to and from a provider’s own managed services within the same region, though this varies and is worth confirming.

That private network point is worth acting on immediately if you have not. An application talking to its database over a public address is paying egress for every query result, and getting worse latency and a larger attack surface in exchange for nothing.

Estimating your own transfer

The arithmetic is straightforward once you know which numbers to gather.

monthly egress  =  (average page weight x page views)
                +  (average API response size x API calls)
                +  (average file size x downloads)
                +  (video bitrate x seconds watched)

Get page weight from your browser’s network panel with the cache disabled, taking the total transferred rather than the resource size, because compression matters and the two figures differ substantially.

A worked example. A site averaging 1.8MB per page at 80,000 monthly views is about 144GB. Add an API serving 400,000 calls at 12KB each, which is roughly 5GB. Add 2,000 PDF downloads at 3MB, which is 6GB. Total around 155GB.

Then apply the plan. On RunxBuild, static sites include 120GB and bill $0.10/GB beyond it, so that site would see about $3.50 of bandwidth. On a metered-from-the-first-byte provider the same traffic is billed in full, and the difference between the two models at this volume is more than the difference between most plan tiers.

Two adjustments worth making to any estimate. Multiply by 1.3 for a safety margin, because real traffic includes bots, retries and repeat loads you did not count. And check whether your video or media is genuinely being served by you, since a single embedded video is often larger than everything else combined.

Where unexpected bandwidth actually comes from

When a bandwidth bill surprises someone, it is nearly always one of a short list, and almost never ordinary user traffic growing.

Uncompressed responses. Text compression is roughly a 70% reduction on HTML, CSS, JavaScript and JSON. Serving those uncompressed triples your text bandwidth for no reason. Check with a single request.
Unoptimised images. A photograph exported at full resolution and scaled down with CSS transfers every one of those bytes. Correctly sized modern formats routinely cut image bandwidth by 60% or more.
Missing cache headers. Assets re-downloaded on every page view instead of being served from the browser cache. This one multiplies with your traffic and is a one-line fix.
Hotlinking. Another site embedding your images and billing you for their traffic. Check your logs for requests with an unfamiliar referrer.
Scrapers and bots. Frequently a substantial fraction of total transfer, and entirely invisible in analytics, which usually only counts human page views.
Backups or logs shipped out of the region. A nightly database dump to a bucket elsewhere is real egress and nobody counts it in the page-weight estimate.

Check compression first. It takes thirty seconds and is the most common finding:

curl -sI -H "Accept-Encoding: gzip, br" https://example.com/ | grep -i content-encoding

No content-encoding header on a text response means you are paying roughly triple for every byte of it.

Reading your actual usage rather than estimating

Estimates are for planning. Once you are live, measure, because the estimate will be wrong in a direction you did not predict.

Read outbound bytes at the interface, which is the ground truth regardless of what any dashboard says:

# Cumulative bytes since boot, per interface.
cat /proc/net/dev

# Or with a summary by day, if vnstat is installed.
vnstat -d
vnstat -m

Then break it down by what is being served. Your access log has the response size in it, so a short aggregation tells you which paths are actually consuming your allowance:

# Top paths by total bytes served, from a combined-format access log.
awk '{bytes[$7] += $10} END {for (p in bytes) print bytes[p], p}' access.log \
  | sort -rn | head -20

This is usually revealing. The path consuming the most bandwidth is frequently not a page at all, but one large asset, one API endpoint returning more than it needs to, or a file being downloaded far more than anyone expected.

Reducing bandwidth, in order of return

Ordered by bytes saved per hour of effort.

Enable text compression. Minutes of work, roughly 70% off all text responses.
Fix images. Correct dimensions, modern formats, and lazy loading below the fold. Usually the largest single saving on a content site.
Set long cache lifetimes on hashed assets. Immutable caching means repeat visitors download nothing.
Trim API responses. Returning fields nobody reads is bandwidth spent on data thrown away. Pagination and field selection both help.
Move large media to storage designed for it, and check whether it has its own allowance and rate.
Block scrapers you can identify, and rate limit the ones you cannot.

The first three are usually an afternoon and frequently halve a bandwidth line. It is one of the rare optimisations that improves cost and page speed at the same time, which makes it easy to justify.

The response headers documentation covers setting cache and compression headers on RunxBuild static sites, which is where most of the saving is available.

How this fits the rest of the stack

Bandwidth is only one line, and it is hard to judge in isolation from the compute, the database and the storage sitting next to it. The RunxBuild hosting calculator shows those together with the 120GB included on static sites and the $0.10/GB rate beyond it, so the transfer estimate becomes part of a total rather than a separate worry you address after the first invoice.

Useful related references:

FAQ

Is inbound bandwidth billed?

Usually not. Most providers bill outbound transfer to the internet and treat inbound traffic as free, which is why uploads generally cost nothing while downloads and page responses do. Traffic on a private network within the same region is also typically free, which is a good reason to reach your database over the private interface.

Do bandwidth allowances pool across an account?

On many providers, yes. Each instance contributes its allowance to an account-level pool, and overage applies only when total outbound transfer exceeds the total allowance. That means one busy server beside several quiet ones often costs nothing extra, which is the main thing a bandwidth calculator is showing you.

How do I estimate my monthly bandwidth?

Multiply average page weight by monthly page views, then add API responses, file downloads and any video. Take page weight from your browser’s network panel with the cache disabled, using the transferred figure rather than resource size. Add roughly 30% for bots, retries and repeat loads.

Why is my bandwidth usage higher than my analytics suggest?

Analytics counts human page views; bandwidth counts every byte leaving the server. Bots, scrapers, monitoring checks, API traffic, hotlinked images and backups shipped out of the region all consume transfer and appear in none of your visitor reports.

What is the fastest way to reduce bandwidth costs?

Enable text compression, which cuts HTML, CSS, JavaScript and JSON by around 70% and takes minutes. Then fix image sizes and formats, and set long cache lifetimes on hashed assets. Those three commonly halve a bandwidth line and improve page speed at the same time.