AWS European Sovereign Cloud: Was sechs Monate und ein Live-Test wirklich zeigen

Vor ein paar Tagen habe ich mich in ein aktives Konto der AWS European Sovereign Cloud (EUSC) eingeloggt und die AWS CLI parallel gegen zwei Welten laufen lassen: die kommerzielle AWS-Partition und die neue souveräne Partition. Kein Marketing-Deck, kein Analystenbericht. Nur nüchterne List- und Describe-Aufrufe über rund 65 Dienste, dazu ein Blick auf Regionen, Availability Zones, den Control-Tower-Baseline-Katalog und die verfügbaren Foundation Models.

Der Grund war einfach: Seit der EUSC-Start am 15. Januar 2026 [1] reden viele über Souveränität, aber wenige haben nachgesehen, was in der Partition tatsächlich antwortet. Genau das wollte ich für unsere Kundengespräche wissen, bevor ich eine Empfehlung ausspreche.

Ein Hinweis vorab zur Ehrlichkeit: Alle Verfügbarkeits-Aussagen hier sind eine Momentaufnahme vom 3. Juli 2026. EUSC ist sechs Monate alt und entwickelt sich schnell. Was heute fehlt, kann nächsten Monat da sein. Die rechtlichen und strukturellen Punkte sind langlebiger.

Was EUSC überhaupt ist: eine eigene Partition, kein größerer Region-Schalter

Die wichtigste technische Tatsache steht schon in den ersten CLI-Antworten. EUSC ist eine eigene AWS-Partition namens aws-eusc, mit eigenem DNS-Suffix amazonaws.eu statt amazonaws.com. Jede Ressource trägt eine ARN der Form arn:aws-eusc:.... Die Identität ist ein getrenntes IAM-Verzeichnis. Die einzige Region heißt eusc-de-east-1 ("EU (Germany) 1") und steht physisch in Brandenburg [1][13].

Das ist dieselbe Art architektonischer Trennung, die AWS auch bei GovCloud (US) und in China nutzt: nicht eine weitere Region unter dem bekannten Dach, sondern ein separates Dach. AWS beziffert die Investition auf 7,8 Milliarden Euro in Deutschland [2]. Beim Start waren laut AWS über 90 Dienste verfügbar [1][2].

Für die Architektur heißt das zweierlei. Erstens: Wer Terraform oder Landing Zones baut, darf arn:aws: niemals fest verdrahten, sonst bricht der Code in aws-eusc. Zweitens: Zwischen den Partitionen gibt es keine Brücke. Kein partitionsübergreifendes IAM-Vertrauen, kein VPC-Peering, keine austauschbaren ARNs. Diese Wand ist kein Bug, sondern der eigentliche Zweck. Sie macht die Souveränitätsgrenze real.

Genau an dieser Wand entscheidet sich später die Landing-Zone-Architektur. Eine Landing Zone in aws-eusc ist eine eigene AWS-Organisation in einer eigenen Partition, mit eigenem Identitäts- und Logging-Fundament. Vieles gleicht der kommerziellen Welt, manches unterscheidet sich zwingend: Die Multi-Region-Guardrails, die man aus der kommerziellen Partition kennt, greifen in einer Single-Region-Partition anders. Wer beide Welten unter einem Betriebsmodell führen will, plant diese Unterschiede von Anfang an ein.

Was heute schon trägt

Der Kern hält, und das war die erste Überraschung im positiven Sinne. Rund 50 von etwa 65 geprüften Diensten haben live geantwortet: 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 und mehr [13]. Für die große Mehrheit klassischer Enterprise-Workloads sind die Primitive vorhanden.

