Multi-cloud without the chaos: how to decide where a workload belongs
Latency, compliance, cost and operational load all pull in different directions. A simple framework for placing each workload deliberately rather than by habit.
Most multi-cloud estates are not designed — they accumulate. A team spins up a database on one provider, marketing launches a campaign site somewhere else, and a regional office adds a third because it was closest. Two years later nobody can explain the bill or the blast radius. Placing workloads deliberately takes an afternoon of thinking and saves years of firefighting.
Start with the four forces
Every placement decision is a trade between four forces. Write them down for each workload before you look at a provider console.
- Latency: where do the people and systems that call this workload actually sit?
- Data residency: which regulator, contract or customer expectation constrains where the data may rest?
- Cost shape: is this steady-state load, spiky load, or mostly idle with occasional bursts?
- Operational load: who is on call for it, and do they already know the platform?
Put the customer-facing tier closest to the customer
Anything a human waits on — the storefront, the booking flow, the login page — belongs near that human. For a business serving Lagos, Accra, Kigali or Cape Town, a regional edge or a regional cloud region will beat a technically superior setup half a world away, because round trips dominate perceived speed.
For everything else — batch jobs, reporting, backups, internal tooling — latency barely matters. That is where you optimise for price and for the platform your team already knows.
Keep the control plane in one place
Multi-cloud becomes chaotic when observability, identity and deployment are also multiplied. Run workloads wherever they fit, but keep one monitoring stack, one identity source, one deployment pipeline and one runbook library. Engineers should not have to remember which console holds the logs for which incident.
Decide the exit before you enter
Before a workload lands, write down how it would leave: what the data export looks like, which managed services it depends on, and roughly how long a move would take. If that answer is uncomfortable, either accept the lock-in consciously or pick a more portable building block. The point is not to avoid managed services — they are usually worth it — but to know the price of changing your mind.
Placement is a business decision wearing a technical costume. Score each workload against latency, residency, cost shape and operational load, keep one control plane over the top, and multi-cloud stops being chaos and starts being leverage.
Talk to our team
