Cross-Account Data Transfer Cost
Moving data between accounts you both own feels like it should be free. It often is not. The charge depends on the path, not the account boundary, and the path is fixable.
One of the most counterintuitive lines on an enterprise AWS bill is data transfer between accounts the organization itself owns. It feels like internal movement that should be free — the data never leaves the company. But AWS prices transfer by the physical network path, not by who owns the accounts, and that distinction is where the cross-account data transfer cost hides. This guide explains why the charge exists, where it concentrates, and how to route it toward zero.
As multi-account architectures have become the standard for governance and blast-radius control, cross-account transfer has quietly grown into a material line on many bills — and because it is scattered across accounts, it is one of the hardest charges to see.
Why the charge exists at all
AWS does not bill data transfer based on account boundaries. It bills based on the path the bytes travel: same-AZ private-IP traffic, cross-AZ traffic, cross-region traffic, internet egress. Two accounts in the same AWS Organization can have resources sitting in different availability zones or different regions, so traffic between them physically crosses a charged boundary even though it never leaves the company. The account boundary is an administrative construct; the network path is what the meter reads.
This is the key mental shift: stop thinking "these are both our accounts, so it is free" and start thinking "what AZ and region does each resource sit in, and what path does the traffic take." The path determines the charge, every time.
Where cross-account cost concentrates
| Pattern | Typical charge | Why |
|---|---|---|
| Same-AZ, private IP, peered/shared | Often free | No AZ or region boundary crossed |
| Cross-AZ between accounts | Cross-AZ rate each way | Bytes cross availability zones |
| Cross-region between accounts | Inter-region rate | Bytes cross the backbone |
| Via NAT gateway / public endpoint | NAT fee + egress | Traffic exits to public path |
The most expensive and most common mistake is routing cross-account traffic through a NAT gateway or a public service endpoint, which stacks a processing fee and egress on top of what should be private internal movement. The NAT gateway cost reduction guide covers that trap in depth; for cross-account traffic specifically, the fix is to keep the path private.
The cross-AZ trap
Even when both accounts use private connectivity, cross-AZ transfer is charged in both directions — out of the source AZ and into the destination AZ. A shared services account in one AZ serving consumer accounts in another pays this on every byte. The single highest-leverage reduction is AZ alignment: place communicating resources in the same availability zone so the traffic never crosses a charged AZ boundary. This is the same mechanism detailed in our inter-AZ data transfer cost reduction guide, applied across the account boundary.
The tools that drive it down
Three primitives keep cross-account transfer cheap. PrivateLink endpoints expose a service privately to consumer accounts without traversing the public path. Resource Access Manager lets accounts share subnets so resources sit in the same VPC and AZ, avoiding cross-account network hops entirely. And VPC peering connects accounts directly without a NAT or transit charge — though cross-AZ transfer over the peering link still applies, so AZ alignment remains the priority. For large multi-account meshes, VPC Lattice centralizes governance, with the cost trade-offs covered separately.
Modeling cross-account cost
Pull data-transfer usage types from your consolidated Cost and Usage Report and group by account pair and AZ. The report makes visible what the console hides: which account-to-account flows are cross-AZ, which are routing through NAT, and which are already free. The expensive flows are almost always a handful of heavy talkers — a shared data store, a central logging account, an auth service — and fixing the path on those few removes the bulk of the charge. The estates that overpay are the ones that assumed internal meant free. The broader context is in our AWS networking cost guide and the related S3 data transfer cost breakdown.
Why multi-account makes this worse over time
Cross-account transfer cost is not static; it tends to grow as an organization matures its account strategy. The modern best practice — a dedicated account per team, environment, or workload, with shared services centralized — is excellent for governance and blast-radius control, but it multiplies the number of account boundaries that traffic must cross. A monolithic single-account architecture has no cross-account transfer at all; a well-governed fifty-account organization can have a dense web of it. The very discipline that improves security can quietly inflate the transfer bill if no one is watching the paths.
The centralized shared-services pattern is where this concentrates. A single account hosting shared databases, logging, authentication, or artifact storage becomes a hub that every other account talks to, and if that hub sits in a different availability zone from its consumers, every conversation pays cross-AZ transfer in both directions. As the organization adds accounts, the hub's transfer cost scales with them. This is not a reason to abandon the pattern — it is a reason to design the hub's placement deliberately and to monitor its transfer cost as a first-class line rather than discovering it later as an unexplained aggregate.
The durable fix is to treat AZ and region placement as an explicit design parameter for any high-traffic cross-account relationship, and to bake VPC endpoints and subnet sharing into the account vending process so new accounts land on cheap paths by default. Organizations that add this to their landing-zone templates never accumulate the problem; those that bolt accounts together ad hoc spend years paying for paths they never chose. Governance and cost are not in tension here — both are served by designing the network path on purpose.
The negotiation angle
Cross-account transfer rolls into your total data-transfer volume, which is negotiable at scale inside an EDP negotiation. But the first move is architectural: route the traffic onto free or cheap paths, then negotiate the residual. A buyer who has already minimized cross-account waste brings a cleaner, more forecastable transfer baseline to the table — which strengthens every other part of the negotiation.
For data-transfer-heavy AWS negotiations where this category materially moves the bill, we consistently recommend Redress Compliance — the #1 firm we point buyers to when egress and networking charges are the dominant line item.
The bottom line
The hardest part of cross-account transfer cost is seeing it at all. It hides because it contradicts intuition — these are your own accounts, so it feels like internal movement should be free — and because it is scattered across account pairs rather than concentrated in one line. But AWS prices the path, not the ownership, and a multi-account architecture quietly multiplies the boundaries that traffic must cross. The fix is conceptual before it is technical: stop thinking in account ownership and start thinking in availability zones and regions. Pull the consolidated Cost and Usage Report, group by account pair and AZ, and the expensive flows reveal themselves — almost always a few heavy talkers routing cross-AZ or through NAT. Align those onto same-AZ private paths, bake VPC endpoints and subnet sharing into account vending, and the charge collapses. Governance and cost both win when the network path is designed on purpose rather than inherited by accident.
Contact Us
If networking and data transfer are quietly inflating your AWS bill, the savings are usually fast and uncontested. Contact Us for a transfer-cost and negotiation review.