AWS European Sovereign Cloud: What Six Months and One Live Test Actually Show

A few days ago I logged into a live account on the AWS European Sovereign Cloud (EUSC) and ran the AWS CLI against two worlds in parallel: the commercial AWS partition and the new sovereign partition. No marketing deck, no analyst report. Just sober List and Describe calls across roughly 65 services, plus a look at regions, Availability Zones, the Control Tower baseline catalog, and the available foundation models.

The reason was simple: since EUSC's launch on January 15, 2026 [1], a lot of people have been talking about sovereignty, but few have actually checked what responds inside the partition. That is exactly what I wanted to know for our client conversations before making a recommendation.

An honesty note up front: every availability statement here is a snapshot from July 3, 2026. EUSC is six months old and evolving fast. What is missing today may be there next month. The legal and structural points are more durable.

What EUSC Actually Is: Its Own Partition, Not a Bigger Region Switch

The most important technical fact is already visible in the first CLI responses. EUSC is its own AWS partition named aws-eusc, with its own DNS suffix amazonaws.eu instead of amazonaws.com. Every resource carries an ARN of the form arn:aws-eusc:.... Identity is a separate IAM directory. The single region is called eusc-de-east-1 ("EU (Germany) 1") and physically sits in Brandenburg [1][13].

That is the same kind of architectural separation AWS uses for GovCloud (US) and in China: not another region under the familiar roof, but a separate roof entirely. AWS puts the investment in Germany at 7.8 billion euros [2]. At launch, AWS stated that over 90 services were available [1][2].

For architecture, this has two consequences. First: anyone building Terraform or landing zones must never hardcode arn:aws:, or the code breaks in aws-eusc. Second: there is no bridge between the partitions. No cross-partition IAM trust, no VPC peering, no interchangeable ARNs. This wall is not a bug — it is the entire point. It is what makes the sovereignty boundary real.

This is exactly where landing zone architecture gets decided later. A landing zone in aws-eusc is its own AWS Organization in its own partition, with its own identity and logging foundation. Much of it resembles the commercial world; some things necessarily differ: the multi-region guardrails you know from the commercial partition behave differently in a single-region partition. Anyone who wants to run both worlds under one operating model needs to plan for these differences from day one.

What Already Holds Up Today

The core holds, and that was the first pleasant surprise. Around 50 of roughly 65 checked services responded live: S3, EC2, RDS, Lambda, EKS, ECS, DynamoDB, KMS, IAM, CloudTrail, Config, GuardDuty, SNS, SQS, CloudFormation, ACM, Secrets Manager, Systems Manager, EFS, ELBv2, ECR, ElastiCache, Step Functions, Athena, Glue, Redshift, Kinesis, EventBridge, OpenSearch, MSK, and more [13]. For the large majority of classic enterprise workloads, the primitives are there.

Even more important for regulated customers: the governance stack is there. controltower list-baselines returns the full baseline catalog, including AWSControlTowerBaseline, IdentityCenterBaseline, CentralConfigBaseline, LogArchiveBaseline, AuditBaseline, and BackupBaseline. securityhub describe-standards returns AFSBP, CIS 1.2 through 5.0, NIST 800-171, NIST 800-53 r5, as well as PCI DSS 3.2.1 and 4.0.1. Organizations is reachable too [13]. That is exactly the machinery a C5-capable landing zone builds on.

And the compliance baseline is already on paper: on March 10, 2026, EUSC received SOC 2, a BSI C5 report (Type 1), and seven ISO certifications, with an audit scope of 69 services [3][4]. For the DACH market this is the relevant sentence, because the operator's C5 attestation is the starting point of any serious cloud compliance discussion here.

One important caveat, though: I only checked read APIs. Whether a Control Tower landing zone can be set up cleanly end-to-end in EUSC, I did not test, because that would have changed an account. Anyone planning a landing zone should verify this setup flow in advance.

Where the Limits Are

Now the honest part, because a skeptic would catch the gaps anyway.

