Compute and storage get budgeted, reviewed, and optimized. Data transfer usually doesn't — it just shows up as a line item that grows quietly until someone asks, "wait, what is this?" Here's where it actually comes from, and why it's disproportionately easy to miss.
Why this category is different from everything else on your bill.
Compute and storage costs are visible at the point of decision — you pick an instance size, you pick a storage class, you see the price. Data transfer costs are a side effect of architecture decisions made for completely different reasons: which AZ a service landed in, whether a NAT gateway sits in the request path, whether two services that talk to each other constantly happen to be in the same region. Nobody chose "pay for cross-AZ traffic" as a decision — it fell out of decisions about redundancy and deployment topology instead. That's exactly why it's the cost category most likely to go unbudgeted.
Where it actually comes from — the three real sources.
Cross-AZ traffic. Multi-AZ deployments are the right call for availability, but every byte that crosses an availability zone boundary typically has a charge attached, in both directions. Two services that chat constantly — a web tier hitting a database, a cache layer, a message queue — can rack up meaningful cross-AZ charges if they're not deliberately co-located, even though each individual call is cheap.
NAT gateway processing. NAT gateways charge per-GB processed, not just an hourly rate — and that per-GB fee is easy to forget exists because it doesn't show up until you're already routing meaningful traffic through it. Any workload doing bulk outbound calls (large downloads, syncing with an external API, pulling container images repeatedly) through a NAT gateway can turn a "just for internet access" component into a real cost center.
Unplanned egress. Data leaving the cloud entirely — to the public internet, to another cloud provider, to an on-prem system — is usually the most expensive transfer type per GB. This is the one that actually blindsides teams: a backup job that changed destinations, a multi-cloud integration nobody sized for the data volume involved, or simply more customer-facing traffic than expected.
How to actually find it, since it won't show up as a helpfully-labeled line item.
Most cloud cost tools bury data transfer inside broader service costs rather than breaking it out cleanly. Two starting points: your cloud provider's detailed billing export (AWS Cost and Usage Report or equivalent) filtered specifically to data transfer line items, and VPC Flow Logs if you need to trace which services are generating the cross-AZ or egress traffic rather than just how much. The FOCUS spec (a cross-cloud billing standard) is also making this easier to isolate consistently if you're dealing with more than one provider — worth a look if this line item keeps eluding you.
What to actually do once you've found it.
Co-locate chatty services in the same AZ where availability requirements allow it. Route traffic to AWS services through a VPC endpoint instead of a NAT gateway where available — Gateway endpoints (S3, DynamoDB) eliminate the NAT processing fee entirely for that traffic, while Interface endpoints for other services still carry their own charge but typically cost less than routing the same traffic through NAT. And treat any new integration that moves meaningful data across a region or provider boundary as a cost decision at design time, not something to discover in next month's bill.
The actual takeaway: data transfer costs are invisible by default, not because they're small, but because they're a byproduct of decisions made for other reasons. The fix isn't a smarter pricing tier — it's making transfer cost a visible input the first time architecture decisions get made, not an afterthought discovered in Cost Explorer.
Found an egress or cross-AZ charge you can't fully explain? Reply to this email — I'll help you trace it.