Managed cloud means a partner runs your cloud infrastructure: the provisioning, scaling, security, cost and the choices about where each workload lives. In 2026 the European question is no longer whether to use the cloud but which parts can sit on a US hyperscaler, and a second question has grown alongside it — why the bill keeps climbing. Argus Root runs a hybrid-first setup, EU-native infrastructure for what the rules touch and hyperscaler where it genuinely earns its place, with the FinOps discipline that keeps the spend honest.
In short
- Wasted cloud spend rose to about 29% in 2026 — reversing five years of decline as AI and new services add complexity — and 84% of organisations say they struggle to manage the bill.
- Most of that waste is reachable: idle compute and over-provisioned instances are roughly 60% of it, the highest-return targets for any cleanup.
- The fix is operational, not magic: structured FinOps cuts 25–30% of monthly spend, and the root cause is an accountability gap — only 44% show teams their own costs.
- Sovereignty is now mainstream: over 70% of large organisations will evaluate or adopt sovereign cloud for regulated data, and about 21% of workloads have already been selectively repatriated.
- The market answer is showing up in the numbers — 60% are turning to managed providers and 59% are expanding FinOps teams to regain control.
Managed cloud, hybrid-first and EU-native at the core.
Most teams do not need to leave the hyperscalers entirely. They need the regulated workloads on EU-native infrastructure and the rest managed sensibly. We place each workload where it belongs, run the EU core ourselves, and keep one hand on the cost.
Not every workload needs the same home.
Gartner's framing for 2026 is hybrid-first: new and sensitive workloads go to EU-native infrastructure, while some hyperscaler integrations stay where no equivalent exists yet. European sovereign cloud spending is the fastest-growing slice of the market, near $80 billion globally, but moving everything at once is neither cheap nor wise. The work is placing each workload by sensitivity.
| Tier | Examples | Where it goes |
|---|---|---|
| A · Highest sensitivity | Personal data, DORA-scoped financial data, health records | EU-native only |
| B · Standard business | SaaS compute, internal tooling, B2B data | EU-native preferred, hybrid where needed |
| C · Low sensitivity | Public CDN, ML training, CI/CD | Hyperscaler acceptable |
The shape of cloud in 2026 settles this argument. Around 92% of organisations now run more than one cloud and roughly three-quarters operate a hybrid mix, with Gartner expecting hybrid to reach nine in ten through 2027, because no single venue is right for everything. The all-in-public-cloud era and the all-on-premise reaction are both behind us; the live question is placement, which workload belongs where, judged by sensitivity, cost, latency and the rules that reach it.
The drift is back toward balance. About a fifth of organisations have moved at least some workloads off public cloud, and well over half of IT leaders now feel pressure to keep infrastructure within a single country, driven by sovereignty rules and the discovery that the cloud bill grew faster than the value. This is a correction rather than a retreat from cloud, which keeps growing: putting the regulated and the steady-state where they belong, and reserving the hyperscaler for the elastic and the genuinely differentiated. We run the placement decision as the core of the service rather than defaulting everything to one provider and hoping.
A region label is not sovereignty.
The hyperscalers now sell sovereign variants: AWS European Sovereign Cloud, the Azure EU Data Boundary, Oracle's EU offering. They give you EU residency, but the US parent keeps a residual CLOUD Act exposure, usually at a 10 to 30 percent premium for what stays an incomplete answer. Servers in Frankfurt under non-EU ownership meet residency on paper and stay reachable in practice.
Real sovereignty has three layers: where data lives, who operates it, and whether your architecture can move. We run the EU-native core ourselves, and we build on portable, cloud-agnostic patterns with a documented exit strategy, the same portability DORA expects of critical ICT contracts. You keep the option to leave, which is what keeps a provider honest. See compliance & sovereignty for the regulatory side.
There is a second reason not to put everything in one place. Concentration on a single hyperscaler is its own risk, operational as much as legal: a major provider outage takes your whole estate down at once, and analysts expect more than one multi-day hyperscaler outage during 2026. Spreading the critical workloads across an EU-native core and, where it fits, a public cloud, removes the single point of failure an all-in-one architecture quietly builds in. Sovereignty and resilience point the same way: do not hand one foreign company the power to read your data or to take you offline.
What do we run for you?
Placement, migration and the unglamorous discipline of keeping it affordable.
Workload assessment
A classification of what you run by sensitivity and dependency, so each system lands on the right tier instead of all of it defaulting to one provider.
Migration
Moves planned and tested before cutover, from hyperscaler repatriation to lift-and-shift onto EU-native infrastructure, with downtime scheduled rather than discovered.
EU-native core
The sensitive workloads on infrastructure we operate inside the EU, with no foreign parent that an extraterritorial warrant could reach.
Cloud-agnostic architecture
Portable patterns and a documented exit strategy, so a provider change is a project you can run rather than a trap you are stuck in.
FinOps & cost control
Tagging, rightsizing and spend visibility, because the fastest way to lose the savings is to lift waste straight into a new bill.
Security & resilience
Hardening, monitoring and backup built into the platform, shared with our SOC rather than bolted on by a separate team.
We run the core ourselves.
The EU-native part of your estate sits on infrastructure we operate ourselves, on our own AlmaLinux fleet and IP space, rather than a tenancy we resell with a portal on top. Where a hyperscaler is the right call for a Tier C workload, we manage it with the same discipline, but the sovereign core is ours to answer for. That split is the point: scale where scale helps, control where control matters.
# visibility first: no tag, no resource (closes the 44% gap) tagging: required: [team, env, cost_center, data_class] enforce: deny_create_if_untagged # attack the ~60% of waste: idle + over-provisioned rightsizing: idle_after: 7d # stop/flag idle compute cpu_target: 60% # downsize over-provisioned showback: cadence: monthly to: each_team # cost lands with the owner # placement = the sovereignty control, by data class placement: regulated: eu_native general: hyperscaler
What does managed cloud cover?
Managed cloud is the operation of your cloud infrastructure rather than the rental of a slice of it. It covers the provisioning and the scaling, the security and the patching, the backups and the cost, and the decisions about where each workload should live, which is the part most providers leave to you. What you are buying is the platform team you would otherwise have to hire, build and retain, applied to infrastructure that does not announce when it needs attention until it is already a problem.
The distinction from a raw cloud account is the same as managed versus unmanaged hosting, one level up. A hyperscaler hands you an enormous toolbox and the bill; making it secure, cost-controlled, resilient and compliant is work that does not happen on its own. We do that work as the service, so the cloud delivers its elasticity without quietly requiring a specialist team to keep it from sprawling, overspending or drifting out of compliance. The elasticity is the point of cloud; the operation is what makes it pay off rather than sprawl.
Lock-in is the real cloud bill.
The price you see is not the price that traps you. Every proprietary service you adopt, a managed database with no equivalent elsewhere, a serverless platform with its own model, an identity system woven through everything, raises the cost of ever leaving, and the providers know it. Spread across several clouds, the problem multiplies. The dependence is built quietly, one convenient managed service at a time, until the switching cost is high enough that the provider can raise prices and you have no realistic answer.
We architect against that from the start, because the deepest cloud cost is the one you cannot walk away from. Favouring portable patterns over proprietary ones, keeping the data in formats that move, and documenting how each workload would be lifted out, we treat your ability to leave as a design requirement rather than an afterthought. It rarely means refusing every managed service; it means knowing the price of each in lock-in and choosing it deliberately, so dependence is a decision you made rather than a trap you fell into.
An exit you can really run, which DORA now expects.
A cloud exit strategy is a documented, tested plan for moving your workloads off a provider: how the data comes out, what the alternative is, and the steps to switch without the business stopping. For financial entities under DORA this has become a compliance requirement in its own right, a tested, viable alternative to a critical cloud provider that you must have ready even if you never use it. NIS2 adds the supply-chain and concentration-risk angle, expecting demonstrable control over the providers your operations depend on.
Beyond the regulation, an exit you could genuinely execute is what keeps the commercial relationship honest. A provider that knows you cannot leave has no reason to keep its pricing or its service keen; one that knows you can, behaves differently. We build and document the exit as part of running the platform rather than as a box ticked once for an auditor, so the plan is current and credible rather than a file nobody has opened since signing. The option to leave is worth most precisely when you are not using it.
Multicloud without losing the plot.
Most organisations are multicloud whether they planned it or not, and the cost is complexity. Spreading workloads across providers and an EU-native core multiplies the places where visibility, security and spend can slip, which is why the dominant worry in 2026 is no longer whether to be in the cloud but how to manage the sprawl across several of them without losing control of any. A multicloud estate with no consistent management layer is several silos wearing one name.
We run it as one estate rather than several. A consistent layer for security policy, cost visibility and operational monitoring across the providers means a workload on the EU-native core and one on a public cloud are governed by the same rules and visible in the same picture, rather than each demanding its own tooling and its own blind spots. The point of multicloud is to place each workload where it fits without the management overhead defeating the benefit, and that takes a deliberate layer over the top rather than a tab open for every provider.
Portable by design, not by promise.
Portability is an architecture rather than a hope you hold about a future migration. The tooling to build it is now mature and open: Kubernetes as a standard for workloads that run the same anywhere, Terraform or OpenTofu to define infrastructure as code that can be pointed at a different target, open storage layers in place of a provider's proprietary one. Built this way, moving a workload is a project you can scope rather than a rebuild you dread, which is the difference between an exit strategy that exists and one that is only claimed.
This is also what makes repatriation a real option rather than a slogan. The same patterns that let a workload move between clouds let it move to an EU-native core or to your own infrastructure, carrying the cloud operating model with it rather than starting over. We favour these portable foundations precisely because they keep the choices open: where a workload runs becomes a decision you can revisit as cost, sovereignty and performance change, instead of a one-way door you walked through at the start and cannot reopen.
Concentration risk, and designing for the outage.
An all-in-one cloud estate has a single point of failure the size of a hyperscaler. When that provider has a bad day, and analysts expect more than one multi-day hyperscaler outage in 2026, everything you run on it goes down together, regardless of how well you built on top. Concentration is comfortable until the day it is not, and the day it is not tends to be expensive and entirely outside your control.
We design so a single provider's failure is a degraded mode rather than a full stop. The critical workloads sit where their loss would hurt most carefully, with the EU-native core under our own operation and recovery that does not depend on the same provider that just failed. The security and backup of the platform are shared with our managed security and recovery practice rather than bolted on by a separate team, so resilience is a property of how the estate is built rather than a clause in a contract. The aim is that no one outage, anywhere, takes the whole business with it.
How do you stop paying for what you forgot?
Cloud's pay-as-you-go model makes it easy to switch capacity on and hard to track what is really used, which is why estimated cloud waste rose to around 29% in 2026, reversing five years of improvement. The waste is structural rather than careless: an instance left running after a test, a volume nobody deleted, capacity sized for a peak that passed, a commitment discount fewer than half of organisations bother to use. It accumulates quietly and shows up only on the bill.
FinOps is the discipline that recovers it, and done properly it commonly returns 20 to 35% through rightsizing, scheduling non-production hours and planning commitments, with tagging governance alone cutting waste materially. We build that visibility and control in rather than treat cost as someone else's problem, because lifting waste straight into a new platform is the fastest way to lose the savings a move was meant to deliver. The deeper, ongoing programme lives in our cloud cost optimization work; in managed cloud the discipline is present by default so spend reflects use rather than habit.
Moving workloads in the right order.
Getting workloads onto the right tier is a migration, and migrations fail when they are rushed or taken whole. We sequence them: the assessment first, then the workloads that move most cleanly, with each one planned, tested on the new infrastructure and cut over with downtime scheduled rather than discovered. Repatriating a workload from a hyperscaler to an EU-native core, or lifting one onto a public cloud where it belongs, follows the same disciplined path rather than a big-bang switch that hopes for the best.
The order is chosen to reduce risk rather than to look fast. Dependencies are mapped before anything moves, so a workload is not migrated only to find the system it talks to was left behind, and the riskier moves are rehearsed before they are real. The full method, including the tricky cases, lives in our cloud migration work; within managed cloud, migration is the means of getting your estate to its right shape rather than a one-off project that ends the moment the last server is copied.
Managed, or build the platform team yourself?
Running cloud well in-house means a platform team: people who know the providers deeply, keep up with a service catalogue that changes weekly, hold the security and cost disciplines, and are on call when something breaks. That team is expensive to hire in a tight market, hard to retain, and difficult to keep busy at the right level in an organisation whose core business is not infrastructure. For most companies below a certain scale, building it is neither affordable nor sensible.
Managed cloud is the alternative to standing that team up. You get the capability, the provisioning, security, cost control, resilience and the placement judgement, without the headcount, the recruitment or the bus-factor risk of one engineer holding all the knowledge. Where an organisation genuinely has the scale and the appetite to run its own platform team, we will say so; for the many that do not, renting the capability is the honest answer rather than half-building a team and hoping it copes.
The market is opening up.
The three hyperscalers no longer have the field to themselves. A wave of specialised and regional providers, EU-native platforms, AI-focused newcomers, transparent-pricing challengers, has grown up specifically around the pain points driving the rethink: sovereignty, predictable cost, and freedom from a single vendor's gravity. The sovereign-cloud market alone is forecast to grow at better than twenty percent a year toward the hundreds of billions, which is the market voting on where this is heading.
That choice is an advantage only if your architecture can use it. A portable estate can place a workload with whichever provider fits it best and move when a better option appears, gaining negotiating power and dodging dependence on any one; a locked-in estate watches the new options go by because it cannot reach them. We keep your architecture able to take advantage of a widening market rather than trapped in the assumptions of the provider you started with, because the value of options is only realised if you can act on them.
Who needs this, and when is a hyperscaler the right answer?
Managed cloud fits an organisation whose estate has outgrown casual administration but does not warrant a full platform team: a business under GDPR, NIS2 or DORA that has to place sensitive workloads defensibly and prove an exit, a company whose cloud bill has grown faster than its understanding of it, a team running across more than one provider without a consistent way to govern them. The common thread is a cloud estate that has become a liability to operate well alone.
We are also clear about where a hyperscaler is the right answer. A workload that genuinely needs elastic global scale, or that depends on a specialised service with no real equivalent, often belongs on a public cloud, and we will place it there and manage it rather than force a sovereign fit that does not work. The honesty cuts both ways: the regulated and steady-state belong on the EU-native core, the genuinely elastic and differentiated may belong on a hyperscaler, and the job is putting each where it genuinely fits rather than selling a single answer for everything.
AI workloads and the new cost question.
AI has become the least predictable line in most cloud budgets, enough that the FinOps discipline formally widened in 2025 to cover it alongside ordinary spend. Inference and training run on expensive accelerated hardware, the usage spikes with demand in ways a steady web workload never did, and the bill can move by an order of magnitude between a quiet month and a busy one. Treated like any other cloud resource, AI spend sprawls faster than anything else on the platform.
It also raises the placement question in a sharper form. The data fed to a model, the prompts, the documents, the customer records, is often exactly the sensitive material that should not cross a jurisdiction, which makes where the inference runs a sovereignty decision rather than only a cost one. We treat AI workloads with the same hybrid-first logic as everything else: sensitive inference on infrastructure we operate in the EU, the elastic and non-sensitive where it is cheapest to run, and the spend watched closely because it is the part most likely to surprise. The model is a workload like any other, with sharper edges on both cost and sovereignty.
Day-two operations: the part that never ends.
Standing infrastructure up is day one; keeping it healthy is every day after, and that is where cloud quietly demands a team. The providers ship changes weekly, security advisories arrive constantly, workloads grow and shrink, costs drift, and a configuration that was right at launch erodes as the estate and the services around it move. Cloud is not set-and-forget, and the gap between a platform that was built well and one that is still run well is where most of the trouble accumulates.
We run the day-two work as the substance of the service: patching and updating, scaling up and back as load changes, watching cost and posture, and keeping the configuration aligned to a known state rather than letting it drift. Automation handles the routine at machine speed and people handle the judgement, the same operating model we apply to servers extended to the cloud control plane. The aim is an estate that stays well-run between the headline projects, because the slow erosion of an unattended platform is what turns a good architecture into an expensive mess.
Compliance and audit, on infrastructure you can name.
A cloud estate has to answer the same questions an auditor asks of anything else: where the data sits, who can reach it, how it is secured, and whether you can prove all three. Cloud makes that harder, because a sprawling, multi-provider estate has many more places for a control to slip and a misconfiguration to hide, and a public-bucket-left-open is a familiar headline for a reason. Posture management across the estate, watching for the drift and the misconfiguration that compliance frameworks care about, is part of running it rather than a separate audit scramble.
The sovereign core makes the hardest questions simple to answer. Where the regulated workloads run on EU-native infrastructure we operate, the residency, the jurisdiction and the operator are all known and documented, rather than reconstructed from a hyperscaler's shared-responsibility small print before an assessment. The evidence an auditor or a customer's procurement team wants exists as a property of how the estate is built, and the regulatory framing lives in our compliance work, so the cloud layer stops being the part of the audit nobody can confidently speak to.
Lift-and-shift or rebuild?
When a workload moves, there is a choice between carrying it across as it is and rebuilding it to suit where it is going, and the right answer is rarely the same for every system. Lifting a workload as-is is faster and cheaper up front, and for a stable application that simply needs a sovereign home it is often the sensible call. Rebuilding to a cloud-native or portable shape costs more now and pays back in resilience, cost and portability later, which suits a workload that will grow or move again.
We make that call per workload on its merits rather than apply one fashionable answer to everything. A wholesale rebuild sold as modernisation can burn a budget on workloads that did not need it, while a pure lift-and-shift can carry old waste and old lock-in straight into the new home. The judgement, what to move untouched, what to reshape, and what to leave where it is, is the part that decides whether a migration is worth its cost, and it is the part we would rather get right than rush.
How does it start?
An engagement opens with two things on the table: your cloud bill and a list of what you really run. From those we map the estate, classifying each workload by sensitivity, dependency and cost, and produce the split, what belongs on the EU-native core, what can stay on a hyperscaler, and where the waste and the lock-in are hiding. That first map is usually the clearest view an organisation has had of its own cloud, which tends to have grown by accretion rather than design.
From there the work is sequenced: the placement decisions, the migrations in a safe order, the cost controls and the exit documentation, run as an ongoing service rather than a one-off project. Nothing is moved before its dependencies are understood, and the riskier changes are tested before they are real. The aim is an estate that ends up shaped by deliberate decisions rather than the defaults and conveniences that built the current one, with the reasoning written down so the next decision starts from a clear picture.
Questions buyers ask.
What is managed cloud?
Should I move everything off AWS, Azure or Google?
Does an AWS or Azure region in the EU make my data sovereign?
What is a cloud exit strategy and why does it matter?
Will EU-native cloud cost me more?
Do you run your own cloud or resell someone else's?
What is hybrid-first, and why does it matter in 2026?
Is cloud repatriation real, or hype?
How much cloud spend is typically wasted?
What does DORA require for cloud?
What happens if a hyperscaler has a major outage?
How do you avoid vendor lock-in?
Do we still need our own platform team?
Where should our AI workloads run?
Should we lift-and-shift or rebuild when we move?
How does an engagement start?
Send us your cloud bill and your workloads. We'll map the split.
Tell us what runs where and what it costs now. We classify your workloads, show which belong on EU-native infrastructure, and where the bill can come down, before you commit to anything.