How Server Bandwidth Is Billed: Dedicated Bandwidth, Per-Traffic, 95th Percentile, and Shared Pools

How Server Bandwidth Is Billed: Dedicated Bandwidth, Per-Traffic, 95th Percentile, and Shared Pools

Bandwidth bills exceed expectations so often because, in billing language, "bandwidth" names four entirely different products. On the same machine with the same configuration, switching the billing model can multiply the monthly cost and, more importantly, change the type of risk altogether.

The four models are fixed-bandwidth allocation sold as a rate, per-traffic billing settled by volume, 95th percentile metering computed from samples, and shared bandwidth pools split across instances. They are not price tiers but four different ways of counting. Choosing wrongly is not a matter of paying slightly more; both the size of the bill and the kind of risk change.

This guide covers the billing models themselves: how each one is calculated, when it saves money, when it traps you, and the three scope questions to settle before signing. How much capacity to configure and how to shrink CDN spend are separate subjects, mentioned here only where a boundary needs drawing.

1. What the Four Models Actually Price

1.1 The Metering Unit Decides What You Should Fear

The core of a billing model is not price but unit. Once the unit is fixed, the risk is fixed with it: the shape of usage that will punish you is written into the contract in advance.

Fixed bandwidth meters rate, so the risk sits at peak hours: saturate it and traffic queues while users feel the slowdown. Per-traffic meters bytes, so the risk sits in total volume: when usage is not controllable, the bill has no ceiling and can in principle grow without limit. The 95th percentile meters a statistical quantile, so the risk sits in sustained highs: brief spikes are forgiven, long plateaus are billed in full. Shared pools meter the aggregate of a bucket, so the risk sits with neighbours: another instance draining the pool slows you down with it.

In one sentence: choosing a billing model means choosing which way you are willing to lose control.

1.2 The Four Models Side by Side

A single overview table first, aligning the metering unit, the usage shape each model punishes, and the workload it fits. The four chapters that follow unpack the arithmetic and the traps.

The easiest cell to misread is "fits". It describes how well a metering method matches a usage curve, not how important the workload is. A business-critical service can legitimately belong to per-traffic billing if its consumption is naturally steady.

2. Fixed Bandwidth: You Buy a Rate Ceiling

2.1 Two Kinds of Waste: Unused and Unreachable

Buying a fixed number of Mbps per month is the most intuitive of the four: you buy a rate ceiling, not a volume. Off peak, whatever you do not use is money spent for nothing; at peak, what you cannot reach becomes stutter for users. The two wastes point in opposite directions: one burns budget, the other burns experience.

The only metric needed to size it is the ratio between peak and trough over the past three months. A ratio near one means steady traffic, so buying to peak on fixed bandwidth is the right call. A wide ratio, for instance near-idle by day and bursty at night, means buying to peak pays for idle capacity month after month.

Fixed bandwidth has one hidden advantage: predictable cost. The bill stays the same no matter how much traffic arrives. For budget-sensitive teams that certainty has value of its own.

2.2 The Conversion: How Much Traffic 1 Mbps Carries in a Month

This is public arithmetic that anyone can do on paper, and it is the basis for comparing billing models. 1 Mbps means one megabit per second, which is 125 KB per second. A month of 30 days holds 2,592,000 seconds. Multiplying the two gives roughly 324 GB, which is why the industry shorthand says 1 Mbps held at full rate for a month is about 320 GB.

With that conversion, "10 Mbps per month" and "a 1 TB traffic bundle" become directly comparable. 10 Mbps can carry at most about 324 GB in a month, while 1 TB is about 1024 GB, equivalent to a sustained rate near 31 Mbps. In other words, a monthly rate only wins when your real usage sits close to that theoretical ceiling; if actual usage is a few hundred GB, the monthly rate is payment for capacity you never touch.

Remember that this is a theoretical ceiling. TCP rarely holds full rate for long in a real network, especially across borders, so the achievable volume is usually below this figure.

2.3 Read the Terms Behind "Unlimited Traffic"

