Sovereign US Cloud Models

What does Sovereignty mean for Cloud Computing?

Sovereignty models are designed to resolve the conflicts between the political and regulatory frameworks of cloud users and those of their cloud providers. These models aim to enable cloud users to remain compliant with European laws and regulations while leveraging the services of US-based cloud vendors. A key focus of sovereignty models is ensuring that data and workloads are safeguarded from access or interference by parties outside the jurisdiction of the cloud user. While many regulations emphasize the protection of personally identifiable information (PII), certain industries, regions, or business scenarios may require safeguarding additional types of sensitive information, including intellectual property (IP), software, trade secrets, financial data, and more. Given the diverse and region-specific nature of data privacy regulations, there is no universally agreed-upon definition of what a sovereign cloud must protect. Consequently, approaches to ensuring sovereignty often vary based on industry requirements, geographic location, and specific business needs.

US cloud vendors have taken different approaches to implement sovereignty, which are described on a conceptual level in the following. They are trying to achieve sovereignty in four dimensions:

• Data Sovereignty: the sovereign entity has full control over when and how data flows in and out of the entity.
• Technical sovereignty: the sovereign entity can take independent technical decisions and technical measures are in place, e.g. to ensure that data does not flow out of the sovereign entity.
• Operational sovereignty: the sovereign entity can operate the cloud without reliance on other parties and other parties cannot interfere with cloud operation.
• Legal sovereignty: the sovereign entity is a legal entity in Europe and respective European jurisdiction applies.

The US cloud vendors are using different models to fulfill sovereignity requirements. On a high level, four different models can be distinguished:

• Self-hosted cloud
• European partner
• Separate instance
• Sovereign boundary

Self-hosted Cloud

In this model, the cloud vendor provides their cloud software stack for operation by the customer. The customer is in full control of operation and of the technology. A downside is that the shared responsibility model a large part of the responsibility lies with the customer.

The self-hosted cloud model is an option with Oracle Sovereign Cloud (they are offering other models as well, e.g. the EU Sovereign Cloud).

European Partner

This model is used between Google and T-Systems as the European partner for the sovereign Google Cloud. It has been used by Microsoft and T-Systems for the Microsoft Cloud Germany between 2016 and 2020. Delos Cloud also falls in this category. Here, Delos is the European partner and Microsoft is providing the cloud software.

While this model is appealing from various perspectives, there are inherent challenges. On the plus side is an European company (with ownership also in Europe) that is “simply” running US software for the provision of its business. On a practical level, there are challenges, e.g. around troubleshooting (can the cloud software vendor access the system for troubleshooting? What are the procedures?), around transparency about what the software is doing, e.g. with regards to data protection and around software delivery. Is the software vendor able to push security fixes? What if not? How “up-to-date” is the sovereign cloud version?

Separate Instance

The Separate Instance model is similar to the European partner model, with the difference that the company providing the local cloud service is not a European (or European-owned) company but the US mother company. Sovereign operation of the cloud is done by European residents.

This model is being implemented by Amazon for the AWS European Sovereign Cloud. While questions around troubleshooting and software delivery process are less of a challenge compared to the European partner model, there is a question with regards to potential conflict-of-interest situations for the European personnel. The limitations of a separate region/instance are comparable to that of the European partner model. Compared to the European partner model, the Separate Instance can be regarded as softer, as ownership of the cloud instance and the operating personnel remain under the umbrella of the US parent.

Sovereign Boundary

Microsoft is trying a new approach with its Azure sovereignty model, where it delineates a sovereign area within Azure. The boundary is implemented on both a technical and organizational level within the “global Azure instance.” The intended advantage is that Azure users within the boundary are protected from non-EU judicial overreach while still being able to leverage and benefit from global Azure services. This approach is perhaps the hardest to implement. It seems easier to “simply” run a separate, isolated instance than to introduce clear, resilient, and provable boundaries within the cloud. Compared to other approaches, it may turn out to be the most versatile and flexible, but it is also the least robust. Its success may largely depend on how effectively Microsoft can convince clients that the boundary is safe and resilient.

Summary

The large US hyperscalers are taking different approaches to address sovereignty needs. Each approach has its unique position with regards to responsibilty/involvement of the client, complexity, access to “global” cloud services, and degree of physical separation. Ultimately all of them require a certain level of trust between the client and the hyperscaler and the respective jurisdiction.

Ultimately, you should ask yourself two simple questions:

1. Who owns it?
2. Who can press the kill switch?

plus the bonus question: “who gets the money?”