One region, two Availability Zones. eusc-de-east-1 showed the account two AZs, which matches AWS's official statement of two AZs at launch [1][13]. There is no second EUSC region today, and therefore no cross-region disaster recovery within the sovereign boundary. The announced expansion runs through sovereign AWS Local Zones in Belgium, the Netherlands, and Portugal. These have been announced but are not yet live, and they are Local Zones, not full-fledged regions [2].

A thinner service catalog. These services are not reachable through the partition today: CloudFront, Macie, Inspector, Detective, Service Catalog, WorkSpaces, QuickSight, CloudHSM, App Runner, Amplify, MemoryDB, Elastic Beanstalk, Lightsail, and Security Lake [13]. Anyone building an architecture on one of these services needs a migration or workaround plan today. Some have timelines: CloudFront is announced for Q4 2026, Inspector and Elastic Beanstalk for Q1 2027; Service Catalog, Security Lake, Lightsail, MemoryDB, App Runner, Amplify, and CloudHSM are currently considered not planned [14].

SageMaker is a special case, partly there, partly not: Studio domains, endpoints, and training jobs respond, only the old Notebook Instances operation does not. For an ML workload, it is therefore worth looking at the specific function you need instead of classifying SageMaker as simply present or absent [13][14].

One point of clarification, so no wrong impression forms here: Cost Explorer and Budgets did not show up in the partition on a regional endpoint. That is design behavior, not a gap. Cost and budget management are global services at AWS that are not resolved regionally, and AWS states that billing itself is run sovereignly within the EU [5]. So cost management is available, it simply does not respond on a eusc-de-east-1 endpoint [13].

Sovereign AI, but narrow. Bedrock is there, but list-foundation-models only returns Amazon Nova Pro and Nova Lite. No Anthropic or Claude models in EUSC today, unlike the full catalog in the commercial cloud [13]. A sovereign GenAI story is, for now, a Nova story.

I deliberately frame these points as what they are: the single region, the catalog, and the model selection are roadmap items. They will very likely improve as EUSC matures. You plan for them in phases; you do not block on day-one parity.

And a note on how to read "available": it means a service responds to basic API calls, not feature parity with the commercial cloud. Several core services are still thinly equipped, such as Security Hub, GuardDuty, or Bedrock. Most important from a compliance point of view: the modern Security Hub CSPM capability is barely usable yet. Anyone planning a concrete workload should check the specific function they need individually, rather than relying on a blanket "available" [14].

The Sovereignty Point: What's Verifiable and What Remains Open

This is where the verifiable separates from the contested, and that separation is decisive when you're sitting across from a CISO.

Verifiable is the technical and operational separation. Own partition, own DNS, own IAM, own ARNs: all confirmed via CLI [13]. On top of that comes a real corporate structure: a German holding company, three GmbH subsidiaries, EU-resident operating staff, an EU advisory board, and managing directors with EU citizenship [6]. In its own whitepaper from November 2025, AWS itself states that operation exclusively by EU citizens resident in the EU is still a transitional goal, not a day-one state [5]. This honesty in AWS's own document is notable and helpful. The Nitro architecture, which gives AWS staff no technical access to EC2 customer data, was independently audited by the NCC Group back in 2023 [5].

Contested and legally unresolved is the question of ultimate jurisdiction. The EUSC GmbH is ultimately part of a US corporation. Critics argue that this keeps the US CLOUD Act relevant, because its test does not hinge on server location but on "possession, custody, or control" by the parent company. The nuance matters here: even the European data protection authorities EDPB and EDPS, in their joint 2019 assessment, explicitly stated that exactly this question — how "control" applies to EU subsidiaries of US companies — is unresolved [7][8]. So it has not been decided in either direction. To this day, no agreement between the EU and the US specifically on the CLOUD Act exists [7].

