AKA: Are you sure you want to read this?
Okay - so this isn’t my typical technical approach to blogging. This topic is regulatory heavy - unavoidably so if you’re to understand and navigate it. You have been warned :).

Intro

You might have noticed the world feels slightly less keen on being stable and predictable. Geopolitics, trade, and national interest are clashing more openly. Cloud computing is an area where we see some of the downstream consequences as a result. The ‘Cloud’ has a truly global presence, and so perhaps it’s unsurprising that it isn’t immune from politics. Companies like AWS made it possible for organisations of any size to start small and grow rapidly to a huge global scale - “reach your clients wherever they are” - that wasn’t by magic. It was because the cloud went global.

The cloud, being global by design, blurred many traditional boundaries. In doing so it made possible faster innovation and global reach to anyone with a good idea and the will to act on it. It also quietly blurred some legal and jurisdictional boundaries.

Over the past 10 years, laws like the CLOUD Act and before that, the PATRIOT Act, have forced business leaders and their legal teams to contemplate some uncomfortable, but legitimate, questions. e.g. “Who can access my data, and under what circumstances?”.

Some of these laws create the possibility that their corporate data, user data, or intellectual property held by a US based service provider, could be subject to a lawful access request from US legal authorities. Potentially without the client knowing.

Companies like AWS have offered strong assurances that they’ll challenge overreach and advise any clients when this happens if they’re legally permitted to. And they provide strong mechanisms to protect your data from unauthorised access, e.g. Nitro, which we’ll take about later. See “How does AWS handle Law enforcement requests?” in their CLOUD Act FAQs.

But AWS don’t need me to fight their corner. They have a few more resources than I have to throw at that.

Either way, Sovereign Cloud is here. It’s up to us as IT professionals to understand what that means for us, our employers, clients, and their users.

In this blog I’ll look at what Sovereignty is, what it’s not - and how to avoid common missteps, e.g. that data residency equates to digital sovereignty. It doesn’t.

Sovereignty

The Oxford English dictionary defines Sovereignty as…. no, that would be awful. :)

Digital Sovereignty is about a few things.

• Control - which outsiders can impact you, derail your business, or access your data?
• Jurisdiction - which legal systems have authority over your data, applications, and services?
• Auditability - who’s done what, where, and when - and can I prove that to auditors?
• Security - how do I protect my data and access to my systems?
• Accountability - who am I answerable to? Users, regulators, shareholders, etc
• Residency - where is my data located?
• Operations - who manages, operates, and maintains my systems?

You might be thinking, some of those overlap. Yup. The factors that contribute to Sovereignty do overlap somewhat.

So think about it this way:
If your important data is classified correctly, you know where it is and it’s confined to where you want it to be, you understand how to control access to it, you can audit who’s had access, you know who you’re subject to in terms of regulatory bodies & compliance frameworks, who needs access to your systems, who has access to your systems, then you’re in a good position.

If you answered positively to those then you’re well on the way to understanding what Sovereignty is, and which aspects apply to you.

What Sovereignty isn’t

Data residency (location) is not Digital Sovereignty. It’s likely that some clients will ask for Sovereign solutions when in actual fact, they’re really concerned about data residency and security. Helping those clients understand the difference between where data can be stored and secured (Residency) and who can legally compel access (legal Jurisdiction) is a difference to be understood.

Make my solution fully Sovereign - retrospectively
If a client states that they want to keep their existing solution but “make it Sovereign”… that’s not necessarily impossible, but it’s tricky. Sovereignty is a design time decision. To achieve the best possible sovereign posture for your solution, the design needs to factor in the Sovereignty objectives and address each where possible. (good luck with Supply Chain Sovereignty).

I want to increase my Sovereignty without compromise
For some clients, the appeal of being sovereign and independent from foreign owned companies will be appealing.

EU Sentiment

I won’t spend time talking about the Schrems II ruling, but I’d recommend having a look into that for some context - it gets to the heart of some of the trust issues that are at the centre of the CLOUD Act, conflicting national interests, and the EU position on the subject.
Suffice it to say, the EU have been concerned for some time about their belief that a lack of equivalence exists in data protection laws between the EU and US, and this creates risk for EU based organisations using US based cloud providers.

