🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - AWS European Sovereign Cloud: Your 20-Minute Essential Guide (GBL101)
In this video, Armin Schneider, a digital sovereignty specialist from Germany, introduces the AWS European Sovereign Cloud (ESC), launching by end of 2025 in Brandenburg, Germany. He explains the AWS Digital Sovereignty Pledge addressing data residency, operator access, and operational independence. The ESC features physical separation with independent governance through four new EU companies, dedicated IAM and DNS systems, and operations restricted to EU residents. Built on the Sovereign Requirements Framework, it ensures customer content and metadata stay within the EU, launches with over 80 services, and operates independently with its own root of trust, Security Operations Center, and billing system. The session details how ESC differs from commercial AWS cloud while maintaining full cloud functionality.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction to Digital Sovereignty and the AWS Digital Sovereignty Pledge
Well, hello, good evening everybody. My name is Armin Schneider. As you can see, I'm a digital sovereignty specialist out of Germany, and our topic today is giving a very quick intro on the AWS European Sovereign Cloud, which is upcoming very soon. The challenge is to do it in 20 minutes, but I'll try my best.
Before we get directly into the ESC itself, I think it's quite important to set some scene on why we did that, what the digital sovereignty landscape is, which kind of requirements we're addressing with this additional offering, and then also taking a deeper look on what the AWS European Sovereign Cloud is.
If you take a look at the landscape, we're hearing a lot of different things and they are slightly different across the world, but if you take them in a common scenario, we're talking about data residency, who has access to my data from an operator perspective, resiliency, transparency, and then fairly also very prominent these days the topic of independence and survivability. I mean, what does it take to be independent from whatever independence means, and I can tell you, in different places of the world you will have different opinions. Some people think the data needs to stay in their countries. Some people are lucky if the data leaves the country and is protected elsewhere. It's a different definition.
If you take those topics and we now group them a little bit in a vertical order here, we're basically putting together the data residency and operator access topic as kind of a data sovereignty. Where is my data? Who can access my data? And then on the right hand side we have the resiliency and independent stuff as operational sovereignty, summarizing it as digital sovereignty as a whole. This is a 10,000 foot view on what it is and there's very little nuances all over the place.
Based on this, about three years back exactly at this time, we made the statement of the AWS Digital Sovereignty Pledge, and it's basically really the promise from us to say people or customers should have control over the location of their data. They should have control over who is accessing their data. Encryption is a topic you have to address—encryption on transit, in use, or on the wire. And we also want to provide the highest resiliency of the cloud. That's basically the promise, and a lot of those things have been there before.
Looking into that a little bit from a timeline perspective, if you start from that angle here and you see 2022 there, we made basically the statement of the AWS Digital Sovereignty Pledge. During that time you can see quite a lot of things happened and they could be either announcing a new operational component, technology enhancement, or technology in relation to contracts. If I take a look at this one example here, at this angle we had the first attestation of our Nitro system, and the Nitro system for us in the sovereignty space is one of the core functionalities because it gives us this zero operator access capability as a design of the cloud at all, not just the AWS European Sovereign Cloud, but for the entire AWS cloud.
While we had Nitro started in 2018, we only came out with a third party attestation that there is no operator access almost five years later. One of the reasons is it's super hard to prove that something does not exist. But having said that, we made this assessment here, but at the same time we brought it into the service terms which made it a contractual statement from us. It's not just a paper thing, it's also part of your contract. If you go further down the line with the announcement of the AWS European Sovereign Cloud, and now at the end of 2025, you're basically seeing that we're looking quite close to the release of this.
Before we dig into the ESC itself, let's take a look at a few components because I think it's important. When we look to the left hand side, we think and we believe that the AWS cloud is sovereign by design. The ESC we will see in a minute is an additional offering with additional things you can get from us. But in the governance cloud, I mean you have all these things like control of your data, encryption, the zero operator access, all of those things exist today.
People in different places and different industries have different requirements. If we go a little bit to the next, in countries very specifically where we don't have a region in the country, a lot of requirements are coming from laws that certain data needs to stay in the country borders.
AWS Outpost is an option where you can put your data within the boundaries of your country or even in your own data centers if you want to. That is one option. Going further to the right, extending the sovereignty of the regular AWS cloud, if you go one step further, then you can look at AWS Outpost is not enough. I need more. I need more services. I need a much higher scale. We introduced the concept of dedicated local zones, which is a local zone but dedicated to a certain customer, typically a group of customers. But let's be honest, that is also quite a big investment in order to get to that. But it gives you the benefit that the resources are only for you and you can even have a certain say in which kind of resources and services we will provide.
So all of these options are shown here as an addition to the commercial cloud environment. Then the next offering on the right-hand side is the AWS European Sovereign Cloud. This is yet another option, and we will dig into it a little bit deeper. It is very well tied to European Union specific requirements, and these are requirements sometimes from highly regulated or public sector customers. We did quite a lot of extra components, but if you are aware of the components like we do in the GovCloud, you can think about some similarity even though there are differences compared to that. So let's dig into it.
AWS European Sovereign Cloud: Architecture, Governance, and Operational Independence
The European Sovereign Cloud is set to launch by the end of the year, so we are basically pretty close to it. It will be a physically separated region and the first region will be starting basically in Brandenburg in Germany, which is pretty close to Berlin. What we are doing here is really a complete new proposition as we call it with quite a lot of additional components. What is important to state, and we will dig deeper into it, is that it is not only the customer content that stays within a region. We are also creating all the customer-created metadata stays in the European Union. We do completely day-to-day operations with people from local entities which really need to be on the European ground. So it is really also a completely different operational model and we will dig into it.
How did we come to this? About three years back when we announced that we basically looked for requirements across customers and regulatory bodies all over the place on what customers require from us to satisfy certain needs. While there is not a common framework available yet across the European Union, we defined what we now call the Sovereign Requirements Framework, which basically captures all the requirements which are needed to design the European Sovereign Cloud. We will make this framework also available quite soon and it will be also part of our audit processes once the region is launched. So we are not just saying these are the requirements, we are also putting controls in place which are telling you with the evidence from an audit that we are taking those controls. But that is really the base of the design. We are having an independent governance structure, though I will talk about a little bit later on how that looks like.
One of the statements we also made is that we have designed this cloud for indefinite operation. I think that is a quite a strong statement because it is not saying it can survive a month or three months or six months. We are stating it is indefinitely operational under whatever circumstances. This requires quite a lot to do and that is what we see on the right-hand side. We really established a complete new route of trust. The whole certificate authority is separate. The top-level domains are separate. The IAM system is separate. So it really basically on a daily operation it has no dependency on anything else in the world. There is a replica to the source code available in case we need it, and there is also a dedicated Security Operations Center, so everything is basically operated out of its own infrastructure.
How does it look like from a governance perspective? We founded basically four new companies which are operating the European Sovereign Cloud. If you start on the bottom left, the infrastructure subsidiary basically owns everything from the physical perspective: the data center, the location, the networks, the cooling, the power. This is what we are doing in other regions as well, but it is an independent company running this. Then we have this part in the middle which is really service teams and people which are operating the European Sovereign Cloud independently, and this includes 24/7 technical support and technical account manager out of the European Union.
On the right-hand side, you can see a different company holding and owning our root of trust authority. There are not many people involved, as they truly own the PKI infrastructure. On top of this is the holding company, which has a managing director as well as an independent advisory board controlling the operations underneath. The concept of this model is that we have physically separated the European Sovereign Cloud from a network perspective. You cannot access it if you are not on EU ground. I could try accessing it from here, but it would not work. Everything is controlled by the management of these companies under European law.
We have also established an advisory board with memberships including non-AWS employees who receive full transparency. We are quite invested in this infrastructure because it involves both technology—network separation and independent stacks—and organizational aspects. This includes who owns it, who controls it, and who makes decisions. The people operating the European Sovereign Cloud must be EU residents and need to be located in the European Union for operational purposes. The European Sovereign Cloud will be open for customers all over the world and is internet-connected, but we as a cloud operator can only operate it while we are within EU boundaries and employed by one of those EU entities.
We have also made an announcement that this requirement will change in the future toward EU citizenship. So we are adopting that as well, though probably not right now. The key point is that we maintain full control of operations. We still use the same global code because we do not want to lose the agility of the cloud. We use the code base, but these teams control it, can stop it, and can roll back. They have full control of the operation.
Looking at the data perspective, customer content stays in the region you choose. This is true for the commercial cloud today—for 95 percent of our services, they are regional or zonal services. You select the region, and we do not transfer the data out. However, what potentially leaves the region by the nature of a global cloud is what we call customer-graded metadata. This could be namespaces, such as the name of an S3 bucket, which is a global namespace. If the name contains any sensitive data, which people advise against putting in there, it could potentially leave the region because it is metadata in a global partition.
Within the European Sovereign Cloud, everything stays in the European Union, which means it stays in that partition. Think of it as a new region similar to US East 1 in 2006. The data difference is really on the right-hand side. What you see on the left-hand side is also true. We are also seeing that while we have our own IAM system, we also have our own DNS system. These data like roles and permissions are independent and stay within the region of the European Sovereign Cloud. We also have separate billing for the European Sovereign Cloud, and people can choose to bill in euros if they want. There is a local billing system, so billing data does not leave the region.
Service Offerings, Partner Ecosystem, and Launch Considerations for the European Sovereign Cloud
If you take a look at this, I avoided using a slide where all the services are listed because it is not readable. However, if you go to this hyperlink, you will see we will launch a region with roughly over 80 services, which is more services than in any other new region when we launch them. I am saying this because the goal is for the European Sovereign Cloud to be a fully flavored cloud. We do not want there to be a limited cloud with a handful of services and limited functionality. It is really supposed to be a fully flavored cloud, and if you go to that link, you will see all the services we will launch with. As in any other region, there is more to come. We are building additional services and will also launch a roadmap.
But if you look into it, there's quite a strong number of services right away. This is also because in order to be a full global cloud, we have a huge number of already assigned launch partners. There will also be an independent marketplace because we want customers to have the capability to use offerings from the marketplace and use all those components they're accustomed to having there.
It's important to note that these partners are sometimes operational partners. Some partners are on the SaaS providers side, and there's quite a mix of all of them. However, there's a huge number of people also having the sovereignty competency. I think it's important to mention that we have put our sovereignty requirement framework and boundaries in place. But if a customer is operating on us and their customers are probably demanding a similar component, it doesn't help if you're just deploying your software on the sovereign cloud if your operational concept is not sovereign in what your customers are asking for.
That's where we're also looking into the competency component. We're still not forcing people. Whenever a customer is doing something on the European Sovereign Cloud, it is their responsibility. However, it's highly advisable to also look at those competencies because we believe if people make the decision to go to the European Sovereign Cloud because they have requirements, they should take it in the full picture.
Having said that, we also think people need to take a look at the requirements if they need the additional component of the European offering. This is certainly not a one-size-fits-all solution, and it's just an additional offering to what we already have in the commercial cloud, including things like Outposts and dedicated local zones. If customers say, "This first region is in Germany, but I'm in another state of the European Union and I want to have a dedicated local zone or Outposts connected to it," that's possible as well.
It could be an extension of the European Sovereign Cloud just as it is an extension of the commercial cloud. The general concept really is to have a full-flavored cloud with all the services and functionality, knowing that you can't make a one-to-one comparison on day one. The region is still supposed to launch by the end of 2025. We basically have not yet made an announcement on it, but we certainly will. The region will be available in general to everybody, which is also different from being tied to a certain group. Everybody can sign up for an account in the European Sovereign Cloud and create their own account.
Keep in mind there is a new IAM system, new accounts, and new organizations. The organizational structure and the governance structure needs to be replicated. If you're operating in both parts of the world, you also need to consider different IAM systems or your federation might go in both places. However, we are not allowing you to do an assumed role between regions by the nature of it. The same thing is true for networking. It's internet connected, but if customers want to use Direct Connect, there's a Direct Connect point of presence for the European Sovereign Cloud in parallel to Direct Connect because the network is purposely built separately from each other.
This is about the content on the slide. I will probably be around if there are questions, and other than that, thank you very much for your attention.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)