Why Switzerland Needs a Different Kind of Sovereign Cloud

Why Switzerland Needs a Different Kind of Sovereign Cloud

Switzerland doesn’t follow. It observes, evaluates, and decides on its own terms. In tech, in policy, and especially in how it protects its data. That’s why the typical EU sovereign cloud model won’t work here. It solves a different problem, for a different kind of political union.

But what if we could go further? What if the right partner, one that understands vertical integration, local control, and legal separation, could build something actually sovereign?

That partner might just be Oracle.

Everyone is talking about the EU’s digital sovereignty push and Oracle responded with a serious answer: the EU Sovereign Cloud, which celebrated its second anniversary a few weeks ago. It’s a legally ring-fenced, EU-operated, independently staffed infrastructure platform. Built for sovereignty, not just compliance.

That’s the right instinct. But Switzerland is not the EU. And sovereignty here means more than “EU-only.” It means operations bound by Swiss law, infrastructure operated on Swiss soil, and decisions made by Swiss entities.

Oracle Alloy and OCI Dedicated Region – Sovereignty by Design

Oracle’s OCI Dedicated Region and the newer Alloy model were designed with decentralization in mind. Unlike traditional hyperscaler zones, these models bring the entire control plane on-premises, not just the data.

That allows for policy enforcement, tenant isolation, and lifecycle management to happen within the customer’s boundaries, without default exposure to centralized cloud control towers. In short, the foundation for digital sovereignty is already there.

But Switzerland, especially the public sector, expects more.

What Still Needs to Be Solved for Switzerland

Switzerland doesn’t just care about where data sits. It cares about who holds the keys, who manages the lifecycle, and under which jurisdiction they operate.

While OCI Dedicated Region and Alloy keep the control plane local, certain essential services, such as telemetry, patch delivery, and upgrade mechanisms, still depend on Oracle’s global backbone. In the Swiss context, even a low-level dependency can raise concerns about jurisdictional risk, including exposure to laws like the U.S. CLOUD Act.

Support must remain within Swiss borders. Sovereign regions that rely on non-Swiss teams or legal entities to resolve incidents still carry legal and operational exposure – but this data can be anonymized. Sovereignty includes not only local infrastructure, but also patch transparency, cryptographic root trust, and full legal separation from foreign jurisdictions. 

Yes, operational teams must be Swiss-based, except at the tier 2 or tier 3 level.

Avaloq Is Already Leading the Way

This isn’t just theory. Switzerland already has a working example: Avaloq, the Swiss financial technology provider, is running core workloads on OCI Dedicated Region.

These are not edge apps or sandbox environments. Avaloq supports mission-critical platforms for regulated financial institutions. If they trust Oracle’s architecture with that responsibility, the model is clearly feasable. From a sovereignty, security, and compliance perspective.

Avaloq’s deployment shows that Swiss-regulated workloads can run securely, locally, and independently. And if one of Switzerland’s most finance-sensitive firms went down this path, others across government, healthcare, and infrastructure should be paying attention.

Sovereignty doesn’t mean reinventing everything. It means learning from those already building it.

The Bottom Line

Switzerland doesn’t need more cloud. It needs a cloud built for Swiss values: neutrality, autonomy, and legal independence.

Oracle is closer to that model than most. Its architecture is already designed for local control. Its EU Sovereign Cloud shows it understands the legal and operational dimensions of sovereignty. And with Avaloq already in production on OCI Dedicated Region, the proof is there.

The technology is ready. The reference customer is live.

What comes next is a question of commitment.

Why Sovereignty Needs Both Centralization and Decentralization

Why Sovereignty Needs Both Centralization and Decentralization

Europe’s cloud strategy is at a crossroads. There’s pressure to take control, to define sovereignty in infrastructure terms, and to reduce exposure to non-European hyperscalers. But somewhere along the way, the conversation fell into a binary trap: either centralize for control or decentralize for autonomy.

That’s not how modern systems work. And it’s not how sovereignty is going to work either.

Europe’s reliance on U.S. hyperscalers remains a security and sovereignty risk. While countries like France, Germany, and Italy invest in local providers, their efforts remain siloed. Without alignment, Europe is left with patchwork sovereignty.

