Sovereignty in the Cloud is A Matter of Perspective

Sovereignty in the Cloud is A Matter of Perspective

Sovereignty in the cloud is often treated as a cost.  Something that slows innovation, complicates operations, and makes infrastructure more expensive. But for governments, critical industries, and regulated enterprises, sovereignty is the basis of resilience, compliance, and long-term autonomy. Hence, sovereignty is not seen as a burden. The way a provider positions sovereignty reveals a lot about how they see the balance between global scale and local control.

Some platforms like Oracle’s EU Sovereign Cloud show that sovereignty doesn’t have to come at the expense of capability. It delivers the same services, the same pricing, and operates entirely with EU-based staff. Nutanix pushes the idea even further with its distributed cloud operating model, proving that sovereignty and value can reinforce each other rather than clash.

Microsoft’s Framing

In Microsoft’s chart, the hyperscale cloud sits on the far left of the spectrum. Standard Azure and Microsoft 365 are presented as delivering only minimal sovereignty, little residency choice, and almost no operational control. The upside, in their telling, is that this model maximizes “cloud value” through global scale, innovation, and efficiency.

Microsoft Sovereignty Trade-Offs

Move further to the right and you encounter Microsoft’s sovereign variants. Here, they place offerings such as Azure Local with M365 Local and national partner clouds like Delos in Germany or Bleu in France. These are designed to deliver more sovereignty and operational control by layering in local staff, isolated infrastructure, and stricter national compliance. Yet the framing is still one of compromise. As you gain sovereignty, you are told that some of the value of the hyperscale model inevitably falls away.

Microsoft’s Sovereign Cloud Portfolio

To reinforce this point, Microsoft presents a portfolio of three models. The first is the Sovereign Public Cloud, which is owned and operated directly by Microsoft. Data remains in Europe, and customers get software-based sovereignty controls such as “Customer Lockbox” or “Confidential Computing”. It runs in Microsoft’s existing datacenters and doesn’t require migration, but it is still, at its core, a hyperscale cloud with policy guardrails added on top.

The second model is the Sovereign Private Cloud. This is customer-owned or partner-operated, running on Azure Local and Microsoft 365 Local inside local data centers. It can be hybrid or even disconnected, and is validated through Microsoft’s traditional on-premises server stack such as Hyper-V, Exchange, or SharePoint. Here, sovereignty increases because customers hold the operational keys, but it is clearly a departure from the hyperscale simplicity.

Microsoft Sovereign Cloud Portfolio

Finally, there are the National Partner Clouds, built in cooperation with approved local entities such as SAP for Delos in Germany or Orange and Cap Gemini for Bleu in France. These clouds are fully isolated, meet the most stringent government standards like SecNumCloud in France, and are aimed at governments and critical infrastructure providers. In Microsoft’s portfolio, this is the most sovereign option, but also the furthest away from the original promise of the hyperscale cloud.

On paper, this portfolio looks broad. But the pattern remains: Microsoft treats sovereignty as something that adds control at the expense of cloud value.

What If We Reframe the Axes From “Cloud Value” to “Business Value”?

That framing makes sense if you are a hyperscaler whose advantage lies in global scale. But it doesn’t reflect how governments, critical infrastructure providers, or regulated enterprises measure success. If we shift the Y-axis away from “cloud value” and instead call it “business value”, the story changes completely. Business value is about resilience, compliance, cost predictability, reliable performance in local contexts, and the flexibility to choose infrastructure and partners that meet strategic needs.

The X-axis also takes on a different character. Instead of seeing sovereignty, residency, and operations as a cost or a burden, they become assets. The more sovereignty an organization can exercise, the more it can align its IT operations with national policies, regulatory mandates, and its own resilience strategies. In this reframing, sovereignty is not a trade-off, but a multiplier.

What the New Landscape Shows

Once you adopt this perspective, the map of cloud providers looks very different.

Sovereign Cloud Analysis Chart

Please note: Exact positions on such a chart are always debatable, depending on whether you weigh ecosystem, scale, or sovereignty highest. 🙂

