Data Transfer Cost

Data transfer cost is the charge a cloud provider applies to moving bytes between places, and it is billed on a dimension no other resource uses: which direction the traffic went and which boundary it crossed. Compute is billed by time and storage by volume; transfer is billed by topology.

Specific rates change often enough that no article should be your source for them — read the provider’s current pricing page before planning against a number. What is stable is the structure, and knowing the structure is what lets you predict a bill rather than explain it afterwards.

What the charge is keyed to

Direction first. Inbound traffic is typically free and outbound to the internet is typically charged, which is why a service that ingests heavily and answers briefly costs almost nothing to feed and a service that serves large responses costs in proportion to its popularity. Azure’s ExpressRoute billing models show the same asymmetry from the connectivity side — an unlimited plan where “all inbound and outbound data transfer is included free of charge,” and a metered plan where “all inbound data transfer is free of charge” while “outbound data transfer is charged per GB of data transfer,” with rates that “vary by region.” Descriptions here follow the Microsoft and AWS documentation, checked in September 2026.

Then the boundary it crossed. Cost rises roughly as the crossing widens — within one availability zone, between zones in a region, between regions, and out to the internet. The exact treatment differs by provider and by service, and the ordering is consistent enough to design against. Which means the question that determines the bill is not how much data you have but where the pieces that talk to each other sit, and that is a decision made in an architecture diagram rather than in a pricing calculator.

Worth clearing up one thing, because it changes how people reason about the charge: crossing a boundary does not mean traversing the public internet. AWS states that packets originating on its network with a destination on its network “stay on the AWS global network,” including across regions. The charge reflects the provider’s own backbone use, not a detour through the open internet — so arguments about the charge being unfair because “it never leaves their network” have the premise right and the conclusion wrong.

Copies and chatter are where the money goes

A one-off transfer rarely matters. What accumulates is anything that moves the same data across a boundary repeatedly, which is why the expensive patterns are the ones nobody experiences as a transfer at all.

Cross-zone or cross-region replication is the clearest case: the availability benefit is real and so is the monthly charge, which scales with write volume rather than with stored size — so a small dataset under heavy write load can cost more to replicate than a large, quiet one. Logs and telemetry shipped to a collector somewhere else behave the same way, continuously and invisibly, because the people generating them are thinking about observability rather than about bytes crossing a line.

The pattern that surprises teams most is a chatty service pair split across zones, because it is created by a decision taken for a good reason. Spreading two components across zones improves availability, and it also puts every call between them across a billed boundary. A protocol that makes many small round trips then pays the crossing on each one — and the resulting bill is proportional to the conversation, not to the data anybody would say they were moving. Each of those decisions is defensible. The failure is not making them; it is making them without knowing a recurring charge was part of the trade.

Reducing it, and what each reduction costs

The options below are genuine alternatives rather than a sequence, so they are worth comparing on what they give up. Only one of them is free.

Approach	Gives up
Reduce what crosses: compress, filter at the source, batch instead of per-record calls	Usually nothing but engineering time. Do this first
Co-locate components that talk constantly in one zone	Zone-level availability for that pair — sometimes the right trade, sometimes not
Cache or serve from the edge instead of from origin every time	Freshness, and a cache to operate and invalidate
Use private connectivity or a committed-transfer plan where volumes are large and steady	Money up front and less flexibility — an ExpressRoute Local SKU, for instance, folds transfer into the port charge rather than billing it separately

The ordering matters more than the list. Filtering and batching cost engineering time and nothing else, and teams frequently skip straight past them to negotiate a plan for traffic that did not need to exist. It is worth establishing that the traffic is necessary before paying to carry it more cheaply.

Make it visible before it is a problem

Transfer charges are hard to act on because the invoice shows a total while the cause is a topology decision made months earlier by someone else. Closing that gap takes two things, and neither is a tool.

The first is to write down, at design time, every boundary the data crosses in the normal path. That list is simultaneously the cost model and the latency model — the same crossings that are billed are the ones that add milliseconds — which is why it belongs in the design document rather than being inferred later from a bill.

The second is to attribute the charge to the team whose architecture creates it. Transfer cost is the classic case of a number nobody owns: the platform team sees it and cannot change it, the product team can change it and never sees it. Treated as part of total cost of ownership for a service rather than as a platform overhead, it becomes a design input like any other.

A related cost sits further out and deserves its own estimate, with one condition that changes the arithmetic: leaving a provider entirely is not priced like ordinary ongoing egress. Providers offer waivers or credits for a qualifying full exit, subject to a process — arranging it with support in advance, completing within a defined period, and closing the account — and the waiver typically excludes some transfer services and does not cover other usage charges.

So the honest sequence is to check whether the exit qualifies and what is excluded before multiplying volume by a published rate. And the opposite conclusion does not follow either: a transfer waiver removes one line from an exit cost, not the cost of rebuilding the foundation, running both environments in parallel, and retraining — which are usually the larger lines.

How transfer cost fits with network topology, private connectivity, and on-premises links is worked through in The Route Table Nobody Read.

References: Microsoft Learn, Azure ExpressRoute Overview (documentation updated 2026-08-27); AWS, How Amazon VPC works; AWS Global Network FAQs.