Digital sovereignty: what the “sovereign” clouds of AWS, Microsoft and Google actually offer

Data residency is not sovereignty

The sovereignty debate gets muddled because three different things are lumped together under one word. It pays to separate them right at the start; otherwise vendor offerings cannot be compared sensibly.

• Data residency – where data is physically stored and where it is processed. It is addressed by choosing a region and by a policy that blocks other regions.
• Operational sovereignty – who operates the service, who has administrative access, who approves interventions, and whether the service keeps running if connectivity to the rest of the world is cut.
• Legal (jurisdictional) sovereignty – which law the provider is subject to and who can order it to hand over data or shut down the service.

The first two layers can be solved technically, and the hyperscalers have done a great deal of work on them over the past two years. The third layer is about ownership and law – and no configuration will change it.

What AWS, Microsoft and Google offer today

AWS European Sovereign Cloud

AWS chose the most radical route: a separate cloud. In January 2026 it opened its first region in Brandenburg as a separate partition, aws-eusc, with the region eusc-de-east-1, its own IAM and its own billing. Operations are to be handled exclusively by EU residents located in the EU, and sovereignty matters are overseen by an advisory board made up solely of EU citizens. According to AWS, the infrastructure is designed to keep working even if connectivity to the rest of the world is interrupted. AWS cites an investment of EUR 7.8 billion and has announced sovereign Local Zones in Belgium, the Netherlands and Portugal.

The separation comes at a price. A January 2026 analysis by the Cloud Security Alliance pointed out that at launch, IAM Identity Center and delegated administration in AWS Organizations were missing, only a single region was available, and the partitions are isolated from each other – data moves between regular AWS and the sovereign cloud over the internet or the customer’s own private links. CSA’s recommendation at the time was: start with a sandbox, keep deployments small, and don’t put critical applications there that cannot tolerate an outage. The list of services has been changing since then, so the current state must be checked directly in the documentation.

Microsoft Sovereign Cloud

Microsoft went the opposite way: instead of a new cloud, it is adding controls to its existing European regions. In an announcement from June 2025 it described three options. Sovereign Public Cloud applies to all workloads in European regions without the need to migrate and rests on two elements: Data Guardian (remote access by Microsoft engineers is approved and monitored in real time by Europe-based personnel) and External Key Management (keys in the customer’s own HSM or with a trusted third party). Sovereign Private Cloud builds on Azure Local and Microsoft 365 Local for hybrid or disconnected environments. The third option is national partner clouds – Bleu in France (Orange and Capgemini) and Delos Cloud in Germany (an SAP subsidiary).

The advantage is obvious: nothing moves, and the tools and services stay the same. So is the drawback: it is the same global Azure with added controls, not separate infrastructure.

Google Cloud

Google offers three tiers – Data Boundary, Dedicated and Air-Gapped. In February 2026 it described how, in the Dedicated option, the environment is fully controlled by a partner who can block software updates in exceptional cases; Google is not supposed to have remote access or the ability to shut down workloads, and the partner should be able to run the instance for up to 12 months after the connection to Google is cut. This option underpins the French PREMI3NS offering from S3NS, which according to Google has obtained SecNumCloud 3.2 qualification from the French agency ANSSI. The Air-Gapped option requires no connection to Google or to the internet at all.

The table summarizes the vendors’ public claims, not an independent audit. Before deciding on any offering, request the current list of services, contractual commitments regarding government requests, and audit reports.

The blind spot: the parent company’s legal reach

The most quoted moment of the whole debate came on 10 June 2025 (date according to the French Senate record; The Register gives 18 June). The Senate commission of inquiry into public procurement asked Anton Carniaux of Microsoft France whether he could guarantee under oath that French citizens’ data would not be handed over to US authorities without the consent of the French authorities. According to the record quoted by The Register, he replied:

Both halves of that sentence matter. The first confirms that contractual and organizational measures do not override a legal obligation. The second is a reminder that this is a risk with a low observed frequency: Carniaux also stated that since Microsoft began publishing transparency reports, no such request has affected any European company or public sector body.

Counterarguments worth stating fairly

• European law erects its own barrier. Article 32 of the Data Act requires providers of data processing services to take all reasonable technical, organizational and legal measures to prevent access by third-country authorities to non-personal data held in the Union where this would conflict with EU or member state law. A provider can thus find itself caught between two legal orders – and that is precisely why it challenges such requests.
• Encryption with your own keys changes what can be handed over. If the provider does not have the key, it can only hand over encrypted data. That, however, applies only to data at rest; once the service processes the data in plaintext, the protection is weaker.
• A European provider is not automatically more secure. A smaller vendor may have weaker security, a narrower service portfolio and poorer resilience. Jurisdictional risk is traded for operational risk.

What the EU is preparing and what already applies in Czechia

European regulation of cloud sovereignty is at the proposal stage, and readers should treat it as such.