I said it many times already, but let me repeat it. Sovereignty in the cloud isn’t a matter of choosing one path or the other. It’s about building an architecture that combines both centralized coordination with decentralized execution. Anything else either fragments too fast or becomes too rigid to function in a sovereign context.

Centralization Is About Structure, Not Control

Centralization plays a role. A central governance framework helps define what sovereignty means: where data can move, who operates the infrastructure, how compliance is enforced, how identity is managed. Without some level of central alignment, sovereignty collapses into 27 different interpretations with no common ground.

This is where Europe still struggles. They are good at setting principles – GDPR, data residency, trusted cloud labels – but they lack shared operational infrastructure. What they do have is fragmented: agencies, member states, and industry sectors each building their own versions of sovereignty with little interoperability between them.

Centralization brings order, but order alone isn’t resilience.

Sovereign Microzones: Fragmented by Design

The current trajectory in many parts of Europe is toward what could be called sovereign microzones, individually defined, locally controlled, often incompatible cloud environments built by national or sector-specific entities.

These microzones are born out of good intentions: protect critical data, maintain legal oversight, reduce dependency. But most of them don’t scale well. Each implementation introduces its own stack, its own compliance logic, and often its own interpretation of what “sovereign” really means.

In practice, this results in technical fragmentation and governance friction. Cross-border collaboration becomes harder. Data sharing between sectors stalls. Innovation slows as cloud-native capabilities are stripped back to meet narrow compliance targets.

Sovereignty was never meant to be a bunker. If these microzones can’t interoperate, they may become silos. Silos with flags on top.

Operational Autonomy vs. Strategic Realism

One idea gaining momentum is operational autonomy, ensuring that European workloads can continue to run even in the event of a political embargo or legal dispute with a non-EU provider. It’s a serious concept, grounded in real geopolitical concerns. The fear is that U.S. cloud vendors could, under extraordinary circumstances, be forced to restrict services in Europe. I get it.

But let’s be honest: the probability of a coordinated embargo cutting off hundreds of cloud regions across Europe is extremely low. Not zero. But close. The legal, economic, and political blowback would be enormous. The U.S. has more to lose than gain by treating Europe as an adversary in this space.

Still, operational autonomy has value. It’s about having options. The ability to reassign workloads, shift operational control, and decouple governance when needed. But building that autonomy doesn’t mean rejecting foreign technology outright. It means investing in layered sovereignty: trusted deployment models, contractual separation, technical isolation when necessary, and above all – control over the control plane.

Note: Operational autonomy is not the same as autarky.

What Oracle Cloud Enables

Oracle Cloud fits this model in ways that are often overlooked. Not because it’s European, it isn’t, but because it supports the technical and operational diversity that sovereignty requires.

With OCI Dedicated Region and the Cloud@Customer portfolio, institutions can run full-featured or a subset of Oracle Cloud environments inside their own data centers, with some/complete control over operations, updates, and access.

Oracle’s EU Sovereign Cloud further separates European workloads from global infrastructure, with EU-based personnel and compliance boundaries. And unlike some providers, Oracle doesn’t require full-stack standardization to make it work. It’s open, modular, and designed for interoperability.

A good example of this approach is the new partnership between Oracle and Nextcloud. It brings together a leading European open-source collaboration platform with Oracle’s sovereign cloud infrastructure. The result is a deployment model where public sector organizations can run Nextcloud in a scalable, cloud-native environment while maintaining full data control and legal jurisdiction within the EU. It’s an antidote to sovereign fragmentation: a solution that respects both European values and operational pragmatism.

This kind of flexibility matters. It respects the complexity of European sovereignty rather than trying to erase it.

Conclusion: Not Either/Or – Both

Europe shouldn’t have to choose between centralization and decentralization. In fact, it can’t. Real sovereignty (political, technical, operational) lives in the tension between the two.

The false choice only leads to false confidence. The reality is more difficult, but also more durable: structure without rigidity, autonomy without fragmentation.

Sovereignty isn’t built in isolation. It’s coordinated. Together.

Rethinking Digital Sovereignty – From Decentralized Control to a “Cloud NATO” for Europe

