Networking · Fundamentals
Bandwidth Explained: Capacity, Throughput, and How You Get Billed
Bandwidth is the maximum capacity of a network connection — the width of the pipe — measured in bits per second (Mbps, Gbps). It is not the same as throughput, which is the actual data rate you achieve and is always less than the bandwidth, nor latency, which is the delay before data arrives. Your port speed sets a hard ceiling on the rate, while your billing model — metered per-gigabyte egress, 95th percentile, or unmetered — decides what you pay for using it. Getting the distinction right is the difference between a predictable bill and a surprise invoice.
Key takeaways
- Bandwidth is capacity, throughput is reality. Throughput is always at or below the bandwidth, limited by the whole data path.
- Port speed is a hard ceiling. A 1 Gbps port maxes near 324 TB/month if saturated; a 10 Gbps port near 3,200 TB.
- Three billing models dominate: per-GB egress (most expensive), 95th percentile (rewards bursty traffic), and unmetered (flat per port).
- Cloud egress is the “success tax.” Per-GB pricing means a single traffic spike can dwarf your steady-state bill.
- Unmetered is not DDoS protection. A volumetric attack can saturate your port whatever your billing model says.
”Bandwidth” is one of the most overloaded words in infrastructure. People use it to mean capacity, speed, throughput, and the monthly data cap interchangeably, and the confusion shows up later as a saturated link or a bill nobody budgeted for. This guide untangles the terms and then walks through the part that actually costs money — how providers measure and charge for the data you move.
What is bandwidth, exactly?
Bandwidth is the maximum rate at which data can move across a connection, measured in bits per second — megabits (Mbps) or gigabits (Gbps). The pipe analogy is the one that sticks: bandwidth is the diameter of the pipe, the most water that can flow through it at once. A 1 Gbps connection can carry up to one gigabit every second, no more, regardless of how much data you have waiting to send.
One unit trap worth flagging immediately: network bandwidth is quoted in bits (lowercase b), while file sizes and storage are in bytes (uppercase B), and there are eight bits to a byte. A 1 Gbps link therefore moves roughly 125 megabytes per second at best, not 1,000. Mixing the two is how people convince themselves a transfer should be eight times faster than it ever could be.
Bandwidth vs throughput vs latency
These three get conflated constantly, and they measure different things. Bandwidth is the ceiling — the capacity available. Throughput is what you actually get: the real data rate achieved over the link, always at or below the bandwidth, and usually below it because of protocol overhead, congestion, and the slowest component in the path. Latency is the delay before data starts arriving, measured in milliseconds, and it is independent of bandwidth entirely — a fat pipe with high latency feels sluggish for interactive work even though it can move enormous files quickly.
The practical upshot: a “10 Gbps” server does not guarantee 10 Gbps of throughput, and adding bandwidth does nothing for a latency problem. If a transfer is slow, the question is which of the three you are actually limited by, because the fixes are completely different.
Port speed: the hard ceiling on your rate
Port speed is the physical link rate between your server and the provider’s switch, and it is the hard ceiling on how fast data can move at any instant. The common tiers sold today are 100 Mbps, 1 Gbps, 10 Gbps, and 25 Gbps, with higher tiers available for specialised needs. No billing model and no tuning lets you exceed the port — it is the width of the pipe, full stop.
There is also a difference between a shared and a dedicated port. A shared port aggregates several tenants onto one switch port, so your real throughput depends partly on what your neighbours are doing. A dedicated port belongs to your server alone, and the link rate stays consistent regardless of anyone else. For predictable performance, a dedicated port matters as much as the headline speed.
How much data does a port move in a month?
More than most people expect, but it is a finite, calculable number. Run a port flat out for a month and a 1 Gbps link transfers roughly 324 TB; a 10 Gbps link, around 3,200 TB. In practice no real workload sustains 100% utilisation, so a 1 Gbps port at typical patterns delivers closer to 180 TB of useful transfer per month. That ceiling is why “unlimited” on a slow port can still be limiting — the cap is not a data allowance, it is physics.
# What link speed did I actually negotiate? $ ethtool eth0 | grep -E ‘Speed|Duplex’ Speed: 10000Mb/s Duplex: Full # Measure real throughput to a test host (not the port rate) $ iperf3 -c speedtest.example.net -P 8 [SUM] 0.00-10.00 sec 10.9 GBytes 9.34 Gbits/sec receiver # Theoretical monthly transfer at this rate (bits -> bytes) $ python3 -c “print(round(10e9/8 * 86400*30 / 1e12,0),‘TB/mo at 100%’)” 3240.0 TB/mo at 100% # 8 parallel streams hit ~9.3 of 10 Gbps; single-stream would fall short.
The three ways bandwidth gets billed
This is where money enters, and the model matters more than the headline price. Three dominate. Metered (per-GB egress) charges for every gigabyte that leaves your network; ingress is usually free. Included allowance plus overage gives a monthly quota and a flat per-TB rate beyond it, often pooled across a project. Unmetered charges for the port itself — a flat monthly fee for unlimited transfer up to the port’s speed. And separately, many bare-metal and colocation providers use 95th percentile, which deserves its own explanation.
A caution on unmetered: almost every unmetered plan carries a Fair Use Policy. These are rarely enforced against legitimate heavy use, but they give the provider a contractual right to throttle or terminate genuinely abusive traffic. Read for red flags — vague “normal use” language, no defined port speed in the agreement, clauses allowing a drop to 10 Mbps past a threshold, or bans on specific traffic types. “Unlimited” plans, as opposed to true unmetered ones, are frequently throttled.
What is 95th-percentile billing?
It is a model that bills you for sustained traffic while forgiving short spikes. Your usage is sampled every five minutes for the whole month; at the end, the highest 5% of samples are thrown away, and you are billed on the next-highest reading. Because the top 5% of a month is roughly 36 hours, you can run hard for about a day and a half of bursts — a product launch, a batch job, a viral moment — without it touching your bill.
The trade-off is in the name: it rewards bursty traffic and punishes sustained traffic. If you run at a steady high rate, your 95th percentile sits right up near that rate, so there is little to discard. Watch two details in the contract — some providers bill on the higher of your inbound or outbound samples, and a few use 90th percentile instead, which forgives roughly 60 hours rather than 36. Both materially change the math.
Why cloud egress is so expensive
Per-gigabyte egress is the costliest way to consume bandwidth, and it is the model the big public clouds lean on — commonly around seven to nine cents per gigabyte out, with ingress free to draw you in. The reason it stings is that the cost scales directly with your success: a release day or a viral spike that moves a lot of data in a short window is billed for every byte, with none of the spike-forgiveness that 95th percentile or unmetered models provide. A single large game release pushed through per-GB cloud egress can run into six figures for bandwidth alone.
To be fair, per-GB is not always the wrong choice. For small or genuinely spiky workloads that move little data overall, paying only for what you use can be cheaper than committing to a port. The model turns punishing precisely when traffic is sustained and high — streaming, CDN origins, large backups, game distribution — which is exactly the territory where flat unmetered or included-allowance bare metal wins decisively. That egress gap is a major reason teams pull high-bandwidth workloads back onto owned hardware; we work the numbers in TCO: dedicated vs cloud and the broader pattern in cloud repatriation.
What really limits real-world throughput?
Rarely the link itself — usually something else in the data path. Hitting line rate on a 10 Gbps port requires the NIC, PCIe lanes, switch fabric, upstream transit, CPU, kernel tuning, and storage all to keep pace, and the slowest one sets your real ceiling. A common failure is pairing a fast port with an underpowered CPU: a 10 Gbps link needs real packet-processing cycles, and a low-core processor will peg one core at 100% and underperform a well-tuned 1 Gbps build.
Single-stream TCP is another quiet limiter — one connection rarely saturates a 10 Gbps link, while parallel streams across multiple cores can. On the hardware side, 10 Gbps NICs come as SFP+ (taking fiber or direct-attach copper) or 10GBASE-T (RJ45 copper), and not all transit is equal: Tier 1 IP transit means fewer hops and lower latency than cheaper, more circuitous routing. When throughput disappoints, audit the whole path before blaming the port.
Choosing the right bandwidth for your workload
Match the port and the billing model to your actual traffic, not to a number that looks impressive on an invoice. Audit your real 95th-percentile usage over a month first: if it regularly approaches your port’s ceiling, the port is the bottleneck and an upgrade pays for itself; if you sit far below it, a faster port is spend you will not use. For sustained high-volume work — streaming, CDN origin serving, game servers, heavy replication — unmetered or generous included bandwidth on a dedicated server is usually the honest-cost choice, and the premium from 1 Gbps to 10 Gbps is often smaller than expected for a tenfold capacity jump.
Two final cautions. First, bandwidth and DDoS protection are separate problems: an unmetered port spares you overage charges from attack traffic, but a large volumetric attack can still saturate the link and take you offline, which is why high-risk services need a dedicated scrubbing layer — see our DDoS protection guide. Second, if you are serving a lot of static content, a CDN offloads most of that traffic from your origin and cuts the origin bandwidth you pay for, while clustered workloads should account for the east-west traffic between nodes covered in our Kubernetes on bare metal guide. Size for the traffic you actually have, and the bill stops surprising you.