The cloud bill nobody modeled: egress and the IPv4 tax

The surprising line on a 2026 cloud bill isn't compute - it's the networking. Egress fees, NAT gateway charges, and per-address IPv4 costs have quietly become a tax on data leaving the cloud, and for many teams they now add up to roughly an 18% "hidden" share of total spend. The trap is that the per-gigabyte price looks trivial in isolation, so nobody models it, and then real-time features and a global user base multiply the volume until the line item is impossible to ignore. Worse, the usual cost-cutting levers top out fast - you can trim 15-25% off a raw bill and then hit a wall, because the thing driving the cost is where your data lives, which right-sizing can't touch.

Why this matters now

The economics shifted. Cloud providers largely stopped competing on compute price and started charging for the network. The per-GB egress rate has barely moved since 2020, but application data volumes have grown to 3-7× what teams modeled in their original migration plans - real-time features, global users, and microservices all multiply cross-boundary traffic. Analyses of 2026 bills put networking charges - egress, public IPv4, and NAT processing - at a ~18% hidden tax on total cloud spend for organizations running multi-cloud or hybrid setups (2026 cloud networking cost analysis).

The individual charges look small, which is exactly why they slip past estimates. It's the aggregate, at scale, that hurts.

The mechanism: small per-GB, huge in aggregate

Here's what a single gigabyte of internet-bound traffic actually costs once you stop looking at the headline rate.

On AWS, base egress to the internet runs about $0.09/GB - but a NAT Gateway adds $0.045/GB in processing on top, pushing the true cost of internet-bound traffic to roughly $0.135/GB. Cross-AZ transfer adds $0.01/GB each way, and every public IPv4 address now carries a $0.005/hour charge (which is why moving to IPv6 - and dropping NAT gateways - is one of the few structural wins available). Stacked up, these "hidden" networking costs can add 50-200% on top of the base egress you budgeted for.

The reason this compounds is architectural. A chatty microservices design, a real-time feature that streams to a global audience, a multi-cloud setup that shuttles data between providers - each multiplies the number of gigabytes crossing a billed boundary. The per-GB price didn't change; your architecture made you cross that boundary far more often than you planned.

Why optimization hits a ceiling

The standard FinOps playbook works - up to a point. Right-sizing instances, killing idle resources, and buying reserved capacity will pull 15-25% off a raw bill, and most teams reach that ceiling within about 18 months. But none of those levers touch egress, because egress isn't about how big your instances are - it's about the fundamental model of charging you to move your own data.

Right-sizing makes the compute cheaper. It does nothing about the toll you pay every time data leaves. Past a point, the only real lever is architectural: move less data across billed boundaries, or move the data somewhere the toll is lower.

That's where the numbers get stark. Egress rates vary by up to 127× across providers - from $0/GB on zero-egress object storage to $0.12/GB on premium tiers. For a workload where egress is 50%+ of the bill, no amount of right-sizing competes with putting the data where leaving it is free.

What actually moves the needle

• Make networking visible. You can't manage a cost you never itemized. Break egress, NAT, cross-AZ, and IPv4 out of the bill so the 18% stops hiding.
• Cut cross-boundary traffic architecturally. Cache at the edge, colocate chatty services, keep data-heavy paths inside a zone. The cheapest gigabyte is the one that never crosses a billed line.
• Move to IPv6 and drop NAT gateways where you can - it removes both the per-address IPv4 charge and the NAT processing fee.
• Put egress-heavy data on a zero-egress store. If serving data is the workload, the storage location is the cost driver - and some providers charge nothing to read it back.

Our opinion

Our take: treat egress as an architecture decision, not a line item to negotiate down. The teams that keep getting surprised are the ones treating cloud cost as a procurement problem - chasing discounts and reserved instances while the networking bill climbs underneath. The teams that stay in control design for data locality from the start: fewer billed boundary crossings, edge caching where it counts, and egress-heavy data placed where reading it is cheap or free.

We'd also push back on the reflex to accept the ~18% as a cost of doing business. It's a cost of a particular architecture, and it's often avoidable without heroics - the biggest wins we see come from moving one egress-heavy workload off a premium tier, not from a thousand small optimizations. This is the same mindset as our broader take on controlling cloud costs: measure honestly, then fix the structural driver rather than shaving the edges.

How Ashvara helps

We design and run cloud infrastructure, and the networking bill is squarely our lane: itemizing where egress actually comes from, cutting cross-boundary traffic with sane architecture and edge caching, moving to IPv6 to kill the IPv4 and NAT tax, and placing egress-heavy data where it's cheap to serve. The goal is a bill that reflects your compute, not a hidden tax on every gigabyte that leaves.

If your cloud bill is climbing faster than your usage, or you want infrastructure designed so egress doesn't ambush you, that's our DevOps and cloud work. Talk to us and we'll find the structural driver, not just the low-hanging fruit.

Source: The hidden networking bill: egress, IPv4, and NAT gateway fees in 2026 (true internet-bound cost ~$0.135/GB on AWS; ~18% hidden networking tax; egress rates vary up to 127× across providers).