EU Data Act: Was sich beim Cloud-Wechsel ab 2027 ändert

Die Übergangszeit ist verlängerbar, wenn der Wechsel technisch in 30 Tagen nicht machbar ist, und Kunden können sie auf eigenen Wunsch strecken. Als Planungsgröße solltest du trotzdem mit der kurzen Frist rechnen, denn sie beschreibt den Anspruch. Wichtig ist außerdem der Abrufzeitraum nach Vertragsende: In dieser Zeit müssen die Daten noch verfügbar sein, bevor der Anbieter sie löschen darf. Diese Frist gehört in jede Umzugsplanung, denn sie ist der letzte Zeitpunkt, an dem etwas Vergessenes noch geholt werden kann.

Für Neuabschlüsse lohnt sich ein Zusatz, der über den gesetzlichen Anspruch hinausgeht: eine Zusage über die Exportformate samt Schnittstelle, eine Frist für die Bereitstellung des Exports und das Recht, den Wechsel einmal jährlich zu proben. Der letzte Punkt kostet den Anbieter wenig und ist für euch der Unterschied zwischen einem Anspruch auf dem Papier und einer geübten Fähigkeit. Für souveräne Anbieter aus Deutschland und der EU gelten dieselben Regeln, die Abwägung dazu steht unter Souveräne Cloud-Anbieter.

# Azure: alle Ressourcen nach Typ gruppieren
az resource list --query "[].type" -o tsv | sort | uniq -c | sort -rn

# AWS: alle getaggten Ressourcen einsammeln
aws resourcegroupstaggingapi get-resources \
  --query 'ResourceTagMappingList[].ResourceARN' --output text \
  | awk -F: '{print $3}' | sort | uniq -c | sort -rn

# Wie viele Daten liegen wo, als Grundlage fuer die Transferrechnung
aws s3 ls --summarize --human-readable --recursive s3://daten-produktion/ | tail -3
az storage blob list --container-name daten --account-name stprod \
  --query "length(@)" -o tsv

Die Auszählung nach Diensttyp trennt in wenigen Minuten das Austauschbare vom Spezifischen. Alles, was in der oberen Hälfte der Liste steht und nicht Rechenleistung, Speicher oder Netz ist, gehört einzeln bewertet.

tofu init
tofu plan -out plan.tfplan
tofu apply plan.tfplan

# Was ist tatsaechlich beschrieben, was steht daneben
tofu state list | wc -l
tofu state list | grep -E 'aws_(lambda|dynamodb)|azurerm_(function|cosmosdb)'

# Bestehende Ressourcen nachtraeglich in die Beschreibung holen
tofu import azurerm_resource_group.prod \
  /subscriptions/<abo-id>/resourceGroups/rg-prod

Die zweite Abfrage ist der eigentliche Kern: Sie zeigt, welche Teile eures Aufbaus anbieterspezifisch sind. Genau diese Liste bestimmt den Aufwand eines Wechsels, alles andere ist überall gleich.

Halte die Struktur zweigeteilt: Ein Bereich beschreibt anbieterunabhängige Konzepte wie Umgebungen, Namensgebung, Netzsegmente und Rollenmodell, der andere die konkreten Ressourcen eines Anbieters. Beim Wechsel bleibt der erste Teil unverändert. Kubernetes ist auf der Anwendungsebene der gemeinsame Nenner, weil dieselben Manifeste bei jedem Anbieter laufen. Ob Terraform oder OpenTofu die bessere Grundlage ist, wägt Terraform oder OpenTofu ab.

# Welche Dienste haengen an einem anbietereigenen Lastverteiler
kubectl get svc -A -o jsonpath='{range .items[?(@.spec.type=="LoadBalancer")]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

# Welche Speicherklassen werden benutzt
kubectl get pvc -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,SC:.spec.storageClassName

# Annotationen, die nur bei einem Anbieter existieren
kubectl get ingress -A -o yaml | grep -E 'alb\.ingress|service\.beta\.kubernetes\.io/azure'

# Werte je Umgebung getrennt halten, statt sie fest einzubauen
helm get values anwendung -n produktion > werte-produktion.yaml

Anbietergebunden sind auf dieser Ebene fast immer drei Dinge: Lastverteiler, Speicherklassen und Annotationen am Eingang. Wer diese drei sauber über Werte je Umgebung steuert, tauscht beim Wechsel eine Datei statt der Manifeste.

# Vorher: Menge und geschaetzte Dauer bestimmen
aws s3 ls --summarize --human-readable --recursive s3://daten-produktion/ | tail -3

# Uebertragung mit Zeitmessung, parallelisiert
time aws s3 sync s3://daten-produktion/ /mnt/export/ --only-show-errors

# Datenbank konsistent sichern
pg_dump --format=custom --no-owner \
  --host db.produktion.example.de --username export \
  --file /mnt/export/anwendung.dump anwendung

# Rueckweg in die Zielumgebung pruefen
pg_restore --list /mnt/export/anwendung.dump | head -20

Miss die Dauer wirklich, statt sie zu rechnen. Bei großen Beständen bestimmen Anzahl und Größe der Objekte die Zeit stärker als die Bandbreite, weil jede Datei einzeln quittiert wird.

Dokumentiere das Ergebnis wie einen Wiederherstellungstest: Was wurde übertragen, wie lange hat es gedauert, was hat gefehlt, was musste von Hand nachgebaut werden. Diese Notiz ist zugleich der Nachweis gegenüber einer Aufsicht und die Grundlage für die nächste Vertragsverhandlung, denn sie benennt die realen Fristen. Wiederhole die Probe einmal im Jahr. Wie sich der Parallelbetrieb bei mehreren Anbietern dazu verhält, ordnet Multi-Cloud-Strategie ein.