Workload placement by economics means deciding where each workload runs from its total cost on each candidate provider, not from a company wide default cloud. The comparison has four inputs: the compute and storage price on each of AWS, Azure, GCP, and OCI, the data transfer the workload generates given where its data sits, the commitment tier the workload can realistically reach on that provider, and the operational cost of running it there. Data gravity, the pull that keeps a workload near the data it reads, usually dominates the result, because large datasets are slow and expensive to move and reading them across a provider boundary incurs egress on every byte. The practical rule that falls out is to put each workload where its data already lives unless a compute saving elsewhere clearly beats the transfer cost of getting there.
Here is the framework, the inputs, and a worked comparison.
Why place by workload rather than by company policy?
A single company wide cloud is simple to operate but leaves money on the table, because providers do not price every workload the same. OCI prices egress and certain database workloads below the hyperscalers, GCP suits some analytics patterns, and AWS or Azure may win on a managed service a workload depends on. A blanket policy ignores all of that. The opposite error, splitting everything across clouds for diversity, is worse, because it manufactures cross cloud transfer and dilutes commitments, as weighed in when multicloud saves money and when it costs. Placement by economics threads between the two: decide per workload, on the numbers, and let the totals rather than a policy choose the cloud.
What inputs decide where a workload belongs?
Four costs determine the all in price, and a workload belongs where their sum is lowest, not where any single line is cheapest.
| Input | What to compare | Why it matters |
|---|---|---|
| Compute and storage | The instance, database, and storage price for the workload on each provider | The headline number, but rarely the deciding one on its own |
| Data transfer | Egress and cross zone traffic the architecture generates from where the data sits | Often the silent swing factor for stateful and chatty workloads |
| Commitment tier | The discount tier the workload helps the provider commitment reach | Concentration earns deeper discounts than spreading spend thin |
| Operations | Tooling, monitoring, on call, and skills to run it on that cloud | A second platform adds fixed overhead regardless of unit price |
The most common mistake is to compare only the first line, the sticker compute price, and move a workload to a cheaper instance on another cloud, only to pay it all back in egress and a thinner commitment tier. The transfer cost is detailed in multicloud networking costs explained, and why data resists moving is in data gravity and its cost consequences.
How does data gravity decide most cases?
Most enterprise workloads are stateful and read large datasets that already live somewhere. For those, the data is the anchor. Moving a multi terabyte dataset to a cheaper compute cloud costs egress once to move it and then egress forever if anything left behind still reads it, and the compute saving rarely covers that. Stateless workloads are the exception: a batch job, a rendering farm, or a training run that pulls little data and produces little can chase the cheapest capacity, including spot and preemptible, across providers, because it has almost no gravity to fight. So the placement question usually resolves to one of two patterns: pin stateful workloads to where their data lives, and let stateless workloads roam to the cheapest fit.
For any proposed move, calculate the annual egress the split creates and the commitment tier you lose, then subtract both from the compute saving. If what remains is not clearly positive, the workload belongs where it already runs.
What does a placement comparison look like?
The decision becomes concrete once the four inputs are totaled side by side rather than argued in the abstract.
A European SaaS company considered moving a data heavy analytics service to a second cloud whose compute looked cheaper. We totaled all four inputs. The compute line was indeed lower, but the service read a large dataset that lived on the original provider, so the move would have paid egress continuously and split the company commitment into two shallow tiers. The all in cost on the second cloud was higher once transfer and the lost tier were counted. We kept the analytics service where its data lived, rightsized it there, and instead moved a stateless batch pipeline, which had almost no data gravity, onto cheaper preemptible capacity elsewhere. The placement decisions together contributed to a reduction in line with our results. Figures are verified against billing data and anonymized.
The lesson is that the cheapest compute line lost to the silent transfer line, which is the usual outcome for stateful workloads and the reason placement has to be decided on totals.
Frequently asked questions
What is workload placement by economics?
What is data gravity in cloud placement?
Should you move a workload to a cheaper cloud?
Place your workloads on the numbers
We model the all in cost of your workloads on each cloud, weigh data gravity and transfer honestly, and recommend placement that lowers total spend, independent of any provider and taking zero provider commissions. Start with our playbook, then bring us your estate.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.