Was haben wir getestet?

Unser Test untersucht, wie gut europäische Cloud-Provider eine typische Einstiegsarchitektur mittelständischer Unternehmen unterstützen. Dafür haben wir bei IONOS-Cloud eine praxisnahe Umgebung mit Web-Anwendung, Datenbank, Kubernetes sowie Netzwerk- und Sicherheitskomponenten aufgebaut, ausschließlich mit Standard-Services und ohne Sonderverträge. Weitere Details zur Zielarchitektur gibt es hier.

Bewertet wurden insbesondere Dokumentation, Automatisierbarkeit, Developer Experience sowie der zusätzliche Eigenaufwand im Vergleich zu etablierten Hyperscalern und die Eignung als Grundlage für weitergehende Cloud-Architekturen.

Wer hat getestet?

Das Test-Team ist breit aufgestellt, um individuelle Präferenzen und Anbieter-Bias möglichst auszugleichen. Beteiligt waren Cloud- und Software-Architekten mit langjähriger Erfahrung in Hyperscaler-, Sovereign- und europäischen Cloud-Ökosystemen.

• David Sterz, Senior Cloud Architect (AWS, Azure, GCP, Alibaba, STACKIT, IONOS)
• Felix Gerdes, Sovereign Cloud Architect (Azure, Delos Cloud)
• Jens Eickmeyer, Software Engineering Lead (AWS, Azure)
• Dr. Sven Köppel, Software Engineer (AWS, GCP, Azure, STACKIT)

Durch diese Mischung aus Architektur-, Plattform- und Beratungsperspektiven konnten wir IONOS Cloud sowohl aus Sicht von Cloud-Einsteigern als auch von ambitionierten Cloud-Anwendern bewerten.

Eignung für Cloud-Einsteiger – Der Data Center Designer beeindruckt

Die IONOS Cloud macht den Einstieg in moderne IT leicht:

• Einstiegshürde niedrig: Viele Ressourcen lassen sich schnell und ohne tiefes Vorwissen aufsetzen, erste funktionierende Setups wie Kubernetes plus Webanwendung sind in kurzer Zeit realisierbar.
• Weniger kleinteilig als Hyperscaler: Die Ressourcenmodelle sind grober geschnitten, dadurch schneller verständlich, was den Umstieg von On-Premises erleichtert.
• Visuelles Setup-Tool mit Grenzen: Der Data Center Designer unterstützt beim Zusammenklicken einer Infrastruktur und senkt die Einstiegshürde spürbar. In der Praxis zeigt die UI Änderungen aber nicht immer zuverlässig an und braucht manuelles Neuladen.
• Lücke zwischen Basis und erweiterten Services: Der Visual Designer ist nicht konsequent durchgezogen, erweiterte Services tauchen dort teils nicht auf, während einfache Compute-Ressourcen sichtbar bleiben. Das erschwert es Einsteigern, sich ein vollständiges Bild der eigenen Infrastruktur zu machen.
• Fehlende Abstraktion: Es gibt keinen einfachen Container-as-a-Service, Einsteiger müssen direkt mit Kubernetes arbeiten, was die Einstiegshürde im Vergleich zu einem gemanagten Container-Dienst erhöht.

Wer schnell starten will, kommt bei IONOS gut ins Rollen, ein Tester bezeichnete das visuelle Setup-Tool sogar als "total cool" für den schnellen Einstieg. Wer aber tiefer geht, wird irgendwann auf die Kanten stoßen, die noch nicht sauber ausgearbeitet sind.

Abbildbarkeit Referenzarchitektur – Möglich mit vielen nativen Cloud-Services

Die Referenzarchitektur lässt sich bei IONOS größtenteils mit nativen Services umsetzen, an einzelnen Stellen bleiben aber Lücken:

