🦄 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: From concept to reality (SEC201)
In this video, Colm MacCárthaigh and Addy U introduce the AWS European Sovereign Cloud, a physically and logically separated cloud infrastructure operated exclusively by EU citizens in the EU. They explain AWS's sovereign-by-design philosophy, including data residency controls and regional isolation. The European Sovereign Cloud features enhanced data residency for customer-created metadata, operational autonomy, independent governance under AWS European Sovereign Cloud GMBH, and a dedicated European root certificate authority. With a 7.8 billion euro investment in Brandenburg, Germany, it offers end-to-end euro pricing, no dependencies on non-EU infrastructure, and includes source code within EU boundaries for indefinite operations. The session covers the Sovereign Reference Framework, compliance acceleration, and clarifies that it targets public sector and regulated industry workloads requiring additional sovereign controls beyond standard AWS regions.
; 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: A Unique Project Bridging Two Continents
Good morning. Welcome to day 3 of Reinvent 2025. Hopefully everybody's having a great Reinvent so far. My name is Colm MacCárthaigh. I'm a Vice President and Distinguished Engineer at Amazon Web Services. I've been at AWS about 18 years, and for the last few years it's been my job to lead the design, build, and delivery of the AWS European Sovereign Cloud, which we're going to talk to you about today. It's a unique project for me. I've never worked on a project that's involved so many different aspects of my background.
As you might be able to tell from my accent, I'm proud to be an EU citizen. I was born and grew up and lived in Ireland for a long time at a time when the European Union made an enormous difference to the modernization and development of Ireland. I also moved to the US to work for AWS, and I'm proud that I became a naturalized US citizen, so I've got a foot on both sides of the Atlantic. My technical background and career actually started in public service. I worked at a publicly owned agency in Ireland serving government departments, serving citizens and end users inside other government agencies.
I've lived across Europe and spent a long time living in the Netherlands. I've worked on pan-European projects like CERN, and as a developer, my focus has always been on privacy. When I write code, I'm writing encryption software and virtualization software, which are both key technologies that allow us to work with data in ways where we can't see the data. I've never had a project that's involved all of these different aspects until working on this, so for me it's been fun.
With me today is also my colleague Addy. Hi, thanks, Colm. Hi everyone. My name is Addy U, and unlike Colm, I'm not an EU citizen, but I have been there plenty of times for the border control to recognize me by my name and also have figured out my favorite bakeries in the EU. I'm a Principal Product Manager on the EC2 team, currently working on digital sovereignty and the AWS European Sovereign Cloud. Please excuse me for my voice. It's a little hoarse. I don't know what's going on with the air in Vegas, but hopefully we'll have a great session today. Take it away.
Thanks, Addy. So today we're going to dig into why sovereignty matters and how we think about sovereignty at AWS, not just in the context of the European Sovereign Cloud, but in the context of all of our existing commercial regions too. We'll dig into our sovereign-by-design patterns, and then we're going to talk about the differences with the European Sovereign Cloud, why we've built it, what's different, help you decide whether you should use it or not, and hopefully we're going to leave you with some key takeaways that will let you make that decision and then what to do as next steps if you're going to use and run on the AWS European Sovereign Cloud.
Sovereignty Without Compromise: Protecting Nations While Delivering Full Cloud Power
So let's start. In my opinion, sovereign nations and international unions like the European Union are no understatement of humanity's greatest accomplishment. They literally lessen wars, conflict, and famine. It's hard to do better than that in the development of all human society. They're a pinnacle of human achievement. But anything that can get tens or hundreds of millions of people united behind one flag to any degree of common identity and common purpose is just amazing.
Even though those nations and international unions foster collaboration between countries, there are still matters that have to be protected to safeguard that sovereignty. There are still rivalries and even enmities between countries and unions. So for a certain class of workloads and a certain class of sovereign customers, we face enhanced requirements that dig into security, autonomy, and continuity in particular, and how do we safeguard those so that we can reassure our sovereign customers that no matter what's going to happen, the workloads that they need to serve in that way are always going to be protected.
At a high level, our philosophy for our sovereign customers and the way we want to serve those customers is that they should have all the control they need, but without any compromises. Too often these customers are left stranded on relatively small deployments, on-premises legacy infrastructure, or small-scale systems that have subsets of services and features that force these customers to make trade-offs. They often do that because they need really tight control around the systems, but ironically, it can actually backfire and lead to eroding sovereignty. The most realistic day-to-day risks that these customers face are just ordinary security risks: breaches, phishing attacks, malware, and ransomware attacks.
Think of headlines and examples where government agencies, health departments, and police departments have been taken out for days or weeks at a time because of cybersecurity issues. Sometimes those issues are triggered by foreign actors. Often behind these attacks and breaches are criminal gangs who are sometimes state-sponsored, state-sanctioned, or at least state-tolerated by foreign states. Despite all of this work to protect sovereignty, citizens' data still ends up in the hands of adversaries. Because we've seen that, we wanted to be able to offer our customers our full offerings. We want them to be able to use all of our services at our full hyperscale without any compromises. We want them to have access to our fine-grained security policies, our always-on security monitoring, our integrated backup and restore, and all of those things that make day-to-day risks go away.
The Scale Advantage: Bringing Hospital-Level Capabilities to Sovereign Customers
But we still want them to have all of the control that they need so they can be reassured about all of the other aspects of sovereignty. When I say the full power of AWS, it can be hard to convey what that means. Many of our sovereign customers are used to relatively small-scale systems with a few servers or a few racks in a closet in an office building, or maybe a cage in a colocation facility that has a few racks. But at AWS, our scale is vastly different. The data centers and availability zones that we build are the size of IKEA stores, just full of servers. When we're building services, they have unparalleled scale. Think of a system like S3, with just massive storage capacity, or a system like EC2, with incredible compute flexibility and agility.
There aren't that many analogies I can use for this, but one I do like to use is to think of a modern research hospital. This is the Leiden University Medical Center. I used to live in Leiden, so as far as I'm concerned, this is Europe's premier hospital. If you were to drill in on any one department in that hospital, you'd see it's a marvel. They have a world-class cardiology facility or a world-class medical school. Each of those on their own takes an enormous breadth of experience and expertise, and also requires constantly running logistics. Think of the pharmaceutical and blood products that constantly have to be supplied. Think of all the cleaning that just has to happen to keep everything sterile, constantly happening. Each one of those departments is a world-class facility on its own.
But even more powerful is that they're all brought together in one place. That means the hospital can be a tier-one trauma center. If someone is in a critical accident with injuries to different parts of their bodies, they can all be treated in that one place. Or if they have a complex disease, the same thing applies. That's the kind of power we want for our customers. We don't want them to have to make trade-offs because of scale or subsets of features. We want all of our marvels like S3 and EC2 to be there so that customers can build workloads as complex as Amazon.com or as leading-edge as their own foundational or fine-tuned machine learning models. We want to be able to deliver all of that with no compromises directly, even to our sovereign customers.
Actually, today we deliver most of our public sector business and most of our sovereign customers in our normal commercial regions, and that's still going to be the best place for many of those customers. We're actually able to give them the controls they need for most workloads there. What's becoming even more important for these customers is that sovereign and government customers almost universally have their own national or international regulations, compliance laws, and so on to comply with. We've gotten clear feedback from customers and regulators over time that this needs to be easier and easier. When I talk to regulators across Europe, they're pretty much all understaffed and have backlogs of workloads that need to be certified. So anything that we can do to help simplify that story is a huge accelerator for customers and can speed up adoption.
Sovereign-by-Design: How AWS Built Regional Independence from Day One
That's something else we tend to have to do a little differently for sovereign customers. Our design philosophy from day one at AWS has been to make our systems sovereign by design. So what does that mean? We built AWS twenty years ago, and our first region was in Northern Virginia in the US. When we were building our second region, which launched in 2008 in Ireland, our first region in Europe, we faced an important decision to make. Would we just make it a seamless extension of our existing infrastructure,
When designing our infrastructure, we faced a fundamental choice: would we make it a seamless extension of our existing infrastructure, or would we show the seams and treat it as quite different infrastructure? In the seamless model, a customer could store data in Northern Virginia and then access it directly in Ireland. This gives you flexibility and allows you to move workloads between regions more easily. Many of our competitors chose this engineering design, and many other clouds work this way, where data and compute can migrate between locations.
However, we chose a different path based on feedback from our customers. We heard that data residency and jurisdictional boundaries were incredibly critical. When a customer puts data in a particular AWS region, it stays there, and we don't move it. The customer moves that data if they want to copy it to a different location. This ensures it's always clear what jurisdiction the data is in.
As we designed our technical systems, we also paid key attention to our exposure to customer data. We love hosting customer data and serving customer workloads, but we don't want to see that customer data, and we don't want to see inside their workloads. It's not our business. We want to focus on our business, and so we're allergic to that data. We actually call it radioactive. We don't want to touch it, we don't want to see it, and we want shields between us and it.
In our core architectures, like the AWS Nitro System for EC2 or KMS, which protects the keys that encrypt all your data, we've built them in such a way where the customer can use our services and enjoy the experience of AWS, but we have no technical means to access their data. This is really important. The seams and the walls between our regions go even higher. We actually operate every AWS region almost entirely independently. If you look at the EC2 service running in Northern Virginia, we have a separate copy of the EC2 instance running autonomously in each region in Europe and elsewhere around the world. This is important not just for digital sovereignty, but also for availability, redundancy, and resilience. If we have a problem in one region, we don't want it to cascade or have knock-on impacts in other regions. We want customers to be able to get all of the benefits of using multiple regions.
We have more regions than ever, and we're always building more. We have almost 40 regions publicly and commercially available today, and always have more on the way. All of these regions come with sovereign-by-design controls. Most of our public sector workloads and sovereign workloads run in these regions today, and all of those controls and compliance processes we have are able to accommodate them in existing regions.
However, sometimes we face needs that go far beyond this, where it's not just that the customer needs to be reassured that we can't see the data, but they need to be reassured about other things like who's operating it and what the legal governances are. This is not the first time we've faced these issues or done something like this. In the US, we've long had US GovCloud, which we build for US government customers and which is operated exclusively by US citizens. We also have some other dedicated sovereign clouds. We have a cloud in China that's dedicated for our Chinese customers and Chinese business and is operated very separately. We have a good track record. We know how to take full hyperscale infrastructure and build it in a way where we can achieve the highest levels of sovereignty separations and get into not just the data sovereignty that our customers need, but operational sovereignty and all of their government's controls.
Creating the Bubble: Technical Architecture of the European Sovereign Cloud
That's what we're doing with the European Sovereign Cloud. The really short version is we're building a completely dedicated, physically and logically separated cloud infrastructure just for Europe, run exclusively by EU operators in the EU with no external dependencies on non-EU infrastructure or personnel. Now, because each region is already isolated, the question is: what are the technical differences and where does it start? Let's drill in on those.
We do have a handful of services that we call global services that actually operate either in front of our regions or are centralized in some way in one particular place. The first example here is billing and usage. Many of our customers might use two or forty regions, but they only want to get one bill. So we aggregate all of the billing and usage data and centralize that in one place.
We generate one bill every month, and that's how our customers get their bills. Our identity and access management has some components that are global. The actual authentication and security happens in each region, and we're doing it in really smart, clever ways where the credentials used are actually specific to each region. This way, we still get all of that nice regional separation. But for consistency, we do allow customers to define their users, accounts, policies, permissions, and organizations once. Those can be defined in one consistent place and reused across all of the regions.
Services like Amazon Route 53, which is a DNS service, are global because DNS is an intrinsically global system. The world only has one DNS, and DNS is often used to serve customers from different regions. A customer might use DNS to say they want their European users sent to a European region and their US customers sent to a US region. So it has to sit in front of regions and outside of that concept of a region. Those are global services, and you'll see how we're building versions of those dedicated to and specific for the European Sovereign Cloud.
Inside our regions, services like EC2 and S3 that I mentioned are regional, so we're running full autonomous copies of those services. When I'm calling EC2 in Ireland, my request never leaves Ireland. In Paris, it never leaves Paris. In Frankfurt, it never leaves Frankfurt, and so on. That's true for almost all of our services. That's our default design pattern, very strong. I'm actually telling a little bit of a white lie here because if you were to drill in even further, you'd see that those services are actually zonal under the hood. Our regions are made up of availability zones of different data centers. Those availability zones are spread across an area about the size of a city, and services like EC2 and S3 have redundant, resilient infrastructure in each of those availability zones so that we can maintain and offer our customers very high availability.
The very short technical version of all this is that for the European Sovereign Cloud, it's like we're putting a bubble around everything, not just our regional services, but even the global ones too. We're building full dedicated, isolated copies of those with dedicated EU staff to serve them. We'll get into more detail in a bit, but for the next section, I'm going to hand over to Addy, who's going to introduce you to the AWS European Sovereign Cloud.
Inside the AWS European Sovereign Cloud: Infrastructure, Governance, and Operational Autonomy
Let's dive deep into the AWS European Sovereign Cloud. We pre-announced our plans to build the AWS European Sovereign Cloud back in October of 2023 based on decades of AWS experience in running, operating, and building multiple independent clouds for the most critical and restricted workloads. The AWS European Sovereign Cloud is going to be located in the state of Brandenburg and is established under a parent German company. It is a net new partition, which is physically separate and independent from the rest of our regions at AWS. It features its own identity and access management and billing stack.
Let me break down what that means. How many of you use more than one AWS region today? When you do that, you realize you get one bill which consolidates all of your spend across these regions. You also end up using one account to access all these regions. With AWS European Sovereign Cloud, that's going to change. You will have to create net new accounts in order to access the services that we provide for the AWS European Sovereign Cloud, and you will get a separate bill for this region.
In addition to these aspects, the AWS European Sovereign Cloud also provides enhanced data residency. With AWS, customers have always been in control of their data. They decide where the data gets stored and who has access to it. With the European Sovereign Cloud, we've gone one step beyond in providing enhanced data residency, which means that not just customer content but also customer-created metadata will stay within the EU. Customer-created metadata is defined as the metadata that customers create to manage their resources in the cloud. I'm talking about resource labels, tags, configurations, and so on. All of that is going to stay within the EU.
Apart from independent infrastructure, the AWS European Sovereign Cloud will also provide operational autonomy.
This means zero operational control from outside of the EU. All of the operations of the European AWS Sovereign Cloud will be done by EU citizens who are AWS employees and are located in the EU. This covers everything from the infrastructure layer where you have data center operations to service operations to day-to-day operations and also customer support. We are right now transitioning to ensure that the European Sovereign Cloud is exclusively operated by EU citizens. During this transition period, we will work with a blended model that includes EU residents as well as EU citizens until a certain period of time.
Some other key characteristics of the AWS European Sovereign Cloud include an independent governance structure. For the AWS European Sovereign Cloud, we have established new entities and have established independent governance, which I will go over in a few minutes. The second characteristic is around indefinite operations. When we have been working backwards with customers, one of the key themes that emerged was around survivability. The use case that kept coming up was that customers want to make sure they can sustain their operations despite a geopolitical crisis, a technical failure, or even a natural disaster. In order to address that, AWS has been committed to ensuring continuous operations. With the AWS European Sovereign Cloud, we have ensured that there are no critical dependencies on the infrastructure side from outside of the EU. Additionally, we are committed to ensuring that customers are able to deliver continuous operations even in the most extreme circumstances.
To deliver on that commitment, the third thing I want to talk about is that we have made sure a copy of the source code for the services that are required to run the AWS European Sovereign Cloud are also sitting within the boundary of the AWS European Sovereign Cloud. We are also introducing the Sovereign Reference Framework with the AWS European Sovereign Cloud. This framework helps translate the sovereignty requirements into auditable controls. These sovereignty requirements are a function of what we have learned from our customers and regulators, and they are guided by industry-leading frameworks. They help identify and communicate to customers and partners a consistent way to understand how the sovereignty requirements map into auditable controls and how they are designed, implemented, and also independently audited. It is basically a framework of legal, operational, and technical controls all coming together.
We are also going to be establishing a dedicated security operations center, and for the first time we are also introducing a dedicated European service trust provider for the European Sovereign Cloud. What that means is that this dedicated European trust service provider is going to be in control of issuing key certificate materials and certificates within the EU. In the event of a disconnect, this particular entity can autonomously still continue to issue certificates within the EU. The key takeaway from here is that everything you need to operate the AWS European Sovereign Cloud is in the EU, from the talent, the technology, the infrastructure, and the leadership. Coming to leadership, let me walk you through what the governance structure of the European Sovereign Cloud looks like.
We have established a parent German company, AWS European Sovereign Cloud GMBH. This is going to have its own managing director, Stefan Israel, who joined us recently, and we will also have a security officer as the manager of this parent company. Both of these roles will be EU citizens located in the EU. We are also establishing an advisory board with the AWS European Sovereign Cloud, and the advisory board is entitled to act in the best interest of the AWS European Sovereign Cloud. The composition of the advisory board is going to include four members, of which three of them are Amazon employees, and we are also going to have one independent member who is not an Amazon employee.
The purpose of the advisory board is to ensure that the sovereignty expectations we have set with the AWS European Sovereign Cloud are held, and secondly, to ensure accountability for all of the sovereignty controls that we are bringing in with the AWS European Sovereign Cloud. The European Sovereign Cloud will also have its own sub-entities. The first one is the infrastructure entity, then there is research and development, and the third one is the trust certificate subsidiary, which will be responsible for issuing trust certificates in the EU for AWS European Sovereign Cloud.
With AWS European Sovereign Cloud, you will get an end-to-end euro pricing experience. This means that all of the services offered as part of the European Sovereign Cloud will be priced in euros, including our other pricing models such as savings plans and support plans. The pricing calculator will also display all of your quotations in euros. Customers will have the choice to pay in any of their preferred currencies from the 18 that we support today. It is still built on all the same pricing principles of AWS—you pay as you go. The European Sovereign Cloud is the first globally available region where we are offering a non-USD denomination apart from China, and this is where we are delivering an end-to-end pricing experience completely in euros.
We have an enormous list of backend systems that operate autonomously inside the European Sovereign Cloud. Think of the badge and access systems that people use to get into buildings, email, and all sorts of backend and corporate systems that we have had to localize for the European Sovereign Cloud. Let me double-click into some of the services we are building in the European Sovereign Cloud that customers get to see and interact with. We have our trust services provider where, for the first time and I believe it is a world first, we are operating a dedicated European root certificate authority. Our operators have gone through everything it takes to operate a root certificate authority in Europe. We have built the secure physical infrastructure, conducted key signing ceremonies, and completed all of the training and certification processes. When you run a load balancer or a CloudFront distribution, or if you need an SSL certificate for your own EC2 instance, that comes directly from our trust provider in the European Sovereign Cloud, and that can continue day to day.
We also have a dedicated DNS service inside the European Sovereign Cloud. We are building a dedicated version of our Amazon Route 53 service directly inside it. If you create a domain today on Amazon Route 53, you might notice that we host it on four name servers, and if you look closely, those four name servers are hosted on different top-level domains. One ends in .com, one ends in .net, one ends in .org, and one ends in .co.uk. That is actually for our own resilience and redundancy. If any of those top-level domains have a bad day, we do not want our customers to be impacted. However, none of those domains are hosted in the EU. In our version in the European Union, in the European Sovereign Cloud, we are actually using European domains. Those name servers are hosted on .eu, .de, and so on. That is how deep we have to go to ensure we really do meet that commitment that there are no technical or operational dependencies outside of the EU.
The European Sovereign Cloud also has its own dedicated network and backbone. The links that connect our data centers and availability zones are all managed inside of the European Sovereign Cloud. We also have dedicated Direct Connect locations that are going to be part of the European Sovereign Cloud. It also has its own dedicated internet connectivity. We are doing a best of both worlds approach. We are connecting the European Sovereign Cloud to the global AWS backbone, so we will have fast, low-latency, high-reliability, always-encrypted connectivity to all of our other regions, and on a day-to-day basis, that is what it will use. But we also have dedicated backup connectivity and separate transit connectivity from European providers so that if the AWS backbone were unreachable or went away for any reason, the European Sovereign Cloud could still operate fully autonomously.
We have a dedicated security operations center inside the European Sovereign Cloud with security staff and a dedicated security leader who have full supervision and access to all of the security monitoring that we run inside our regions and everything it takes to run proactive response to any risks and threats that emerge. All of this helps us achieve compliance obligations. We want it to be easy and rapid for customers to be able to certify their workloads to run inside the European Sovereign Cloud. One of the reasons why customer-created metadata stays inside the European Sovereign Cloud is so that customers no longer need even those trivial administrative data exceptions that they sometimes require. Stuff like that is dramatically simplified in the European Sovereign Cloud.
For the first time, and based on consultation and working with regulators across Europe, we are documenting all of our sovereignty controls rigorously. We have an exhaustive list of everything we have done, how the control works, and why it was done that way. We provide evidence-based processes that we use with regulators to show that compliance control works. This is designed to accelerate compliance. Feedback from regulators across Europe has told us that they greatly appreciate any kind of acceleration that we can do there. It makes a big difference for how quickly our customers can adapt.
Investment in Europe: Partners, Target Customers, and Best Practices
With that, I will hand you back to Addie, and then I will be back for the end. Thank you. AWS has always been committed to Europe and its digital goals and ambitions, and we have always been making sure that we are investing heavily in the EU. The AWS European Sovereign Cloud represents the continued AWS investment in Europe. The EU has the single largest group of our engineering teams for AWS outside of the US in our development centers in Dresden, Dublin, and Berlin. Some of our core services like AWS Nitro and CloudWatch are actually built from the other side of the pond, which is pretty interesting.
The AWS European Sovereign Cloud represents an investment of 7.8 billion euros, and we are making sure that we are committed to contributing to the social and economic fabric of the EU by investing heavily. We are ensuring that we are building skills, talent, and technology for the EU to really compete at a global level and global scale. Moving on to partners, partners and AWS have always been a winning combination. They provide an immense amount of value delivery because they are the closest to our customers in understanding their workloads and use cases. We will have a bunch of partner offerings on the AWS European Sovereign Cloud as we get ready to launch. The idea here is to ensure that with the help of these partner offerings that are going to be offered on the AWS European Sovereign Cloud, customers can actually leverage the depth and breadth that the AWS Sovereign Cloud brings with itself.
Who is this AWS European Sovereign Cloud exactly for? The AWS European Sovereign Cloud is targeted for customers in the public sector as well as regulated industries. What I mean by that is that the AWS European Sovereign Cloud is for customers and workloads that are not yet on the cloud because of any sovereignty concerns or reasons. This is a good segue into one of our best practices, which is that it is important to establish and understand what your use case is and what type of workloads you are thinking about bringing onto the AWS European Sovereign Cloud. It is not like you want to migrate everything from our existing regions onto the AWS European Sovereign Cloud because they still offer the same compliance and standards that are industry leading. The idea here is to really think and be thoughtful about the kind of workloads and the additional sovereign controls that warrant these workloads to actually move to the cloud only on the basis of what is needed or what is required of them.
The second best practice is the need to qualify instances. It is the same APIs and the same AWS goodness that we are offering with the AWS European Sovereign Cloud. However, we are always continuously and rapidly improving our hardware. All the instance types that we launch, we try to launch with new instance types in our regions.
The idea here is that we highly recommend that if you want to play around or get into the AWS European Sovereign Cloud, you do thorough testing and make sure that you're qualifying the instances. The third best practice is around reserving capacity for business continuity. What we would like to happen is that you don't think of the AWS European Sovereign Cloud at the last minute just because there is a concern around continuous operations. What we would like to recommend is that you think about this in advance as you're thinking about your workloads and your use cases to determine when is a good time to reserve capacity and ensure that you are thinking ahead of a scenario which could be of concern to you or your customer.
Addressing Hard Questions: Legal Compliance, Threat Models, and Getting Started
Having said that, I'm going to now hand this over back to Colm because I'm sure you have a lot of top-of-mind questions and hard questions that come with the AWS European Sovereign Cloud. Thanks, Addy. Across Europe, I've been talking to a lot of customers, partners, systems integrators, and end users, and there are some common questions that come up that we want to make sure we can leave you with answers as part of this presentation. One question that comes up often is whether the AWS European Sovereign Cloud is subject to the Cloud Act. If you haven't heard of the Cloud Act, that's actually a US law that standardizes how cross-jurisdictional legal requests, law enforcement investigations, court orders, and so on are handled rather than having hundreds or thousands of police departments or judges make it up on their own each time. There's a standardized process for this that goes through policies and procedures. We've got a great blog post called "A Better Approach to the Cloud Act" that we put online a few months ago, and I encourage you to search for "AWS Cloud Act." You'll get that blog post, and it will give you all the detail on it, bust some common myths about the Cloud Act, and explain how it works and how it actually doesn't work.
One key takeaway I want you to have from that blog post is that when we build systems that have no technical means for us to access data, then we have no means to access that data. The one thing I would add, in addition to everything we've already put in that blog post that's specific to the AWS European Sovereign Cloud, is that all of the operational control rests entirely in the European Union. Only those EU operators have any control or permissions over that infrastructure. It's clear at all times that EU laws apply to those operators and to those operations. A very similar question also comes up: what about other lawful requests and orders, including from European governments and police agencies? The answer is the same. If we've built systems that mean we have no technical means to access data, then we have no means to access that data. All of our processes here are highly standardized, and again, the only folks with operational control or permissions over this infrastructure are EU operators in the EU. So it's clear at all times that EU law applies.
Another common question we get is whether sovereign customers usually have to worry about the kind of threats that I call movie plot threats, because you normally would see them in a movie. They'll ask questions like, what if one of your employees is a spy? Or what if they're the target of some international espionage? What if they're the victim of some international targeted campaign, which could be as simple as phishing to get to the wrong administrator, or as complex as a nation-state-sponsored custom malware attack? At AWS, we've long considered these kinds of insider threats just part of our basic threat model. We assume that all of these things can happen, and then we design accordingly. What that looks like is multi-person approval for sensitive actions and always-on pervasive monitoring and detective controls. We've got many layers of this and a lot of defense in depth. This isn't something we talk about much in public, and we don't go into detail about how those systems work, but we do from time to time do reviews with government security agencies.
One of my favorite meetings was actually with one of these customers where we did a really thorough review and analysis. We showed how all of these layers work and how we've actually got sophisticated systems that are looking for suspicious activities. We're getting immediate reports about even innocuous things like typos just because they look unusual, and it's always on. Their feedback was that about half of what we've done would be enough, that we had just done overkill.
And that's what we want to hear. This is the type of controls we intentionally want to make sure we very rigorously invest in. We're able to make investments and developments that typically go far beyond what a customer can do themselves in legacy on-premises environments or smaller scale infrastructure. We're simply able to go much more deeply than they are. So we tend to have a really great story here.
Another question we hear a lot from sovereign customers is: what's our approach to business continuity planning? Well, the design for the AWS European Sovereign Cloud, our region in Brandenburg, follows normal, very resilient, highly redundant patterns. We're building our data centers with redundant technologies inside them. We separate our data centers into availability zones so they can't be vulnerable to the same natural disasters and events, and all of that comes as standard.
In addition to that, in the European Sovereign Cloud, because we have dedicated EU operators who are running the cloud on a day-to-day basis, we have that additional layer of business continuity too. You can imagine that if, for any reason, Europe or the European Sovereign Cloud were somehow separated from the rest of the world or from the US, the European Sovereign Cloud would just keep running indefinitely. There are no known expiries or deadlines or anything in there that would stop functioning. It would just keep going.
The really short version of this is that the European Sovereign Cloud is what we've built in Europe, by Europe, for Europe. To double-click on that "by Europe" part, as Addy was saying, we developed key systems like the AWS Nitro system in Europe. It's actually developed in Dresden and in Berlin. Or take the CloudWatch service, which is developed in Dublin, Ireland. Beyond that, we actually have about 5,000 builders in Europe, many of whom will be able to support the European Sovereign Cloud, so we have an enormous amount of talent and capacity in Europe.
Many of these people were part of the design, build, security, and isolation plans for the European Sovereign Cloud. We're not just designing and building these things; we're also testing them in Europe. We've tested that we can actually isolate and separate the European Sovereign Cloud and that everything continues to work. That's really important.
Hopefully you've gotten a sense now of the distinction of what kind of sovereign customers and workloads might be most suitable for the European Sovereign Cloud. Typically, it is critical infrastructure, very critical systems, systems that go beyond the sovereignty levels that we're able to offer in our commercial regions. If you're interested in building in the European Sovereign Cloud, the best thing to do right now is to talk to your account manager.
It's actually possible to start building already in the sense that we're using the same APIs and same features and services that are available in any other AWS region, the same SDKs and so on. From a technical perspective, there should not be any barriers or much difference in terms of how to build for the European Sovereign Cloud, and applications should be highly portable.
If you want even more detail, we've put out a full list of initial services that are going to be there on day one. We also have more services that are landing after that. Even on day one, we're going to have our AI and ML services such as Bedrock. We've also got a very detailed white paper which dives deep into how the European Sovereign Cloud works, and we have details on our controls and governance structure that we've published and made available for all of this. Just go to our website. It's really easy to remember: hewest.au. That's where you'll find all of our material, in particular for the European Sovereign Cloud.
We've been building this, and our launch is imminent. We know that we are still building the plumbing, building the infrastructure layer. The European Sovereign Cloud is still cloud infrastructure, and what I personally get the most excited by is when I come back to re:Invent a year or the year after that. I'm really hoping I can hear stories of what customers have actually built on top of the European Sovereign Cloud, because I'm always humbled by the benefits that they've been able to deliver to actual end users and customers.
In particular, I'm hoping we're able to make a real material difference in the risk profile that these customers face to ordinary day-to-day threats of breaches from malware and ransomware and so on, that can plague those kinds of on-premises environments. So with that, thank you very much for coming and listening to our talk about the European Sovereign Cloud. We'll be around outside if folks have additional questions. Enjoy the rest of re:Invent. Thank you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)