Bandwidth Allowances Across Cloud Providers

Three Ways Providers Sell You Traffic

Every cloud bill treats network traffic differently, but the arrangements reduce to three models. Recognising which one you are on explains most of the surprises.

Metered from the first byte. The hyperscaler default. Outbound traffic is measured and charged by volume, usually with different rates by destination, and a small monthly amount is excluded. Nothing is bundled with the instance, so a quiet server costs nothing in traffic and a busy one costs a great deal. This is the model the egress costs article deals with in detail.

An allowance included with the instance. The developer cloud default. Each instance size ships with a monthly transfer quota, and traffic beyond it is charged at a published overage rate. DigitalOcean, Linode, Vultr and Hetzner all work this way, with the allowance scaling by plan size.

A port speed with no hard volume cap. Common on dedicated servers and some European VPS ranges. You are sold a connection at a given speed, sometimes with a slower guaranteed rate, and traffic is governed by an acceptable use policy rather than a counter.

The models are not ranked. Metered billing suits low-traffic workloads that would never approach an allowance, and allowances suit steady, predictable delivery.

What Actually Gets Counted

Reading an allowance correctly means knowing which traffic it applies to. Four distinctions do most of the work.

The cross-zone row is the one that catches architecture teams. A design that spreads a database cluster across zones for availability may generate constant replication traffic that is metered even though it never touches the internet. That is not a reason to avoid multi-zone designs, but it belongs in the estimate rather than arriving as a line on the invoice.

The other detail worth confirming is measurement point. Providers count traffic at the hypervisor or network edge, which includes protocol overhead and retransmissions. Your application's own numbers will always read slightly lower than the provider's, and the gap is normal rather than a billing error.

Pooling, and Why It Changes the Arithmetic

On several providers the allowance is not per server. It is summed across the account and consumed collectively, so ten small instances share one combined pool.

That has a real design consequence. If allowances pool, a fleet of small instances gives you more total included traffic than a single large one, and a few idle machines effectively subsidise a busy one. If they do not pool, each instance is capped on its own and one hot server can go into overage while the rest of the fleet has untouched quota.

Three details to confirm for your provider, none of which are consistent across the industry:

• Whether allowances pool at all, and whether pooling is per region or per account.
• Whether the allowance is prorated for instances that existed for part of the month. Destroying and recreating servers frequently can earn less quota than it appears.
• What happens at the limit: an overage charge, a speed reduction, or a suspension. These are very different outcomes and only one of them is reversible by paying.

Read it from the provider rather than from a forum post, because this is the area where terms change most often. The DigitalOcean bandwidth billing documentation is a clear example of how the pooled model is described, and Hetzner's cloud server documentation sets out a different arrangement for comparison.

Estimating Your Own Number

Most teams guess badly because they think about page weight and forget everything else. Build the estimate from observed data instead.

Start with what the server already reports. vnstat -m gives a monthly summary per interface once it has been collecting for a while, and it is worth installing on day one of any new server precisely so the history exists later. For a quick current reading, cat /proc/net/dev shows cumulative byte counters per interface.

Then add the sources people forget:

• Backups leaving the server every night, which on a file-level repository can exceed all user traffic combined.
• Container image pulls on every deploy, multiplied by the number of instances.
• Log and metric shipping to an external service, which is small per event and relentless.
• Database replication to a replica in another zone or region.
• Bots, scrapers and preview crawlers, which are a genuine fraction of traffic on any public site.

Finally, size for the peak rather than the average. An allowance is monthly, but a launch, a viral link or a bad crawler can consume a large share of it in a day, and the alert needs to fire while you can still act. Fold the counter into the same alerting you use for everything else, as described in the monitoring guide.

Reducing the Number Before Buying More

Traffic is one of the few bills that responds well to straightforward engineering.

Put a CDN in front of anything static. It moves the bulk of delivery off your origin entirely, and CDN traffic is usually cheaper than instance egress or excluded from it altogether. The CDN basics article covers how to set the cache headers so this actually happens.

Then work through the unglamorous list. Enable compression for text responses. Serve images at the size they are displayed and in a modern format. Set long cache lifetimes on fingerprinted assets so repeat visitors fetch nothing. Move backups to a target on the same private network where that traffic is free. Pull container images from a registry in the same region as the instances that deploy them.

Where sustained volume is the whole business, choose the provider for it deliberately. Hosts that sell generous allowances or plain port speed suit media delivery and download-heavy services better than a metered platform does. A Hetzner account or a Contabo account both fit that pattern in different ways, and the Hetzner and Contabo comparison covers how the two German hosts differ in philosophy.

Questions About Allowances