On the point of trust — it’s an important distinction to make, but the European Commission created the EU Sovereign Cloud framework because the EU considers foreign legal reach to be a risk that could undermine things like GDPR, not because it distrusts cloud technology.

Organisations that are subject to foreign legal obligations, such as the US CLOUD Act, may be viewed through a sovereignty lens as presenting a potential avenue for legal overreach.

Enter the EU Cloud Sovereign Framework

It’s no surprise then that the EU decided to produce a framework that helps organizations assess their current sovereignty posture and to provide some clear guidance and metrics in the form of the EU Cloud Sovereignty Framework.

What does the framework define

It’s definitely worth reading the framework, it’s actually very concise considering what it is, but in the meantime, I’ll summarise here:

SEAL scores

The document explains the concept of SEAL scores - Sovereignty Effectiveness Assurance Level.
There are eight contributing ‘Sovereignty Objectives’, and a related formula that accounts for different weightings, that provide the inputs for calculating the SEAL score of a platform or solution.

Sovereign Objectives (the factors)

• Strategic Sovereignty - This assesses the supplier’s ownership stability, governance influence, & alignment with EU Strategic priorities.
• Legal & Jurisdictional Sovereignty - Evaluates the legal environment, exposure to foreign authority, & enforceability of rights.
• Data & AI Sovereignty - Focuses on how data and AI services are secured, protected, controlled, where they’re located, and where they’re processed from.
• Operation Sovereignty - Assess the ability of EU based organizations to support, patch, maintain, service, and evolve a technology or solution independent of non-EU control.
• Supply Chain Sovereignty - Evaluates the geographic origin, transparency, and resilience of the supply chain, with a specific focus on the extent critical components are or aren’t controlled by the EU.
• Technology Sovereignty - Considers the degree of transparency and independence in the technology stack. Can EU organizations, operate the technology, audit it, and evolve it without lock-in to foreign owned systems.
• Security & Compliance Sovereignty - Assesses the extent to which security operations, compliance obligations, and resilience are controlled within the EU, without reliance on foreign jurisdictions.
• Environmental Sustainability - This assesses the autonomy & resilience of cloud services over the long term in relation to energy usage, dependency, and raw material security. (aka - can you be Sovereign if you’re not energy independent and someone else can switch off the lights?)

The framework goes into more detail about some of the specific examples and criteria they look for and assess in each of those factors. At this stage I just wanted to give you some relevant context to frame the Hyperscaler response, where it works and where it doesn’t.

Hyperscaler response

I’ve stated outright that I personally operate in the AWS arena - other hyperscalers are taking this seriously too - but I’ll talk about how AWS are now facing up to the sovereignty challenge in the EU.

Enter EU AWS Sovereign Cloud.

AWS first announced plans for their EU Sovereign Cloud business in October 2023. In January 2026, following €8 billion investment, AWS formally announced general availability of its EU Sovereign Cloud located in Germany.

“The AWS European Sovereign Cloud is a new, independent cloud for Europe entirely located within the European Union (EU), designed to help customers meet their evolving sovereignty requirements.”

AWS conceived and built the EU Sovereign Cloud to be “Sovereign-by-design”. AWS have worked with various EU organizations to gather the needs of clients who are interested in Sovereign Cloud. In that sense it’s a genuine attempt at a purpose built Sovereign Cloud. You can see the thought that’s gone into that when you look at service availability. For example, at the time I write this there are only two Foundational Models available in eusc-de-east-1 under Amazon Bedrock - ‘Nova Lite’ and ‘Nova Pro’.
Is that just taking time to roll out services and features, or is it regulation making vendors think carefully and seriously about risk, compliance, & governance?

If you’re already familiar with AWS, then EU Sovereign Cloud won’t initially look any different. In many respects it looks and behaves like any other AWS Region. As with AWS Regions, there’s variation in number of Availability Zones (eusc-de-east-1 has two), variation in service/feature availability, and pricing differences.

The sole purpose of AWS’s investment in the EU Sovereign Cloud is to offer, as close as is achievable, a truly sovereign platform for the EU. In their words, from the

Does it manage that? Let’s look first at how AWS’ EU Sovereign cloud measures up to the framework:

