EU Sovereign Cloud Teil 3 – Hands-On Migration von Azure zu IONOS

Von Christopher Tröger am 03/02/2026

Back

9:17

Im zweiten Teil unserer Serie “EU Sovereign Cloud“ haben wir theoretisch analysiert, wo europäische Cloud-Provider im Featurevergleich zu Azure stehen – doch wie sieht die Realität aus? Wir haben den ultimativen Praxistest gewagt: Eine vollständige Migration einer cloud-nativen Anwendung von Microsoft Azure zur IONOS Cloud. Container, Secrets, KI-Services – alles was eine moderne Architektur ausmacht, musste portiert werden. Das Ergebnis? Überraschende Hürden, kreative Workarounds und einige unerwartete Erkenntnisse. In diesem dritten Teil zeigen wir, was direkt abbildbar war, wo es Lücken gab und wie mit Re-Architect darauf reagiert werden kann. Ein ehrlicher Erfahrungsbericht mit konkreten Lessons Learned für alle, die den Sprung zur EU Sovereign Cloud wagen wollen.

Inhalt

Aktuelle Architektur in Azure
Service-Mapping und Gap-Analyse
Filling the Gaps - Secret Management und Job-Repository
Fazit & Lessons Learned

Aktuelle Architektur in Azure

Wir haben eine AI-Assistant-Anwendung zur Unterstützung von Faktura gewählt, die repräsentativ für moderne cloud-native Workloads ist. Die Anwendung besteht aus drei Komponenten: Chat-UI, MCP-Server für Docuware-Integration und Backend-Job-Processor für asynchrone Dokumentenverarbeitung. Nutzer interagieren via Chat mit einem KI-Assistenten, der aus Zeiterfassungen und anderen Unterlagen weiterführende Dokumente generiert. User-Aktionen triggern asynchrone Jobs für die Dokumentenerstellung im Hintergrund. Technisch läuft alles auf Azure Container Apps, Azure Table Storage dient als Repository für asynchrone Jobs, Images werden in der Azure Container Registry gepflegt, Provisionierung erfolgt via Terraform in GitLab CI. Nutzer loggen sich via SSO über Microsoft Entra ID ein. Dazu kommen Standard-Azure-Services für Logging, Secret Management und Storage.

Eine typische Azure-native Architektur, die das komplette Service-Ökosystem nutzt – ideal, um die Migrationskomplexität zu testen!

azure_architecture

Abb. 1: Anwendungsinfrastruktur in Azure mit CI/CD Stack und externen Komponenten.

Service-Mapping und Gap-Analyse

Wenn man Azure gewohnt ist, muss man sich bei IONOS auf ein paar Änderungen gefasst machen. Neben dem Look-And-Feel des UIs unterscheiden sich auch grundlegende Konzepte – Lücken in IAM & Governance (keine klassischen technischen Nutzer oder fine-grained RBAC), bedingte Gruppierung von Cloud-Ressourcen und gänzlich nicht verfügbare Services. Die beiden folgenden Screenshots zeigen das IONOS Datacenter Web-UI.

ionos-ui

Abb. 2: IONOS Data Center Designer Web-UI.

Nachdem mit wenigen Klicks und Hinterlegen einer Kreditkarte der Account angelegt wurde, gelangt man direkt in das zentrale UI, den IONOS Data Center Designer (s. Abb. 2).

ionos-datacenter

Abb. 3: IONOS Data Center Details Web-UI.

Wie bei Azure Resource Groups können Cloud-Ressourcen in “Data Centers” gruppiert werden. Die einzelnen Infrastrukturkomponenten werden via Drag&Drop zusammengeklickt (s. Abb. 3).

Die folgenden Tabelle zeigt die Abbildbarkeit der verwendeten Azure Services in IONOS:

	Azure	IONOS	Bemerkung
Infrastructure-as-Code	Azure Terraform Provider	IONOS Terraform Provider	Nicht alle Resources provisionierbar (z.B. AI-Model-Hub)
IaC-Pipeline Authentication	Microsoft Entra ID Service Principal	IONOS Auth Token	Muss manuell in IONOS-UI angelegt werden
Resource Organization	Azure Resource Group	IONOS Data Center	Gruppierung nur in geringerem Umfang möglich (z.B. Storage ausgeschlossen)
Container Runtime	Azure Container Apps	IONOS Managed Kubernetes	Provisionierung via Terraform
Log Collection	Azure Log Analytics Workspace	IONOS Logging Service	Grafana-Loki Stack Log-Collection in K8s muss manuell eingerichtet werden, IONOS bietet hier einen detaillierten Guide zur Integration via FluentBit
Container Registry	Azure Container Registry	IONOS Private Container Registry	incl. CVE-Image-Scanning und Retention-Policies
Blob Storage	Azure Storage Account - Container	IONOS Object Storage	Zugriff aus CI/CD erfolgt via Access-Key
Persistent Volume Claims	Azure Storage Account - Azure File	IONOS Block Storage	Provisionierung in K8s erfolgt automatisch über Storage-Classes
AI-Model Service (LLM)	Azure OpenAI	IONOS AI Model Hub	weniger Modelle (z.B. kein openai/gpt-5) Hosting eigener Modelle nicht möglich
Secret Management	Azure Key Vault		Keine IONOS-native Lösung verfügbar → Re-Architect nötig
Job Repository	Azure Storage Account - Azure Table		Keine IONOS-native Lösung verfügbar → Re-Architect nötig
Identity Provider (SSO)	Microsoft Entra ID App Registration		kein typischer Identity Provider, IONOS-IAM vorwiegend zur Zugriffssteuerung auf Cloud-Ressourcen, nicht für tatsächliches End-User-Management
Service-Level RBAC	Azure Managed Identity		kein Service-Level RBAC, stattdessen Token-Auth gegen Cloud-Services (Container Registry, Loki, Storage)

