Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Cloud Contracts Now Charge for Internal Load Balancer Throughput
Transcript
- Lucas: If you've been assuming that traffic between your virtual networks inside the same cloud provider's data center is free — it's time to check your latest contract. Luna: Are we talking about the new internal load balancer throughput charges? I've seen some grumbling on Reddit about it. Lucas: Exactly. AWS, Azure, and GCP have all quietly introduced per-gigabyte charges on internal load balancers — the ones that sit between your application tiers, not exposed to the internet. It used to be bundled into the hourly fee for the load balancer itself. Luna: So what changed? Why did they start unbundling this? Lucas: The official line is 'infrastructure sustainability' — which is cloud-speak for 'we need to capture revenue from the massive amount of east-west traffic we weren't billing for before.' Internal traffic has been growing much faster than internet-facing traffic as microservices architectures proliferate. And the cloud providers realized they were leaving money on the table. Luna: How much money are we talking? Give me a real-world scenario. Lucas: Say you're a mid-size SaaS company running fifty internal load balancers — that's not uncommon for a multi-service architecture. If each one handles an average of 500 megabits per second of throughput, and you're now paying around five cents per gigabyte processed through the load balancer, that's roughly fifteen thousand dollars a month extra. Per month. Luna: Ouch. And that's just the load balancer data processing fee — doesn't include the data transfer between availability zones or regions. Lucas: Right. But here's the thing — the new charges apply even within the same availability zone. So it's purely a tax on internal traffic routing. AWS's Application Load Balancer now has a 'data processing fee' of — let me get this right — eight dollars per TB of data processed by the load balancer. That's on top of the hourly rate. Luna: Wait, is that per load balancer or per account? Lucas: Per load balancer. So if you have multiple ALBs handling different parts of your application, each one incurs its own data processing charge. And Azure is doing something similar with their internal Standard Load Balancer — they've introduced a 'data processed' charge that shows up on your bill as a separate line item. Luna: How are enterprises reacting? I imagine this isn't going over well in FinOps circles. Lucas: There's definitely frustration, but the cloud providers have framed it as a 'more granular pricing model' that lets you pay only for what you use. The problem is, most architects and procurement teams didn't see it coming because it was buried in terms of service updates. A lot of organizations are only now discovering these charges when their monthly bill jumps unexpectedly. Luna: So what's the playbook for teams that want to avoid or minimize these charges? Lucas: First, audit your load balancer usage. You might be overprovisioning — consolidating services behind fewer load balancers can reduce the total data processing fees. Second, consider using service mesh technologies like Istio or Linkerd that can route traffic at the application layer without going through a cloud-managed load balancer. That keeps the traffic internal and avoids the per-gigabyte charge. Luna: But doesn't running a service mesh on Kubernetes come with its own operational overhead and cost? Lucas: Absolutely. It's a trade-off. You're swapping a cloud-variable cost for a fixed operational cost. For large-scale deployments, the math can work in your favor. But for smaller teams, it might not be worth the complexity. The key is running the numbers with your actual traffic patterns. Luna: What about contract negotiation? Can you push back on these charges in an enterprise agreement? Lucas: Yes, but you have to be strategic. If you're signing a three-year commitment with AWS or Azure, you can negotiate a cap on data processing fees — say, no more than ten percent of your total monthly bill. Or you can ask for a waiver on internal load balancer charges for a set period. The providers are more willing to give concessions on new line items than on core compute or storage. Luna: Interesting. So the smaller line items are actually more negotiable because they're not as locked in. Lucas: Exactly. The providers want to establish the fee as a standard, but they'll trade short-term discounts to lock in the overall contract. I've seen enterprise agreements where the customer got a full twelve-month exemption on load balancer data processing in exchange for a higher commit on compute. Luna: That's a good data point. Any other architectural tricks to reduce exposure? Lucas: One approach is to use direct private connectivity — like AWS Direct Connect or Azure ExpressRoute — to route internal traffic through a dedicated link that bypasses the load balancer. But that's only feasible if you're in a hybrid setup. For purely cloud-native architectures, you can also look at using Network Load Balancers instead of Application Load Balancers for simple TCP traffic — NLB's data processing charge is typically lower. Luna: And GCP? I haven't heard as much about their internal load balancer pricing changes. Lucas: GCP's internal load balancer — which they call the Internal TCP/UDP Load Balancer — has historically been priced solely on forwarding rules. But in early 2026, they introduced a 'data processing' charge similar to AWS. It's about six dollars per TB processed. They also added a minimum charge per forwarding rule per hour, which makes it harder to have many small load balancers. Luna: So the trend is clear: the big three are all moving to meter internal traffic. What's the bigger picture here? Is this a one-off or a signal for what's next? Lucas: I think it's a signal. The cloud providers have been notoriously opaque about internal networking costs. Historically, the mantra was 'the network is free inside the cloud.' That's no longer true. We're seeing a broader unbundling: first it was egress charges, then NAT gateway fees, then VPC peering costs, and now internal load balancer throughput. I expect the next shoe to drop will be charges for VPC flow logs or DNS queries within the data center. Luna: Which means cloud cost management is becoming less about compute and storage optimization and more about network architecture decisions. Lucas: Exactly. And that's a skill set many cloud architects didn't need five years ago. The FinOps role is evolving from 'right-size your instances' to 'design your network topology for cost.' It's a significant shift. Luna: Speaking of shifts that matter — if you're finding these insights useful for what you're building or running, there's a simple way to keep this podcast ad-free and independent. Lucas: Yeah, listener support is what makes this possible. If you can, consider buying us a coffee at buy me a coffee dot com slash fexingo. It helps us keep diving into these contract details without having to chase sponsors. Luna: And we genuinely appreciate it. Now, back to those architectural changes — one thing I've been wondering: how do you actually audit your current load balancer usage across multiple accounts? Lucas: Great question. Most cloud providers offer cost allocation tags that you can apply to load balancers. The first step is to ensure every load balancer is tagged with the application, environment, and owner. Then use the provider's cost explorer to filter by 'load balancer' service and look for the data processing line item. You can set up anomaly detection alerts for any sudden spike. Luna: Any third-party tools that help visualize this? Lucas: Yes — tools like Vantage, CloudHealth, and Spot by NetApp have updated their cost models to include these new charges. They can show you cost per load balancer and even recommend consolidation. But honestly, a well-structured spreadsheet with your top twenty load balancers by throughput will get you eighty percent of the way. Luna: So the action item for our listeners: audit your internal load balancers, run the numbers, and if they're significant, consider consolidation or architectural alternatives before your next bill cycle. Lucas: And if you're in the middle of a contract renewal, bring this up in negotiation. The providers are still in the rollout phase — they're more flexible now than they will be in a year. This is the moment to lock in favorable terms. Luna: Good advice. I think that's a solid place to wrap up. Thanks, Lucas. Lucas: Thanks, Luna. And thanks to everyone listening. We'll be back next episode with another deep dive into the fine print that's shaping your cloud bill.