In most terms of service, "unlimited traffic" is not unconditional. The usual attachments are fair use clauses, throttling after a threshold, or connection limits once a quota is crossed.

What matters is the behaviour after the threshold: does it throttle, and to what rate; does it cap concurrent connections, and at what number; or does it convert to extra charges, at what unit price. The three differ enormously. Throttling to a small fraction of the original rate turns a fixed rate into a worse fixed rate; converting to extra charges quietly switches you onto a per-traffic model without your noticing.

3. Per-Traffic Billing: You Buy a Volume

3.1 Outbound and Inbound: Who Generates the Bill

Per-traffic billing settles by bytes, but in most scenarios the bytes that generate the bill are outbound, meaning data leaving the server toward users: pages, images, video, downloads, API responses. Inbound traffic is uploads, form submissions, request payloads, usually far smaller in volume.

That asymmetry is where understanding per-traffic starts. Every byte you serve may be a cost, while most bytes sent to you are not. The cost of a per-traffic product is therefore almost entirely determined by how much you send out.

3.2 One-Way Metering, Cross-Zone, and Origin-Pull Traffic

Providers differ widely in what they actually meter. Some count outbound only, some count both directions; some waive traffic inside the same zone while metering cross-zone or cross-region separately; and if object storage or a CDN sits in front, origin-pull traffic is often a separate bill of its own.

Added up, these scope differences can make the same workload differ by an order of magnitude between vendors. Before signing, draw the traffic path and mark every segment that is metered. That is the only reliable approach. For shrinking origin-pull itself, see the CDN cost optimization guide.

3.3 The Risk of Being Flooded, and Two Hard Limits

The biggest risk of per-traffic billing is not the unit price; it is that cost control is handed to outsiders. Outbound metering means anyone who does not log in and does not pay can still generate your bill simply by requesting your resources: hotlinking downloads, hammering images, looping video segments, spamming an API.

That is why the first engineering constraint of per-traffic billing is to set both a bandwidth cap and a total volume cap. The rate cap locks the speed so a short burst cannot flood you; the volume cap locks the total so the monthly bill has a ceiling. Both are required because they fail differently: a volume cap without a rate cap still allows one enormous bandwidth event and an outage before the cap is hit; a rate cap without a volume cap still permits slow, steady consumption that burns the whole allowance.

Alerts alone are not enough. An alert is a notification, not a stop-loss; it only lets you see the bill growing sooner. What actually catches the risk is a hard limit plus a rehearsed plan for switching things off when a flood starts.

4. The 95th Percentile: You Buy Tolerance for Spikes

4.1 Samples and the Top Five Percent Discard

Wording varies by vendor, but the core of 95th percentile billing is consistent: sample bandwidth at fixed intervals, commonly every five minutes; a month yields roughly 8,640 samples; discard the highest five percent; bill on the highest remaining value.

The discarded five percent is roughly 36 hours. That is a generous window, meaning a workload can absorb about a day and a half of abnormal peaks without them reaching the bill, which per-traffic billing can never do.

4.2 What the 95th Percentile Punishes Is Sustained Peak

The key to 95th percentile is what it punishes: not instantaneous spikes but sustained peaks. A backup job that runs a few minutes, a short promotional pulse, barely moves the bill; two or three days held high appears fully in the billed value.

That opens a practical optimization space: schedule what can be scheduled elsewhere. Backups, log archiving, image replication, data exports and similar batch jobs are best placed in troughs. Spread out, the 95th percentile value lands clearly below the raw peak. This is the engineering-friendly side of the model: the bill depends on how you arrange load, not only on how much you use.

Conversely, if your workload is naturally high for long stretches, such as continuous video delivery, the 95th percentile and a dedicated monthly rate converge, and the dedicated rate is often the simpler choice.

5. Shared Bandwidth Pools: You Buy a Bucket

5.1 What Happens When a Single Instance Is Uncapped

A shared bandwidth pool merges several lines into a single resource pool that all instances draw from. Its selling point is utilization: peaks across instances rarely coincide, so sharing one aggregate is cheaper than reserving separately.

