Die AWS European Sovereign Cloud ist keine weitere Region in der bestehenden kommerziellen AWS-Partition. AWS beschreibt sie als eigenständige Infrastruktur innerhalb der EU. Die erste Region in Brandenburg ist seit dem 14. Januar 2026 allgemein verfügbar. Konten, Identitäten und Abrechnung sind von der bestehenden AWS-Cloud getrennt.

Für eine Kostenentscheidung reicht deshalb die Frage „Was kostet dieselbe Instanz dort?“ nicht aus. Vor einer Migration müssen FinOps, Plattform und Finance gemeinsam prüfen, welche Kosten überhaupt vergleichbar sind, welche Verpflichtungen übertragbar sind und wie die neue Abrechnung in das Monatsreporting gelangt.

Zuerst die Entscheidungsgrenze festlegen

Souveränitätsanforderungen sind eine Risiko- und Architekturentscheidung. FinOps sollte sie nicht durch einen scheinbar günstigeren Preis ersetzen. Die Kostenanalyse beginnt erst, nachdem feststeht, welche Workloads die zusätzlichen Kontrollen tatsächlich benötigen.

Teilen Sie das Portfolio in drei Gruppen:

Workloads mit einer dokumentierten Anforderung an die eigenständige EU-Partition.
Workloads, bei denen eine bestehende EU-Region und die vorhandenen Kontrollen genügen könnten.
Gemeinsame Dienste und Datenflüsse, die beide Umgebungen verbinden würden.

Diese Trennung verhindert, dass ein pauschaler Migrationsvergleich eine Compliance-Anforderung mit einer Preisoptimierung vermischt.

Die Kosten in vier getrennten Ebenen prüfen

Ebene	Zu prüfende Frage	Benötigter Nachweis
Dienst	Ist der benötigte Dienst mit denselben Funktionen verfügbar?	Aktuelle AWS-Dienstliste und Architekturabhängigkeiten
Preis	Welche Rate gilt für Region, SKU, Betriebssystem und Kaufmodell?	Preislisten-API oder belastbares Angebot zum Prüfdatum
Verpflichtung	Können bestehende Savings Plans, Reservierungen oder private Preise genutzt werden?	Vertrags- und Billing-Nachweis für beide Partitionen
Betrieb	Welche zusätzlichen Kosten entstehen für Migration, Datenfluss, Betrieb und Ausfallsicherheit?	Architektur, Mengen und verantwortlicher Owner

Addieren Sie diese Ebenen nicht zu einer einzelnen Zahl, bevor jede Annahme einen Owner und eine Quelle hat. Ein Listenpreisvergleich kann richtig sein und trotzdem die falsche Entscheidung stützen, wenn zum Beispiel ein Dienst fehlt oder eine bestehende Verpflichtung nicht anwendbar ist.

Preise und Währung nicht mit Vergleichbarkeit verwechseln

AWS veröffentlicht Preise für die European Sovereign Cloud und nennt EUR als Vertragswährung. Das ist für europäische Budgets hilfreich, beseitigt aber nicht automatisch alle Währungsfragen. Prüfen Sie getrennt:

In welcher Währung Vertrag, Rechnung und internes Budget geführt werden.
Ob Rabatte und private Konditionen für die neue Partition gelten.
Welcher Preisstand und welche SKU im Vergleich verwendet wurden.
Wie Steuern, Support und Marketplace-Käufe im internen Reporting behandelt werden.

Die AWS-Dokumentation zur Sovereign Cloud nennt die öffentliche Price List API als Preisquelle. Sie weist zugleich darauf hin, dass nicht jedes gewohnte Preiswerkzeug innerhalb der neuen Partition verfügbar ist. Ein wiederholbarer Export der verwendeten Raten ist deshalb belastbarer als ein Screenshot aus einem Rechner.

Abrechnung und Kostenhistorie als neue Datenquelle behandeln

Die getrennte Partition bedeutet auch eine getrennte Kostenquelle. Planen Sie die Integration so, als würden Sie einen neuen Provider-Datensatz aufnehmen:

Abrechnungskonto und Zugriffsweg identifizieren.
Exportformat, Granularität und Lieferverzug verifizieren.
Konten und Ressourcen auf dieselben Kostenstellen, Teams und Produkte wie im bestehenden Reporting abbilden.
Währung und verwendete Kostenart ausdrücklich speichern.
Summen gegen die Rechnung abstimmen, bevor Trend- oder Einsparungsberichte darauf basieren.

Historische Vergleiche brauchen einen sichtbaren Schnitt. Wenn ein Workload die Partition wechselt, darf der Bericht den Wechsel nicht als organisches Wachstum, Anomalie oder Einsparung interpretieren. Markieren Sie Migrationsdatum, alten und neuen Scope sowie einmalige Migrationskosten.

Verpflichtungen vor dem Workload prüfen

Commitment-Abdeckung ist nur dann wertvoll, wenn die zugrunde liegende Nutzung im richtigen Scope anfällt. Prüfen Sie vor einer Kauf- oder Migrationsentscheidung:

Welche bestehenden Verpflichtungen die aktuelle Nutzung abdecken.
Ob diese Verpflichtungen in der Sovereign-Partition gelten oder dort neu abgeschlossen werden müssten.
Welche Laufzeiten mit dem Migrationsplan überlappen.
Wer das Risiko ungenutzter Verpflichtungen trägt, wenn sich die Architektur ändert.

Das Ergebnis ist keine maximale Abdeckung, sondern eine nachvollziehbare Grenze: welcher stabile Verbrauch verpflichtbar ist und welcher vorerst variabel bleiben sollte.

Ein brauchbares Entscheidungsdokument

Das Review kann auf eine Tabelle reduziert werden. Pro Workload enthält sie:

die konkrete Souveränitätsanforderung und ihren Entscheider;
benötigte Dienste und bestätigte Verfügbarkeit;
aktuelle und geplante Abrechnungs-Scope;
Preisquelle mit Prüfdatum und Währung;
anwendbare Verpflichtungen und private Konditionen;
einmalige sowie laufende Betriebsfolgen;
Daten- und Kostenflüsse über die Partitionsgrenze;
offene Annahmen, Owner und nächstes Prüfdatum.

Damit wird aus „Sovereign Cloud ist teurer oder günstiger“ eine prüfbare Entscheidung. Finance sieht die Budgetwirkung, Engineering die Architekturgrenzen und FinOps die Annahmen, die später mit echten Rechnungsdaten abgeglichen werden müssen.

Quellen und Methode

Ausgangspunkt sind die AWS-Ankündigung Opening the AWS European Sovereign Cloud, die AWS-Preisseite, der AWS Summit Hamburg Rückblick und das AWS European Sovereign Cloud User Guide, geprüft am 5. September 2026. Anbieterangaben belegen Produkt- und Abrechnungsmerkmale; sie ersetzen keine eigene rechtliche, Sicherheits- oder Vertragsprüfung.

AWS European Sovereign Cloud: die Kostenfragen vor einer Migration