Rethinking Digital Sovereignty – From Decentralized Control to a “Cloud NATO” for Europe

Cloud infrastructure has quietly become one of the most strategic layers of modern sovereignty. The ability to store, process, and control data within national or regional boundaries isn’t just a regulatory preference anymore. It’s a matter of economic security, political leverage, and systemic resilience.

Across Europe, the pressure is mounting to find alternatives to centralized cloud dependencies, especially on non-European hyperscalers. But the response doesn’t have to be isolation or reinvention. A new kind of architecture is emerging, one that combines local control with collective strength.

This article explores two major ideas driving the conversation forward: decentralized digital sovereignty and the potential for a NATO-style model of cloud governance. It also looks at how Oracle Cloud aligns with this vision as a modular enabler of sovereignty, interoperability, and trust.

The Shift Toward Decentralized Sovereignty

When digital sovereignty first entered the mainstream conversation, it was often framed in binary terms: own the stack, or remain dependent. Control your cloud, or get locked in. But real-world infrastructure isn’t built on such clean lines. Across Europe, what’s emerging is a decentralized approach to sovereignty – one that accepts technical diversity, regulatory pluralism, and federated execution.

A decentralized model doesn’t reject sovereignty, it redefines it. Each country, or even each sector, can set and enforce its own policies around data protection, infrastructure, and compliance. But instead of operating in isolation, these systems connect through shared governance, open standards, and secure interoperability. It’s not about building a pan-European hyperscaler but about creating a European cloud ecosystem.

This is the principle behind initiatives like Gaia‑X, which doesn’t aim to replace existing infrastructure, but rather to standardize how participants exchange data, certify services, and establish trust. It’s sovereignty is maintained at the edge, but coordinated at the core.

This model is particularly well-suited to the European context, where data protection laws like the GDPR already offer a common legal framework, but where political and operational control must remain localized. Sovereignty, in this sense, becomes a set of enforceable guarantees, not a monolithic stack.

From Decentralization to Collective Defense – A “Cloud NATO”?

Decentralized control brings autonomy, but what about defense? In a digital world, resilience isn’t just about uptime. It’s about coordination. Europe needs to think beyond who hosts the data and start asking how we defend, recover, and coordinate our digital responses as a unified front.

The idea of a “Cloud NATO” is more than a metaphor. Like its military counterpart, it would be built on the principle of shared responsibility with local autonomy. Each country would operate its own cloud environment: certified, secured, and governed by its own rules. But all participants would align on common protocols for interoperability, auditing, security standards, and incident response.

Think of it as a federation of sovereign clouds: decentralized in ownership, but unified in execution when needed. Such a model would preserve the diversity of national approaches and offer a collective backbone for coordination and trust.

In moments of crisis, whether regulatory, technical, or geopolitical, a NATO-style alliance would allow sovereign clouds to mutually support each other, share threat intelligence, and even mirror critical workloads across trusted jurisdictions. In a time of rising cyber threats, digital fragmentation is not an option, but neither is centralization. A federated alliance may be the only workable path.

Where Oracle Cloud Fits In

To make these models viable, Europe needs cloud providers that don’t force one mode of operation. It needs platforms that support sovereignty by design, federation by architecture, and trust by default. Oracle Cloud brings several elements to this table.

Oracle offers one of the most modular and flexible cloud deployment models in the hyperscaler landscape. With Dedicated Region and Cloud@Customer, Oracle enables governments and critical industries to deploy full-featured Oracle Cloud environments within national borders or sovereign facilities. That means local control over infrastructure, compliance, and operations- without giving up cloud-native scalability or modern service architectures.

Crucially, Oracle’s architecture emphasizes openness. It supports Kubernetes, open APIs, and multi-cloud integrations, ensuring sovereign environments aren’t isolated silos but nodes in a larger ecosystem. Whether connecting ministries across borders or bridging data domains between sectors, this openness makes decentralized coordination feasible at scale.

Building Blocks for a “Cloud NATO”

For a federated governance model to work, interoperability isn’t enough. Providers must support auditable governance, strong identity management, transparent encryption controls, and legal separation of sovereign workloads. Oracle’s EU Sovereign Cloud does exactly that: operating independently from its global infrastructure, with EU-based support, operations, and compliance.