Microsoft Azure sits in the lower left, offering little in terms of sovereignty or control and, as a result, little real business value for sectors that depend on compliance and resilience. Adding Microsoft’s so-called sovereign controls moves the position slightly upward and to the right, but it still remains closer to enhanced compliance than genuine sovereignty. AWS’s European Sovereign Cloud lands in the middle, reflecting its cautious promises, which are a step toward sovereignty but not yet backed by deep operational independence.

Oracle’s EU Sovereign Cloud moves higher because it combines full service parity with the regular Oracle Cloud, identical pricing, and EU-based operations, making it a credible sovereign choice without hidden compromises. OCI Dedicated Region provides strong business value in a customer’s location, but since operations remain largely in Oracle’s hands, it offers less direct control than something like VMware. VMware by Broadcom sits further to the right thanks to the control it gives customers who run the stack themselves, but its business value is dragged down by complexity, licensing issues, and legacy cost.

The clear outlier is Nutanix, rising toward the top-right corner. Its distributed cloud model spanning on-prem, edge, and multi-cloud maximizes control and business value compared to most peers. Yes, Nutanix is not flawless, and yes, Nutanix lacks the massive partner ecosystem and developer gravity of hyperscalers, but for organizations prioritizing sovereignty, it comes closest to the “ideal zone”.

Conclusion

The lesson here is simple. Sovereignty is always a matter of perspective. For a hyperscaler, it looks like a tax on efficiency. For governments, banks, hospitals, or critical industries, it is the very foundation of value. For enterprises trying to reconcile global ambitions with local obligations, sovereignty is not a drag on innovation but the way to ensure autonomy, resilience, and compliance.

Microsoft’s chart is not technically wrong, but it is incomplete. Once you redefine the axes around real-world business priorities, you see that sovereignty does not reduce value. For many organizations, it is the only way to maximize it – though the exact balance point will differ depending on whether your priority is scale, compliance, or operational autonomy.

What If Cloud Was Never the Destination But Just One Chapter In A Longer Journey

What If Cloud Was Never the Destination But Just One Chapter In A Longer Journey

For more than a decade, IT strategies were shaped by a powerful promise that the public cloud was the final destination. Enterprises were told that everything would eventually run there, that the data center would become obsolete, and that the only rational strategy was “cloud-first”. For a time, this narrative worked. It created clarity in a complex world and provided decision-makers with a guiding principle.

Hyperscalers accelerated digital transformation in ways no one else could have. Without their scale and speed, the last decade of IT modernization would have looked very different. But what worked as a catalyst does not automatically define the long-term architecture.

But what if that narrative was never entirely true? What if the cloud was not the destination at all, but only a chapter? A critical accelerator in the broader evolution of enterprise infrastructure? The growing evidence suggests exactly that. Today, we are seeing the limits of mono-cloud thinking and the emergence of something new. A shift towards adaptive platforms that prioritize autonomy over location.

The Rise and Fall of Mono-Cloud Thinking

The first wave of cloud adoption was almost euphoric. Moving everything into a single public cloud seemed not just efficient but inevitable. Infrastructure management became simpler, procurement cycles shorter, and time-to-market faster. For CIOs under pressure to modernize, the benefits were immediate and tangible.

Yet over time, the cost savings that once justified the shift started to erode. What initially looked like operational efficiency transformed into long-term operating expenses that grew relentlessly with scale. Data gravity added another layer of friction. While applications were easy to deploy, the vast datasets they relied on were not as mobile. And then came the growing emphasis on sovereignty and compliance. Governments and regulators, citizens and journalists as well, started asking difficult questions about who ultimately controlled the data and under what jurisdiction.

These realities did not erase the value of the public cloud, but they reframed it. Mono-cloud strategies, while powerful in their early days, increasingly appeared too rigid, too costly, and too dependent on external factors beyond the control of the enterprise.

Multi-Cloud as a Halfway Step

In response, many organizations turned to multi-cloud. If one provider created lock-in, why not distribute workloads across two or three? The reasoning was logical. Diversify risk, improve resilience, and gain leverage in vendor negotiations.

