Network Cost Monitoring and 95th Percentile Billing: A Practical Guide
Reviewed for technical accuracy by: Lauren Basile, Senior Product Marketing Manager at Kentik, specializing in network cost intelligence and service provider observability.
Bandwidth is one of the few line items in IT that is billed on measurements most teams never independently verify. Service providers and digital enterprises pay for transit, peering, and interconnects under 95th percentile, flat-rate, tiered, and commit-based contracts — while cloud-heavy organizations face metered egress charges that arrive after the traffic has already flowed. Network cost monitoring is the practice of measuring the same traffic your providers bill you for, attributing spend to the customers, applications, and routes driving it, and using that visibility to forecast bills, validate invoices, and engineer costs down.
This guide explains how 95th percentile billing actually works, how to audit it yourself, how cloud egress charges fit the same discipline, and how unit economics like cost per Mbps turn bandwidth bills into decisions.
Network Cost Monitoring at a Glance
- 95th percentile billing measures bandwidth in 5-minute samples across a billing cycle, discards the top 5% of samples, and bills on the highest remaining value — so short bursts are free, but sustained peaks are not.
- Other billing models — flat-rate, tiered, and commit-based — price the same traffic differently, which is why comparing providers requires normalizing everything to a unit cost such as effective cost per Mbps.
- Cloud egress is the other bandwidth bill: metered per-GB charges on traffic leaving cloud environments (and crossing zones, regions, and gateways), measured from VPC flow logs rather than router counters.
- Cost attribution connects spend to its causes: which customers, ASNs, CDNs, OTT services, regions, and routes are driving the bill — the foundation for pricing, peering, and routing decisions.
- The audit principle: if a provider can compute your bill from traffic measurements, you can too — and you should, continuously, with alerting before thresholds are crossed rather than surprise afterward.
What is 95th percentile billing?
95th percentile billing (sometimes called burstable billing) is the dominant model for pricing internet transit and many interconnect services. The mechanics are simple to describe: the provider samples your bandwidth usage at regular intervals — almost always every 5 minutes, recording the peak of inbound or outbound traffic for each interval — across the billing month. At the end of the cycle, the samples are sorted, the top 5% are discarded, and the highest remaining sample becomes your billable rate.
The logic behind the model is fair to both sides. Providers must engineer their networks for sustained load, not momentary spikes, so they charge for the level you consistently push rather than your single worst moment. Customers, in turn, aren’t penalized for short bursts. In a 30-day month of roughly 8,640 five-minute samples, the discarded top 5% represents about 36 hours of your busiest traffic, free of charge.
The practical consequence is that traffic shape determines your bill as much as traffic volume. A steady, high-utilization link has a 95th percentile close to its average — you pay for roughly what you use. A bursty link can have a modest average but a high 95th percentile, because the bursts last long enough to survive the 5% discard. Two customers moving the same total bytes per month can receive very different bills, and understanding that difference is the first step in managing it.
Kentik in brief: Kentik is the network intelligence platform that delivers network cost intelligence as an automated workflow rather than a spreadsheet exercise. Kentik’s Connectivity Costs capability models provider contracts across transit, peering, Internet Exchange (IX), and private interconnect links — normalizing 95th percentile, flat-rate, tiered, and commit-based billing into consistent cost models computed from real interface measurements — while Traffic Costs applies that pricing to flow-enriched traffic slices (ASN, customer, CDN/OTT, geography, IP/CIDR) to calculate effective cost per Mbps for any slice of traffic. The result is instant answers to which customers, services, and routes are driving spend, invoice validation against your own measurements, and a defensible record of what each routing and peering change saved. For the product overview, see the Network Cost Intelligence solution brief.
Learn everything you need to know about network telemetry in this new O'Reilly guide.
How to audit and monitor your own 95th percentile
The core principle of bandwidth cost monitoring is that nothing in the bill is unknowable in advance. If your provider computes the charge from traffic measurements, you can compute the same number from your own — and tracking it continuously converts the bill from a monthly surprise into a managed metric.
The measurement recipe mirrors the provider’s. Sample each billed interface every 5 minutes, capturing both inbound and outbound peaks — in SNMP terms, the high-capacity counters ifHCInOctets and ifHCOutOctets, converted to rates. Across the billing cycle, sort the samples and discard the top 5%; the highest survivor is your running 95th percentile. Done continuously, this yields three things a monthly invoice never provides: a current-cycle forecast of the bill, an alert when you’re trending toward (or past) your contracted commit, and an independent number to true up against the provider’s invoice — billing errors are more common than anyone likes to admit.
Two complications are worth planning for. First, real contracts often aggregate. The percentile may be computed across a group of circuits, or separately per region, which means your monitoring must compute the same aggregates rather than per-interface values alone. Second, the burden shouldn’t fall on you alone — if a provider bills at the 95th percentile, they can show you the measurement, and a provider who claims they can’t display your running percentile and alert against your commit has earned a pointed follow-up question.
Flat-rate, tiered, and commit-based billing — and why normalization matters
The 95th percentile isn’t the only model on your invoices. Flat-rate billing charges a fixed price for a port at a given capacity regardless of usage — simple, predictable, and economical only when utilization is consistently high. Tiered billing prices usage in bands, with the unit price changing as volume crosses thresholds. Commit-based contracts blend the approaches: you commit to a minimum (often expressed as a 95th percentile level) at a favorable unit rate and pay overage rates beyond it — which makes right-sizing the commit itself a recurring financial decision driven by traffic trends.
The strategic problem is that these models can’t be compared directly. Whether a peering port is cheaper than transit, whether one provider’s commit beats another’s tiers, whether an IX connection justifies its fixed costs — none of these questions can be answered from contract terms alone. The comparison requires normalizing every arrangement to the same unit economics: what each connection actually costs per Mbps delivered, given the traffic it actually carries.
That normalization — translating 95th percentile, flat-rate, tiered, and commit structures into consistent effective cost per Mbps across transit, peering, IX, and private interconnects — is the foundational computation of network cost intelligence, and it’s what turns a pile of dissimilar invoices into a provider-mix strategy. (For the underlying economics of transit versus peering, see IP Transit vs. Peering.)
Cloud egress: the other bandwidth bill
Cloud-heavy organizations face the same discipline with different mechanics. Cloud providers meter data transfer rather than billing on percentiles. Traffic leaving the cloud to the internet or on-prem environments (north-south) is charged per GB, and — the part that often surprises teams — so are many movements inside the cloud, including transfers between availability zones, between regions, and through managed gateways such as NAT and transit gateways, each with its own rate. Meanwhile, east-west traffic within a zone is typically free or cheap, which means the same application architecture can produce wildly different bills depending purely on how its traffic is routed.
The measurement source changes too. There are no router counters to poll in someone else’s cloud. Instead, the meter is VPC flow logs (and their equivalents), which record which workloads sent how much to where. Joined with the provider’s published rates, flow logs let you attribute egress charges to specific services, paths, and gateways before the invoice arrives.
Cloud flow logs also expose the classic cost pathologies:
- Traffic hairpinning out of and back into the same environment
- Intra-zone traffic needlessly traversing a transit gateway when VPC peering would carry it for less, and
- NAT gateway processing charges accumulating on flows that never needed the gateway at all.
Each of these is invisible in a billing console, which reports that you were charged, but are obvious in flow telemetry, which shows why.
From bills to unit economics: attributing cost to traffic
Knowing what you spend is accounting, while knowing what the spend is for is intelligence, and it’s where cost monitoring starts paying for itself. Attribution means joining cost models to enriched flow telemetry so spend can be sliced the way decisions are made — by customer, by ASN or AS group, by CDN and OTT service, by geography, by IP block. Once each traffic slice carries an effective cost per Mbps, previously unanswerable questions become queries.
For service providers, the highest-value question is margin. What does it cost to deliver each customer and service, compared to what it earns? Per-customer delivery cost guides pricing, renewals, and which relationships justify dedicated infrastructure.
Questions about peering would be the next most valuable question. Which traffic currently rides paid transit that could move to peering or an IX where footprints overlap — and what would the shift actually save?
OTT and CDN traffic analysis serves the same goal at the content level, revealing which services dominate the traffic mix and whether their delivery paths are the economical ones. And every interconnection decision is ultimately a cost-versus-performance trade-off. The cheapest path per Mbps is not always the right one for latency-sensitive services, and the analysis is only accurate when both sides — unit cost and delivery performance — are measured for the same traffic.
For enterprises, the same attribution discipline applied to cloud flow logs answers the egress version. Which applications, environments, and architectural choices drive data transfer charges, and which routing or placement changes would reduce them without harming the services involved?
Building a network cost monitoring practice
A working practice has a rhythm to it. On a continual basis, your cost monitoring solution computes running 95th percentiles and current-cycle spend forecasts per provider and circuit, with alerts ahead of commit thresholds and anomaly detection on traffic shifts that change the cost picture.
Monthly, invoices are validated against your own measurements, and unit-cost trends — such as cost per Mbps by provider, connectivity type, site, and market — are reviewed for circuits drifting more expensive.
And around every deliberate change — a peering turn-up, a routing policy shift, a commit renegotiation, a workload migration — you snapshot before and after, so the financial impact of the decision is measured rather than simply assumed. That last habit is what earns the practice executive credibility: “this peering change saved this much” is a sentence finance can act on, and a defensible historical record is what separates “cost intelligence” from “cost anecdotes”.
The organizational point is that the audience for network cost data is bigger than just the network team. Finance departments want forecast versus actual and validated invoices. Sales wants per-customer delivery cost when pricing renewals. Leadership wants the trend line and the savings story. Network cost telemetry that lives in an engineer’s spreadsheet serves only one of those audiences (and badly, at that). Network cost intelligence delivered as shared, real-time views serves all of them.
How Kentik delivers network cost intelligence
Kentik turns the practice above into automated workflows on the platform that already holds your traffic data:
Connectivity Costs captures provider pricing and contract terms across transit, peering, IX, and private interconnects, normalizes 95th percentile, flat-rate, tiered, and commit-based structures into consistent cost models, and computes spend from SNMP-based interface measurements — with invoice true-up, billing error discovery, and current-cycle forecasting built in.
Traffic Costs goes deeper, applying that connectivity pricing to flow-enriched traffic slices — by ASN and AS group, customer, CDN and OTT service, geography, and IP/CIDR — to calculate total monthly cost and effective cost per Mbps for each slice, identify high-cost routes and interconnects, and compare delivery cost against revenue for margin decisions. Snapshots and monthly tracking quantify the impact of routing and peering changes over time, and edge workflows like Discover Peers identify where transit traffic could be offloaded to peering, with the cost context to size the opportunity.
It’s a complement to FinOps rather than a replacement. FinOps tools govern cloud billing and allocations, while Kentik answers the question they can’t, “which traffic, paths, and interconnect decisions are driving the spend and what should change?”
Service providers like Seaborn Networks have used this approach to save $4 million annually while increasing profitability.
Related Reading on Network Cost Monitoring
- Network Cost Intelligence (Solution Brief) — the product-side companion: Connectivity Costs and Traffic Costs workflows in depth.
- Introducing Kentik Traffic Costs: Real-Time Network Cost Intelligence — the launch deep-dive on flow-based cost attribution.
- IP Transit vs. Peering — the economics and trade-offs behind the provider-mix decisions cost data informs.
- What Are VPC Flow Logs? — the measurement source for cloud egress attribution.
- NAT Gateway — how gateway charges accumulate and how to attribute them.
- Avoid These Five Cloud Networking Deployment Mistakes — the cost pathologies (hairpinning among them) that flow telemetry exposes.
- Seaborn Networks Saves $4 Million Annually with Kentik (Case Study) — network cost intelligence in production at a subsea operator.
FAQs about 95th Percentile Billing and Network Cost Monitoring
What is 95th percentile billing?
95th percentile billing (also called burstable billing) is the dominant pricing model for internet transit and many interconnect services: the provider samples your bandwidth every 5 minutes across the billing month, discards the top 5% of samples, and bills on the highest remaining value. The model lets customers burst above their billed rate for free — roughly 36 hours’ worth of peaks in a typical month — while charging for the load they sustain, which is what providers must actually engineer their networks to carry.
How do you calculate 95th percentile bandwidth usage?
Sample each billed interface every 5 minutes across the billing cycle, recording the peak of inbound and outbound traffic for each interval (from high-capacity interface counters such as ifHCInOctets and ifHCOutOctets, converted to rates). At any point, sort the collected samples, discard the top 5%, and the highest remaining sample is the current 95th percentile. Watch for contract nuances: many agreements compute the percentile across aggregated circuit groups or per region, so your calculation must mirror the contract’s aggregation to match the invoice. Kentik supports this by computing spend automatically from provider pricing models and SNMP traffic measurements, including aggregate structures.
What’s the difference between 95th percentile and flat-rate billing?
Flat-rate billing charges a fixed price for a port at a stated capacity regardless of how much traffic it carries; 95th percentile billing charges based on measured sustained usage, with the top 5% of samples forgiven. Flat-rate is predictable and favors consistently high utilization — you’re paying for the capacity anyway. The 95th percentile favors variable traffic, since you pay for sustained levels rather than provisioned capacity, but it makes the bill sensitive to traffic shape: bursts lasting longer than the discard window raise the bill even when average utilization stays modest.
Why do ISPs and transit providers bill at the 95th percentile?
Because providers engineer for sustained peaks, not momentary spikes. Capacity planning, upstream commitments, and interconnect sizing are all driven by the load a customer consistently places on the network — so billing on a measure that ignores the busiest 5% of intervals charges for that sustained load while tolerating bursts. It also aligns incentives: customers aren’t punished for occasional spikes, and providers are compensated when “occasional” becomes routine.
What is effective cost per Mbps and why does it matter?
Effective cost per Mbps is a connection’s real unit economics: what you actually pay divided by the traffic it actually carries, regardless of billing model. It matters because transit, peering, IX, and private interconnect arrangements are priced under incompatible structures — 95th percentile, flat-rate, tiered, commit-based — and unit cost is the only basis on which they can be honestly compared. Computed per traffic slice (per customer, ASN, CDN, or service), it becomes the foundation for margin analysis, peering decisions, and provider negotiations. Kentik calculates effective cost per Mbps both per connection and per flow-enriched traffic slice.
What is the best way to assess cloud egress costs driven by network traffic?
Measure the traffic itself rather than waiting for the bill: ingest VPC flow logs (and equivalents) to see which workloads send how much traffic out of the cloud, across zones and regions, and through metered gateways, then join those volumes with the provider’s published rates to attribute charges to specific services and paths. This converts an opaque line item into an itemized, queryable picture — and surfaces the architectural causes, like hairpinned paths or traffic crossing a transit gateway unnecessarily. Kentik supports this by ingesting cloud flow logs alongside on-prem flow data and breaking down egress by region, VPC, gateway, and interconnect.
How can I track and reduce cloud data transfer charges from traffic flows?
Track continuously by attributing flow-log traffic to the gateways, zones, regions, and destinations where charges accrue, with alerting on volume shifts that change the cost picture. Reduce by acting on what attribution reveals: move chatty service pairs into the same zone, replace transit-gateway paths with VPC peering where traffic stays intra-region, eliminate hairpinning, and place NAT gateways so that only traffic that needs them crosses them — then verify the change in both traffic and spend. Kentik supports this loop by tying flow-level traffic views to the gateway and path dimensions that drive data transfer charges.
How can I model cost vs. performance trade-offs for interconnection?
Measure both sides for the same traffic: the effective cost per Mbps of each candidate path (transit, peering, IX, private interconnect) and the delivery performance — latency, loss, path stability — that traffic experiences on each. The trade-off is only a real model when the two are joined: the cheapest path for a traffic slice may be wrong for latency-sensitive services, and a premium path may be unjustified for bulk traffic. Kentik supports this by pairing per-slice cost analytics with the performance and routing telemetry for the same flows, so interconnection decisions can be made on evidence from both dimensions.
How do I analyze OTT traffic patterns to optimize network spend?
Identify and classify OTT and CDN traffic in your flow telemetry, then quantify each service’s share of volume, its delivery paths, and — with cost models applied — what each service costs to carry per Mbps. For service providers, this reveals which content sources dominate the traffic mix, whether that traffic arrives over paid transit or settlement-free paths, and where caching, peering, or embedded-CDN arrangements would change the economics. Kentik supports this with OTT and CDN classification as first-class traffic dimensions, combinable with cost attribution and trended over time.
How can I avoid surprise bandwidth and egress bills?
Compute the bill yourself, continuously, from the same measurements the provider uses — running 95th percentiles per contract for circuit billing, flow-attributed transfer volumes for cloud egress — and alert on trajectory rather than arrival: when a circuit trends toward its commit, when egress runs ahead of forecast, when a traffic shift changes the cost picture mid-cycle. Pair the forecast with invoice validation, since billing errors do occur and your independent measurement is the leverage for correcting them. Kentik automates both halves: current-cycle cost forecasting with threshold alerting, and invoice true-up against measured traffic.
Put your bandwidth bill under an X-ray, with Kentik
Kentik is the network intelligence platform that connects what you spend to the traffic that caused it — across transit contracts, peering, interconnects, and cloud egress.
- Request a demo — see Connectivity Costs and Traffic Costs compute your spend from real traffic, live.
- Start a free trial — model your contracts and see effective cost per Mbps on your own traffic.
- Read the Network Cost Intelligence solution brief — the full product picture: cost workflows, executive outcomes, and how Kentik complements FinOps.
