Cloud Placement Decision Diagram
How to decide where a workload runs — the profile that drives the answer, the three legitimate outcomes, and the cost and portability controls that have to exist before the first workload lands.
SVG. No sign-up, no email.
Cloud versus owned is not a strategy question, and answering it once for the whole estate is how organisations end up paying rental rates for steady, predictable load. It is a per workload decision, driven by a profile that takes an afternoon to establish.
The profile drives the answer#
Five properties decide it, and four of the five are measurements rather than opinions.
Load pattern is the dominant one. Variable and unpredictable load is what cloud pricing is designed for — you pay for peaks you actually have, instead of buying for a peak you might. Steady, always-on load is the opposite case: you are renting at an hourly rate something you could own, and paying a margin for elasticity you never use.
Utilisation must be measured. Nearly everyone overestimates their own, and the guessed figure is what makes the business case look obvious in whichever direction it was already leaning.
Egress is the cost that surprises people, because it does not appear in any comparison built from instance prices. Data transfer out is charged per GB by every major provider, and a workload that serves a lot of data out is the clearest case for owning.
Constraints — data residency and availability requirements — can settle the question before the economics are considered at all.
Lifetime is the honest one. Something that might not exist in six months should not be bought hardware for. That is a genuine and underrated argument for renting.
Three legitimate outcomes#
Drawn as a set, not a sequence, because they are alternatives — and because hybrid is a real answer rather than an indecisive one. What makes hybrid legitimate is that the split follows the profile: variable front end in cloud, steady heavy processing owned. What makes it expensive is drifting into it by accident, one workload at a time, with no rule.
Two mistakes account for most of the disappointment with cloud programmes, and neither is about the choice itself. Lift and shift unchanged captures nearly none of the benefit while adding the rental margin. Multi-cloud adopted to avoid lock-in, absent a specific reason, buys the complexity of both providers and the volume discounts of neither.
Controls before the first workload#
The bottom lane is drawn as prerequisites, not follow-ups, because every one of them is harder to introduce later.
Budget alerts cost nothing and are the difference between a surprise and a decision.
Mandatory tags — owner, environment, cost centre — are what make the bill readable. Untagged resources are never deleted, because nobody can establish whose they are, and they accumulate for years.
Non-production off outside working hours, automated, is typically the single largest saving available and requires no architecture.
The exit test is the portability question: if this proprietary service vanished, how long to replace it? Weeks is an acceptable answer. Quarters means it is load-bearing, and that should be a decision someone signed rather than a default nobody noticed.
Using this diagram#
Take the three workloads with the largest bills and run each through the top lane individually. The point is not to move anything — it is that the numbers usually contradict whichever blanket policy is currently in place, and roughly a fifth of what has been moved to public cloud industry-wide has since been moved back.