Bandwidth is the line on a dedicated server invoice that generates the most confused support tickets we see. Two servers pushing the same total traffic can end up with wildly different bills, or with one throttled and the other fine, purely because of how the provider measures consumption. There are two dominant billing models, 95th percentile and metered data transfer, and they reward completely different traffic shapes. Understanding which one you are on, and what your traffic profile looks like under it, is worth more than any port upgrade you can buy.
Metered billing counts total bytes moved in a month and charges per terabyte above an included allowance. A server with 30 TB included that moves 34 TB pays for 4 TB of overage. It is the model most people intuitively expect, and it is easy to reason about: your bill tracks how much you moved, full stop. Its weakness is that it treats a smooth stream and a violent spike as equivalents if the totals match, and it gives you no structural incentive to smooth anything.
Percentile billing works like this. The provider samples your traffic, typically every five minutes, in one direction or the higher of the two. Over a 30-day month that is roughly 8,640 samples. They sort the samples by rate and discard the top 5%, about 432 of them. Your committed rate is set by the next sample down: the 95th percentile. You are billed against that sustained rate for the whole month, and, crucially, the top 36 hours of the month are effectively free.
This has a counterintuitive consequence. You can push a hard 1 Gbps for 36 scattered hours across a month at zero extra cost, as long as those bursts fit inside the discard window. But push 1 Gbps for 40 hours, or burst badly during the wrong sampling slots, and your billed rate jumps to near 1 Gbps for the entire month. We have seen customers triple their effective bill with four days of unthrottled backups, and others run nightly bursts of heavy traffic entirely free because the pattern stayed inside the discarded 5%.
Before you sign a commit, pull your provider's traffic graph and look at the shape, not the average. A flat line with modest daily rhythm is the ideal percentile customer; commit slightly above the plateau. Backup-heavy or batch-heavy profiles are the dangerous ones. If you move most of your traffic in concentrated windows, metered transfer will almost always price better than a percentile commit sized to your peaks.
A concrete test: take your busiest month, apply the 95th percentile math to the graph yourself, and compare that implied monthly volume against your actual total transferred. If the percentile-implied volume is more than about 1.3 times your real total, your traffic is spiky for the model and you should negotiate metered billing instead.
A 1 Gbps port with no stated transfer limit does not mean unlimited data. It means the provider bills by one of the above methods and the port speed is simply the ceiling. Some budget offerings genuinely include all the traffic you can push, because their upstream economics at scale allow it, but they enforce fairness through other levers: congested shared uplinks, traffic prioritisation, or acceptable use clauses that kick in precisely when you become expensive. Ask what the fair use threshold is before you rely on the port for anything regular and heavy.
Providers sell commits in steps, and the pricing is heavily stepped: a 500 Mbps commit costs far less than half of 1 Gbps. Under-committing means overage at a punitive burst rate, usually two to three times the committed rate per Mbps. Over-committing means paying sustained for capacity you touch twice a month. The right commit sits at your real 95th percentile plus 20 to 30 percent of headroom for growth, reviewed quarterly. If your 95th percentile sits at 310 Mbps, you buy the 500 Mbps commit, not the 1 Gbps, and you watch the graph.
The related infrastructure decisions matter as much as the number. How failover and re-pointing interacts with your traffic measurements during an incident is covered in our piece on BGP announcements and failover IPs, because a failover event can drop your traffic onto a link billed differently from your normal path. And none of this helps if the server itself is not recoverable when hardware dies, so the recovery planning in what separates a 4-hour recovery from a 4-day one belongs in the same planning document as your bandwidth commit.