But as the theory met reality, the complexity of multi-cloud began to outweigh its promises. Each cloud provider came with its own set of tools, APIs, and management layers, creating operational fragmentation rather than simplification. Policies around security and compliance became harder to enforce consistently. And the cost of expertise rose dramatically, as teams were suddenly required to master multiple environments instead of one.

Multi-cloud, in practice, became less of a strategy and more of a compromise. It revealed the desire for autonomy, but without providing the mechanisms to truly achieve it. What emerged was not freedom, but another form of dependency. This time, on the ability of teams to stitch together disparate environments at great cost and complexity.

The Adaptive Platform Hypothesis

If mono-cloud was too rigid and multi-cloud too fragmented, then what comes next? The hypothesis that is now emerging is that the future will be defined not by a place – cloud, on-premises, or edge – but by the adaptability of the platform that connects them.

Adaptive platforms are designed to eliminate friction, allowing workloads to move freely when circumstances change. They bring compute to the data rather than forcing data to move to compute, which becomes especially critical in the age of AI. They make sovereignty and compliance part of the design rather than an afterthought, ensuring that regulatory shifts do not force expensive architectural overhauls. And most importantly, they allow enterprises to retain operational autonomy even as vendors merge, licensing models change, or new technologies emerge.

This idea reframes the conversation entirely. Instead of asking where workloads should run, the more relevant question becomes how quickly and easily they can be moved, scaled, and adapted. Autonomy, not location, becomes the decisive metric of success.

Autonomy as the New Metric?

The story of the cloud is not over, but the chapter of cloud as a final destination is closing. The public cloud was never the endpoint, but it was a powerful catalyst that changed how we think about IT consumption. But the next stage is already being written, and it is less about destinations than about options.

Certain workloads will always thrive in a hyperscale cloud – think collaboration tools, globally distributed apps, or burst capacity. Others, especially those tied to sovereignty, compliance, or AI data proximity, demand a different approach. Adaptive platforms are emerging to fill that gap.

Enterprises that build for autonomy will be better positioned to navigate an unpredictable future. They will be able to shift workloads without fear of vendor lock-in, place AI infrastructure close to where data resides, and comply with sovereignty requirements without slowing down innovation.

The emerging truth is simple: Cloud was never the destination. It was only one chapter in a much longer journey. The next chapter belongs to adaptive platforms and to organizations bold enough to design for freedom rather than dependency.

Stop Writing About VMware vs. Nutanix

Stop Writing About VMware vs. Nutanix

Over the last months I have noticed something “interesting”. My LinkedIn feed and Google searches are full of posts and blogs that try to compare VMware and Nutanix. Most of them follow the same pattern. They take the obvious features, line them up in two columns, and declare a “winner”. Some even let AI write these comparisons without a single line of lived experience behind it.

The problem? This type of content has no real value for anyone who has actually run these platforms in production. It reduces years of engineering effort, architectural depth, and customer-specific context into a shallow bullet list. Worse, it creates the illusion that such a side-by-side comparison could ever answer the strategic question of “what should I run my business on?”.

The Wrong Question

VMware vs. Nutanix is the wrong question to ask. Both vendors have their advantages, both have strong technology stacks, and both have long histories in enterprise IT. But if you are an IT leader in 2025, your real challenge is not to pick between two virtualization platforms. Your challenge is to define what your infrastructure should enable in the next decade.

Do you need more sovereignty and independence from hyperscalers? Do you need a platform that scales horizontally across the edge, data center, and public cloud with a consistent operating model? Do you need to keep costs predictable and avoid the complexity tax that often comes with layered products and licensing schemes?

Those are the real questions. None of them can be answered by a generic VMware vs. Nutanix LinkedIn post.

The Context Matters

A defense organization in Europe has different requirements than a SaaS startup in Silicon Valley. A government ministry evaluates sovereignty, compliance, and vendor control differently than a commercial bank that cares most about performance and transaction throughput.

The context (regulatory, organizational, and strategic) always matters more than product comparison charts. If someone claims otherwise, they probably have not spent enough time in the field, working with CIOs and architects who wrestle with these issues every day. Yes, (some) features are important and sometimes make the difference, but the big feature war days are over.

