AWS Launches European Sovereign Cloud: What You Need to Know and What You Need to Do

Amazon just launched the European Sovereign Cloud. It’s an important milestone, but enterprises need to know the limits.

On January 15, 2026, Amazon Web Services opened up their brand new European Sovereign Cloud. Now since I find consistently spelling ‘sovereign’ nearly as hard as spelling ‘bureau’ I will refer to it using the official acronym, ESC (insert your own escape joke here).

The ESC is a tremendous advancement; creating a version of AWS that is hosted, run, and managed completely by Europeans. Although it’s still under overall control of Amazon in the United States, there are guardrails in place to reduce the geopolitical risks of cross-border ownership.

There is a lot to unpack here. This information is based on Amazon’s release post, this post by CSA Contributing Analyst Chris Farris, and Chris’ hands-on testing on launch day. We’ll be doing a lot more testing in the coming weeks to support our members, and we expect to see rapid updates as AWS migrates more existing features into the ESC.

 

What is the European Sovereign Cloud?

The ESC is a new Partition within Amazon Web Services that is located in the EU and managed by dedicated European entities. The objective is to help European customers meet data sovereignty requirements by keeping both the control plane and data plane of AWS in Europe, run by Europeans.

Here is how AWS describes it, “The AWS European Sovereign Cloud represents a physically and logically separate cloud infrastructure, with all components located entirely within the EU.”

 

What’s an AWS Partition?

In AWS a Partition is a completely physically and logically separated and isolated management plane. There are no connections between partitions. Think of it as a complete version of the AWS software stack running on its own hardware, in its own datacenters, totally separate from any other AWS partition.

The main partition is called, shockingly, “AWS” and is the global commercial version of AWS we are all familiar with. GovCloud, China, the secret intelligence community, and now the ESC are examples of other partitions. They can talk to each other over the Internet, but nothing else overlaps.

 

What makes it “sovereign”? How is this different from the EU region?

AWS already has regions all over the world, but they all rely on the same management/control plane that is located in the United States. Some services, like IAM and Route53, are only located in the US. This means that there are always US ties, even when you’re trying to run only in Europe.

The ESC has no ties to the United States (beyond corporate ownership). Everything runs and stays in the EU, to help meet European sovereignty requirements.

From AWS: “The AWS European Sovereign Cloud and its Local Zones provide enhanced sovereign controls through its unique operational model. The AWS European Sovereign Cloud will be operated exclusively by EU residents located in the EU. This covers activities such as day-to-day operations, technical support, and customer service. We’re gradually transitioning the AWS European Sovereign Cloud to be operated exclusively by EU citizens located in the EU.”

 

Who owns and manages the ESC?

Amazon, a US company, still owns the ESC. However, “The infrastructure is managed through dedicated European legal entities established under German law.”

Chris covers the structural and political implications really well in his 2025 post, The tl;dr is that although AWS does own it, the legal, technical, and managerial structures in place strongly isolate ESC from US influence, even with the CLOUD Act.

 

So it’s safe for Europeans to use without worrying about meddling from the US?

Yep. And if you dig into the weeds of the technologies AWS uses (especially their Nitro hardware), you can see strong technical controls for isolation and privacy on top of the management and employment structures. It’s pretty fascinating stuff if you’re into secure enclaves and confidential computing.

 

How many regions are there?

Just one for now, and initial expansion into other EU member states will be via Local Zones.

 

Uh… what’s a Local Zone?

It’s an extension of an AWS region into a different physical location.

Okay, so a region is usually a collection of datacenters in one geographic area (e.g. us-east-1 is in Virginia). Within a region are different Availability Zones that are separate hardware/buildings using their own network/power/etc. A Local Zone is primarily for latency and typically doesn’t support the full array of services that an AZ does.

Local Zones (once released) will help with country-level data residency requirements, but only for the supported services (mostly EC2 and VPC).

 

Are all AWS services available in the ESC?

No. Not yet. Most of the major services are available (e.g. EC2, S3, Bedrock, Lambda, etc.). The updated list is maintained at this link.

It’s enough I feel confident building there and it includes all the services I tend to use. Well, almost. ESC lacks CloudFront, which could be a game stopper for some of you. That will be available in Q4.

 