• EUCS, the European cybersecurity certification scheme for cloud services, is on hold due to disputes over sovereignty requirements, according to an analysis by Clifford Chance. The revision of the Cybersecurity Act proposed by the Commission on 20 January 2026 envisages certification based solely on technical criteria – that is, without requirements such as protection against extraterritorial laws or limits on non-EU ownership.
• The Cloud and AI Development Act (CADA) is meant to address sovereignty separately. The Commission published the proposal on 3 June 2026. According to a summary by the law firm Wilson Sonsini, it introduces four assurance levels (the first based on self-assessment, the higher ones with an independent audit) and, for public authorities, a rule to use providers established in the EU, with an exception for third-country providers that meet level 3 and are controlled from a jurisdiction approved by the Commission. The proposal is at the start of the legislative process; Parliament and the Council may change it substantially, and it is premature to talk about deadlines.

The Czech public sector already has rules

Since 1 November 2025, public administration bodies have been subject to Decree No. 412/2025 Coll. (vyhláška č. 412/2025 Sb.) on security rules for the use of cloud computing. For the high and critical security levels, it requires customer data at rest to be stored exclusively on the territory of EU/EFTA member states. For the critical level, customer data and specific operational data are to be processed on the territory of the Czech Republic; outside it only with explicit written consent. And for all levels it requires an assessment of the risks arising from possible requests by foreign authorities for access to data.

The decree does not apply to private companies. It is, however, useful as a ready-made template: tiered requirements based on impact, rather than one rule for all data. Anyone supplying software or services to public administration will encounter it in tender documentation.

A decision framework: three questions instead of one

The question “are we sovereign?” has no answer. The following three do, and they can be broken down into concrete tasks.

1. What data and systems do you have – and what would their leakage or unavailability mean?

Divide your workloads into three or four classes by impact, much as the decree for public administration does. Typically it turns out that the vast majority of systems (websites, internal tools, development environments, routine operational data) need no special treatment. A narrow group – trade secrets, data regulated by sector-specific rules, systems for public sector or defense customers – deserves a stricter regime. Only for that group does it make sense to consider a separate partition, a partner cloud or a European provider.

2. Who holds the keys?

Encryption with customer-managed keys is standard today, but a key stored in a service from the same provider does not reduce jurisdictional risk. What makes a difference is external key management: an HSM you manage yourself or one held by a third party, with the ability to revoke access. Expect to pay a tax – higher latency, another critical dependency and the need to run it yourself with high availability. Losing the key means losing the data. So deploy external keys only for the class of data that justifies it.

3. How quickly can you leave?

An exit plan is the cheapest form of sovereignty, and it also helps against price increases or a service being discontinued. It rests on infrastructure described as code, containerized workloads, backups in open formats outside the primary provider, and a list of the proprietary services your applications depend on. The law is on your side: under Article 29 of the Data Act, from 12 January 2027 providers may not charge any fees for the switching process. The regulation will not, however, remove technical lock-in to managed services. How to write infrastructure code so that it stays portable is covered in the article on Infrastructure as Code security.

What to do on Monday

Data residency can be enforced right away and almost for free. In AWS, for example, with an organization policy that denies regions outside the EU (global services must be exempted, otherwise IAM, among other things, will stop working):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideEU",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "sts:*",
                  "route53:*", "cloudfront:*", "support:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["eu-central-1", "eu-west-1", "eu-north-1"]
      }
    }
  }]
}

Treat the list of exemptions and regions as a starting point and test it on a non-production organizational unit before rolling it out. In Azure, the built-in allowed locations policy plays the same role. Further baseline controls for AWS are summarized in the article on AWS cloud security.

When a sovereign offering makes sense and when it doesn’t

On the other hand, it doesn’t pay to move the whole company into a separate partition just because the topic is in the news. You will pay with the migration, duplicated tooling and slower access to new services, and you still won’t solve the third layer – ownership of the technology. For ordinary workloads, putting order into what is already running brings more: clear ownership, controlled access and code instead of manual changes. Without that, you cannot reliably say even where your data is today, as described in the article on infrastructure chaos.

One more limitation of this recommendation: it does not apply to organizations whose data residency or provider is prescribed by law. There, the decision is not made on the basis of risk considerations, but on the text of the regulation and the regulator’s interpretation.

Key takeaways

• Three layers, not one. Data residency and operational sovereignty can be solved technically; the legal reach of the parent company cannot.
• The offerings differ in their model. AWS built a separate cloud, Microsoft adds controls to existing regions, Google hands operations over to partners. Each model carries a different migration cost.
• The risk is real, but narrow. Microsoft did not rule it out before the French Senate, while also stating that no such case has occurred with European companies or the public sector.
• The European rules are not finished. EUCS is stalled, CADA is a fresh proposal. The Czech public sector already has tiered rules in Decree No. 412/2025 Coll.
• Order of steps: data classification, region enforcement, keys for the most sensitive class, a tested exit plan. Only then the choice of a “sovereign” product.