What the AWS European Sovereign Cloud can do – and what it cannot
As part of the Sovereign Data Summit, which forms part of the Silicon Valley Europe event, I met with Andreas Nissen, Senior Partner Solutions Architect for the Public Sector at AWS, for an interview. We spent 30 minutes discussing the AWS European Sovereign Cloud: what it really entails, what its limitations are, and what the Cloud Act has to do with it.
Here are the key points from our conversation.
The ESC is not simply a new AWS region
AWS has been operating its own regions in Europe for years: Frankfurt, Ireland, Stockholm, Paris and London. Customer data has therefore already been stored within the EU. So why launch a separate “European Sovereign Cloud” (ESC) now?
The problem until now lay with the metadata. Which users exist, what permissions do they have, what resources are available, how is billing handled – all of this was previously shared across regions. The ESC changes precisely that: metadata remains entirely within the EU, separate from the rest of AWS’s commercial operations.
This is not merely a technical measure. The ESC has its own data centres in the EU, its own staff based in the EU, its own German limited liability company (GmbH) as its governance structure, and its own billing system that charges in euros rather than dollars. Anyone switching from Frankfurt to the ESC must set up a new account: user management, IAM, billing – everything separately. There is no automatic migration.
What remains the same: the AWS APIs, the console and the services. Anyone currently running AWS workloads won’t need to learn anything new.
The Cloud Act – what’s true, what isn’t
The question comes up in every meeting with a client. And rightly so.
Under certain conditions, the Cloud Act allows US authorities to request data from US companies, even if they are based outside the US. That is a fact. But what does that actually mean?
Andreas answered this very directly in the interview: since 2020, AWS has not handed over any corporate or government data to the US government under the Cloud Act. Not a single case. Requests are subject to judicial review, there are high legal hurdles, and AWS actively defends against such requests.
Furthermore, the Cloud Act does not apply solely to US companies. European providers with a US presence are subject to comparable requirements. This is often forgotten in the debate.
One key finding we took away from the AWS & TD Synnex Partner Day: according to the AWS Transparency Report, only 0.6% of all government requests actually relate to content. The vast majority simply ask for account information, i.e.: “Who owns this account?” And the requests do not primarily come from the US, but frequently from Germany and India.
AWS publishes these figures every six months. That is also part of the strategy, but they are still real figures.
From a technical perspective, there is another key point: with the AWS Nitro system, AWS has introduced a zero-operator-access approach. AWS itself has no access to customers’ ongoing computations. What cannot be read from a technical standpoint cannot be disclosed either.
I recommend the linked AWS blog post, “5 Facts About the Cloud Act”, as a concise read on this topic.
When does the ESC make sense – and when doesn’t it?
The ESC isn’t the right choice for every workload. Andreas made that clear in our conversation, and I see it the same way with our customers.
The ESC costs more than Frankfurt. That’s due to the higher operational costs: EU staff, EU electricity prices, separate infrastructure. Anyone who sees the exchange rate risk associated with euro-denominated billing as an advantage can offset that, depending on the situation.
The service portfolio is already extensive at launch, but not every AWS service is available in the ESC. Some customers will continue to use Frankfurt for certain workloads and, alongside this, use the ESC for anything with higher sovereignty requirements.
The sensible approach: classify data. Which workloads require the ESC’s full metadata separation level, and which do not? That is what matters, not gut feeling or a blanket rule.
You can use the AWS Capability Explorer to check which services are available in which regions, including planned ESC enhancements.
Resilience is part of the same consideration
One point that came up in my conversation with Andreas, and which I believe is underestimated, is that sovereignty is often equated with data protection, but availability is just as much a part of it.
The ESC offers the same resilience concepts as Frankfurt: multiple Availability Zones, automatic S3 replication as a managed service, and backup and disaster recovery options. Anyone still running on-premises today and considering the cloud should factor this in from the outset, not as an afterthought.
Current status
The AWS ESC has been available since January 2026, with Brandenburg as the first region. AWS has announced an investment of just under 7 billion euros by 2040. The portfolio is growing, based on specific customer feedback.
Our position as eggs unimedia
We are a launch partner of the AWS European Sovereign Cloud, not because we sell AWS products, but because our clients – including BMW, Siemens and HUK-Coburg – run specific workloads on AWS and are grappling with precisely these issues.
Our approach: advising based on requirements, not on a product catalogue. For some clients, Frankfurt is entirely sufficient. For others, the ESC is the only way to move certain workloads to the cloud at all, as previous regions have not met their compliance requirements.
Links
- General information about the ESC: aws.eu/de
- 5 facts about the Cloud Act: AWS Security Blog
- AWS Capability Explorer (Services by Region): builder.aws.com
- ESC FAQ including independent auditing: aws.eu/de/faq