• Kernkomponenten nativ abbildbar: Compute, Netzwerk und Kubernetes lassen sich direkt mit Bordmitteln umsetzen, ohne dass Eigenimplementierungen nötig sind.
• Storage direkt integrierbar: S3-kompatibler Object Storage ließ sich ohne größere Hürden in die Referenzarchitektur einbinden; auch das Zusammenspiel mit Kubernetes und Datenbank funktionierte im Test problemlos. Die abweichende Regionenlogik fällt allerdings etwas aus dem sonstigen Plattformmodell heraus.
• Managed VPN als Stärke: Der native VPN-Service deckt einen zentralen Baustein der Referenzarchitektur ab. Für VM- und Netzwerk-Teile funktioniert das ohne Eigenbau; bei Managed Kubernetes ist zusätzliche Netzwerkkonfiguration nötig, da VPN Gateways noch nicht direkt mit von Managed Kubernetes verwalteten LANs verbunden werden können.
• Zertifikatsmanagement inklusive: Ein integrierter Zertifikatsservice übernimmt die Verschlüsselung in Transit, ein Baustein, der sonst oft manuell nachgerüstet werden muss.
• Kein hochabstrahierter Container-Service: Es fehlt ein Pendant zu einem Service wie AWS Fargate, wodurch Kubernetes direkt betrieben werden muss statt eine abstrahierte Container-Plattform zu nutzen.
• Load Balancer bei Kubernetes nur eingeschränkt integriert: Managed Network und Application Load Balancer sind vorhanden. Private Node Pools unterstützen den Kubernetes Service-Typ LoadBalancer derzeit jedoch nicht; für private Setups muss ein Load Balancer außerhalb des Clusters mit einem Ingress Controller kombiniert werden.
• Netzwerk-Peering gemanagt und automatisierbar: Verbindungen zwischen Netzwerksegmenten lassen sich konfigurieren und in die Automatisierung einbinden.

Unterm Strich: Die wichtigsten Bausteine der Referenzarchitektur sind vorhanden und funktionieren gut zusammen, an der Schnittstelle zwischen Kubernetes und Netzwerk bleibt aber Handarbeit nötig. Einer der Tester fasste den VM- und Netzwerk-Teil so zusammen: mit der Referenzarchitektur ließ sich sogar ein VPN bauen, ohne dass man dafür irgendwo drumherum arbeiten musste.

Automatisierbarkeit (IaC) – Mit dem MCP-Server in die Welt der KI

Was IONOS an automatisierbaren Bausteinen anbietet, ist sauber umgesetzt:

• Terraform als verlässliche Basis: Zentrale Ressourcen wie Compute, Kubernetes und Netzwerk lassen sich stabil und reproduzierbar per Terraform provisionieren, die Templates funktionieren zuverlässig.
• Crossplane offiziell unterstützt: IONOS dokumentiert Crossplane offiziell und pflegt den Provider aktiv. Der Ansatz geht über reine Terraform-Unterstützung hinaus, deckt derzeit aber weniger Ressourcen ab als der Terraform-Provider.
• MCP-Server als Kommunikationsschnittstelle: Ein MCP-Server ermöglicht den Zugriff auf die aufgebaute Landschaft, etwa um Auslastung oder Kostentreiber abzufragen. Zum Teststichtag war er nur lesend nutzbar; seit dem 24. August 2026 sind erste Schreiboperationen als Opt-in verfügbar, zunächst unter anderem für Data Center.
• Kein kaskadierendes Löschen: Über Terraform lässt sich Infrastruktur regulär zurückbauen. API und Data Center Designer löschen abhängige Ressourcen jedoch nicht automatisch mit; bei manuell entstandenen oder verwaisten Abhängigkeiten bleibt Handarbeit.
• Weniger kleinteilig als bei Hyperscalern: Die Terraform-Ressourcen sind vergleichsweise übersichtlich geschnitten, was die Automatisierung insgesamt zugänglicher macht.

Unterm Strich: Der Umfang ist ausreichend für die mittelständische Referenzarchitektur. Was IONOS automatisierbar macht, funktioniert zuverlässig, der MCP-Server zeigt zudem, wohin die Reise gehen könnte.

Dokumentation & Orientierung – Gute und verständliche Dokumentation

IONOS bündelt seine Doku übersichtlich an einem Ort, verliert aber an Tiefe, sobald es komplexer wird.

• Zentraler Einstieg mit ergänzenden Dokumentationsräumen: Die Cloud-Dokumentation ist übersichtlich gebündelt. Für Terraform, Crossplane und die API existieren daneben separate Dokumentationsräume. 
• Gut auffindbar und aktuell: Zentrale Services sind schnell zu finden, die Inhalte wirken aktiv gepflegt und werden in kurzen Abständen aktualisiert.
• Terraform-Doku als Stärke: Der offizielle Terraform-Provider ist mit Beispielen gut dokumentiert und unterstützt die praktische Umsetzung spürbar.
• Fragmentierte Struktur: Verschiedene Einstiegspunkte wie Developer Docs und User Guides laufen nebeneinander her, was die Orientierung an manchen Stellen erschwert.
• Dünn bei komplexeren Themen: Für Standard-Setups reicht die Tiefe, bei Netzwerk, IAM oder Service-Integration fehlen oft weiterführende Erklärungen.
• Kaum Architektur-Guidance: Es gibt wenig konkrete Best Practices oder Referenzarchitekturen, vieles müssen Nutzer sich selbst herleiten.

