The multi-cloud tax, and how to stop paying it

The multi-cloud pitch is always about bargaining power. Resilience and best-of-breed services come up too. What never comes up is the question that decides whether you get any of it. For each workload, what does it cost to run here, and what does it cost to leave? Answer that per workload, in numbers, and the second cloud is a tool. Skip it and it's a tax.

We call it a tax because it acts like one. It's charged every time data moves, and it grows quietly until nobody remembers agreeing to it. Usually the second cloud got approved for a good reason, like a service the main provider doesn't have. Then the bill comes in higher than anyone planned, and nobody can say which line grew.

The free allowance sounds generous until you put it next to a data warehouse that replicates nightly. A busy system can pass that in a day. After that every gigabyte is billed, and the meter keeps running for as long as the system runs.

EgressdefinitionData leaving a cloud provider's network. Getting data in is free. Getting it out is billed by the gigabyte. pricing is how cloud lock-in gets enforced. Data comes in free and goes out at roughly $0.08–0.12 per GB at list price, and inter-region or cross-cloud transit charges stack on top of that. Split a chatty system across two providers and you pay that toll on each request, each replication cycle and each backup, for as long as it runs. We keep seeing the same cause. Someone drew the architecture diagram by service preference, and nobody priced it.

Before adopting a second cloud, trace the data paths that would cross the boundary and price them at twelve months of production volume. Cross-cloud replication for a warehouse, image pulls from a registry on the other side, observability agents shipping telemetry home: each is a recurring line item that scales with success. Some crossings are worth it. Most were never examined.

The cheapest place to run a workload is almost always next to the data it reads. That's data gravitydefinitionThe pull a big dataset has on the apps that use it. In practice it's usually far cheaper to bring the compute to the data than the other way around., and it should drive placement, because compute moves easily and petabytes don't. A sound multi-cloud setup is lopsided on purpose. One primary cloud holds the center of gravity. A short, deliberate list of workloads earns a place elsewhere, say a managed service with no real equivalent, a sovereignty requirement, or a resilience tier with a real failover runbook.

Write the placement rule down as policy so it doesn't depend on someone's memory. Each workload gets a home and a reason for being there. It also gets an exit costdefinitionWhat it would actually take to move a workload off its current cloud: the engineering effort plus the egress bill for getting its data out., which is the engineering effort plus the egress bill to move its data out. Workloads that are cheap to leave are where the real negotiating power sits. The expensive ones are commitments and should be priced that way. When someone says "we could move it if we had to," that's a claim. The exit-cost line is the evidence, and you'll want it at the next renewal.

# every workload declares its home and its exit
workload: order-analytics
home: primary-cloud / eu-west // co-located with lakehouse
cross-cloud paths: 2 detected → 0 after co-location
exit-cost: priced · reviewed quarterly
✓ justified · ✓ egress mapped · ✓ owner named

A cost report nobody can act on is observability theater. FinOpsdefinitionTreating cloud spend as an engineering problem. Resources get tagged, costs land with the team that owns them, and someone acts on them while the numbers are still fresh. works when cost sits in the engineering loop the way latency does. Tag it at the resource, allocate it to the team that owns it, and express it as unit economicsdefinitionSpend divided by a unit of work, per tenant, per pipeline run or per thousand requests, so a team can see what drives it. such as cost per tenant, per pipeline run or per thousand requests. Alert on anomalies within a day instead of finding them at month-end. Multi-cloud makes this harder because each provider bills in its own schema. Without a normalization layer you can't even compare the numbers, let alone act on them.

Commitment management is where the discipline saves real money or wastes it. Reserved instances, savings plans or committed-use discountsdefinitionYou promise the provider a steady amount of usage for a set term, and it cuts the price. Reserved instances and savings plans work much the same way. Move the work elsewhere and you still pay for what you promised., they all assume a stable baseline on one provider. Split that baseline across two clouds without re-modeling coverage and you'll be under-committed on both while running more on-demand than either. Treat coverage like capacity planning. Forecast it per cloud and review it monthly. Use the placement policy to set where the baseline sits, instead of the sales cycle. Do that and the second cloud remains what it was meant to be, a source of negotiating power.

Exit fees have come down, partly under pressure from European rules. That helps the exit-cost line in your placement policy. It does much less for a system that runs on two clouds every day, because those crossings still get billed.

Read the exit offers carefully. AWS's waiver covers moving off AWS. Ongoing transfers fall under the normal allowance. So a nightly replication job between two clouds keeps paying. The EU parallel-use rule caps those fees at cost. It doesn't make them free.

Our cloud strategy work starts with that placement map. We list each workload, the data it reads and the paths that cross between clouds, and we price the exit before anything moves. Our cloud strategy page explains how an engagement runs, or you can start with an assessment.