The multi-cloud tax, and how to stop paying it
Workload placement, egress economics and the FinOps discipline that keeps a second cloud from doubling your bill.
part 2 of 3 · Cloud calls you'll have to makethe ideaRun each workload next to its data, and price every crossing between clouds.
after reading, you can- Before you sign for a second cloud, list every data path that would cross over and price each one at twelve months of production volume.
- Explain data gravity, then write down where each workload lives, why, and what leaving would cost.
- Spot when a baseline gets split across two clouds, and why that quietly weakens your discounts on both.
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 behaves like one: it compounds quietly, it's levied on movement, and nobody remembers voting for it. Three disciplines keep it off your bill.
Egress is the tax collector, so map it before you sign anything
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.
Place each workload next to its data
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 live in people's heads. Each workload gets a stated home and a stated reason. It also gets a stated 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., meaning the engineering effort plus the egress bill to move its data out. Workloads that are cheap to leave are where your real negotiating power sits. The expensive ones are commitments and should be priced that way. "We could move it if we had to" is a claim. The exit-cost line is the evidence.
The cheapest cloud for a workload is usually the one already holding its data.
# 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 ✓ placement justified · ✓ egress mapped · ✓ owner named
FinOps belongs in the engineering loop
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 pays off or punishes you. Reserved instances, savings plans and committed-use discountsdefinitionYou commit to a steady level of usage for a set term, and the provider knocks the price down. Reserved instances and savings plans are close cousins. all assume a stable baseline on one provider. Split that baseline across two clouds without re-modeling coverage and you'll underpay for commitments on both while running more on-demand than either. Treat coverage like capacity planning. Forecast it per cloud and review it monthly, and let the placement policy decide where the baseline lives instead of the sales cycle. Do that and the second cloud stays what it was meant to be, a source of negotiating power.
What to take from this
- 01
Price every cross-cloud data path at twelve months of production volume before you commit to it.
- 02
Let data gravity set placement: one center of gravity, plus a short list of workloads that earn an exception, each with a written exit cost.
- 03
Put cost in the engineering loop. Each team sees its own unit economics and hears about anomalies within a day, and commitment coverage gets modeled per cloud.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1Your analytics job runs on cloud B. Its warehouse is on cloud A. Every query pays egress. What would you change first?
show the answer
B. Move the job to cloud A, next to its data Compute can move and petabytes can't. Put the job next to the data it reads and the cross-cloud path disappears, along with the egress it was paying on each request.
-
Q2Leadership says, "We could move this workload if we had to." Fine. What evidence does the post say should be sitting behind that sentence?
show the answer
A. A written exit cost: engineering effort plus egress to move the data The post calls that sentence a claim. The exit-cost line is the evidence. If the exit cost is low, you really can negotiate. If it's high, you've made a commitment, so price it like one.
-
Q3A company splits its steady baseline across two clouds and nobody re-models the commitments. What happens?
show the answer
C. Commitment coverage falls short on both and more runs on-demand All three, reserved instances, savings plans and committed-use discounts, assume a stable baseline on one provider. Split that baseline and, as the post warns, you underpay for commitments on both while running more on-demand.