Does the ESC have all the same security and governance features?

Not yet. And one of these in particular will be very annoying until it’s released.

The ESC supports AWS Organizations, but lacks many of the capabilities we use for cloud governance. I’ve been told Service Control Policies are supported even though they didn’t show up in the matrix. Delegated administration is not supported, which means you will need to run Organizations services like CloudFormation StackSets from your Management Account, which isn’t ideal.

Most of the core security tools are available, including GuardDuty, Config, and Security Hub (including Security Hub CSPM). Amazon Inspector, for workload scanning, is not available yet. S3 Block Public Access is available, but not enabled by default like it is in the AWS partition.

GuardDuty is limited compared to the AWS partition, lacking Organization-level management and a bunch of the more-recent capabilities.

This isn’t great, but keep in mind that AWS doesn’t need to write this code from scratch, they just need the time to migrate it into the ESC, test, and release. I suspect we will see a very rapid pace of feature additions.

The core AWS security features, including the Nitro architecture, KMS, IAM, and security groups are all available. ESC is MORE secure than AWS was for many years, even without all the features of all the security services.

 

So Rich, what’s the big annoying gap you mentioned? It’s something IAM, isn’t it?

Yep. No IAM Identity Center.

So, if you aren’t up to date on handling identities in AWS, IAM Identity Center is the modern way of managing identities and access centrally for an AWS Organization. You hook in your identity provider and then assign out which users have access to which roles in which accounts. This is one of those Day 0 features we use when creating a new organization.

This will be the most painful of the missing features.

 

Okay, so how do I manage access without IAM Identity Center?

The hard way.

IAM still supports adding an Identity Provider, which is a connection to an external IdP. The issue is, you need to do this for every AWS account in your organization individually, and there is no central visibility. Also, it’s harder to manage switching personas, and there’s more friction for users to swap accounts or easily obtain session-based Access Keys for command line and API access.

The main issue is for command line users. To assume a role you need to have a trusted principal to start with. When using IAM Identity Center, this is based on your login. Without IAM Identity Center, you either need to use an IAM User with evil static credentials or you have to use a specialized command line tool that will work with your identity provider product.

Yeah, we know what most users will do. Access Keys are the biggest source of AWS account compromises, so I really hope IAM Identity Center is supported ASAP.

 

Since this is a separate Partition does that mean my app will stay up if us-east-1 goes down again?

YES!

However, our resilience rules still apply. Because these are isolated Partitions all data synchronization involves paying to move your data over the Internet (or your private network connections). It’s going to increase your costs, but unlike going multicloud you don’t need to redesign your architecture. And if you are good with your Infrastructure as Code you can write it in a way you can easily migrate and deploy into different Partitions.

 

What else do I need to know?

I’m writing this post on Day 1 of the launch. A lot will change very quickly as new services and features come online. We’ll also likely find some more sharp edges, but nothing that we haven’t seen before.

Heck, when we first launched the CCSK+ Labs here at CSA, IAM didn’t even exist! Yep, everything was root access!

There are also some fun aspects to a new region. Various industry friends have already been running around snapping up S3 bucket names like “amazon.s3.eusc-de-east-1.amazonaws.eu”. That’s right, hundreds if not thousands of bucket names were squatted on before I even woke up this morning.

 

What are your recommendations?

• Anyone based in Europe, or with European operations, should start evaluating the ESC. Create an Organization, create a sandbox account, and start experiencing the differences yourself.
• Keep your deployments small for now. The lack of centralized IAM and certain governance features increases the likelihood of adopting some riskier security patterns.
• Don’t allow expanded use of IAM users. While SSO is harder without IAM Identity Center, it isn’t impossible.
• Your CSPM/CNAPP vendor may not support ESC yet, so ask them and get a timeline.
• Be VERY aware of the resiliency limitations. There’s only one region and limited AZs. Local Zones aren’t launched yet.
• Do not deploy a mission critical application into the ESC if you can’t accept some potential downtime! Maybe there won’t be any outages. AWS has a great track record. But, right now, we can’t architect completely for resiliency. This will change, perhaps soon, but… not this week.

 

What if I have more questions?

CSA Members can reach out to schedule a call with myself or Chris, or another member of our team.