Wichtiger noch für regulierte Kunden: Der Governance-Stack ist da. controltower list-baselines liefert den vollständigen Baseline-Katalog, inklusive AWSControlTowerBaseline, IdentityCenterBaseline, CentralConfigBaseline, LogArchiveBaseline, AuditBaseline und BackupBaseline. securityhub describe-standards gibt AFSBP, CIS 1.2 bis 5.0, NIST 800-171, NIST 800-53 r5 sowie PCI DSS 3.2.1 und 4.0.1 zurück. Organizations ist ebenfalls erreichbar [13]. Das ist genau die Maschinerie, auf der eine C5-fähige Landing Zone aufsetzt.

Und die Compliance-Basis steht bereits schriftlich: Am 10. März 2026 hat EUSC SOC 2, einen BSI-C5-Bericht (Typ 1) und sieben ISO-Zertifizierungen erhalten, mit einem Prüfumfang von 69 Diensten [3][4]. Für den DACH-Markt ist das der relevante Satz, weil das C5-Testat des Betreibers der Ausgangspunkt jeder ernsthaften Cloud-Compliance-Diskussion hier ist.

Eine wichtige Einschränkung nenne ich trotzdem: Ich habe nur Lese-APIs geprüft. Ob eine Control-Tower-Landing-Zone in EUSC end-to-end sauber aufgesetzt werden kann, habe ich nicht getestet, weil das ein Konto verändert hätte. Wer eine Landing Zone plant, sollte diesen Setup-Fluss vorab verifizieren.

Wo die Grenzen liegen

Jetzt der ehrliche Teil, denn ein Skeptiker fängt die Lücken ohnehin auf.

Eine Region, zwei Availability Zones. eusc-de-east-1 hat dem Konto zwei AZs gezeigt, und das deckt sich mit der offiziellen AWS-Angabe von zwei AZs zum Start [1][13]. Es gibt heute keine zweite EUSC-Region und damit kein Disaster-Recovery über Regionen hinweg innerhalb der souveränen Grenze. Die angekündigte Erweiterung läuft über souveräne AWS Local Zones in Belgien, den Niederlanden und Portugal. Diese sind angekündigt, aber noch nicht live, und es sind Local Zones, keine vollwertigen Regionen [2].

Dünnerer Dienstkatalog. Diese Dienste sind heute nicht über die Partition erreichbar: CloudFront, Macie, Inspector, Detective, Service Catalog, WorkSpaces, QuickSight, CloudHSM, App Runner, Amplify, MemoryDB, Elastic Beanstalk, Lightsail und Security Lake [13]. Wer eine Architektur auf einen dieser Dienste stützt, braucht heute einen Migrations- oder Umgehungsplan. Für einige gibt es Zeitpläne: CloudFront ist für Q4 2026 angekündigt, Inspector und Elastic Beanstalk für Q1 2027; Service Catalog, Security Lake, Lightsail, MemoryDB, App Runner, Amplify und CloudHSM gelten derzeit als nicht geplant [14].

SageMaker ist ein Sonderfall, teils vorhanden, teils nicht: Studio-Domains, Endpoints und Training-Jobs antworten, nur die alte Notebook-Instances-Operation nicht. Für einen ML-Workload lohnt sich deshalb der Blick auf die konkret benötigte Funktion, statt SageMaker pauschal als vorhanden oder fehlend einzustufen [13][14].

Ein Punkt zur Einordnung, damit hier kein falscher Eindruck entsteht: Cost Explorer und Budgets tauchten in der Partition nicht auf einem regionalen Endpunkt auf. Das ist Designverhalten, keine Lücke. Kosten- und Budgetverwaltung sind bei AWS globale Dienste, die nicht regional aufgelöst werden, und die Abrechnung selbst führt AWS laut eigenen Angaben souverän in der EU [5]. Cost Management ist also verfügbar, es antwortet nur nicht auf einen eusc-de-east-1-Endpunkt [13].

Souveräne KI, aber schmal. Bedrock ist da, list-foundation-models liefert aber nur Amazon Nova Pro und Nova Lite. Keine Anthropic- oder Claude-Modelle in EUSC heute, im Gegensatz zum vollen Katalog in der kommerziellen Cloud [13]. Eine souveräne GenAI-Story ist derzeit eine Nova-Story.