Oracle also demonstrates multi-cloud execution through its partnership with Microsoft Azure, Amazon Web Services and Google Cloud, where Oracle Database services run natively in Azure, AWS or GCP data centers. It’s a working example of what a trusted, cross-platform alliance can look like. Tech giants respect the sovereignty of each other’s platforms while delivering real interoperability.

These technical capabilities are supported by a broader strategy: Oracle doesn’t push for lock-in or exclusive dependencies. It supports coexistence and federation. The very principles that would make a “Cloud NATO” not just possible, but resilient.

Sovereignty Is Evolving. So Should the Cloud

The old model of sovereignty – one state, one data center, one stack – is no longer viable. Europe needs an approach to cloud that is both locally governed and globally coordinated.

Decentralized sovereignty gives each country the autonomy it needs. A “Cloud NATO” gives the continent the collective strength it lacks. Together, they offer a roadmap not just for compliance, but for cloud independence with integrity.

And for this to work, cloud providers must be more than platforms, they must be partners in sovereignty. Oracle’s architecture, deployment flexibility, and governance tooling place it in a unique position to support this shift. Not by dominating the stack, but by enabling distributed trust.

The future of Europe’s cloud may not belong to a single player. It may belong to an alliance.

5 Challenges in Building National Cloud Infrastructures and How to Solve Them

5 Challenges in Building National Cloud Infrastructures and How to Solve Them

Governments around the world are facing increasing pressure to assert control over their digital infrastructure. Whether driven by regulatory mandates, national security concerns, or political developments, the concept of a national cloud or sovereign cloud is gaining serious traction.

But building a national cloud infrastructure is far from straightforward. It is a complex balancing act between innovation, control, compliance, and risk management. Based on my work in the cloud space across Oracle and VMware, and through conversations with customers in the public sector, I have seen the same set of challenges come up again and again.

In this post, I want to walk through five of the biggest challenges governments and regulated industries face when building sovereign cloud environments, and explore some practical ways to solve them.

1. The Data Sovereignty Dilemma

One of the most fundamental challenges is ensuring data remains under the control of the nation that owns it. Most global cloud providers are headquartered in the US and are subject to extraterritorial laws, such as the CLOUD Act. That’s a serious concern for countries in the EU, Middle East, and Asia-Pacific who require sensitive data to remain on national or regional soil, with no foreign access.

Saying that “data is stored in Frankfurt” doesn’t automatically mean it’s sovereign. True data sovereignty requires not only residency, but also legal and operational separation from foreign jurisdictions. This is where traditional hyperscale models fall short.

To address this, vendors like Oracle have started offering sovereign cloud regions – such as the Oracle EU Sovereign Cloud – which are operated and supported entirely from within the EU, by EU-based personnel. That is a major step forward. But ultimately, sovereignty isn’t just a location, it’s an operating model. You need to design the cloud platform from day one with jurisdictional independence and compliance in mind.

2. Securing National-Scale Cloud Platforms

Security is always important in cloud architecture, but when you are talking about a national cloud, the stakes are even higher. You are dealing with mission-critical applications, citizen data, defense information, or classified intelligence systems. A breach or compromise isn’t just a technical issue, it’s a national event.

Unfortunately, many government environments still rely on legacy perimeter models and lack deep cloud-native security architecture. The challenge is how to build a cloud environment that meets zero-trust standards, supports high-assurance workloads, and integrates with national cybersecurity frameworks.

The answer lies in combining hardened cloud regions, private connectivity, data encryption with customer-controlled keys, and isolation mechanisms such as dedicated tenancy or confidential computing. Platforms like Oracle’s National Security Regions (NSRs) offer this level of separation and assurance. But even then, security isn’t just about tools. It’s about governance. Governments must define strict policies and enforce them consistently across cloud and on-prem environments.

3. Operational Control and Cloud Autonomy

A common concern I hear from public sector architects is the fear of losing operational control. Many cloud services are abstracted to a point where customers can’t dictate how and where they run. For governments, that’s not always acceptable. Especially when they want to run critical workloads or classified systems.

