Right placing a workload is a total cost decision, not a price comparison. The cloud with the cheapest published compute rate is rarely the cheapest home once you add data transfer, the egress to feed the workload, the commitment discount you forgo by splitting volume across providers, and the cost of running a second control plane. AWS, Azure, GCP, and OCI each have genuine economic strengths for particular workload shapes, so the right estate is usually one primary cloud carrying the bulk of spend, with a small number of workloads placed elsewhere on purpose because the numbers are decisive. The discipline is to score each workload on the same model and move only when the verified net saving is larger than the one time and ongoing cost of the move.
Below is the framework we use to place workloads, the per cloud strengths that change the answer, and a worked example showing why the cheapest compute line is not the cheapest decision.
What does right placing actually mean?
Placement is the question of which provider a given workload should run on, decided one workload at a time rather than as a blanket strategy. A blanket strategy picks a single cloud for everything, or spreads everything across several to avoid lock in. Right placing rejects both defaults and asks a narrower question for each workload: where does this specific thing run most cheaply once every cost is counted, and is the difference large enough to justify the move and the ongoing complexity.
That framing matters because most estates carry a long tail of workloads where placement is irrelevant, the saving is trivial, and the right answer is to leave them where they are. Effort should go to the handful of workloads that are large, data heavy, or commitment intensive, where placement moves a real number.
Which factors decide the right home?
Five factors carry almost all of the weight. Compute fit is whether the provider has an instance family, processor, or managed service that matches the workload closely, because a good fit removes overprovisioning before any discount applies. Data gravity is where the data already lives, since the cost and latency of moving it often dwarfs the compute difference. Egress is the charge to move data out and between regions or providers, a quiet budget eater that turns a cheap looking placement expensive. Commitment leverage is the discount you keep or lose by concentrating volume, because splitting spend across providers can drop you below the threshold for the deepest tiers. Operational load is the human cost of a second platform: more tooling, more on call surface, more places for waste to hide.
Weight these to your estate rather than treating them as equal. A data heavy analytics workload is dominated by data gravity and egress. A stateless compute fleet is dominated by compute fit and commitment leverage. A regulated workload may be dominated by region and residency constraints that override price entirely.
How do the four clouds differ on placement?
The providers are not interchangeable, and the differences are what make placement worth doing. On AWS, the breadth of instance families plus Graviton and gp3 migrations make it a strong default for general compute, while data transfer and NAT gateway charges are the costs to watch when a workload talks across zones or out to the internet. On Azure, Hybrid Benefit and Dev Test pricing change the math sharply for Windows and SQL Server estates, and an existing MACC commitment can make Azure the cheapest home for net new workloads simply because the spend draws down a commitment you already owe. On GCP, sustained use discounts apply automatically and spend based Committed Use Discounts are flexible, while BigQuery economics and premium versus standard network tiers are their own discipline that can dominate a data workload. On OCI, egress is materially cheaper than the hyperscalers, flexible compute shapes allow precise sizing, Support Rewards offset Oracle support fees, and license included versus bring your own license changes database economics, which together make OCI a strong home for egress heavy and Oracle database workloads.
A European SaaS company assumed an analytics workload should move to the provider with the lowest published compute rate, which looked roughly 18 percent cheaper on compute alone. Scoring the full picture changed the answer. The workload read from a data store of several hundred terabytes that already lived on the incumbent cloud, so moving it meant continuous cross provider egress plus a one time transfer bill, and splitting the volume dropped the estate below the commitment tier that was discounting the rest of the compute. Counting egress, the lost commitment discount, and a second monitoring stack, the cheaper looking cloud was about 11 percent more expensive in total. The workload stayed put, and the saving came instead from rightsizing it and tightening commitment coverage. Two egress heavy batch jobs with no data gravity did move to a cheaper home, where the net saving was real. Figures are verified against billing data and anonymised.
How do you score a workload without guessing?
Build one model and apply it to every candidate. Start from billing data to establish the current fully loaded cost, including the share of egress and networking the workload drives. Price the same workload on each candidate provider using current published rates, sized to a realistic shape rather than a like for like instance, and label any rate you cannot verify as indicative. Then add the costs a price comparison hides: one time migration effort, ongoing egress if data stays behind, the commitment discount lost on the volume you remove from the primary cloud, and the operational overhead of the new platform. Compare the net annual position, not the headline rate, and set a threshold so you only move when the saving clearly beats the cost of moving and the added complexity.
When is staying put the right answer?
Often. A workload with heavy data gravity, a deep existing commitment on its current cloud, or a tight integration with managed services on that provider usually stays, because the move would strand a discount or trigger continuous egress. In those cases the saving lives inside the current cloud through rightsizing, waste removal, storage tiering, and better commitment coverage, not in a migration. Placement analysis that ends in leave it where it is and optimise in place is a success, because it spends nothing to confirm the cheaper looking option was a trap.
Frequently asked questions
Does right placing workloads mean going multicloud?
What costs do teams forget when comparing clouds?
How often should placement be revisited?
Place workloads on the economics, not the sticker rate
We score each workload across AWS, Azure, GCP, and OCI on the full economics and move only what clears the cost of moving, with zero provider commissions on either side of the table. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk. Book a strategy call and we will pressure test your placement assumptions against your billing data.
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.