Stop Trusting Cloud Provider Bandwidth Bills: How /proc/net/dev Exposes the Great Metering Fraud

Your AWS bill shows 847GB of data transfer this month. Your Azure invoice lists 623GB of bandwidth usage. GCP charged you for 729GB of network egress. Yet when you add up the actual bytes that moved through your applications, you're looking at maybe 550GB total.

The numbers don't lie, but the cloud providers aren't exactly telling the whole truth either.

The Great Bandwidth Billing Mystery

Cloud bandwidth billing operates on a fundamentally different model than what most sysadmins expect. When you download a 1GB file, your application sees 1GB of data. But your cloud provider bills for packet headers, TCP retransmissions, routing overhead, and a dozen other network-layer details that never appear in your application logs.

This isn't necessarily fraud in the legal sense. But it's a systematic disconnect between what you think you're using and what you're actually paying for. The markup can be anywhere from 15% to 40% depending on your traffic patterns and network conditions.

The only way to get ground truth is to monitor network traffic at the kernel level, independent of your cloud provider's metering systems.

/proc/net/dev: Your Ground Truth

Linux gives you direct access to interface-level byte counters through /proc/net/dev. This file shows exactly what the kernel has sent and received on each network interface, without any cloud provider markup or interpretation.

cat /proc/net/dev | grep eth0
eth0: 45234567890 412785643 0 0 0 0 0 0 23847562341 287453291 0 0 0 0 0 0

Those first two numbers after the interface name are RX bytes and RX packets. The ninth and tenth columns are TX bytes and TX packets. These counters represent exactly what moved across the wire at the network interface level.

Unlike CloudWatch, Azure Monitor, or GCP's Network Intelligence, these numbers can't be manipulated by billing algorithms or marked up with "value-added" overhead calculations. They're raw kernel counters that increment every time a packet crosses the interface boundary.

Building Independent Bandwidth Verification

To catch billing discrepancies, you need continuous monitoring that logs these interface counters alongside timestamps. A simple bash script running every minute can build a comprehensive picture of your actual bandwidth usage:

while true; do
    echo "$(date +%s),$(grep eth0 /proc/net/dev | awk '{print $2","$10}')"
    sleep 60
done >> /var/log/bandwidth.log

This creates a CSV log with timestamp, RX bytes, and TX bytes every minute. After a month, you'll have granular data showing exactly when traffic spikes occurred and how much data actually moved through your interfaces.

Compare this log against your cloud provider's bandwidth billing. The discrepancies are often substantial and systematic.

Multi-Cloud Cost Reconciliation

The problem becomes more complex in multi-cloud environments where each provider uses different billing models. AWS charges for data transfer out of regions. Azure bills for bandwidth based on geographical zones. GCP has its own network egress pricing tiers.

But your servers don't care about billing zones. Data is data, regardless of whether it's crossing an AWS availability zone boundary or moving between Azure regions. Vendor-neutral multi-cloud monitoring becomes essential for normalising these different billing approaches against actual network usage.

Collecting /proc/net/dev data from servers across all your cloud providers gives you a unified view of actual bandwidth consumption. You can then map this real usage against each provider's billing model to identify which environments are consistently overcharging.

The results often reveal that certain providers systematically bill 20-30% more than actual interface-level data transfer. This adds up quickly when you're moving terabytes per month.

When to Challenge Your Cloud Bill

Armed with months of interface-level bandwidth logs, you have concrete evidence to dispute billing discrepancies. Cloud providers will typically investigate billing disputes when you can demonstrate systematic overcharging with technical evidence.

The key is presenting data they can't dispute. /proc/net/dev counters are kernel-level facts. They can't argue with Linux's own network accounting.

Most successful billing disputes focus on periods where the gap between actual interface usage and billed bandwidth exceeds 25%. Smaller discrepancies often get dismissed as normal protocol overhead, but larger gaps indicate billing system problems worth investigating.

Keep detailed logs for at least six months. Filesystem backup health monitoring techniques ensure your bandwidth logs remain intact and verifiable for billing dispute processes.

Server Scout's network monitoring includes interface-level byte counting specifically to help teams verify actual bandwidth usage against cloud provider billing. The lightweight bash agent collects /proc/net/dev data without the resource overhead of complex network monitoring tools that might skew the very measurements you're trying to validate.

Cloud bandwidth billing remains one of the least transparent aspects of cloud computing costs. But with proper interface-level monitoring, you can at least verify you're paying for bytes that actually crossed your network interfaces, not just bytes that crossed the provider's billing algorithms.

FAQ