There’s a growing demand for operational autonomy: the ability to manage, monitor, and maintain the infrastructure independently or through trusted local entities. This is where concepts like “sovereign operations” come into play.

In a sovereign cloud model, operations – including support, monitoring, and incident response – are handled within the national boundary, by vetted personnel. Oracle has implemented this model in its EU Sovereign Cloud, ensuring no foreign nationals are involved in the operational chain. It is this level of people-based sovereignty, not just technology, that defines real national cloud infrastructure.

4. Keeping Up with the Compliance Maze

Compliance is one of the biggest drivers behind national cloud initiatives, and also one of the most frustrating challenges. The regulatory landscape is constantly evolving. Governments must comply with GDPR, national data protection laws, critical infrastructure regulations, defense policies, and sector-specific standards.

But cloud platforms evolve faster than laws do. It’s hard to maintain compliance across services, especially when new features are released weekly and spread across different regions.

One way to address this is by using compliance automation frameworks. Cloud providers like Oracle offer templates and reference architectures that help you deploy workloads in a compliant-by-default manner. Some even include compliance-as-code, which automates controls and checks during the deployment process.

But even the best frameworks won’t help unless your cloud provider aligns its service roadmap with local regulations. That’s why it’s essential to work with vendors who treat compliance not as a checkbox, but as a core part of their product design and go-to-market strategy.

5. Innovation vs. Risk Aversion

The final challenge is cultural, not technical.

Most public sector organizations know they need to modernize, but they operate in environments where risk is avoided at all costs. Innovation often takes a backseat to auditability and procurement processes. As a result, cloud transformation projects get stuck in POCs, or never leave the pilot phase.

Ironically, sovereign clouds are often seen as “less capable” than commercial regions, reinforcing this hesitance. But that perception is changing. Today, sovereign cloud offerings are increasingly on par with global platforms. And in some cases, they offer more control and greater visibility.

To overcome internal resistance, governments need to create safe innovation spaces. That means using pre-certified landing zones, sandbox environments, and trusted architectural patterns. It also means investing in cloud fluency across teams, so that risk management and agility aren’t mutually exclusive.

Note: “Cloud fluency” refers to the ability of individuals or organizations to understand, use, and make informed decisions about cloud technologies, confidently and effectively.

Final Thoughts

Building a national cloud infrastructure isn’t just a technical project. I’s a long-term strategic effort that combines technology, law, policy, and trust. The challenges are significant, but solvable, especially if they’re tackled early and with the right partners.

Whether it’s data sovereignty, security assurance, operational control, or compliance, governments need platforms that are sovereign-by-design, not just sovereign in name. And vendors need to step up with credible solutions that support national priorities without compromising cloud innovation.

Sovereign cloud is no longer a niche requirement. It’s a mainstream architectural model and one that will shape the next decade of public sector IT strategy.

Oracle Compute Cloud@Customer Isolated – Sovereign Public Sector Hosting for Oracle Partners

Oracle Compute Cloud@Customer Isolated – Sovereign Public Sector Hosting for Oracle Partners

Across Europe, public sector organisations are under increasing pressure to modernise their IT environments while maintaining full control over data, infrastructure, and operations. This is where Oracle partners can step in. With Oracle Compute Cloud@Customer Isolated (C3I), they now have the opportunity to offer sovereign cloud hosting services tailored to the needs of governments and regulated industries.

Oracle’s approach to digital sovereignty is not abstract. It is based on clearly defined principles that are embedded in the platform itself. With C3I, data – whether user data, metadata, or telemetry -remains entirely within the customer’s environment. Nothing is transmitted back to Oracle. The complete OCI control plane runs locally, fully disconnected from Oracle’s global infrastructure. This ensures that compliance requirements can be met without compromise.

Transparency and control are fundamental. There is no ongoing operator access to the system because C3I is an air-gapped, disconnected solution. Once installed, Oracle has no remote access to the environment. The installation and activation – including any expansion, such as GPU or storage racks – is handled on-site by Oracle’s field team. Ongoing operations, monitoring, and support are managed entirely by the hosting service provider (HSP), not by Oracle. Customers define their access policies, manage their own encryption keys, and control every layer of the platform.

