Three Clouds Don’t Make You Sovereign

Few concepts have experienced a rise comparable to Multi-Cloud in recent years. Hardly any strategic presentation is complete without architecture diagrams showing applications, data, and platform services distributed across multiple providers. The underlying message is usually the same: operating systems not exclusively with a single cloud provider reduces dependencies, increases resilience, and strengthens a company’s digital sovereignty.

The appeal of this argument is understandable. After all, the past few years have vividly demonstrated the risks that can arise when companies place central parts of their digital infrastructure in the hands of a few global providers. Discussions about the Cloud Act, geopolitical tensions, regulatory requirements, or the increasing concentration of technological power have led to the question of strategic dependencies being taken much more seriously today than just a few years ago.

Nevertheless, it is worth taking a step back at this point and asking a more fundamental question: Does using multiple cloud providers actually lead to more digital sovereignty, or are we perhaps confusing two concepts that are related but by no means describe the same thing?

Upon closer inspection, it becomes clear that a significant part of the Multi-Cloud debate is based on an assumption that is rarely explicitly stated. Namely, the notion that the number of providers used is directly related to the degree of technological independence of a company.

This assumption deserves critical examination.

Confusing Infrastructure with Dependency

When companies talk about lock-in, the focus is often on the infrastructure itself. They don’t want to be entirely dependent on AWS. They don’t want to run all systems exclusively on Azure. They want to avoid having their IT landscape determined by the decisions of a single provider.

This consideration is fundamentally understandable. However, it often falls short because it misidentifies the location of the actual dependency.

The binding effect of modern cloud platforms no longer primarily arises from virtual machines, network segments, or object storage. These components are largely standardized and technically relatively interchangeable. The actual coupling occurs where applications begin to deeply interact with the specific services of a platform.

Identity and access management systems, proprietary database services, messaging platforms, analytics services, AI offerings, or serverless runtime environments today form the actual core of many cloud architectures. The more tailored applications are to these services, the more challenging it becomes to further develop or migrate them independently of the respective provider.

The crucial question, therefore, is not how many clouds an application runs on. The crucial question is which components of the application are directly dependent on the proprietary capabilities of a particular platform.

A company can run workloads simultaneously on AWS, Azure, and Google Cloud and still be highly dependent on the strategic decisions of these providers. Conversely, an application can run entirely with a single European provider and simultaneously have an architecture that allows for a platform switch with manageable effort.

The number of providers initially only describes the distribution of infrastructure. It says surprisingly little about the actual degree of technological freedom of action.

Why Additional Clouds Don’t Automatically Create Less Lock-in

The discussion becomes particularly interesting where Multi-Cloud is understood as an instrument to reduce lock-in.

The underlying logic seems plausible at first glance. If dependency on one provider is problematic, using multiple providers should inevitably improve the situation.

In many cases, however, a completely different effect occurs.

Instead of mastering a proprietary ecosystem, companies suddenly have to understand, operate, and secure multiple proprietary ecosystems simultaneously. Different identity models, different security concepts, different automation tools, different network architectures, and different operational paradigms significantly increase complexity. With each additional platform, not only does the number of available options grow, but also the number of dependencies that must be managed permanently.

The crucial question, therefore, is not whether multiple providers are present. The crucial question is whether the underlying architecture is actually capable of switching between these providers.

It is precisely at this point that a remarkable discrepancy between theory and practice often becomes apparent. Many Multi-Cloud landscapes distribute workloads across multiple platforms without significantly increasing the portability of the applications themselves. The systems run in different environments but remain closely tied to the respective platform services. The result is a situation where the number of providers increases without the actual technological freedom of movement improving to the same extent.

In other words: The diversification of infrastructure is not automatically synonymous with the diversification of dependencies.

Why Kubernetes Alone Does Not Create Sovereignty

At this point, Kubernetes is often mentioned. And indeed, Kubernetes has significantly changed the discussion about portability.

For the first time, companies have a platform that can operate applications largely independently of the underlying infrastructure. Whether a cluster is run in a European data center, in a public cloud, or on its own hardware is of secondary importance for many workloads. This is precisely why Kubernetes is considered today by many organizations as the technical foundation of digital sovereignty.

However, here too, the actual problem is often oversimplified.

Kubernetes primarily solves the portability of workloads. It does not automatically solve the portability of the entire platform.

While running applications in containers, if proprietary databases, proprietary messaging systems, proprietary AI services, or proprietary identity platforms are used simultaneously, only part of the dependencies is reduced. The infrastructure becomes more interchangeable, but the platform services above it often do not.

The real challenge, therefore, is not to introduce Kubernetes. The real challenge is to consciously decide where in an architecture portability is strategically necessary and where a dependency can be accepted because its benefits justify the associated risks.

The Question Missing in Many Strategies

It is noticeable that Multi-Cloud initiatives often start with a discussion about providers, even though the more relevant question often remains unanswered.

Before deciding whether applications should be distributed across multiple platforms, it should first be clarified which components of one’s IT landscape are actually subject to a relevant sovereignty risk and what consequences a loss of technological freedom of action in these areas would actually have.

The answer to this is rarely universal.

Not every database automatically represents a strategic dependency. Not every specialized application requires the ability to migrate to an alternative platform within a few weeks. Similarly, not every use of proprietary services is problematic by definition. The idea that digital sovereignty requires the complete avoidance of all dependencies would be neither economically nor technically sensible.

What is crucial is the ability to differentiate between acceptable and critical dependencies. A consciously chosen commitment to a specialized service can be quite sensible, provided the associated consequences are understood and incorporated into long-term architecture planning. Dependencies only become problematic when they arise unplanned or their scope only becomes visible once regulatory changes, economic constraints, or geopolitical developments already create pressure to act.

Digital sovereignty, therefore, describes less the state of complete independence and more the ability to transparently understand technological dependencies, actively manage them, and maintain alternatives where their loss would become a business risk.

The Real Challenge

The idea that digital sovereignty can primarily be achieved by distributing applications across multiple cloud providers falls short. It focuses on the visible infrastructure and overlooks the much more relevant architectural decisions made above this infrastructure.

For companies, therefore, the decisive question is often not whether they use one, two, or three clouds. What is decisive is whether their applications, data, and operational models are designed in such a way that they remain capable of acting even when provider strategies, regulatory frameworks, or geopolitical realities change.

This is where digital sovereignty begins. Not with the number of logos in an architecture diagram, but with a company’s ability to maintain control over its technological options in the long term.

Digital sovereignty is not a product and not a procurement decision. It is the result of conscious architectural decisions. This is precisely where we support companies at ayedo – with open platforms, cloud-native technologies, and a clear focus on long-term technological capability.