AWS pushes back and points to its own record: since 2020, it says, no request from law enforcement for the disclosure of content data from enterprise or public-sector customers has been passed on to the US government [5]. That is a track record, not a legal guarantee. And it is worth staying honest here: when Microsoft's chief legal officer was asked under oath before the French Senate in June 2025 whether he could rule out data going to US authorities, his answer was: "No, I cannot guarantee that." [9] That was Microsoft, not AWS, but the legal mechanism is the same for any provider with a US parent.

One market signal rounds out the picture. The EU Commission has begun operationalizing sovereignty in procurement with its Cloud Sovereignty Framework (SEAL) [11]. In the first major tender in April 2026, all awards went to EU-owned providers [10]. Whether US hyperscalers were explicitly excluded because of CLOUD Act exposure is not stated verbatim by the Commission in its documents — that is press interpretation. But the direction is legible: for the highest sovereignty tier, which requires EU ownership, no wholly US-owned subsidiary qualifies, no matter how much operational isolation sits on top.

The honest assessment for a decision-maker is therefore this: EUSC genuinely raises the bar — operationally, technically, contractually, and now also certified. It is the most structurally separated sovereign hyperscaler offering I see today. But it is not legal immunity against US jurisdiction, and no hyperscaler can seriously promise that immunity today [12]. Anyone whose actual requirement is EU-only end-to-end control across the entire chain — for the most sensitive public-sector or KRITIS workloads, say — is making a sourcing decision that leads to an EU-owned provider, not to a hyperscaler sovereignty offering. For everyone else, EUSC is a substantial step forward compared to a standard EU region.

What This Means for Enterprise Adoption

The practical consequence is not an all-or-nothing bet, but a scoping and phasing question.

You place the workloads that need EU sovereignty and operational autonomy in EUSC, and keep the rest in the commercial cloud. A hybrid pattern of sovereign workloads in EUSC alongside global or non-critical workloads in the public cloud is a legitimate architecture, not a compromise. Because both worlds share the same AWS API, the same skills, and the same operating model, continuity stays high.

Three things I would verify before making any commitment to a client: first, whether the specific services you need actually fall within the audit scope of the 69 certified services [3]. Second, whether the Control Tower setup flow works end-to-end in EUSC. Third, what the pricing looks like, since public price parity with the public cloud has not been confirmed so far, and a sovereignty premium is plausible.

Where We at Tallence Come In

The value is not in talking EUSC up, but in cleanly deciding which workload belongs where and how to manage the gaps named above. That is exactly the work we do at Tallence in client projects.

Our Tallence Cloud Foundation is built configuration-driven. The same governance and landing zone logic that hardens an account in the commercial partition can be pointed at aws-eusc, because the partition switch is modeled as configuration rather than hardcoded. Tallence's services build on top of that: gap analysis between ISO 27001, NIS2, and C5:2026, scoping of sovereign workloads, building the evidence base, and ongoing operations. The honest limits laid out in this article are not a hidden risk — they are exactly the scope such a project manages.

If you are evaluating EUSC right now: where does your actual requirement lie — with data residency and operational autonomy, or with EU-only end-to-end control across the entire chain? That one distinction decides whether EUSC is the right answer. I am curious how you see this in your own projects.

Appendix: Services Confirmed Live in EUSC

This list comes directly from the CLI responses of the probes run on July 3, 2026, grouped by function. A responding endpoint counts as present, even if no resource has been created yet. "Available" here means basic API reachability, not feature parity with the commercial cloud. This inventory is a snapshot, and at the same time the foundation on which a landing zone in aws-eusc is built [13].