It’s About the Partner, Not Just the Platform

At the end of the day, the platform is only one piece of the puzzle. The bigger question is: who do you want as your partner for the next decade?

Technology shifts, products evolve, and roadmaps change. What remains constant is the relationship you build with the vendor or partner behind the platform. Can you trust them to execute your strategy with you? Can you rely on them when things go wrong? Do they share your vision for sovereignty, resilience, and simplicity or are they simply pushing their own agenda?

The answer to these questions matters far more than whether VMware or Nutanix has the upper hand in a feature battle.

A Better Conversation

Instead of writing another VMware vs. Nutanix blog, we should start a different conversation. One that focuses on operating models, trust, innovation, ecosystem integration, and how future-proof your platform is.

Nutanix, VMware, Red Hat, hyperscalers, all of them are building infrastructure and cloud stacks. The differentiator is not whether vendor A has a slightly faster vMotion or vendor B has one more checkbox in the feature matrix. The differentiator is how these platforms align with your strategy, your people, and your risk appetite, and whether you believe the partner behind it is one you can depend on.

Why This Matters Now

The market is in motion. VMware customers are forced to reconsider their roadmap due to the Broadcom acquisition and the associated licensing changes. Nutanix is positioning itself as a sovereign alternative with strong hybrid cloud credentials. Hyperscalers are pushing local zones and sovereign cloud initiatives.

In such a market, chasing simplistic comparisons is a waste of time. Enterprises should focus on long-term alignment with their cloud and data strategy. They should invest in platforms and partners that give them control, choice, and agility.

Final Thought

So let’s stop writing useless VMware vs. Nutanix comparisons. They don’t help anyone who actually has to make decisions at scale. Let’s raise the bar and bring back thought leadership to this industry. Share real experiences. Talk about strategy and outcomes. Show where platforms fit into the bigger picture of sovereignty, resilience, and execution. And most importantly: choose the partner you can trust to walk this path with you.

That is the conversation worth having. Everything else is just noise and bullshit.

Finally, People Start Realizing Sovereignty Is a Spectrum

Finally, People Start Realizing Sovereignty Is a Spectrum

For months and years, the discussion about cloud and digital sovereignty has been dominated by absolutes. It was framed as a black-and-white choice. Either you are sovereign, or you are not. Either you trust hyperscalers, or you don’t. Either you build everything yourself, or you hand it all over. But over the past two years, organizations, governments, and even the vendors themselves have started to recognize that this way of thinking doesn’t reflect reality. Sovereignty is seen as a spectrum now.

When I look at the latest Gartner Magic Quadrant (MQ) for Distributed Hybrid Infrastructure (DHI), this shift becomes even more visible. In the leader’s quadrant, we find AWS, Microsoft, Oracle, Broadcom (VMware), and Nutanix. Each of them is positioned differently, but they all share one thing in common. They now operate somewhere along this sovereignty spectrum. Some of them are “fully” sovereign and some of them are dependent. The truth lies in between, and it is about how much control you want to retain versus how much you are willing to outsource. But it’s also possible to have multiple vendors and solutions co-existing.

Gartner MQ DHI 2025

The Bandwidth of Sovereignty

To make this shift more tangible, think of sovereignty as a bandwidth rather than a single point. On the far left, you give up almost all control and rely fully on global hyperscalers, following their rules, jurisdictions, and technical standards. On the far right, you own and operate everything in your data center, with full control but also full responsibility. Most organizations today are somewhere in between (using a mix of different vendors and clouds).

