Cross-Region Data Transfer Between Chatty Azure Workloads

This happens when compute is moved to a cheaper region while the data stays behind, when a shared service is deployed centrally for convenience, when a disaster-recovery replica quietly starts serving reads, or when spokes in one region are routed through a hub firewall in another. Data transfer between services in the same region carries no bandwidth charge (VNet peering is billed per GB even within a region), but every GB that crosses a region boundary is billed.

Because the cost is per GB and accrues on every request, a placement decision made once can produce a steady charge that appears only as a Bandwidth or Virtual Network peering line in the bill, far from the resources that cause it. The Well-Architected cost guidance tells teams to minimize data transfer by placing data close to where it is used, caching and using a CDN, and the Azure Firewall guidance specifically warns against unexpected cross-region traffic in hub-and-spoke topologies.

Azure bills data movement by where it starts and ends.

Same-region transfer

Data transfer between Azure services in the same region, and inbound data transfer, carries no bandwidth charge; VNet peering within a region is still billed per GB

Inter-region transfer

Billed per GB leaving the source region, with rates that depend on the source and destination continents

Global VNet peering

Billed per GB at both ends, at the outbound rate of the source zone and the inbound rate of the destination zone

Internet egress

Billed separately per GB after the first 100 GB per month, in tiers that vary by source region

• In Cost analysis, filter to the Bandwidth and Virtual Network services and group by meter and resource to separate inter-region and global peering charges from internet egress, then trend them over several months
• Enable VNet flow logs with traffic analytics and rank flows by volume between source and destination regions to find the top cross-region conversations
• Map dependencies for the heaviest flows (application to database, cache, storage account, firewall, logging workspace) and check whether each pair sits in the same region
• Review hub-and-spoke routing: spokes whose user-defined routes send traffic to a firewall or network virtual appliance in another region pay transfer on every hop
• Check for applications reading from a geo-replica or storage account in another region during normal operation rather than only on failover

• Co-locate tightly coupled components in the same region, moving compute to the data or the data to the compute depending on which is cheaper to move
• Deploy a regional instance of shared services (firewall in each regional hub, regional cache or read replica) instead of calling one central instance across regions
• Cache or batch cross-region reads where the data must stay in another region, and compress payloads to cut per-GB volume
• Serve static and cacheable content to distant users through Azure Front Door or a CDN rather than from a single origin region
• Weigh savings against resilience: some cross-region replication is deliberate for disaster recovery, so target steady-state application traffic rather than replication that the recovery design requires

• Bandwidth pricingazure.microsoft.com
• Virtual Network pricingazure.microsoft.com
• Architecture strategies for optimizing data costslearn.microsoft.com
• Architecture Best Practices for Azure Firewalllearn.microsoft.com