Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Bills Now Charge for Cross-AZ Data Transfer
Transcript
- Lucas: So I was auditing a client's cloud bill last week — a regional e-commerce platform, maybe fifty thousand monthly active users — and I noticed something that made me stop. Forty thousand dollars in a single quarter for a line item that just said 'inter-zone data transfer.' Luna: Oof. That's not the kind of charge you expect to see without warning. How did it get that high? Lucas: Well, that's the thing — it wasn't a surprise to anyone who'd actually built the architecture. They had a Kubernetes cluster spread across three availability zones, and their database replicas were spanning zones too, for high availability. Every time a pod talks to a database replica in another zone, that's metered. Every time a service in zone A calls a service in zone B, that's metered. Luna: Right, and most people think of the network egress fee as something you pay when data leaves the cloud to the internet. But moving data between zones is a different beast. Lucas: Exactly. And it's cheaper than internet egress — typically a cent or so per gigabyte — but it adds up fast when you're moving terabytes of internal traffic every day. The cloud providers charge for it because it's real infrastructure: fiber runs between availability zones, and they have to pay for that capacity. Luna: So it's not just a money grab — it's a reflection of physical reality. But the pricing model still feels opaque. Lucas: It is. And the default advice—'just run your cluster in three zones'—ignores the cost. In this client's case, they didn't need to be running their entire stack across three zones. They had a single region, but the high-availability requirement was really just for the database. The stateless services didn't need it. Luna: So what did you recommend? Did you shift them to two zones? Or consolidate? Lucas: We did a few things. First, we identified which services actually needed cross-zone communication. For their core transactional flow, we collapsed everything into a single zone — that eliminated the bulk of the inter-zone traffic. Then we kept the database replicas in two zones, but we configured the application to write to the primary and only read from the replica when it was in the same zone. Luna: So you're trading a bit of latency for a huge cost saving. What did that end up doing to the bill? Lucas: It cut that forty grand down to about nine thousand — a seventy-five percent reduction. And honestly, the performance impact was negligible because the critical path was staying in one zone. The cross-zone traffic that remained was mostly for background analytics and reporting, which could tolerate a few extra milliseconds. Luna: That's a great before and after. But I'm curious — how common is this mistake? Is it just e-commerce platforms, or does this hit everyone? Lucas: It's everywhere. I've seen the same pattern in fintech startups, in SaaS products, even in internal enterprise tools. The instinct is to design for resilience from day one, so you spread everything across zones. But the reality is, most workloads don't need that level of distribution. And the cloud providers are happy to keep the meters running. Luna: So the first step is always to understand what your actual availability requirement is. Not what you think it should be — but what your business truly needs. Lucas: Exactly. And once you know that, you can start making deliberate choices about where your instances live and how they talk to each other. One simple trick: if you're using a Kubernetes service, make sure your services are pinned to a specific zone, or at least use topology spread constraints to keep traffic local. Luna: Another thing I've seen help is consolidating your NAT gateways. Each zone often gets its own gateway, and that's a fixed cost per hour. If you can route all outbound traffic through a single gateway in one zone, you save on the gateway fee — though you do take on a single point of failure. Lucas: Yeah, that's a trade-off you have to make consciously. But for many workloads, the cost savings are worth it, especially if you're not doing anything mission-critical. Luna: So let's talk about the actual pricing models. Do all three major clouds charge the same way? Lucas: They're similar, but there are nuances. AWS charges about one cent per gigabyte for data transfer between availability zones, both ways. Azure is roughly the same, though they structure it a bit differently — they have a 'data transfer' charge for inter-zone traffic. GCP is a little more generous: they have a tiered model, and if you use their premium tier networking, you pay a bit more, but standard tier is cheaper. Luna: So it's not a one-size-fits-all answer. But the core principle is the same: if you move data between zones, you pay. Lucas: And the key is to avoid it as much as you can. Because it's not just the network cost — it's the added latency, which can degrade performance. And it's the hidden complexity in your billing. Luna: It's also a good reminder that cloud architects need to think about cost as a first-class constraint, not an afterthought. Which, honestly, is a lesson that applies to a lot of things in this industry. Lucas: Absolutely. And that's actually something I think about regularly. If you're getting value from these conversations — whether you're an architect, a founder, or just someone who wants to be smarter about the cloud — that's what keeps this podcast ad-free. If today's episode was worth a coffee to you, the link is buy me a coffee dot com slash fexingo. Luna: Yeah, it's a small way to keep this going, and we genuinely appreciate it. Now, back to the numbers — what are the other hidden charges that tend to sneak into these bills? Lucas: Well, besides cross-zone transfer, there's also something called 'data processing' fees for things like NAT gateways and load balancers. Those are per-hour charges that don't depend on traffic — you pay just for having them running. And then there are the egress fees to the internet, which are much higher, typically nine to twelve cents per gigabyte. Luna: So even if you're not moving data between zones, you're still paying for the infrastructure that makes your network work. Lucas: Right. And the more you can architect around those fixed costs, the better. For instance, using managed services like an internal load balancer in a single zone can reduce the number of components you're paying for. Luna: What about using a content delivery network? Does that help with egress costs? Lucas: Sometimes. If you're serving a lot of static content to users, a CDN can reduce the egress you pay because you're pulling from edge locations. But for internal traffic, that doesn't help. Luna: So the takeaway is really about being intentional with your architecture. Don't just spin up a cluster in three zones because that's the default. Really think about what your availability needs are. Lucas: Exactly. And the tools are getting better. The cloud providers now offer cost analytics that break down transfer costs by zone and by service. We used that to pinpoint the biggest offenders for that client. Luna: So within a few hours of analysis, you can identify the biggest cost drivers and start fixing them. Lucas: Yeah. And the fixes are usually straightforward. It's not about re-architecting everything; it's about making small changes that have a big impact. Luna: It sounds like the kind of thing every team should do annually, at least. Lucas: I'd say more often than that. Cloud pricing changes, and your traffic patterns change. A quarterly review of your transfer costs is a good habit. Luna: So next time you get a cloud bill that seems higher than expected, check the inter-zone transfer line. Lucas: That's the one that'll surprise you. And it's a good reminder that the cloud is a utility — you pay for what you use, but you can control what you use if you're smart about it.