This bandwidth allows us to rate the leaders in the MQ not as sovereign or non-sovereign, but according to where they sit on the spectrum:

  • AWS stretches furthest toward global reach and scalability. They are still in the process of building a sovereign cloud, and until that becomes reality, none of their extensions (Outposts, Wavelength, Local Zones) can truly be seen as sovereign (please correct me if I am wrong). Their new Dedicated Local Zones bring infrastructure closer, but AWS continues to run the show. Meaning sovereignty is framed through compliance, not operational autonomy.

  • Microsoft sits closer to the middle. With Microsoft’s Sovereign Cloud initiatives in Europe, they acknowledge the political and regulatory reality. Customers gain some control over data residency and compliance, but the operational steering remains with Microsoft (except for their “Sovereign Private Cloud” offering, which consists of Azure Local + Microsoft 365 Local).

  • Oracle has its EU Sovereign Cloud, which is already available today, and with offerings like OCI Dedicated Region and Alloy that push sovereignty closer to customers. Still, these don’t offer operational autonomy, as Oracle continues to manage much of the infrastructure. For full isolation, Oracle provides Oracle Cloud Isolated Region and the smaller Oracle Compute Cloud@Customer Isolated (C3I). These are unique in the hyperscaler landscape and move Oracle further to the right.

  • Broadcom (VMware) operates in a different zone of the spectrum. With VMware’s Cloud Foundation stack, customers can indeed build sovereign clouds with operational autonomy in their own data centers. This puts them further right than most hyperscalers. But Gartner and recent market realities also show that dependency risks are not exclusive to AWS or Azure. VMware customers face uncertainty tied to Broadcom’s licensing models and strategic direction, which balances out their autonomy.

  • Google does not appear in the leader’s quadrant yet, but their Google Distributed Cloud (GDC) deserves mention. Gartner highlights how GDC is strategically advancing, winning sovereign cloud projects with governments and partners, and embedding AI capabilities on-premises. Their trajectory is promising, even if their current market standing hasn’t brought them into the top right yet.

  • Nutanix stands out by offering a comprehensive single product – the Nutanix Cloud Platform (NCP). Gartner underlines that NCP is particularly suited for sovereign workloads, hybrid infrastructure management, and edge multi-cloud deployments. Unlike most hyperscalers, Nutanix delivers one unified stack, including its “own hypervisor as a credible ESXi alternative”. That makes it possible to run a fully sovereign private cloud with operational autonomy, without sacrificing cloud-like agility and elasticity.

Why the Spectrum Matters

This sovereignty spectrum changes how CIOs and policymakers make decisions. Instead of asking “Am I sovereign or not?”, the real question becomes:

How far along the spectrum do I want to be and how much am I willing to compromise for flexibility, cost, or innovation?

It is no longer about right or wrong. Choosing AWS does not make you naive. Choosing Nutanix does not make you paranoid. Choosing Oracle does not make you old-fashioned. Choosing Microsoft doesn’t make you a criminal. Each decision reflects an organization’s position along the bandwidth, balancing risk, trust, cost, and control.

Where We Go From Here

The shift to this spectrum-based view has major consequences. Vendors will increasingly market not only their technology but also their place on the sovereignty bandwidth. Governments will stop asking for absolute sovereignty and instead demand clarity about where along the spectrum a solution sits. And organizations will begin to treat sovereignty not as a one-time decision but as a dynamic posture that can move left or right over time, depending on regulation, innovation, and geopolitical context.

The Gartner MQ shows that the leaders are already converging around this reality. The differentiation now lies in how transparent they are about it and how much choice they give their customers to slide along the spectrum. Sovereignty, in the end, is not a fixed state. It is a journey.

Moving into Any Cloud Is Easy. Leaving Is the Hard Part

Moving into Any Cloud Is Easy. Leaving Is the Hard Part

For more than a decade, the industry has been focused on one direction. Yes, into the cloud. Migration projects, cloud-first strategies, and transformation initiatives all pointed the way toward a future where workloads would move out of data centers and into public platforms. Success was measured in adoption speed and the number of applications migrated. Very few people stopped to ask a more uncomfortable question: What if one day we needed to move out again?

This question, long treated as hypothetical, has now become a real consideration for many organizations. Cloud exit strategies, once discussed only at the margins of risk assessments, are entering boardroom conversations. They are no longer about distrust or resistance to cloud services, but about preparedness and strategic flexibility.

