What we learned from piloting AWS European Sovereign Cloud.

The Nordcloud AWS Foundation team, which provides a robust landing zone for our managed cloud customers, recently conducted an early test of AWS’ European Sovereign Cloud (ESC) offering (Nordcloud is an ESC launch partner). The pilot was both interesting and challenging, and we’d like to share some lessons learned.

What is AWS European Sovereign Cloud?

AWS describes ESC as a fully featured, independently operated sovereign cloud backed by strong technical controls, sovereign assurances and legal protections designed to meet the needs of European governments and enterprises. ESC infrastructure is entirely located within the EU and operates independently from existing AWS Regions.

It’s still AWS, but designed to meet EU privacy and regulatory requirements. It’s partition-separated from the AWS Global partition (similar to AWS China or US GovCloud), which means the APIs between them can’t communicate directly. For example, you can’t switch roles from AWS Global to AWS ESC or interconnect VPCs via Transit Gateway between the two.

Lesson 1: Building a quality offering on top of new technology is a challenge

Not only do you need to stay up to date with the tools you rely on to take advantage of new capabilities, but you should also expect that the latest updates from the technology provider may not be fully ready yet.

The Nordcloud AWS Foundation relies heavily on Terraform, Terragrunt and AWS SDK for Go. As it turned out, all of them required updates to their most recent versions. Even Terragrunt – which we always considered cloud-agnostic – makes STS calls in the background that don’t work with releases based on older AWS SDKs, simply because they have no knowledge of ESC endpoints.

The most recent release of terraform-provider-aws at the time we started our ESC PoC (v6.28.0) lacked support for many resources. To move forward, we had to implement workarounds, such as scripted Lambda permission configuration, because the provider’s permission resource treated eusc-de-east-1 as an invalid region.

Even our GitHub Actions required version bumps; otherwise, runners were unable to assume their deployment roles.

Lesson 2: It’s easy to forget that a partition isn't a static thing

When you think of an ARN, you probably picture the familiar arn:aws: prefix. At Nordcloud, we’re well aware that this isn’t always the case – our solution has previously been used to deploy landing zones in AWS China (arn:aws-cn:). Even with that experience, we hadn’t paid enough attention to certain policies or custom references where ARNs were hardcoded with the aws partition. This mostly happened because all customers of the current AWS Foundation generation have so far operated only in the AWS Global partition.

Lesson 3: When things don’t work, it’s not always your fault

After updating multiple tools and libraries and making changes across interdependent modules, seeing an error while deploying Security Hub naturally makes you think: “Yeah, must be one more hardcoded ARN”. Well, not this time.

During troubleshooting, we discovered Internal Errors returned by the API. In this case, the issue was on AWS’ side. Even the big players have teething problems sometimes! Thankfully, AWS Support was responsive and addressed issues relatively quickly.

Lesson 4: Big things are missing

That’s no surprise for any newly launched Region, so isn't specific to ESC that certain services aren't yet available. Still, some of the missing services as of February 2026 may be particularly disappointing.

The lack of Identity Center may be a red flag for many enterprises. And the absence of the Code suite may discourage customers who would like to reuse their existing CI/CD setups built on top of CodePipeline, CodeBuild and related services.

Even available services may lack certain features. For example:

• EKS doesn't support Fargate profiles (even though Fargate is available in ECS)
• GuardDuty doesn't include a few features, e.g. EBS Malware Protection
• AWS Config lacks certain rules, such as DynamoDB encryption checks

Other notable omissions include services such as Inspector, Macie, Firewall Manager and QuickSight. And an obvious one, given its nature, is CloudFront (although it can still be configured in the Global partition to work with ESC workloads, with some limitations).

Lesson 5: Only 1 Region, only 2 Availability Zones

Enterprise architecture standards often require three AZs for critical Tier-0 systems, and this is also the standard for the Nordcloud AWS Foundation. Having just two AZs in eusc-de-east-1 (currently the only Region) forces non-standard network layouts – and may be a red flag for some enterprises. We’re still waiting to hear about AWS’ plans for a third AZ.

On the other hand, the resilience associated with multi-AZ design sometimes turns out to be illusory when looking at historical outages in us-east-1 that affected global AWS. In a partition fully separated from the rest of AWS, including IAM, this type of blast radius should be reduced.

Lesson 6: Small differences can cause pain, too

Similar to the China partition, some VPC endpoints that use reverse-domain naming such as:

com.amazonaws.eusc-de-east-1.dynamodb

may instead use a different domain, for example:

eu.amazonaws.eusc-de-east-1.athena

If you generate endpoint service names programmatically, you need to account for this inconsistency.

Another difference is that the region name eusc-de-east-1 no longer matches the typical [a-z]{2}(?:-[a-z]+)+-\d{1,2} pattern. (This was the very reason why multiple services would fail until fixes released in aws-terraform-provider v6.29.0.) If you validate region names anywhere in your code, you’ll need to update that logic. The same applies to automated region abbreviations (like use1 for us-east-1 or euw2 for eu-west-2), which may otherwise produce errors or odd results.

Bottom line

• It’s still good old AWS: (old, as due to some missing features, it really feels like traveling back in time). You’ll find it familiar and will likely be able to run many standard workloads without major investment. But at the same time, you should understand you won’t be able to cherry-pick things as freely.
• Organisations that truly need ESC for regulatory reasons will accept its limitations, others may prefer to wait until it matures and becomes more aligned with the AWS Global offering.
• ESC only launched in January 2026: Even though the service selection is currently somewhat limited, AWS and partner solutions are constantly being developed and launched in ESC. We at Nordcloud are excited to see how fast ESC keeps maturing – and how quickly AWS’ ESC-specific development teams respond to our and our customers’ needs. You can keep track of planning around this here.

And remember, you may not need to default to ESC to meet sovereignty needs. For example, you may be able to meet requirements in existing AWS Regions with extra controls. We always advocate taking a risk-based approach, so you have an evidence-based understanding of what needs protection and what sovereignty solutions make sense for your situation. Then, you can match your requirements to our tested blueprints – from enhanced security measures to full EU-native migrations – and create a practical roadmap.

Learn more in this guide, which outlines a best-practice approach to planning digital sovereignty on AWS.

Digital sovereignty roadmap.

From uncertainty to control

A best-practice approach to planning your digital sovereignty journey.