Unlike traditional hosted solutions, C3I delivers the full Oracle Cloud Infrastructure (OCI) IaaS portfolio, along with key platform services such as Oracle Kubernetes Engine (OKE), all deployed within the HSP’s own data centre. This empowers Oracle Partners to offer modern, cloud-native infrastructure and container services to public-sector tenants, while keeping everything firmly under local control and governance.

What Makes C3I a Game‑Changer?

Besides OCI Dedicated Region, Alloy, and Oracle Isolated Cloud Region, C3I is Oracle’s most secure and sovereign cloud deployment model. One of the main drivers for adopting Oracle Compute Cloud@Customer Isolated is the need to run classified workloads in fully isolated environments. In this context, governments with strict regulations, ministries of defense, and intelligence services represent the key targeted customers.

What sets C3I apart is that its architecture is the entire control plane, the brain of OCI, is deployed inside the partner’s (or customer’s) premises. Again, there is no connection to Oracle’s public cloud regions, no shared management layer, and no external operator access. Once the system is installed, Oracle no longer has access. There is no remote telemetry, no persistent administrator credentials, and no automated updates. Every action, including patching, must be initiated and approved by the partner’s operators.

Despite its strict isolation, C3I delivers the same developer experience as the public cloud. Users can work with the same APIs, tools, and automation workflows. All core OCI services are available, from compute and storage to networking and IAM. This makes it possible to run modern applications, automate deployments, and enforce security policies. Just like in the public cloud, but with full control.

For Oracle partners, this opens new doors.

Hosting Multiple Tenants with IAM and Compartment Isolation

To serve multiple tenants on shared C3I infrastructure, Oracle relies on the strength of its Identity and Access Management (IAM) framework. Each tenant is hosted in a dedicated compartment, which acts as a logical and administrative boundary. Resources are isolated, policies are scoped, and access is strictly defined. IAM ensures that each tenant sees only what they are supposed to see and nothing more.

With compartments, policies, and groups, providers can implement fine-grained access control while still maintaining a clear operational model.

Oracle Compute Cloud@Customer Hosting Service Provider Model

On the networking side, Virtual Cloud Networks (VCNs) are provisioned per tenant. If connectivity is required between VCNs – let’s say, for shared services or for intercommunication – Dynamic Routing Gateways (DRGs) are used to establish secure and controlled interconnections. This approach allows for scalable, tenant-aware architectures without compromising performance or sovereignty.

C3I is Ready for AI – GPU Expansion Racks

C3I is not just built for traditional workloads. It is also designed to support next-generation applications, including those that require hardware acceleration. Currently, through dedicated GPU expansion racks, Oracle partners can add up to 48 NVIDIA L40S GPUs to a single C3I deployment. These GPUs are integrated into the system’s high-speed network and storage architecture, making them available to tenants just like any other OCI resource.

This capability allows Hosting Service Providers to offer GPU-as-a-Service directly to public-sector clients – ideal for AI, ML, and data analytics workloads that must remain within national borders. All resources are managed through the same local OCI control plane, keeping everything under the same compliance and operational framework.

The sensitive nature of government data demands absolute sovereignty. With Oracle C3I, sovereign AI becomes a reality.

Red Hat OpenShift Support

For Oracle Partners hosting public sector tenants on C3I, delivering enterprise-grade container platforms is critical. That’s why C3I fully supports Red Hat OpenShift, enabling end-customers to run their containerized workloads with confidence and flexibility.

OpenShift brings a comprehensive Kubernetes-based platform with advanced features like developer tools, integrated CI/CD pipelines, and robust security controls. By running OpenShift on C3I, customers benefit from a sovereign, isolated environment that meets strict regulatory demands, while leveraging the rich ecosystem and productivity of Red Hat’s market-leading container platform.

A Sovereign Platform That Grows With You

C3I starts with a strong baseline: 552 cores, 6.7 TB of RAM, and 150 TB of storage. But it doesn’t stop there. The platform can scale to 6’072 cores, 73.7 TB of memory, 3.65 Petabytes of high-capacity storage, and 1.2 Petabytes of high-performance storage.