Part of the challenge is perception. In the early years, the cloud was often viewed as a one-way street. Once workloads were migrated, it was assumed they would stay there indefinitely. The benefits were obvious (agility, global reach, elastic scale, and a steady stream of innovation). Under such conditions, why would anyone think about leaving? But reality is rarely that simple. Over time, enterprises discovered that circumstances change. Costs, which in the beginning looked predictable, began to rise, especially for workloads that run continuously. Regulations evolved, sometimes requiring that data be handled differently or stored in new ways. Geopolitical factors entered the discussion, adding new dimensions of risk and dependency. What once felt like a permanent destination started to look more like another stop in a longer journey.

Exiting the cloud, however, is rarely straightforward. Workloads are not just applications; they are deeply tied to the data they use. Moving terabytes or petabytes across environments is slow, expensive, and operationally challenging. The same is true for integrations. Applications are connected to identity systems, monitoring frameworks, CI/CD pipelines, and third-party APIs. Each of these dependencies creates another anchor that makes relocation harder. Licensing and contracts add another layer of complexity, where the economics or even the legal terms of use can discourage or delay migration. And finally, there are the human and process elements. Teams adapt their ways of working to a given platform, build automation around its services, and shape their daily operations accordingly. Changing environments means changing habits, retraining staff, and, in some cases, restructuring teams.

Despite these obstacles, exit strategies are becoming more important. Rising costs are one reason, particularly for predictable workloads, where running them elsewhere might be more economical. Compliance and sovereignty requirements are another. New rules can suddenly make a deployment non-compliant, forcing organizations to rethink their choices. A third driver is the need for strategic flexibility. Many leaders want to ensure they are not overly dependent on a single provider or operating model. Having the ability to relocate workloads when circumstances demand it has become a necessity.

This is why exit strategies should be seen less as a technical exercise and more as a strategic discipline. The goal is not to duplicate everything or keep environments constantly synchronized, which would be wasteful and unrealistic. Instead, the goal is to maintain options. Options to repatriate workloads when economics dictate, options to move when compliance requires, and options to expand when innovation opportunities emerge. The best exit strategies are not documents that sit on a shelf. They are capabilities built into the way an enterprise designs, operates, and governs its IT landscape.

History in IT shows why this matters. Mainframes, proprietary UNIX systems and even some early virtualization platforms all created situations of deep dependency. At the time, those technologies delivered enormous value. But eventually, organizations needed to evolve and often found themselves constrained. The lesson is not to avoid new technologies, but to adopt them with foresight, knowing that change is inevitable. Exit strategies are part of that foresight.

Looking ahead, enterprises can prepare by building in certain principles. Workloads that are critical to the business should be designed with portability in mind, even if not every application needs that level of flexibility. Data should be separated from compute wherever possible, because data gravity is one of the biggest barriers to mobility. And governance should be consistent across environments, so that compliance, security, and cost management follow workloads rather than being tied to a single location. These principles do not mean abandoning the cloud or holding it at arm’s length. On the contrary, they make the cloud more sustainable as a strategic choice.

Cloud services will continue to play a central role in modern IT. The benefits are well understood, and the pace of innovation will ensure that they remain attractive. But adaptability has become just as important as adoption. Having an exit strategy is not a sign of mistrust. It is a recognition that circumstances can change, and that organizations should be prepared. In the end, the key question is no longer only how fast you can move into the cloud, but also how easily you can move out again if you ever need to. And this includes the private cloud as well.

What Is Sovereign Enough for You?

What Is Sovereign Enough for You?

Digital sovereignty has become one of the defining topics for governments, regulators, and organizations that operate with sensitive data. Everyone wants to know how much control they truly have over their cloud environment. But the question that should be asked first is: what is sovereign enough for you? Because sovereignty is not a binary choice. It comes in different layers, with different levels of autonomy, control, and dependencies on global vendors like Oracle.

Oracle has designed its portfolio with exactly this variety in mind. Not every government or regulated organization needs or wants a fully isolated environment. Some are fine with Oracle managing the service end-to-end, while others require absolute control down to operations and staffing. Let’s walk through the different operating models and connectivity dependencies, so you can decide where your needs for sovereignty fit in.

1) Building a Full Sovereign Cloud With Local Personnel

