Workload Placement Across Clouds: Balancing Cost, Performance, and Portability

Three forces make placement consequential rather than routine.

The first is cost, which is real and not to be dismissed. Different providers price the same nominal capacity differently, and the same workload can cost noticeably more or less depending on where it runs.

The second is performance, and specifically latency. A workload that serves users or other systems with tight response requirements cannot be placed purely on price. Recent work on multi-cloud load balancing models task placement as a problem of matching a task to a cloud across several interdependent resource characteristics at once, including compute, memory, bandwidth, and latency, under quality-of-service constraints [S49]. Latency is not a tie-breaker applied after cost. It is a first-order input that can rule a cheaper provider out entirely.

The third force is data gravity. This is an Atomity framing, defined here so it is not mistaken for a sourced metric: data attracts the compute and services that depend on it. When a dataset is large or heavily accessed, placing the workloads that read and write it somewhere else imposes a latency and transfer penalty, and moving the data later carries its own cost. Data gravity is why "where the data lives" belongs in the placement decision and not in a separate conversation. The criteria registers in the selection literature already encode this: latency requirements and cost per unit of storage sit alongside data-location and data-ownership criteria in the same evaluation table [S15].

None of these three forces is sufficient on its own. That is the whole point.

The cleaner way to think about placement is as a selection problem over a set of heterogeneous providers, where each candidate is scored against several criteria rather than ranked on one.

The systematic review of cloud resource orchestration frameworks makes this concrete. Cross-cloud deployment, where the components of a single application can be distributed across more than one provider, allows each component to be placed on the provider that best fits it, optimising cost or quality of service on a per-component basis [S51]. Orchestration frameworks describe this as binding a requirement to a concrete offer. The interesting variant is optimised binding, in which the framework applies attributes of the provider, such as price and location, as explicit selection criteria when it chooses where to place the resource [S51]. Price and location are inputs to the same function, not competing conversations.

So the unit of placement is often the component, not the application, and the decision is a scored selection rather than a binary cheaper-or-not comparison.

If placement is a scored selection, the next question is: scored on what?

Two sources answer this directly. The design-phase view from service composition holds that an optimal multi-cloud design must satisfy several requirement types at once, naming quality, deployment, security, placement, and cost as co-equal requirement categories [S13]. Cost is one of five, not the frame around the other four.

The provider-selection view is more explicit still. Choosing where to store and run data "extends beyond simple cost-benefit analysis," and is better treated as a multi-criteria decision whose criteria are combined through weighted scoring [S15]. The criteria register in that work is a useful checklist for any architect building a placement model. It includes latency requirements, availability, data consistency, encryption strength, cost efficiency, regulatory compliance, data ownership, data portability, interoperability, and vendor lock-in mitigation, each with its own measurement metric [S15].

A workable selection model follows from this directly:

1. List the candidate providers, regions, and service levels for the workload.
2. List the criteria that actually apply to this workload, drawn from cost, latency and performance, data location and ownership, portability, interoperability, and lock-in risk.
3. Assign each criterion a weight that reflects this workload's reality, not a generic template.
4. Score each candidate against each criterion and combine the scores.
5. Record the weights and scores, because the weights are the decision.

The weighting step is where the honesty lives. A cost-only placement is just this model with every non-cost weight set to zero. Writing the weights down makes that choice visible instead of implicit.

A multi-criteria placement model is only useful if the resulting placement can actually be enacted and, later, revised. That is the job of the orchestration and abstraction layer.

Providers are genuinely different from one another: different APIs, different security models, different networking, different pricing structures. One line of work argues that this heterogeneity can be treated as a strategic asset rather than a problem, on the condition that it is made workable by abstraction through containerisation and infrastructure-as-code, which present a single interface for provisioning and managing resources across providers [S59]. That position comes from a provider-affiliated author and is offered here as professional interpretation rather than neutral fact, but it aligns with the orchestration literature.

Containerisation and container orchestration are repeatedly identified as a primary mechanism for moving workloads across clouds [S52][S51]. The orchestration framework review treats containers and platform-independent standards as the techniques that improve how applications are encapsulated and abstracted away from any single provider's resources [S51]. The abstraction layer is what turns a placement decision from a permanent commitment into a revisable one.