Strategic Sovereignty

AWS EU Sovereign Cloud is owned by “AWS European Sovereign Cloud GmbH”, a German registered company - who are themselves 100% owned the US based Amazon. Although, the AWS EU board is entirely based in the EU though and comprised of EU Citizens. This means they’ll be able to get involved in EU initiatives, and they’ll be able to sustain the service in the EU even if the US government did something unthinkable like instructing Amazon to stop offering services in the EU. AWS have made some pretty firm and public commitments here, saying:

“AWS established an independent advisory board for the AWS European Sovereign Cloud, legally obligated to act in the best interest of the AWS European Sovereign Cloud. Reinforcing the sovereign control of the AWS European Sovereign Cloud, the advisory board will consists of five members, all EU citizens residing in the EU, including at least two independent board members who are not affiliated with Amazon. The advisory board will act as a source of expertise and provide accountability on sovereignty-related aspects of the AWS European Sovereign Cloud operations, including strong security and access controls and the ability to operate independently in the event of disruption.”

Therefore, compared to AWS Public Cloud, AWS EU Sovereign Cloud offers a significant improvement in this regard, but it wouldn’t score as highlight as truly owned EU organization with no ties or ownership outside of the EU.

Legal & Jurisdictional Sovereignty
AWS have done a good job of keeping the “AWS European Sovereign Cloud GmbH” entity at arm’s length. Physically and logically isolated from wider AWS. All staff are EU residents, and the board are entirely EU citizens. AWS state in their Sovereign Cloud overview that:

As part of the technical design, access to the AWS European Sovereign Cloud physical infrastructure and logical system is managed by Qualified AWS European Sovereign Cloud Staff and can only be granted to Qualified AWS European Sovereign Cloud Staff located in the EU. AWS European Sovereign Cloud restricted data will not be accessible, including to AWS employees, from outside the EU.

So only AWS staff employed in the EU have any sort of access.
Is that enough to say there isn’t a loophole that means the FBI can’t petition AWS in the US to get at data? It appears that would require compelling EU employees to brake local law, which doesn’t seem likely.
Truthfully - I think we’ll need to see this tested in the courts to know whether this is as robust as we hope or not, but we might be waiting a while…

The CLOUD Act has resulted in zero disclosures of AWS enterprise or government customer content stored outside the U.S. to the U.S. government, since we started reporting the statistic in 2020.

Data & AI
AWS EU Sovereign Cloud offer a lot to assure clients in this respect, whether on AWS EU Sovereign Cloud or AWS Public Cloud. There are strong controls in places to allow clients to secure access and auditing to their data to a high degree. Factor in things like AWS Nitro which provides strong isolation between tenants. In fact, Nitro Isolation prevents anyone other than the client accessing instances - even AWS Staff have no access to customer Instances. Nitro offloads networking, storage, and management functions to dedicated hardware, it significantly reduced the attack surface of the Hypervisor, and all admin access is prohibited.
AWS EU Sovereign Cloud is independently audited and verified to various compliance standards - including attestations for Nitro.

Operational Sovereignty
AWS EU Cloud staff is entirely comprised of EU residents, and AWS have committed that this will be EU citizens located in the EU shortly. No non-EU residents will have access to the EU Sovereign Infrastructure.

Who clients choose to support the solutions they deploy on EU Sovereign Cloud is entirely in their control - but AWS have closed the door on this one.

Supply Chain Sovereignty
Okay. This is a difficult one to check and satisfy. The EU framework refers to a few aspects of supply chain including where key components are manufactured. But it doesn’t clarify what it means by key.
Think of all the devices involved in a typical solution (regardless of where it is) - cpu, PSU, motherboards, network cards, storage devices, adapters, cables, switches, firewalls, gpus, etc - and how many chips and electronics in each of those?

I couldn’t find much clarity in AWS published material on this point. AWS does publish Supply Chain Standards which includes relevant information - but it’s quiet on where components come from.

My personal belief is that this is a complicated topic even for behemoth organizations like AWS - and the reality is the growing demand for full digital sovereignty shines on a light on an interconnected, complex, global supply chain - which means this is currently an extremely difficult lens to be viewed as Sovereign.