At the very top of the sovereignty spectrum sits the option to build a national or regional sovereign cloud that is completely separated from Oracle’s global public regions (separate realms). These environments are staffed and operated by locally cleared personnel, and the legal entity running the cloud sits within the country or region itself.

A graphic depicting OCI realms with separation.

Examples today are the UK Government & Defence Cloud and the Oracle EU Sovereign Cloud. Here, sovereignty is not only a technical matter but also an organizational one. Governments get the guarantee that operations, compliance, and support are entirely bound by local regulations and cannot be accessed or influenced from outside.

Full operational autonomy by design. The control plane, the data plane, and the people managing the systems are all local. Oracle provides the technology, but the control and day-to-day operations are delegated to the sovereign entity.

From a policy-maker’s perspective, this is the gold standard. Independence from foreign jurisdictions, complete local control of staff, audits, and processes, and guaranteed resilience even without global connectivity. It comes with the highest costs and commitments, but also the strongest assurance.

2) OCI Dedicated Region

OCI Dedicated Region is a full public cloud region deployed directly into a customer’s data center. It includes all Oracle Cloud services, runs on dedicated infrastructure, and provides the same service catalog as Oracle’s global regions.

Diagram of OCI in a dedicated region, description below

From a sovereignty perspective, this model ensures that data never leaves the country if the customer so desires. The region is connected to Oracle’s global backbone (still separate realms), which allows it to remain consistent in updates, operations, and service integration. However, the control plane still depends on Oracle. Updates, patches, and lifecycle management (~15’000 changes per month) are performed by Oracle engineers, who operate under strict contracts and compliance rules.

Examples in practice:

  • Vodafone has deployed six Dedicated Regions across Europe (Ireland, Italy, Germany) to modernize core systems, ensure compliance, and keep data inside the EU while leveraging Oracle’s global innovation cycle.

  • Avaloq, the Swiss banking software leader, runs its own Dedicated Region to provide compliant, modern infrastructure for financial services, combining local control of data with Oracle’s managed operations.

Dedicated Region is often sovereign enough: sensitive workloads stay in-country, under national regulation, while Oracle ensures consistency, security, and ongoing modernization. Operational autonomy is not fully local, but the trade-off is efficiency and scale.

3) Oracle Alloy

Oracle Alloy takes sovereignty one step further by introducing a cloud-as-a-service model for partners. Service providers, system integrators, or governments can license Oracle’s technology stack and operate their own branded cloud. Alloy provides the full OCI service catalog but allows the partner to take over customer relationships, billing, compliance, and front-line operations.

Becoming an Oracle Alloy partner  diagram, description below

This is highly attractive for countries and organizations that want to build their own cloud business or national platforms without developing hyperscale technology themselves. Still, Alloy maintains a technical tether to Oracle. While the partner gains control over operations and branding, Oracle remains in charge of certain aspects of lifecycle management, support escalation (tier 2 and tier 3 support), and roadmap alignment.

Examples in practice:

  • In Saudi Arabia, telecom leader stc is using Alloy to deliver sovereign cloud services that meet local data residency and regulatory requirements.

  • In Japan, Fujitsu uses Oracle Alloy to provide sovereign cloud and AI capabilities tailored to Japanese compliance needs.

  • In Italy, the Polo Strategico Nazionale (PSN) leverages Alloy as part of its managed public cloud offering to deliver secure and compliant cloud services to public administrations.

Alloy strikes a strong balance: It empowers local ecosystems to run a nationally branded sovereign cloud, keeping control of data and compliance, while Oracle provides the innovation foundation. It is not full independence, but it delivers sovereignty in practice for many use cases.

4) Oracle Compute Cloud@Customer

Oracle Compute Cloud@Customer (C3) is a private cloud appliance that delivers OCI services inside your data center. It is ideal for customers who want cloud elasticity and API compatibility with OCI, but who also need workloads to run locally due to latency, compliance, or data residency requirements.

However, the control plane is still managed by Oracle (in a public OCI region or connected to the EU Sovereign Cloud). This means patching, upgrades, and critical operations are carried out by Oracle teams, even though the infrastructure is located in your facility. Connectivity back to Oracle is also required for normal lifecycle operations.