Ich ordne diese Punkte bewusst ein: Der einzelne Region, der Katalog und die Modellauswahl sind Roadmap-Themen. Sie werden mit hoher Wahrscheinlichkeit besser, je reifer EUSC wird. Man plant sie als Phasen ein, man blockiert nicht auf Tag-1-Parität.

Und ein Hinweis zur Lesart von "verfügbar": Es heißt, dass ein Dienst auf grundlegende API-Aufrufe antwortet, nicht Feature-Parität mit der kommerziellen Cloud. Mehrere Kern-Dienste sind noch dünn ausgestattet, etwa Security Hub, GuardDuty oder Bedrock. Für die Compliance-Sicht am wichtigsten: Die moderne Security-Hub-CSPM-Funktion ist noch kaum nutzbar. Wer einen konkreten Workload plant, prüft die benötigte Funktion einzeln, statt sich auf ein pauschales "verfügbar" zu verlassen [14].

Der Souveränitätspunkt: was verifizierbar ist und was offen bleibt

Hier trennt sich das Verifizierbare vom Umstrittenen, und diese Trennung ist entscheidend, wenn man vor einem CISO sitzt.

Verifizierbar ist die technische und operative Separierung. Eigene Partition, eigenes DNS, eigenes IAM, eigene ARNs: alles per CLI bestätigt [13]. Dazu kommt eine reale Unternehmensstruktur: eine deutsche Holding, drei GmbH-Töchter, EU-ansässiges Betriebspersonal, ein EU-Beirat und Geschäftsführer mit EU-Bürgerschaft [6]. AWS beschreibt in seinem Whitepaper vom November 2025 selbst, dass der Betrieb ausschließlich durch EU-Bürger mit Wohnsitz in der EU noch ein Übergangsziel ist, kein Tag-1-Zustand [5]. Diese Ehrlichkeit im eigenen Dokument ist bemerkenswert und hilfreich. Die Nitro-Architektur, die AWS-Mitarbeitenden keinen technischen Zugriff auf EC2-Kundendaten gibt, wurde bereits 2023 von der NCC Group unabhängig geprüft [5].

Umstritten und rechtlich unentschieden ist die Frage der ultimativen Jurisdiktion. Die EUSC-GmbH ist letztlich Teil eines US-Konzerns. Kritiker argumentieren, damit bleibe der US CLOUD Act relevant, weil dessen Test nicht auf den Serverstandort abstellt, sondern auf "possession, custody, or control" der Muttergesellschaft. Wichtig ist die Nuance: Selbst die europäischen Datenschutzaufsichten EDPB und EDPS haben in ihrer gemeinsamen Bewertung von 2019 ausdrücklich festgehalten, dass genau diese Frage, wie "Kontrolle" auf EU-Töchter von US-Firmen anzuwenden ist, ungelöst ist [7][8]. Sie ist also nicht in die eine oder die andere Richtung entschieden. Ein Abkommen zwischen EU und USA speziell zum CLOUD Act existiert bis heute nicht [7].

AWS hält dagegen und verweist auf die eigene Statistik: Seit 2020 sei keine Anfrage von Strafverfolgungsbehörden zur Herausgabe von Inhaltsdaten von Unternehmens- oder Public-Sector-Kunden an die US-Regierung geführt worden [5]. Das ist ein Track Record, keine juristische Garantie. Und es lohnt sich, ehrlich zu bleiben: Als Microsofts Rechtsdirektor im Juni 2025 vor dem französischen Senat gefragt wurde, ob er ausschließen könne, dass Daten an US-Behörden gehen, war seine Antwort unter Eid: "Nein, das kann ich nicht garantieren." [9] Das war Microsoft, nicht AWS, aber der Rechtsmechanismus ist derselbe für jeden Anbieter mit US-Mutter.