Unterm Strich: Für den täglichen Gebrauch ist die Dokumentation angenehm kompakt und aktuell, mit ein bisschen mehr Tiefe an den anspruchsvollen Stellen wäre sie richtig stark.

Engineering Experience – Angenehmes Arbeiten, wenig Reibung

Die Tester berichten übereinstimmend von einer angenehmen Arbeitserfahrung mit der Referenzarchitektur:

• Durchweg positives Feedback: In der Bewertungsrunde gab es zu diesem Kriterium keine nennenswerten Einwände, alle Tester berichteten überwiegend Positives.
• Konsistentes Arbeitsgefühl: Der Umgang mit der Architektur im Alltag wirkt stimmig, ohne dass einzelne Komponenten aus dem Rahmen fallen.
• Trägt die Stärken der Nachbarkategorien mit: Die gute Dokumentation und die saubere Automatisierbarkeit zahlen spürbar auf die tägliche Arbeitserfahrung ein.

Unterm Strich: Eine der unstrittigsten Kategorien im gesamten Test, IONOS liefert hier eine spürbar runde Erfahrung ohne größere Bruchstellen.

Eignung für ambitionierte oder Enterprise Setups – Luft nach oben gibt es auch

Eigentlich liegt diese Kategorie außerhalb dessen, was der Test abbilden soll, denn die Referenzarchitektur ist auf ein Unternehmen wie Müller Anlagenbau zugeschnitten, nicht auf ein Enterprise-Setup. Trotzdem lohnt sich der Blick, schließlich kann sich so ein Unternehmen weiterentwickeln und irgendwann genau diese Anforderungen stellen.

• Governance und IAM bleiben grob: Nutzer- und Gruppenrechte lassen sich nur grob einstellen, eine feingranulare Steuerung einzelner Ressourcen oder Aktionen fehlt.
• Identity Federation nur für Authentifizierung: Externe Identitätsquellen lassen sich über SAML 2.0 oder OIDC inklusive Single Sign-On anbinden. Die Verknüpfung der Federation mit Berechtigungen fehlt jedoch; Rollen und Rechte müssen weiterhin lokal in der IONOS Cloud gepflegt werden.
• Cost Control ausbaufähig: Im Data Center Designer werden Kosten mit bis zu 24 Stunden Verzögerung sichtbar, Granulare Kostendaten pro Ressource sind über die Billing API verfügbar; Budget-Caps, die Deployments automatisch begrenzen, fehlen jedoch.
• Backup vorhanden, aber uneinheitlich: Datenbank-Backups sind konfigurierbar, bei PostgreSQL mit 1 bis 365 Tagen.  Aufbewahrung und wählbarem Backup-Standort; MongoDB Enterprise unterstützt Offsite-Backups, für VMs gibt es einen eigenen Backup Service. Ein durchgängiger produktübergreifender Mechanismus fehlt; für Kubernetes-Workloads bleibt beispielsweise Velero nötig.

Unterm Strich: Für das heutige Testszenario ist das kein Malus, für ein wachsendes Unternehmen mit steigenden Anforderungen an Governance und Skalierung aber ein Punkt, den man im Auge behalten sollte.

Kundenorientierung & Weiterentwicklung – Es bewegt sich was

IONOS entwickelt sich sichtbar weiter, macht daraus aber keine klare Geschichte für Kunden.

• Keine öffentlich einsehbare Roadmap: IONOS veröffentlicht monatliche Release Notes inklusive RSS-Feed und macht damit ausgelieferte Änderungen transparent. Welche Themen als Nächstes kommen oder in welcher Reihenfolge, bleibt öffentlich jedoch weitgehend offen.
• MCP-Server zeigt Fortschritt, aber punktuell: Die Entwicklung wirkt eher wie ein einzelnes Innovationsprojekt als Teil einer klar kommunizierten Produktstrategie.
• Aktive Pflege der Terraform-Basis: Provider und Dokumentation werden sichtbar kontinuierlich erweitert, ein Zeichen für laufende Weiterentwicklung im Kern.
• Positionierung zwischen Hyperscaler und regionaler Cloud unklar: Es bleibt offen, ob IONOS auf Hyperscaler-Niveau mitziehen will oder sich bewusst auf eine schlankere, regionale Rolle konzentriert.
• Zurückhaltung bei Zukunftsaussagen: Konkrete Zusagen zu kommenden Features oder Zeiträumen bleiben rar, was Planungssicherheit für Kunden erschwert.

Unterm Strich: Es bewegt sich etwas bei IONOS, nur lässt sich von außen schwer einschätzen, wohin die Reise eigentlich geht.