An additional strength of C3 is its seamless integration with OCI Dedicated Region. Customers can connect their local C3 instances to their Dedicated Region, effectively combining on-premises elasticity with the scale and service catalog of a full cloud region running inside their country. This creates a flexible architecture where workloads can be placed optimally on C3 for local control and performance, or on Dedicated Region for broader cloud capabilities.

Oracle Compute Cloud@Customer key capabilities

This model is a pragmatic compromise. It guarantees data sovereignty by keeping workloads in-country, but governments or regulated organizations don’t need to staff or manage the complexity of lifecycle operations. With the option to connect to a Dedicated Region, C3 also opens the door to a multi-layer sovereign cloud strategy, blending local control with the breadth of a national-scale cloud.

5) Oracle Cloud Isolated Region (OCIR)

Oracle Cloud Isolated Region (OCIR) is a specialized deployment model designed for environments that require enhanced security, autonomy, and in-country governance at national or organizational scale. Like a Dedicated Region, it is a full OCI cloud region deployed on-premises, but it is operated in a more restricted and isolated mode, with minimized dependency on Oracle’s global backbone.

Oracle Cloud Isolated Region

Example in practice: Singapore’s Defence Science and Technology Agency (DSTA) has selected OCIR to support the Ministry of Defence (MINDEF) and the Singapore Armed Forces (SAF). The deployment provides an air-gapped, sovereign cloud with high-performance compute and AI capabilities to strengthen C4 (Command, Control, Communications, and Computers) systems. It ensures secure operations, scalability, and rapid decision-making, all within a fully national framework.

OCIR is particularly suited to government ministries, defense, or intelligence organizations that want a nationally hosted cloud hub with strong autonomy, while still retaining the scalability and service richness of a hyperscale platform.

OCIR represents a strategic anchor, providing a sovereign cloud backbone for an entire country or authority that combines national-scale control with the innovation and reliability of Oracle Cloud.

6) Oracle Compute Cloud@Customer Isolated (C3I)

Oracle Compute Cloud@Customer Isolated (C3I) is the solution for organizations that need the highest degree of operational autonomy without running a full sovereign cloud program.

C3I is deployed into a customer’s data center and runs in an air-gapped configuration. The control plane is hosted locally and does not rely on Oracle’s global backbone. This means the customer or the designated authority is in charge of lifecycle operations, updates, and connectivity policies. Oracle provides the technology stack and ensures that the platform can evolve, but operations and control are fully handed to the customer/partner.

Scenario for defense organizations: Imagine a defense ministry operating an Oracle Cloud Isolated Region (OCIR) as its central sovereign cloud hub. Non-sensitive workloads such as HR, logistics, or training could run on regular C3 instances connected to OCIR’s control plane. At the same time, highly sensitive or tactical workloads, such as battlefield data analysis, mission planning, or classified operations, could be deployed on C3I instances. These isolated instances would be managed by local defense teams in the field, operating autonomously even in disconnected or hostile environments. This dual approach allows governments to combine centralized governance through OCIR with operational independence in mission-critical scenarios.

Oracle Compute Cloud@Customer Isolated

C3I represents the pinnacle of autonomy: The ability to maintain full local control for sensitive workloads while integrating into a broader sovereign cloud architecture anchored by OCIR.

Where Do You Stand on the Spectrum?

When thinking about sovereignty, it is essential to recognize that not every organization needs the same level of control. For some, a Dedicated Region is already sovereign enough, as it keeps all data within national borders while still benefiting from Oracle’s global expertise. For others, Alloy provides the right balance of local branding, compliance, and ecosystem building. For governments requiring national-scale autonomy, OCIR acts as a sovereign cloud hub. And for those with the most demanding tactical requirements, C3I ensures full local independence.

So the question remains: What is sovereign enough for you? The answer depends on your data sensitivity, regulatory environment, budget and strategic goals. Oracle has built a portfolio that allows you to choose. The challenge is to define your threshold and then pick the model that aligns with it.