Organizations will have to make individual decisions about how far they progress in this direction, or except their partners and suppliers to.

Technology Sovereignty
Transparency, auditability, and avoiding proprietary lock in is the objective here. i.e. Are you using software that can be transparently audited? Can you influence the direction of the code. Could someone else prevent you using that code?

Many AWS services are based on Open Source software, or software that has functional Open Source equivalents, and lock-in is something to be managed anyway when deploying to a cloud - but there are ways to manage that so you’re not entirely dependent on a cloud platform - especially for containerised workloads.

But AWS in the USA are still responsible for the upstream code. So even though the EU is independent in some ways, it’s still seen to be reliant on the US entity for that upstream code.

Again, Organizations will have to decide on the right balance of convenience and compliance in terms of transparency, and whether the improved independence of the AWS EU Sovereign cloud is sufficient.

Security & Compliance Sovereignty
AWS have traditionally done well in this space. The AWS EU cloud is no exception. It has the same security and permissions models as the AWS Public Cloud. e.g. IAM, Organizations, SCPs, etc - but is regionally scoped, implemented, and operated.

Services like Amazon GuardDuty & Security Hub are partially available - some features are on tap today; others planned for the EU Cloud. Check Builder Centre for service/feature availability in eusc-de-east-1.

Amazon Nitro enables no operator access - coupled with no access to anyone outside the EU - this is a strong position for AWS EU Sovereign Cloud.

Environmental Sustainability
AWS do well here also. AWS have a strong message on circular economy, energy efficient data centre, and sustainability. They’re on track to meet targets to be water positive by 2030 and net-zero carbon by 2040.

This is an area that’s weighted lowly in the EU framework though - at only 5%.

AWS EU Sovereign Cloud vs AWS Public Cloud

How do the two platform compare then?
As already pointed out, where a service exists on EU Sovereign Cloud, it’s

Feature / usage comparison

At a high level some of the differences appear quite quickly:

Sovereignty Effectiveness Assurance Level

The formula to calculate SEAL Scores is explained in the EU Sovereign Compliance Framework - refer to that for details. To my mind scoring is subjective to a point You can review the framework, review the platform capabilities, and decide how close you feel there are or aren’t and score accordingly.

I won’t show my working here for various mandated commercial reasons - but I’ll share the outcomes. My personal opinion after consideration resulted in me viewing the platforms to be:

• AWS Public Cloud - SEAL 2
• AWS EU Sovereign Cloud - SEAL 3

Final thoughts

The AWS EU Sovereign Cloud is a strong option for clients with strong Sovereignty requirements, but it isn’t the right choice for everyone. It’s not a one-size-fits-all solution.

Given AWS prices usually fluctuate by region, it’s difficult to accurately compare the cost difference with EU cloud. I deploy in eu-west-1 & eu-west-2 a lot, so I compared with my costs there and found the price was in the region of 15-20% more in eusc-de-east-1. That’s enough to be noticed and given the improved Sovereignty posture over AWS Public cloud, that feels reasonable to me. It also feels just high enough that it’ll help AWS clients decide if they want improved compliance, security, and data control (which they could likely do in their existing environments) or whether they really need a full sovereign platform.

The highest SEAL rating is ‘4’. I think as we see other platforms being assessed - 4 will be awarded rarely. The framework doesn’t easily allow for that in a global economy with global supply chains.

Both AWS Cloud and Sov Cloud lose points in ‘Strategic’, ‘Supply chain’, and ‘Technology’ sovereignty objectives.
However, AWS EU Sov cloud does significantly improve the position on ‘Legal & Jurisdictional’, ‘Operational’, & ‘Data & AI’ sovereignty objectives.

The small caveat is that the scoring of these is somewhat subjective (hence I stressed above my personal opinion) and clients will decide themselves what they need. It’s our job to understand the differences, articulate those, and design & build accordingly.

Additional Resources

• EU Cloud Sovereignty Framework
• Five facts about how the CLOUD Act actually works
• Overview of the AWS EU Sovereign Cloud

This post is part of my AWS technical blog series. Found this helpful? Connect with me on LinkedIn or check back here for more AWS content and discussions.