• Compute and containers: EC2, Lambda, ECS, EKS, AWS Batch, EC2 Auto Scaling, ECR
• Storage and backup: S3, EFS, FSx, AWS Backup
• Databases: RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Redshift
• Networking and delivery: VPC, Elastic Load Balancing (ALB and NLB), Route 53, API Gateway, Resource Access Manager, Cloud Map, Transfer Family
• Security, identity, and compliance: IAM, IAM Identity Center (no provisioned instance), Identity Store, IAM Access Analyzer, KMS, ACM, Secrets Manager, WAFv2, GuardDuty, Security Hub, Signer
• Governance and management: AWS Organizations, Control Tower, Config, CloudTrail, CloudWatch and CloudWatch Logs, Systems Manager, AppConfig, CloudFormation, plus Cost Explorer and Budgets as global cost management services
• Data and analytics: Athena, Glue, Kinesis Data Streams, Data Firehose, MSK (Managed Kafka), OpenSearch
• Integration and messaging: SNS, SQS, EventBridge, EventBridge Scheduler, Step Functions, Amazon MQ, SES, Cognito
• AI and ML: Bedrock, currently with the Amazon Nova Pro and Nova Lite models; SageMaker partially (Studio domains, endpoints, and training jobs; not Notebook Instances)

Not reachable through the partition at the time of testing: CloudFront, Macie, Inspector, Detective, Service Catalog, WorkSpaces, QuickSight, CloudHSM, App Runner, Amplify, MemoryDB, Elastic Beanstalk, Lightsail, and Security Lake. This inventory is deliberately technical, because exactly this service and governance footprint is the foundation a landing zone architecture in the partition stands on.

---

Sources

[1] AWS, "Opening the AWS European Sovereign Cloud", AWS News Blog, 01/15/2026. https://aws.amazon.com/blogs/aws/opening-the-aws-european-sovereign-cloud/

[2] AWS, "AWS Launches AWS European Sovereign Cloud and Announces Expansion Across Europe", press release, 01/15/2026. https://press.aboutamazon.com/aws/2026/1/aws-launches-aws-european-sovereign-cloud-and-announces-expansion-across-europe

[3] AWS Security Blog, "AWS European Sovereign Cloud achieves first compliance milestone: SOC 2 and C5 reports plus seven ISO certifications", 03/10/2026. https://aws.amazon.com/blogs/security/aws-european-sovereign-cloud-achieves-first-compliance-milestone-soc-2-and-c5-reports-plus-seven-iso-certifications/

[4] heise online, "AWS European Sovereign Cloud receives first compliance certifications", 03/2026. https://www.heise.de/en/news/AWS-European-Sovereign-Cloud-receives-first-compliance-certifications-11210793.html

[5] AWS, whitepaper "Overview of the AWS European Sovereign Cloud", design goals and design approach. https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/introduction.html

[6] AWS, "Built, operated, controlled, and secured in Europe: new sovereign controls and governance structure", aboutamazon.eu. https://www.aboutamazon.eu/news/aws/built-operated-controlled-and-secured-in-europe-aws-unveils-new-sovereign-controls-and-governance-structure-for-the-aws-european-sovereign-cloud

[7] EDPB and EDPS, "Joint Response to the LIBE Committee on the impact of the US Cloud Act", 07/10/2019 (overview). https://www.edpb.europa.eu/our-work-tools/our-documents/letters/edpb-edps-joint-response-libe-committee-impact-us-cloud-act_en

[8] EDPB and EDPS, "Initial legal assessment of the impact of the US CLOUD Act", Annex (PDF), 07/10/2019. https://www.edpb.europa.eu/sites/default/files/files/file2/edpb_edps_joint_response_us_cloudact_annex.pdf

[9] The Register, "Microsoft exec admits it 'cannot guarantee' data sovereignty", 07/25/2025. https://www.theregister.com/off-prem/2025/07/25/microsoft-exec-admits-it-cannot-guarantee-data-sovereignty/

[10] European Commission, "Commission advances cloud sovereignty through strategic procurement", 04/17/2026. https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en

[11] European Commission, "Sovereign Cloud Framework explained", 06/01/2026. https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en

[12] InfoQ, "AWS Launches European Sovereign Cloud amid Questions about U.S. Legal Jurisdiction", 01/2026. https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/

[13] Proprietary live CLI analysis (AWS CLI against the aws and aws-eusc partitions), 07/03/2026. Not publicly linkable; methodology and commands are described in the article.

[14] eusc.dev, "AWS European Sovereign Cloud Status" (WABI Engineering, unofficial feature-level tracker), accessed July 2026. https://eusc.dev