The multicloud tax exists because of how cloud providers price data movement: it is cheap or free to bring data in, but you pay to send it out, and a cross-cloud hop is an egress event on the sending side every single time. Put your storage on one cloud and your processing on another and every job pays to pull its data across; place a database on one provider and the analytics that read it on another and every query that crosses the boundary is billed. Because the charge is per gigabyte and recurs with every transfer rather than being a one-time move, a chatty cross-cloud architecture can run up a transfer bill that rivals the compute it was meant to optimize. The tax is not a reason to avoid multicloud, which has real benefits, but it is a reason to design deliberately so that data crosses cloud boundaries as little as possible.
This article is part of our complete guide to cloud storage and data cost optimization, the cluster pillar it links up to. It extends data egress charges explained from the single-cloud case to the boundary between providers.
Every byte that crosses from one cloud to another is billed as egress on the sending side, every time. Multicloud pays best when data and the compute that uses it live on the same cloud.
Where the tax lands
The cross-cloud tax shows up wherever a data dependency spans providers. The classic case is split storage and compute: a data lake on one cloud feeding processing on another means every pipeline run pays egress to pull its input across. A second case is cross-cloud replication and backup, where keeping a copy on a second provider for resilience means a continuous stream of billed transfer to keep it current. A third is cross-cloud queries and APIs, where a service on one cloud repeatedly calls a database or API on another, and the cumulative chatter, each call small, adds up to a large transfer line. And a fourth is data gravity working against you: once a large dataset lives on one cloud, everything that uses it is pulled toward that cloud or pays to reach across, the dynamic explored in the hidden cost of data gravity. In all four, the fix is the same in principle: keep data and the things that use it on the same side of the boundary.
Co-locate data with the compute that uses it
The most effective response to the multicloud tax is placement: put each dataset on the same cloud as the workloads that read it most, so the heavy traffic stays internal and only light, occasional traffic crosses. That often means choosing a primary cloud per data domain rather than spreading a single domain's storage and compute across providers, and accepting that a workload should live next to its data even if another cloud has a marginally cheaper compute rate, because the egress saved usually dwarfs the rate difference. Where a genuine reason forces a cross-cloud dependency, minimize what crosses: filter, aggregate and compress before the boundary so you send results rather than raw data, the same upstream discipline as reducing inter-region data transfer costs, since the boundary economics are similar.
| Pattern that taxes you | Why it costs | The fix |
|---|---|---|
| Storage on cloud A, compute on cloud B | Every run pulls data across | Co-locate compute with its data |
| Cross-cloud replication | Continuous billed sync | Right-size what truly needs a second-cloud copy |
| Cross-cloud queries and APIs | Chatty per-call egress adds up | Cache results, batch calls, move the caller |
| Raw data crossing the boundary | Full volume billed each transfer | Filter, aggregate, compress first |
Is multicloud taxing every byte twice?
Our cloud cost audit maps every cross-cloud data dependency, redesigns placement so heavy traffic stays internal, and proves the saving against a clean baseline on AWS, Azure, GCP and OCI. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Cut the chatter and cache across the boundary
For the cross-cloud dependencies you cannot remove, the levers are the ones that reduce how much and how often data crosses. Cache frequently-read cross-cloud data on the consuming side so repeat reads are served locally instead of re-fetched across the boundary, the same cache-hit logic as using a CDN and caching to cut egress bills. Batch many small cross-cloud calls into fewer larger transfers to reduce per-request overhead. Use direct interconnect or private network links between providers where the volume justifies it, since dedicated cross-cloud connectivity is often billed at a lower per-gigabyte rate than public egress. And verify the current egress and interconnect pricing for each provider in its documentation as of May 2026, since cross-cloud rates and the available private-link options change and they decide which mitigation pays.
The Cloud Storage and Egress Cost Playbook includes the cross-cloud dependency map and the placement worksheet we use to design the multicloud tax out before it compounds.
Model the tax before you commit to multicloud
The cheapest way to deal with the multicloud tax is to count it before you build, because the most expensive cross-cloud architectures are the ones adopted for a reason that the transfer bill then quietly outweighs. When a multicloud design is on the table, estimate the steady-state volume that will cross the boundary, multiply it by the egress rate, and compare that recurring cost against the benefit the second cloud is supposed to deliver, whether that is a cheaper compute rate, a specific managed service, or resilience. Often the comparison reverses the decision: a service that is marginally cheaper on the second cloud stops being cheaper once the egress to feed it is counted, and the resilience of a cross-cloud replica has to be weighed against its continuous sync cost. Where the benefit is real, the model also tells you which data to keep on each side to minimize what crosses, which is the same placement thinking the architecture rests on. Counting the tax up front turns multicloud from an accidental cost into a deliberate one, and deliberate costs are the ones you can defend or design away.
The short version
The multicloud tax is the egress you pay every time data crosses from one cloud to another, charged per gigabyte on every transfer rather than once. It lands wherever a data dependency spans providers: split storage and compute, cross-cloud replication, chatty cross-cloud queries, and data gravity pulling against you. Design it out by co-locating each dataset with the compute that uses it most, sending results rather than raw data across the boundary, caching and batching what must cross, and using private interconnect where volume justifies it. Verify current cross-cloud pricing before committing. Multicloud pays best when the heavy traffic stays inside each cloud. When you want every cross-cloud dependency mapped and the transfer proven down, that is part of what our rightsizing and waste elimination service delivers.