Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Bill for NAT Gateway Processing
Transcript
- Lucas: So Luna, you know how we keep talking about cloud contracts getting more granular with what they charge for. I think this one might actually fly under a lot of people's radar until the invoice arrives. Luna: I'm all ears. What's the new line item? Lucas: NAT gateway processing. As in, the thing that lets your private instances talk to the internet without exposing them. It used to be a flat hourly rate, and now the big three are starting to meter the actual data that flows through it per gigabyte. Luna: Okay, that is subtle. Because the hourly charge is still there, right? It's just stacked on top. Lucas: Exactly. And if you're running anything that does software updates, pulls container images, or streams logs out to a SIEM, that per-gigabyte number adds up fast. And you know, if these conversations are useful for what you're building or running, the way these stay ad-free is listener support — buy me a coffee dot com slash fexingo. It genuinely helps keep the deep dives coming. Luna: Yeah, and we do appreciate that. But back to the NAT gateway — because I think what's interesting is not that they're charging, it's that they've been charging for years in some form, just bundled. Lucas: Right. Historically, you paid for the NAT gateway by the hour, and the data processing was just part of that. But now, starting with some of the 2025 price list updates, AWS, Azure, and Google Cloud have all introduced per-gigabyte processing fees on top of the hourly rate. Luna: So what's the actual magnitude? I mean, per gigabyte sounds small, but... Lucas: It's typically fractions of a cent per gigabyte, but when you're moving terabytes a day, it compounds. I saw a case study from a mid-size e-commerce platform — they run Kubernetes on AWS, multi az, and they estimated a twelve percent increase in their overall network spend just from this line item. Luna: Twelve percent on network — that's not nothing. And for a company that size, that could be six figures annually. Lucas: Exactly. And the kicker is, it's not just the NAT gateway itself. It's also the associated data transfer charges that were already there. So now you've got egress fees, plus the NAT processing fee, plus the hourly rental. It layers. Luna: So what's driving this? Is it just the vendors looking for new revenue streams, or is there a cost rationale? Lucas: I think it's a mix. The hardware that runs NAT gateways has to scale with throughput, and they're passing that cost through. But there's also a trend in cloud pricing toward 'pay for what you use' at a more granular level. They're moving away from flat rates to usage-based models across the board. Luna: And it's not just NAT gateways. We've seen it with load balancers, with API calls, with storage events. This is part of a broader pattern. Lucas: Exactly. And for teams that are on reserved capacity or enterprise agreements, this might not hit as hard because they have committed use discounts. But for on-demand users, it's a direct line item. Luna: So what should a team do if they're looking at their bill and seeing this new NAT processing fee? Is there a way to mitigate it? Lucas: The first thing is to understand your traffic patterns. If you have a lot of east-west traffic — that is, traffic between instances in the same region — that shouldn't go through a NAT gateway at all. That should be internal. The NAT gateway is only for outbound to the internet. Luna: But a lot of architectures accidentally route internal traffic through the NAT gateway because of routing table misconfigurations. Lucas: Right. So the immediate win is auditing your route tables to make sure only actual internet-bound traffic is going through the NAT. And then look at what's actually egressing. Is it software updates? Is it pulling container images from public registries? Some of that can be cached or redirected. Luna: Caching? Like running a local mirror for container images? Lucas: Exactly. If you're pulling the same base images repeatedly, a local cache can cut that NAT processing traffic significantly. And for things like OS updates, you can use a proxy or a private repository that sits inside your VPC. Luna: So the fee is essentially a tax on egress-heavy workloads. And if you can reduce egress, you reduce the fee. Lucas: Yes. And there's also the architectural option of using a NAT instance instead of a NAT gateway, but that brings its own management overhead and availability concerns. Luna: But with NAT instances, you're paying for the EC2 instance itself, not the per gb fee, right? Lucas: Right, and you have to manage it yourself, which is a trade-off. For some workloads, it might be cheaper, especially if you have predictable traffic. But you lose the managed service aspect. Luna: So this is a classic FinOps decision: do you pay for convenience or do you optimize? Lucas: And it's not just about the fee itself. It's also about the complexity of forecasting your cloud spend. Now you have to estimate per-gigabyte processing, which is variable. That makes budgeting harder. Luna: And with the economy the way it is in 2026, every line item is under scrutiny. Lucas: Absolutely. We're seeing more and more companies adopting FinOps practices precisely because of these kinds of changes. They need visibility into where their money is going, and granular billing forces that. Luna: So what's the takeaway for our listeners? Should they be worried about this? Lucas: I wouldn't say worried, but aware. If you're running a NAT gateway, check your bill this month and see if there's a new line item. If there is, start investigating what's flowing through it. Luna: And if you're not using NAT gateways yet, maybe this is a factor in your architecture decisions going forward. Lucas: Exactly. It's not a reason to avoid NAT gateways altogether, but it's a cost to factor in. And as always, the cloud providers are making these changes to reflect their own costs, but they're also giving you more granular data to work with. Luna: So it's a double-edged sword. More transparency, but also more things to track. Lucas: Yeah. And the teams that do well are the ones that embrace that granularity and build systems to monitor it. Luna: I bet we're going to see a whole new wave of FinOps tools that specifically track NAT gateway processing costs. Lucas: I wouldn't be surprised. In fact, some of the cloud cost management platforms are already adding this as a separate dimension. So it's becoming a first-class citizen in the cost conversation. Luna: And for our listeners who are in the middle of a cloud migration, this is something to consider in the early architecture design, not an afterthought. Lucas: Right. Because once you're in production, changing your networking architecture is a lot harder. So think about your egress patterns now, before you're locked in. Luna: It's a good reminder that cloud pricing is never static. It's always evolving. Lucas: And that's the nature of the business. The providers are constantly optimizing their own margins, and they're passing those changes along. The ones who stay informed are the ones who keep their costs under control. Luna: So, Lucas, what's the one thing you'd want our listeners to remember from this episode? Lucas: I think it's this: look at your NAT gateway bill this month. If you see a processing fee, it's not a bug, it's a feature — and it's one you can manage if you understand your traffic.