What Is Bandwidth?
Bandwidth is the maximum rate at which data can move across a network connection in a given period of time. It is measured in bits per second, usually expressed as megabits per second (Mbps) or gigabits per second (Gbps), and it sets the ceiling on how much traffic a server can send or receive at any moment.
In server hosting, the word carries two meanings that are easy to confuse. It can refer to the speed of the network port assigned to a server, such as a 1 Gbps or 10 Gbps uplink. It can also refer to the total volume of data transferred over a billing period, quoted in terabytes. Providers use both senses, sometimes on the same specification sheet, so it is worth confirming which one a quote refers to before comparing plans.
Bandwidth vs Throughput vs Latency
These three terms get used interchangeably in hosting conversations, and confusing them leads to buying capacity that does not solve the actual problem.
| Measurement | What it describes | Unit | Everyday analogy |
|---|---|---|---|
| Bandwidth | The maximum data rate a link is capable of | Mbps, Gbps | The width of a pipe |
| Throughput | The data rate actually achieved in practice | Mbps, Gbps | The water genuinely flowing through it |
| Latency | The time a packet takes to reach a destination and return | Milliseconds (ms) | How long the water takes to arrive |
A server with a 10 Gbps port can still deliver 400 Mbps of throughput if the path is congested, the upstream carrier is saturated, or packet loss is forcing retransmissions. Bandwidth is what appears on the invoice. Throughput is what the application experiences.
Adding bandwidth also does nothing for latency. Widening a pipe moves more water per second, but the water does not arrive any sooner. Applications that feel slow because of round-trip time need better routing, not a faster port.
How Bandwidth Is Measured
Network speed is quoted in bits. File sizes and storage are quoted in bytes. There are eight bits to a byte, and forgetting the conversion is the most common source of confusion when someone benchmarks a transfer and concludes their port is running at one eighth of its rated speed.
| Port speed | Theoretical maximum transfer rate | Volume at 100% utilization for 30 days |
|---|---|---|
| 100 Mbps | 12.5 MB/s | ~32 TB |
| 1 Gbps | 125 MB/s | ~324 TB |
| 10 Gbps | 1.25 GB/s | ~3.2 PB |
Those figures are ceilings, not expectations. Protocol overhead consumes roughly 5% of nominal capacity once Ethernet framing and TCP/IP headers are accounted for, so a 1 Gbps port typically sustains around 940 Mbps of actual payload. No production workload runs at 100% utilization for a full month either, which is why the volume column matters mainly as a sanity check against a provider’s transfer allowance rather than as a planning number.
How Hosting Providers Sell Bandwidth
There are three billing models in common use, and the difference between them can change a monthly bill by an order of magnitude for the same traffic pattern.
| Billing model | How it works | Suits |
|---|---|---|
| Unmetered port | A fixed port speed with no volume cap, charged as a flat monthly fee | Sustained, always-on traffic |
| Metered transfer | A fixed allowance in TB, with overage charged per GB | Moderate or seasonal traffic |
| 95th percentile | Usage is sampled every five minutes; the top 5% of samples are discarded and billing is based on the highest remaining sample | Traffic with short, sharp peaks |
The 95th percentile model deserves a closer look because it is the least intuitive of the three. Over a 30-day month there are 8,640 five-minute samples. Discarding the top 5% removes 432 of them, which is the equivalent of 36 hours. A workload can therefore run at full port speed for a day and a half every month without affecting its bill at all, provided those bursts stay within that window. For traffic that is genuinely spiky, such as a scheduled batch replication or a product launch, this is often cheaper than either alternative. For traffic that is flat and continuous, it is usually the most expensive of the three.
On custom server builds, bandwidth is selected at configuration time alongside CPU, memory and storage, which makes it easier to match the billing model to the traffic profile rather than accepting whatever a standard plan bundles.
Why Bandwidth Costs Differ Between Cloud and Dedicated Infrastructure
Public cloud platforms meter outbound traffic per gigabyte. At list prices current in August 2026, AWS applies a monthly free allowance of 100 GB, then charges $0.09/GB for the first 10 TB, $0.085/GB for the next 40 TB, $0.07/GB for the next 100 TB, and $0.05/GB above 150 TB. A workload sending 10 TB to the internet in a month therefore incurs just over $900 in egress charges alone, before compute, storage, NAT gateway processing, or cross-zone traffic are counted. Rates vary by region and are higher in parts of Asia Pacific.
Dedicated infrastructure prices bandwidth differently. Capacity is attached to the port and billed at a flat rate, so the cost of the hundredth terabyte is the same as the cost of the first. For workloads with steady, high outbound volume, this is where the two models separate most sharply. It is also why organizations serving video, large file downloads, or continuous data replication are the ones most likely to move that traffic off metered platforms.
Why Actual Throughput Is Lower Than the Port Speed
Port speed is the first constraint, and rarely the binding one. Four things degrade real throughput more often than an undersized port:
- Upstream transit capacity: A 10 Gbps port behind a congested transit provider delivers whatever that provider has left.
- Path length and peering quality: Traffic that crosses several networks to reach its destination accumulates latency and exposure to congestion at every handoff. Direct peering shortens the path.
- Packet loss: TCP interprets loss as congestion and reduces its sending rate. A path with 1% loss can lose a substantial share of achievable throughput even with capacity to spare.
- TCP window size: A single TCP session is limited by its window divided by round-trip time. With a 64 KB window over a 150 ms path, that session tops out near 3.5 Mbps no matter how fast the port is. Long-distance transfers need either window scaling or parallel streams to use available capacity.
The last three are network design problems rather than capacity problems, which is why carrier diversity and peering density matter as much as port speed. XLC publishes its full carrier mix and internet exchange footprint on its network page, including direct connectivity to the three major China carriers and peering at HKIX, BBIX and ANY2West, so these paths can be verified rather than assumed.
Which Workloads Are Bandwidth-Bound?
Most applications are limited by compute or storage. A smaller set is limited by the network, and these are the ones where bandwidth planning changes the architecture:
- Video streaming and media delivery, where sustained outbound throughput scales directly with concurrent viewers
- Large file distribution, including software updates, game patches and mirror hosting
- Backup and disaster recovery replication between regions
- AI and machine learning pipelines moving training datasets between storage and compute
- Public data and API services with high response payload volumes
How to Verify the Bandwidth You Are Paying For
A port specification is a claim until it is measured. Three checks are worth running before committing to a provider:
- Test the route, not just the speed: Traceroute and MTR show which networks the traffic crosses and where loss appears. A clean speed test from a nearby location says little about performance from the markets that matter.
- Test from your users’ geography: Throughput from Los Angeles to Los Angeles is not evidence of throughput from Los Angeles to Shanghai.
- Read the SLA, not the headline number: Check how network uptime is defined, over what measurement period it is calculated, and what credit schedule applies when the target is missed.
XLC’s Looking Glass runs ping, traceroute and MTR tests from its data center locations, which allows routing and latency to be checked from outside before any commitment is made.