The problem is the allocation rule inside the pool. If the pool does not limit the rate of an individual instance, one instance can drain the entire pool and every other workload on it slows at once. This is not a theoretical risk in practice: a retry storm, a download service without rate limiting, or a flooded API is enough to fill the pool.

5.2 How to Judge Whether a Pool Is Usable

Two questions decide it: does the pool support per-instance rate limits, and when the pool total is exceeded, does it drop packets or throttle everyone globally.

A pool with per-instance limits is controllable, because you can at least guarantee each workload its own ceiling. Without them, the pool is a commons and whoever grabs fastest wins. As for over-pool behaviour, packet drops are usually easier to diagnose than global throttling, because the failure is visible on specific flows, whereas global throttling slows every workload together and costs far more to investigate.

Watch the boundary too: whether instances in different availability zones or regions can share one pool. Some products only share inside one zone, meter cross-zone traffic separately, and this detail is frequently overlooked.

6. Three Questions About Metering Scope

6.1 Is Inbound Traffic Metered

The first question: is inbound traffic metered? Most products make it free, but some meter both directions, or start metering inbound once it exceeds some proportion. The difference matters little for content delivery and enormously for backup, synchronization, and image-pull workloads, whose traffic runs in the opposite direction.

6.2 Is Outbound Metered One Way or Both Ways

The second question: is outbound counted one way or both ways? Some providers count both sides of every connection, effectively doubling the bill; others count only bytes that truly leave the facility. Contracts usually spell this out, so read specifically for the phrase describing metering direction.

6.3 Are Internal and Cross-Zone Flows Counted

The third question: are internal, cross-zone, and cross-region flows included in the metered total? Internal traffic is normally free, but "internal" is defined differently by each provider: some treat different zones in one region as internal, others do not; cross-region replication and cross-region disaster recovery are almost always separate line items.

Unless these three are settled, no price comparison means anything, because the two sides may not be pricing the same product.

7. Choosing a Model by Workload Shape

7.1 Bandwidth Is Not Throughput

Buying bandwidth buys a ceiling on link transmission, while users experience throughput. Protocol sits between them: TCP throughput is constrained by round-trip time and loss, so the longer the RTT and the more loss on a link, the lower the rate a single connection can reach.

A 10 Mbps cross-border link with high round-trip time and some loss can deliver far below its nominal rate on a single connection, and adding bandwidth will not fix it. More bandwidth solves insufficient aggregate capacity, not a slow single connection. The latter needs multiple connections, congestion-control tuning, or a route with lower RTT. For how to read a link's latency behaviour, see the route spectrum guide.

7.2 Selection Criteria

Matching the four models to workload shape gives fairly clear criteria:

• Steady and predictable traffic: fixed bandwidth. You know what to buy and the cost is stable.
• Volatile traffic with short peaks: 95th percentile. Spikes are forgiven and the bill follows the normal level.
• Small volume with sharp bursts: per-traffic plus a hard cap. Cheapest at low volume, with the cap catching runaway usage.
• Many small instances with bounded aggregate: a shared pool, provided per-instance limits exist.
• Sustained high load for long periods: fixed bandwidth and 95th percentile converge, so compare unit price per Mbps and route tier instead; the cloud server price reference shows how to align the scope before comparing.

Whichever model you pick, settling the metering scope and configuring hard caps before signing is worth more than a few percent off the unit price. Bandwidth is one of the few cost items that expands quietly as a business grows, and setting boundaries matters more than squeezing the rate. For how vendors differ on bandwidth and traffic products, the official documentation of Alibaba Cloud ECS and Vultr describe the two conventions quite differently. For configuration paired with bandwidth, see the cloud server configuration guide; for dedicated hardware with colocation bandwidth, the dedicated server selection guide covers the purchasing vocabulary; and for the structural problem of shared egress, continue with BGP multiline facilities. More coverage lives in the cloud server category.

Source: 16IDC original, billing rules, routing and terms are subject to each provider's official documentation and contract.