Unlocking a New Business Model for Oracle Partners

For Oracle Partners, C3I creates a new type of service opportunity. Instead of simply reselling cloud subscriptions, they can operate a sovereign cloud environment, offering secure, isolated, and scalable hosting to public sector clients. It is a cloud environment you can trust, built for those who need to guarantee data residency and operational autonomy.

With C3I, Oracle provides the tools. Now it is time for partners to build the services.

Rethinking Digital Sovereignty – A Response to the Public Cloud Critique

Rethinking Digital Sovereignty – A Response to the Public Cloud Critique

I understand it, believe me. The public cloud promised a lot: speed, scale, flexibility. But over time, cracks have appeared. Bills grow faster than workloads and compliance becomes harder, not easier. And some applications never really fit, especially those that demand low latency or strict control.

So, we are told, companies are pulling workloads back from the public cloud. These reverse cloud migrations are also known as cloud repatriation. You have to understand, it is not a reversal of digital transformation and the abandoning of public cloud – it’s a correction. A realignment based on experience, governance needs, and financial pressure.

But the answer isn’t to go backward, if your expectations have not been met. The challenge is to retain the benefits of the cloud – automation, elasticity, operational efficiency – while regaining the control that is often lost in the public model.

But moving away from the cloud doesn’t mean giving up the cloud. The real question is: how do we keep what worked and fix what didn’t?

Oracle Compute Cloud@Customer (C3) was built precisely for that purpose. It brings Oracle’s public cloud infrastructure and tooling into your data center, under your governance, with the same APIs, security, and operational model. What follows is how C3 directly addresses the core reasons driving repatriation and why many enterprises are choosing a more strategic hybrid path forward. C3 changes everything.

Cost Control Without Surprises

Ask any IT leader what drove their move to the cloud, and chances are “cost savings” is on the list. Ask them what drove them back, and they will likely say “cost surprises.” 🙂

Public cloud can scale, but it also scales your bill. Between data egress fees, idle VM costs, and unpredictable licensing, many organizations find their cloud TCO spiraling. Oracle Cloud Infrastructure, Oracle Compute Cloud@Customer in this scenario, changes the equation. It delivers the OCI experience on-premises, in a consumption-based OpEx model, but with predictability built in. No data egress. No hidden costs. No guessing. Just clear, auditable resource usage within your own data center.

Performance Without Compromise

Latency is often a business risk. Trading platforms, AI inference, and high-speed transaction systems, they all demand millisecond or sub-millisecond responsiveness. But in the public cloud, compute and data are often separated across zones or regions.

With C3, you bring compute right to where your data lives. Ultra-low latency, high-throughput workloads no longer need to be shoehorned into far-off regions. The cloud comes to you and it is backed by high-performance storage, native GPU options, and OCI’s virtual cloud networking.

Data Sovereignty, Security & Compliance – Rebuilt for Reality

Oracle C3 provides on-premises infrastructure, fully managed by Oracle, but entirely controlled by you. Data never leaves your facility unless you allow it. Access is managed through Operator Access Control, which gives you precise control over who can log in, when, and for what. Encryption at rest, in motion, and during access? Built in. Full audit trails? Native. That is the level of control regulators expect and enterprises now demand.

Governance, Visibility & Control

One of the hidden challenges of public cloud? Shadow IT. Teams spin up services without oversight, leading to risks in compliance, billing, and security posture.

With Oracle C3, everything runs within the bounds of your governance framework. You control IAM, compartmentalization, policy enforcement, tagging, metering, and quotas. It is the same control plane as OCI, so your security posture doesn’t depend on where the workload runs.

Operational Resilience You Actually Own

Let’s be honest: handing over infrastructure management can reduce operational overhead, but it can also mean giving up visibility, scheduling flexibility, and recovery control.

Oracle Compute Cloud@Customer delivers the best of both worlds. Oracle manages the infrastructure lifecycle, from firmware updates to patching. But you define the maintenance windows, and the failover behaviour. DR scenarios, backup policies, hardware separation – they are yours to orchestrate.

What Is Operator Access Control?

