The monthly invoice has arrived and the traffic number is double that of last month, yet you haven't launched any new services. Or worse: the site on your cloud server has suddenly slowed down, and in the panel, outbound traffic is sitting at the cap. These two situations almost always share the same root cause: nobody knows exactly where "cloud server traffic" is counted from and which bytes are being billed.
First of all, you should know that in cloud infrastructure, traffic is not a single number. There are at least four separate numbers, each with its own place in the invoice and in network behavior.
Ingress and Egress Traffic; Which One Is Counted
The rule that is almost universally consistent: ingress traffic is free and egress traffic is counted. That means every byte coming from the internet toward your server is financially worthless; every byte going from your server toward the internet costs money.
This definition is simple, but it has two exceptions that cause the most confusion:
- Traffic between servers on the same private network is usually not counted. If the database and web server communicate over a private network, those gigabytes are not deducted from your account. If that same communication goes over a public IP, it is fully counted. In practice, the difference between these two can amount to several hundred gigabytes per month.
- Traffic between data centers or between regions is almost always counted, even if both servers belong to you.
So the first thing you should do is figure out which path in your architecture goes over a public IP. A simple traceroute will reveal this:
traceroute -n db.internal.example.com
# If the first hop is 10.x.x.x, the path is private
# If it goes over a public IP, that traffic is countedHow Cloud Server Traffic Is Measured
The traffic number you see in the panel comes from the network card counters on the hypervisor, not from your application logs. This means there are several things you will never see: loopback traffic, traffic within the same machine, and packets that were dropped before reaching the network card.
More importantly, counting is done at layer 3, not layer 7. If you send an HTTP request with 800-byte headers and a 200-byte body, the counted number is about 1000 bytes, not 200 bytes. For APIs that return small responses with large headers, this discrepancy can reach up to three times.
To see the real number from inside the server itself, vnstat is the most accurate option that works without an extra agent:
vnstat -m # monthly usage broken down by interface
vnstat -i eth0 -h # hourly report for the past 24 hours
cat /proc/net/dev # raw kernel counter, does not resetIf the vnstat number differs greatly from the panel number, traffic is probably going over a different interface, or part of the traffic was filtered at the network layer before reaching your machine. To see the full picture, combining these counters with cloud monitoring and automated alerts is necessary; without alerts, the first time you notice traffic growth is on invoice day.
What Happens After You Exceed the Cap
This is where provider behavior really differs, and you should know which model you are buying before choosing. There are three common models:
| Model | Behavior after exceeding the cap | The sign you see |
|---|---|---|
| Strict | Bandwidth is limited to a few megabits until the start of the next month | The site loads but TTFB goes from 200ms to 3 seconds |
| Pay-as-you-go | The service works normally, an extra charge appears on the invoice | You feel no slowdown, only a heavier bill |
| Hybrid | Free up to the first cap, then a reduced rate | Cost grows but not linearly |
The first model is more dangerous than it seems, because throttling is usually applied to the entire interface, not just web traffic. That means your SSH also slows down, and if the nightly backup goes over the same interface, it may be left incomplete. If you work on a server whose traffic is unpredictable, choose the pay-as-you-go model; it seems more expensive, but you are not buying service outages.
A real number that will come in handy: a typical web server with 50,000 monthly visits and 1.5-megabyte pages produces about 75 gigabytes of egress. If the same site serves images without compression, that number reaches 300 gigabytes. The difference is just one setting.
Additional IP; When It Is Really Needed
Every cloud server comes with one public IP. An additional IP makes sense in three scenarios, and in the rest it is just cost and complexity:
- Separating services on port 443. If you have two sites with two separate SSL certificates and don't want to deal with SNI, a second IP is the old and reliable solution. Of course, today SNI works on all real browsers, and this reason has faded.
- A static egress for external services. If your banking API or payment gateway whitelists the source IP, a static egress IP is mandatory. This is the only case where you truly have no choice but an additional IP.
- Separating management traffic from service traffic. SSH and the panel on one IP, user traffic on another. This both improves security and makes traffic analysis simpler.
A point that is rarely seen: an additional IP is bound to the same interface, so it does not raise the bandwidth cap. If your problem is a bandwidth shortage, a second IP won't help at all. For that, you need to move toward a distributed architecture.
Where People Go Wrong
The most common mistake I see in tickets is this: someone enables a CDN on the main domain to reduce traffic usage but doesn't change the DNS record from A to CNAME. The result is that the CDN receives no traffic, all requests come directly to the server, and usage stays exactly the same as before. The sign is that in the CDN panel the hit ratio is near zero, yet server traffic hasn't changed.
The second mistake, and the more expensive one: someone counts traffic from the Nginx log and doesn't trust the panel number. The Nginx log only counts the response body and doesn't see headers, the TLS handshake, or retransmit packets. A 15 to 25 percent difference between these two numbers is normal, not a sign of a calculation error.
The third mistake concerns backups. If you send backups to another server on the same network but over the public path, you burn several dozen gigabytes of egress traffic every night. Transferring backups over a private network between servers eliminates this cost entirely and is usually faster too.
Reducing Usage Without Touching the Architecture
Before any major change, do these three things. First, enable compression on Nginx; for text and JSON it usually reduces by 70 percent:
gzip on;
gzip_types application/json text/css application/javascript;
gzip_min_length 1024;Second, convert images to WebP. Third, set browser caching for static files over a long period so every visitor doesn't fetch them again. In practice, these three things reduce egress traffic by 40 to 60 percent and require no changes to the application code.
If usage is still high after these, the problem is architecture, not settings. In that case, turn to a content delivery network so static files are served from the edge, and for large files like video or backups, object storage is a better choice than server disk; because its egress traffic is billed separately and you can see exactly which file consumes how much.
If you work on ServerNet's cloud infrastructure, traffic counters are visible in the same panel, broken down by interface, and you can take a one-week baseline before any change. Have the baseline number; without it, any optimization is a guess.
Frequently Asked Questions
Is ingress traffic on a cloud server also counted?
In almost all cloud providers, ingress traffic is free and only egress is counted. The exception is where traffic goes between regions or between data centers; that is usually counted in both directions.
Why does the panel traffic number differ from vnstat?
Because the panel reads from the hypervisor counters and vnstat reads from the machine's own kernel. A 5 to 15 percent difference is normal and usually comes from management packets, ARP, and traffic before reaching your interface. A difference greater than 30 percent means you haven't seen an interface or a path.
What happens after the bandwidth cap is used up?
It depends on the billing model. In the strict model, bandwidth is limited and all services including SSH slow down. In the pay-as-you-go model, the service stays normal and the cost is added to the invoice. Before buying, you should know which model you are purchasing.
Does an additional IP affect the bandwidth cap?
No. An additional IP is just an address on the same interface and does not change the bandwidth cap. Its real use is separating services, a static egress for whitelisting, and separating management traffic from user traffic.