Filling the Gaps - Secret Management und Job-Repository

Eigenes Secret Management

IONOS bietet kein natives Secret Management – ein kritischer Gap für unsere Anwendung und ein Fall für Re-Architect. Als zentralen Secret-Store haben wir uns für OpenBao, ein Open-Source-Fork von HashiCorp Vault, als StatefulSet in Kubernetes entschieden. OpenBao implementiert das Hashicorp-Vault-API und lässt sich somit als regulärer SecretStore mit dem External Secrets Operator nahtlos in Kubernetes integrieren. IaC-Provisioniering von Secrets via Terraform ist ebenfalls mit dem Vault-Terraform-Provider möglich.

Alternative für das Job Repository

Table Storage existiert bei IONOS nicht – somit musste für das Job Repository ebenfalls eine Alternative her. Wir haben uns für Redis als simplen Key-Value-Store entschieden, ebenfalls deployt in Kubernetes mit PVC. Dieser Schritt erforderte leider eine Anpassung des Applikationscodes in mehreren Komponenten, der Entwicklungsaufwand hielt sich jedoch in Grenzen.

IAM & SSO

IONOS-IAM ist primär zur Zugriffssteuerung auf Cloud-Ressourcen ausgelegt, nicht für echtes Enduser-Management analog eines regulären Identity Providers. Eine mögliche Lösung wäre gewesen, ein eigenes Keycloak-Deployment in Kubernetes als eigenen Identity Provider aufzusetzen. Jedoch haben wir diese Option nicht weiter verfolgt, da unsere Anwendung auf existierende Nutzer in Microsoft Entra ID angewiesen ist und eine Federation mit Azure somit trotzdem notwendig wäre. Daher bleiben wir bei Microsoft Entra ID für SSO – ein pragmatischer Ansatz, der zeigt, dass nicht jeder Service zwangsläufig migriert werden muss.

Zielarchitektur in IONOS

Die Zielarchitektur zeigt einen Mix aus direkten Service-Mappings und notwendigem Re-Architect. Während Standard-Services wie Managed Kubernetes, Container Registry und Object Storage direkt verfügbar sind, musste OpenBao das fehlende Secret Management ersetzen und Redis die Job-Repository-Funktion übernehmen. Für SSO bleibt Microsoft Entra ID erhalten – die finale Lösung ist somit Hybrid.

Abb. 4: Anwendungsinfrastruktur in IONOS mit CI/CD Stack und externen Komponenten.

Fazit & Lessons Learned

Kubernetes ist der ultimative Gap-Filler – und Hybrid-Architekturen sind oft die strategisch klügere Realität. Unsere wichtigsten Erkenntnisse aus der Migration:

Object Storage, Container Registry und Managed Kubernetes bilden den kleinsten gemeinsamen Nenner zwischen Cloud-Providern
Service-Gaps sind überbrückbar, erfordern aber deutlich mehr Engineering-Aufwand
Native Cloud-Services reduzieren Komplexität erheblich – deren Fehlen macht sich sofort bemerkbar
Infrastructure-as-Code via Terraform funktioniert, hat aber provider-spezifische Limitierungen
Kubernetes-native Lösungen bieten oft mehr Flexibilität als Managed Services, verschieben jedoch auch die Betriebsverantwortung ins Team
UI/UX-Qualität des IONOS-Portals bietet Raum für Optimierungen
Dokumentation und Guides sind entscheidend für erfolgreiche Implementierungen
Mehrkosten entstehen durch den höheren Preis der EU-Cloud-Infrastruktur selbst und durch zusätzliche Entwicklungs- und Betriebskosten für die eigenen Gap-Filler
Nicht alles muss migriert werden – strategische Hybrid-Ansätze sind oft praktikabler

Fazit: EU Sovereign Cloud ist technisch machbar, erfordert aber realistisches Erwartungsmanagement bezüglich Entwicklungsaufwand und Feature-Parität. Der Souveränitätsgewinn kommt mit einem Engineering-Overhead, der kalkuliert werden muss.

Haben Sie Fragen oder benötigen Unterstützung?

Stehen Sie aktuell vor der Herausforderung, den für Ihr Unternehmen optimalen Weg zu definieren und Ihre digitale Souveränität zu sichern? Als erfahrener Partner unterstützen wir Sie dabei, diese Komplexität zu durchdringen, die richtigen Entscheidungen zu treffen und Ihre individuelle Cloud-Strategie erfolgreich umzusetzen. Kontaktieren Sie uns oder finden Sie mehr zu Cloud Transformation auf unserer Website.