Ein Marktsignal rundet das Bild ab. Die EU-Kommission hat mit ihrem Cloud Sovereignty Framework (SEAL) begonnen, Souveränität in der Beschaffung zu operationalisieren [11]. Bei der ersten großen Ausschreibung im April 2026 gingen alle Zuschläge an EU-eigene Anbieter [10]. Ob US-Hyperscaler dabei explizit wegen CLOUD-Act-Exposition ausgeschlossen wurden, sagt die Kommission in ihren Unterlagen nicht wörtlich, das ist Presse-Interpretation. Aber die Richtung ist ablesbar: Für die höchste Souveränitätsstufe, die EU-Eigentum verlangt, kommt kein hundertprozentig US-eigenes Tochterunternehmen infrage, egal wie viel operative Isolation darüber liegt.

Die ehrliche Einordnung für einen Entscheider lautet deshalb: EUSC hebt die Messlatte real an, operativ, technisch, vertraglich und jetzt auch zertifiziert. Es ist das strukturell am stärksten getrennte souveräne Hyperscaler-Angebot, das ich heute sehe. Es ist aber keine juristische Immunität gegen US-Jurisdiktion, und kein Hyperscaler kann diese Immunität heute seriös versprechen [12]. Wer als Anforderung wirklich EU-only-Endkontrolle über die gesamte Kette braucht, etwa für die sensibelsten Public-Sector- oder KRITIS-Workloads, trifft eine Sourcing-Entscheidung, die zu einem EU-eigenen Anbieter führt, nicht zu einem Hyperscaler-Souveränitätsangebot. Für alle anderen ist EUSC ein substanzieller Fortschritt gegenüber einer Standard-EU-Region.

Was das für die Enterprise-Adoption heißt

Die praktische Konsequenz ist keine Alles-oder-nichts-Wette, sondern eine Scoping- und Phasen-Frage.

Man legt die Workloads in EUSC, die EU-Souveränität und operative Autonomie brauchen, und behält den Rest in der kommerziellen Cloud. Ein Hybridmuster aus souveränen Workloads in EUSC und globalen oder unkritischen Workloads in der Public Cloud ist eine legitime Architektur, kein Kompromiss. Weil beide Welten dieselbe AWS-API, dieselben Skills und dasselbe Betriebsmodell teilen, bleibt die Kontinuität hoch.

Drei Dinge würde ich vor jeder Zusage an einen Kunden verifizieren: erstens, ob die konkret benötigten Dienste im Prüfumfang der 69 zertifizierten Dienste liegen [3]. Zweitens, ob der Control-Tower-Setup-Fluss in EUSC end-to-end funktioniert. Drittens, wie das Pricing aussieht, denn eine öffentliche Preisparität zur Public Cloud ist bisher nicht bestätigt, und ein Souveränitätsaufschlag ist plausibel.

Wo wir als Tallence ansetzen

Der Wert liegt nicht darin, EUSC schönzureden, sondern darin, sauber zu entscheiden, welcher Workload wohin gehört und wie man die genannten Lücken managt. Genau das ist die Arbeit, die wir bei Tallence in Kundenprojekten leisten.

Unsere Tallence Cloud Foundation ist konfigurationsgetrieben aufgebaut. Dieselbe Governance- und Landing-Zone-Logik, die ein Konto in der kommerziellen Partition härtet, lässt sich auf aws-eusc richten, weil der Partitionswechsel als Konfiguration modelliert ist und nicht fest verdrahtet. Die Tallence Services setzen darauf auf: Gap-Analyse zwischen ISO 27001, NIS2 und C5:2026, Scoping der souveränen Workloads, Aufbau der Evidence-Basis und der laufende Betrieb. Die ehrlichen Grenzen aus diesem Artikel sind kein verstecktes Risiko, sondern genau der Umfang, den ein solches Projekt steuert.

Wenn Sie EUSC gerade evaluieren: Wo liegt bei Ihnen die tatsächliche Anforderung, bei Datenresidenz und operativer Autonomie, oder bei EU-only-Endkontrolle über die gesamte Kette? Diese eine Unterscheidung entscheidet, ob EUSC die richtige Antwort ist. Ich bin gespannt, wie Sie das in Ihren Projekten sehen.