Oracle Operator Access Control (OpCtl) is a feature used in products like Oracle Compute Cloud@Customer (C3) and Exadata Cloud@Customer, designed to give customers:

  • Explicit approval over Oracle’s administrative access

  • Time-bound, purpose-specific access windows

  • Comprehensive logging and session recording

  • Segregation of duties and multi-party authorization

So, before any Oracle operator can access the C3 environment for maintenance, updates, or troubleshooting, the customer must approve the request, define the time window, and scope the level of access permitted. All sessions are fully audited, with logs available to the customer for compliance and security reviews. This ensures that sensitive workloads and data remain under strict governance, aligning with zero-trust principles and regulatory requirements. 

A diagram showing your tenancy in an OCI region, and how it connects to Compute Cloud@Customer in your data center.

So, in practice, you can say:

“No one from Oracle can access my infrastructure unless I approve it, for a specific task, at a specific time.”

This is an excellent feature and tool for operational governance, auditability, and security assurance.

If you think about the U.S. CLOUD Act, then OpCtl, in my opinion, strengthens your legal and practical posture since you control the external access to the C3 systems. Additionally, you can provide proof and logs that no access occurred without your approval.

Let’s Think Differently. Give It A Try!

A Swiss professor recently outlined four conditions for digital sovereignty in the public cloud. The assumptions are valid, but they are also rooted in a narrow view of how the cloud has to work. If you want cloud, you have to give up control. And if you want sovereignty, you have to give up most of the cloud (services).

That binary thinking doesn’t hold up anymore. And it never should have. 

Let’s be clear: digital sovereignty is not about avoiding cloud, it’s about deploying it on your terms. And that’s exactly what Oracle Compute Cloud@Customer (C3) enables as a third path (besides public cloud and repatriation).

Let’s take the arguments one by one.

1. “Only unmodified open source software ensures sovereignty”

Yes, I agree, open standards matter. But sovereignty isn’t just about code transparency. It’s about control over where software runs, how it’s operated, and who has access.

With C3, you run any open-source stack you want, inside your own data center. But more importantly, you also control the platform it runs on. Compute, storage, and networking stay within your facility, under your governance. You decide the architecture, the patch cycle, and the integrations. And you do it without giving up cloud automation, elasticity, or DevOps tooling.

2. “Internal know-how must be retained”

Agreed. Sovereignty without competence is meaningless.

C3 supports the same APIs, SDKs, Terraform modules, and CLI as the Oracle public cloud. That means your teams build skills once and apply them everywhere – on-premises, in the public cloud, or across hybrid landscapes.

You keep operational knowledge in-house. You train on real cloud-native patterns. And you run them on infrastructure that belongs to you.

3. “Avoid proprietary, specialized services”

This is where things get nuanced.

Most enterprises don’t want to avoid modern services. They just want freedom of movement (aka portability). With C3, you are not locked into proprietary ecosystems. You get the full Oracle Cloud Infrastructure stack but deployed in your data center, on infrastructure fully under your legal and physical control.

Because the environment is API-compatible with OCI, you are not locked in – you are portable by design. Move workloads to Oracle public regions. Or any other cloud. Or don’t. It is your choice. I would call that leverage.

4. “SaaS without data export is unacceptable”

Right again. Exit strategy matters.

C3 isn’t SaaS. It’s IaaS and PaaS delivered as a service inside your firewall. And because you control the storage, the networking, and the OS stack, you always retain the ability to export your data by using open formats, standard tools, and your own access policies.

Want to back up to another system? Build cross-platform failover? Disconnect from Oracle entirely? No problem. Your data stays in your hands.

Final Thought

Cloud repatriation is happening for good reasons. But walking away from cloud entirely isn’t the answer. The better move is to rethink where the cloud belongs and who’s in control of it.

Oracle Compute Cloud@Customer gives you the cloud experience your teams want, with the sovereignty your business needs.

And today, that may be the one most strategic infrastructure choice you can make (besides Oracle’s EU Sovereign Cloud and Dedicated Cloud offerings).

If you are working in the public sector, have a look at this article: Enabling Public Sector Unity – How Oracle Alloy Could Power a Government Cloud and Cross-Agency Collaboration