Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Bills Now Charge for Egress to Your Own VPC
Transcript
- Lucas: So there's a line item that's been showing up on more and more cloud bills this year, and it's not AI compute or GPU time. It's the charge for moving data between two virtual private clouds inside the same provider, in the same region. Luna: Wait, you mean egress charges for traffic that never leaves the provider's network? I thought that was the one thing they didn't charge for. Lucas: That's the assumption a lot of teams make, and it's becoming an expensive one. I've got a concrete example. A friend of mine runs a data platform at a mid-sized fintech, and in their last monthly bill, the line for intra-region vpc to vpc transfer was over eighteen thousand dollars. That's up from around twelve hundred a year ago. Luna: Eighteen thousand dollars for moving data between your own virtual networks. That's a fifteen times increase. What changed? Lucas: What changed is they rearchitected. They moved from a single large VPC with everything inside, to a multi vpc setup using VPC peering. On paper, peering is supposed to be free or cheap. But the traffic between the peered VPCs is now billed as egress, even though it's all within the same region and the same cloud provider. Luna: So the more you follow the best practice of isolating workloads into separate VPCs, the more you end up paying for the privilege. Lucas: Exactly. And the providers don't exactly advertise it. On AWS, for example, data transfer between VPCs using a transit gateway or peering connection has a per-gigabyte rate. Azure has similar charges for VNet peering, though they make some of it free depending on the region and the direction. GCP is a bit more generous with internal IP traffic, but even they have started to meter certain paths. Luna: I remember when cloud providers used to boast that moving data around inside their network was free. That was a big selling point. Lucas: It was, and it's still true for some things. But the line has moved. Now, if you're doing a lot of data-intensive work, like training models, syncing databases, or even just running microservices that talk to each other across VPCs, you can blow through hundreds of gigabytes an hour without thinking about it. And the metering is per gigabyte, so it adds up fast. Luna: How does the pricing actually compare across the big three? Is there a cheap one? Lucas: It's not straightforward. AWS charges around two cents per gigabyte for most VPC peering traffic, but it drops to one cent after a certain volume. Azure has a zone-based model where intra-region peering can be free for the first ten gigabytes per month, then a penny and a half per gig after that. GCP is the outlier — they still don't charge for most internal IP traffic, including between VPCs using their VPC peering, as long as it's within the same region. But they've started to charge for some network service tiers. Luna: So a company could save a lot just by choosing GCP for internal-heavy workloads. Lucas: Maybe, but you can't ignore the rest of the stack. The point isn't that one provider is cheaper. It's that egress has become a strategic factor in cloud architecture, and teams need to plan around it. Luna: And that's something you can actually do, right? Architect around it. Lucas: You can. The most obvious move is to use private endpoints instead of peering when you're accessing a shared service. If you have a central database or a data lake, putting it behind a private endpoint and accessing it from other VPCs can be cheaper than routing through a transit gateway. But it depends on your traffic patterns and the provider's pricing model. Luna: What about just placing everything in one VPC? Is that still viable? Lucas: It is, if you can tolerate the security trade-offs. A single large VPC with subnets and security groups can work for many workloads. But as you scale, you often want isolation for compliance or blast-radius reasons. So it's a balance between security and cost. The teams that are managing this well are the ones that treat egress like any other resource — they monitor it, they set alerts, and they design with cost in mind from the start. Luna: Interesting. Before we go deeper into the workarounds, I have to say, this kind of conversation — it's exactly the stuff that helps people who are actually running these systems. And if you're getting value out of it, consider supporting the show. A couple of dollars a month genuinely helps keep this podcast independent and ad-free. You can do that at buy me a coffee dot com slash fexingo. It takes a minute, and it makes a real difference for us. Lucas: Thanks for saying that, Luna. And yeah, every bit helps. Now, back to the architecture. One more thing to think about is where you put shared services. If you have a data analytics team in one VPC and the data warehouse in another, you're paying for every query that crosses the boundary. Sometimes it makes sense to co-locate them in the same VPC, or even the same subnet, even if it means a bit less isolation. Luna: So it's a trade-off between security and cost, but it's not always obvious which side wins. Lucas: Right. And that's why you need to model your traffic. A lot of teams don't have visibility into how many gigabytes are moving between VPCs each month. They just see a line item at the end of the bill. If you start measuring early, you can make informed decisions. Luna: What about using a NAT gateway or a proxy? Does that change the calculation? Lucas: A NAT gateway can actually make it worse, because you're adding another metered component — the NAT gateway itself has an hourly charge, plus per-gigabyte processing fees. And it's not a replacement for VPC peering; it's for outbound internet access. So you want to be careful not to route internal traffic through it. Luna: Okay, so what about the long term? Is this a trend that's going to continue, with providers charging more for internal data movement? Lucas: I think it's part of a broader shift. Cloud providers are looking for ways to monetize the massive amount of data that flows through their networks. Egress is a lever they can pull without raising list prices on compute or storage, which are under competitive pressure. So I wouldn't be surprised to see more granular egress pricing in the future, maybe even for traffic between availability zones within the same region. Luna: That's already happening in some cases, isn't it? I've heard of charges for cross az traffic. Lucas: Yes, AWS has charged for cross az data transfer for years. But the intra-region, inter vpc charge is newer and less understood. And it's a different beast because it's not about redundancy — it's just about isolation. So the bill comes as a surprise to many. Luna: Have you seen any good examples of companies optimizing this successfully? Lucas: One pattern I like is using VPC endpoints for specific services like S3 or DynamoDB. Instead of sending traffic through a NAT gateway or a peering connection, you use a private endpoint that keeps the traffic within the provider's backbone and often at a lower or zero cost. On AWS, for example, using a gateway endpoint for S3 is free — you just pay for the data transfer, and that's often cheaper than a NAT solution. Luna: So the answer is to know which services have endpoints and which don't. Lucas: Exactly. And to design your network topology around those endpoints. But it requires a bit of homework, because each provider has different services and different pricing models. GCP, for example, has private Google access, which lets you reach Google Cloud services from your VPC without a public IP, and they don't charge extra for that in most cases. Luna: It sounds like the cloud bill is becoming a lot more like a utility bill — you have to understand the rate structure to control your costs. Lucas: That's a good analogy. And just like with utilities, there are often discounts for committed use or volume tiers. AWS has the data transfer program where you can get lower rates if you commit to a certain volume. Azure has savings plans that include some data transfer. So it pays to negotiate. Luna: But negotiation is easier for big enterprises. What about a startup that's just trying to keep their burn rate under control? Lucas: For startups, the best advice is to start with a single VPC and only split when you have a real need. And then, when you do split, monitor your egress from day one. Set up billing alerts for when you cross certain thresholds. A lot of this data is available in the provider's monitoring tools, but you have to turn it on. Luna: Have you seen any tools that help with this? I'm thinking of third-party FinOps platforms. Lucas: There are a bunch, and they're getting better at breaking down egress costs. Some can even recommend specific architectural changes based on your traffic patterns. But you can also do a lot with a simple spreadsheet and some thoughtful tagging. The key is to tag your resources with the workload or team, so you can attribute egress costs accurately. Luna: So it's about visibility first, then optimization. Lucas: Exactly. And I think that's the bigger lesson here. The cloud gives you incredible flexibility, but it also gives you a bill that can surprise you if you're not paying attention. The teams that are winning are the ones that treat cost as a first-class design constraint, not an afterthought. Luna: Well said. So, for someone listening who's about to design a new environment, what's the one thing you'd tell them? Lucas: Map your data flows before you build anything. Know which services need to talk to each other, and how much data they're going to move. Then choose your VPC topology and endpoints based on that map. It'll save you a lot of money and a lot of headache down the road. Luna: And if they're already in a situation where they're paying too much for egress? Lucas: Start by auditing your current bill. Look for line items that mention data transfer, egress, or peering. Then trace back to the source. Often, you'll find a few heavy hitters — like a database replication job or a data pipeline that's moving terabytes a day. Fix those first, and the savings can be substantial. Luna: It's a bit like finding the energy hogs in your house. You don't need to change everything, just the big consumers. Lucas: Exactly. And once you've optimized those, you can look at the long tail. But the big wins come from the big flows. I've seen companies cut their egress costs by forty percent just by moving a few workloads into the same VPC or using a private endpoint for a data lake. Luna: Forty percent is a big deal. And it's not even about switching providers — it's about using the one you have more intelligently. Lucas: Right. And that's the takeaway I want listeners to have: egress is not a fixed cost. It's something you can manage with the right architecture and the right tooling. The cloud is still the best deal in computing, but it's not a blank check. Luna: Great way to put it. Thanks for breaking this down, Lucas. I feel like I actually understand my bill a little better now. Lucas: Thanks, Luna. And if you're listening and you've got a cloud cost horror story, we'd love to hear it. You can find us on the Fexingo network. Until next time.