Anhang: Die in EUSC live bestätigten Dienste

Diese Liste stammt direkt aus den CLI-Antworten der Probes vom 3. Juli 2026, gruppiert nach Funktion. Ein antwortender Endpunkt zählt als vorhanden, auch wenn noch keine Ressource angelegt ist. Verfügbar heißt hier Basis-API-Erreichbarkeit, nicht Feature-Parität mit der kommerziellen Cloud. Die Aufstellung ist eine Momentaufnahme und zugleich die Basis, auf der eine Landing Zone in aws-eusc aufsetzt [13].

• Compute und Container: EC2, Lambda, ECS, EKS, AWS Batch, EC2 Auto Scaling, ECR
• Storage und Backup: S3, EFS, FSx, AWS Backup
• Datenbanken: RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Redshift
• Netzwerk und Delivery: VPC, Elastic Load Balancing (ALB und NLB), Route 53, API Gateway, Resource Access Manager, Cloud Map, Transfer Family
• Sicherheit, Identität und Compliance: IAM, IAM Identity Center (ohne provisionierte Instanz), Identity Store, IAM Access Analyzer, KMS, ACM, Secrets Manager, WAFv2, GuardDuty, Security Hub, Signer
• Governance und Management: AWS Organizations, Control Tower, Config, CloudTrail, CloudWatch und CloudWatch Logs, Systems Manager, AppConfig, CloudFormation, dazu Cost Explorer und Budgets als globale Cost-Management-Dienste
• Daten und Analytics: Athena, Glue, Kinesis Data Streams, Data Firehose, MSK (Managed Kafka), OpenSearch
• Integration und Messaging: SNS, SQS, EventBridge, EventBridge Scheduler, Step Functions, Amazon MQ, SES, Cognito
• KI und ML: Bedrock, aktuell mit den Modellen Amazon Nova Pro und Nova Lite; SageMaker teilweise (Studio-Domains, Endpoints und Training-Jobs; Notebook Instances nicht)

Zum Testzeitpunkt nicht über die Partition erreichbar: CloudFront, Macie, Inspector, Detective, Service Catalog, WorkSpaces, QuickSight, CloudHSM, App Runner, Amplify, MemoryDB, Elastic Beanstalk, Lightsail und Security Lake. Diese Aufstellung ist bewusst technisch, denn genau dieser Dienst- und Governance-Bestand ist das Fundament, auf dem eine Landing-Zone-Architektur in der Partition steht.

---

Quellenverzeichnis

[1] AWS, "Opening the AWS European Sovereign Cloud", AWS News Blog, 15.01.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", Pressemitteilung, 15.01.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", 10.03.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-Ziele und Design-Ansatz. 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 und EDPS, "Joint Response to the LIBE Committee on the impact of the US Cloud Act", 10.07.2019 (Übersicht). https://www.edpb.europa.eu/our-work-tools/our-documents/letters/edpb-edps-joint-response-libe-committee-impact-us-cloud-act_en

[8] EDPB und EDPS, "Initial legal assessment of the impact of the US CLOUD Act", Annex (PDF), 10.07.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", 25.07.2025. https://www.theregister.com/off-prem/2025/07/25/microsoft-exec-admits-it-cannot-guarantee-data-sovereignty/

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

[11] Europäische Kommission, "Sovereign Cloud Framework explained", 01.06.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] Eigene Live-CLI-Analyse (AWS CLI gegen die Partitionen aws und aws-eusc), 03.07.2026. Nicht öffentlich verlinkbar; Methodik und Befehle sind im Artikel beschrieben.

[14] eusc.dev, "AWS European Sovereign Cloud Status" (WABI Engineering, inoffizieller Feature-Level-Tracker), abgerufen im Juli 2026. https://eusc.dev