That word, revisable, is the bridge to the criteria that cost-only placement tends to ignore.

Portability is the property that lets a workload run on a different platform with little or no modification. Lock-in is its absence. Both belong in the placement decision at decision time, not as an afterthought when a move becomes necessary.

The evidence that they belong is migration cost. The trans-cloud migration literature is candid here. Moving a deployed component from one provider to another is not free; the cost is real and is usually measured as downtime, operational cost, or person-hours of effort [S01]. Open standards such as TOSCA and CAMP, together with abstraction and automation, reduce that cost and restrict lock-in to the provider level rather than the code level, but they do not remove it [S01][S51]. Portability, in other words, is partial and standards-dependent rather than absolute [S51].

Two qualifications matter. First, there is no single universal figure for migration cost. The same research that measures it is explicit that migration time depends on the application's topology, the components affected, and their source and target locations [S01]. Anyone quoting a fixed "cost to switch" number is overstating what is known. Second, low portability is not always wrong. A workload that will never move and faces no data-location requirement can reasonably accept lock-in in exchange for a deeply integrated, cheaper service. The point is to price that trade-off at decision time, not to discover it later.

This is exactly why portability and lock-in risk are criteria, not warnings. Migration cost is the measurable evidence that converts a vague worry about lock-in into a number you can weight against the cost saving that lock-in buys.

Put the pieces together and the failure mode of cost-only placement becomes clear.

When a workload is placed on price alone, the non-cost criteria do not disappear. They are deferred. The latency penalty of placing compute away from its data is still there. The data-location requirement is still there. The lock-in that came with the cheapest deeply integrated service is still there, and so is the migration cost of undoing it. This is what we mean by governance debt: criteria that were assigned a weight of zero at decision time, which later resurface as remediation cost when a regulator, an outage, a price change, or a portability requirement forces the issue.

It is worth being precise that even mature cost practice already concedes the point. Serious multi-cloud cost work goes beyond raw price comparison toward performance-normalised pricing, because a cheaper instance that performs worse is not actually cheaper [S59]. Once you normalise cost by performance, you have already admitted a second criterion. The argument of this article is simply to keep going: normalise by data location, by portability, and by lock-in risk as well, and write down the weights.

Once placement is framed as a weighted, multi-criteria selection that has to be made, enforced, and revisited as conditions change, the need for a place to do that consistently becomes visible.

This is where Atomity fits, and the role is deliberately narrow. Atomity provides workload decision support that evaluates trade-offs across criteria, supporting the evaluation of sovereignty, compliance, operational, and cost criteria together rather than cost in isolation. It applies defined policy, monitors placements against that policy, and records evidence of how a decision was reached so the reasoning can be reviewed later. The aim is not to remove the architect's judgement but to make the weights explicit and the decisions reviewable, which is precisely what cost-only placement skips.

This article frames a way of deciding, not a finished formula. The criteria registers cited here are drawn from specific research settings, including distributed storage and load balancing, and the right criteria and weights for a given workload will differ [S15][S49]. Migration cost is real but not universal, and the figures will vary with topology and providers [S01]. The heterogeneity-as-asset framing comes from a provider-affiliated source and is presented as interpretation [S59]. Finally, where this article touches data location, it does so as a placement criterion. Data location is one input among several. It is not the same thing as sovereignty, and it should not be treated as a complete answer to a sovereignty or compliance requirement.

Workload placement is a decision with at least five inputs: cost, performance and latency, data gravity, portability, and lock-in risk. The selection literature treats it as a multi-criteria, weighted decision over heterogeneous providers, enacted through an abstraction layer that keeps the choice revisable [S51][S13][S15][S49]. Cost-only placement is that same model with the non-cost weights silently set to zero, and the bill for those zeros arrives later as governance debt and migration cost [S01].

List the non-cost criteria your current placement decisions ignore. Write down, for one real workload, the weight you implicitly assign to latency, data location, portability, and lock-in risk today. If any of those weights is zero by accident rather than by choice, you have found your starting point.