Wir haben die IONOS Cloud ausführlich getestet. Danach hatten unsere Cloud-Architekten Fragen. IONOS antwortete ... und wir glauben, das könnte euch auch interessieren.

Stichtag: 31. August 2026

Enterprise Control Features

Frage: Wie können Unternehmen heute schon rollenbasierte Zugriffe umsetzen, solange die policy basierte IAM noch nicht produktiv ist?

Antwort: Aktuell können wir Zugriffsrechte noch nicht feingranular auf einzelne Services, Regionen oder Operationen wie read only, create only oder cannot delete beschränken. Eine policy basierte IAM konnten wir bisher nicht integrieren. Das wird noch etwas dauern.

Bis dahin arbeiten Kunden mit Users und Groups, rollenbasiertem Zugriff, Passwort Policies, Token Manager und IAM Federation über SAML oder OIDC für Single Sign On. Das deckt die gängigen Szenarien ab, ersetzt aber noch keine granularen Policies auf Operationsebene.

Frage: Confidential Kubernetes und Secrets Management sind für unter neun Monate angekündigt. Welches Quartal ist realistisch, und was ist der aktuelle Entwicklungsstand?

Antwort: Eine feste Quartalszahl können wir aktuell nicht nennen, das würde ich auch nicht versprechen wollen. Secrets Management ist gerade erst eingeführt, wir sammeln also noch echtes Nutzungsfeedback bevor wir das als stabil bezeichnen. Confidential VMs mit hardwaregestützter Speicherverschlüsselung via AMD SEV-SNP sind bereits als reguläres Produkt verfügbar. Confidential Kubernetes ist als fixer Roadmap Punkt mit einem Zeithorizont von unter neun Monaten eingeplant, aber wir geben aus Wettbewerbsgründen grundsätzlich keine öffentlichen Termine für einzelne Features raus. Was ich sagen kann: beide Themen sind priorisiert und in aktiver Entwicklung, nicht nur angekündigt und dann liegen gelassen.

Kosten-Management

Frage: Bietet das Portal stündliche oder tägliche Kostengranularität, oder ist das nur per API zugänglich?

Antwort: Im Portal gibt es die Cost & Usage Ansicht, dort wird täglich aktualisiert, mit bis zu 24 Stunden Verzug. Feinere, wirklich granulare Daten pro Ressource holt man sich über die Billing API, dort auch programmatisch und detaillierter als im Portal. Cost Alerts lassen sich direkt im Portal mit Schwellenwerten einrichten, das greift also schon bevor die Rechnung kommt. Einen Preiskalkulator gibt es ebenfalls, getrennt vom Portal unter cloud-price-calculator.ionos.de.

Frage: Wie verhindert IONOS, dass Entwickler versehentlich hohe Kosten verursachen, bevor das im Portal sichtbar wird?

Antwort: Vollständig verhindern lässt sich das aktuell nicht. Die Cost Alerts warnen erst, wenn ein Schwellenwert erreicht ist, das ist reaktiv, kein Ausgabenlimit im Vorfeld. Da die Kostendaten im Portal mit bis zu 24 Stunden Verzug aktualisiert werden, sieht ein Entwickler eine Kostenspitze also erst am nächsten Tag. Wer das vermeiden will, muss selbst über die Billing API eigene Checks bauen oder Ressourcenquotas auf Kontoebene setzen. Ein echtes Budget Cap, das Deployments automatisch blockiert, bieten wir bisher nicht.

Frage: Gibt es einen Preiskalkulator für komplexere Architekturen, oder muss der Kunde selbst rechnen?

Antwort: Ja, es gibt einen Preiskalkulator unter cloud-price-calculator.ionos.de. Für Standardkomponenten wie Compute, Storage und Netzwerk lässt sich damit gut kalkulieren. Bei komplexeren Architekturen mit mehreren Services, Region übergreifenden Setups oder Add-ons wie Logging oder Backup muss der Kunde die Einzelposten aber selbst zusammenrechnen, ein vollständiges End to End Angebot für komplette Architekturen liefert der Kalkulator nicht.

Kubernetes und Netzwerk

Frage: Gibt es einen nativen Cloud Load Balancer Controller für Managed Kubernetes, damit Worker Nodes im privaten Netzwerk bleiben können?

Antwort: Nein, es gibt keinen nativen Cloud Load Balancer Controller im Sinne der Hyperscaler. Der Kubernetes Service-Typ LoadBalancer wird derzeit nur für Public Node Pools unterstützt. Dabei wird einer statischen IP eines Kubernetes Nodes eine zusätzliche Adresse zugewiesen; dieser Node übernimmt die Rolle des Load Balancers. Zum Erhalt der Client-IP sind externalTrafficPolicy: Local und die Annotation cloud.ionos.com/node-selector nötig, damit die Load-Balancer-IP am passenden Node hängt.

Private Node Pools unterstützen den Service-Typ LoadBalancer dagegen derzeit nicht. Für Setups mit privaten Worker Nodes empfehlen wir deshalb einen Network Load Balancer oder Application Load Balancer außerhalb des Clusters, kombiniert mit einem Ingress Controller. Die Control Plane bleibt auch bei Private Node Pools über das Internet erreichbar und lässt sich per IP-Restriktion absichern.

Frage: Können Anwendungen im Cluster per Service Account oder OIDC temporäre Credentials für Object Storage beziehen?

Antwort: Nein, das ist so bei IONOS aktuell nicht möglich. Für Object Storage gibt es nur einen dauerhaften Access Key und Secret Key pro User, keine Workload Identity Federation über OIDC. Diese Keys müssen manuell erzeugt und verwaltet werden, maximal fünf pro User. Ein AWS IRSA oder Azure Workload Identity vergleichbarer Mechanismus mit kurzlebigen, automatisch rotierten Tokens fehlt.

Betrieb und Resilienz

Frage: Welche nativen Backup und Restore Mechanismen gibt es für Datenbanken und Kubernetes Workloads, und wie aufwendig ist die Wiederherstellung im Ernstfall?

Antwort: Für Datenbanken über DBaaS gibt es tägliche automatische Backups mit Point in Time Recovery, standardmäßig 7 Tage, konfigurierbar bis 365 Tage. Wiederherstellung läuft per API oder DCD, entweder in place oder als neuer Cluster aus einem Backup. Während der Restore ist die Datenbank nicht erreichbar, das dauert je nach Größe einige Minuten bis Stunden.

Für Kubernetes Workloads selbst gibt es keinen nativen, IONOS spezifischen Backup-Mechanismus. Persistent Volumes lassen sich über Snapshots des Block Storage sichern, für den Rest des Cluster-Zustands braucht man ein eigenes Tool wie Velero.

Der Aufwand im Ernstfall ist für Datenbanken überschaubar, ein API Call reicht. Für Kubernetes Workloads hängt es davon ab, wie gut man das selbst vorbereitet hat, ohne eigenes Backup Tooling ist die Wiederherstellung deutlich aufwendiger.

Frage: Gibt es einen vollständig gemanagten Container Service vergleichbar mit AWS Fargate?

Antwort: Nein. IONOS bietet keinen direkten Fargate Gegenpart, bei dem man nur einen Container übergibt und keine Infrastruktur verwaltet. Die eigene Positionierung ist Managed Kubernetes, dort verwaltet IONOS Control Plane, Updates und Patching, aber die Nodes bleiben sichtbare Infrastruktur, keine serverlose Ausführung pro Container.

Frage: Gibt es schon eine grobe Zeitschiene für automatisches kaskadierendes Löschen abhängiger Ressourcen?

Antwort: Auf Kundenseite ist das ein bekannter Wunsch, aber wir haben aktuell noch keinen Termin dafür, das steht bei uns als offenes Roadmap Thema.

Ökosystem und Transparenz

Frage: Wie bekommen Enterprise Kunden verlässliche Zukunftssicht, wenn es keine öffentliche Roadmap gibt?

Antwort: Eine öffentliche Roadmap gibt es bewusst nicht, der Markt verändert sich zu schnell und wir müssen Ressourcen kurzfristig verschieben können. Außerdem würden regionale Wettbewerber davon überproportional profitieren. Enterprise Kunden bekommen Zukunftssicht stattdessen im direkten Austausch mit ihrem Account Team.

Frage: Warum verwendet Object Storage eine andere Regionsbezeichnung als der Rest der Plattform?

Antwort: Object Storage ist S3 kompatibel, die Regionsbezeichnungen sind jedoch historisch gemischt. eu-central-2 (Berlin) und eu-south-2 (Logroño) folgen der marktüblichen Benennung; Frankfurt läuft zugleich als Region de und ist dort der Default. Zusätzlich gibt es in Frankfurt Object Storage unter eu-central-4. Die gemischte Namensgebung ist historisch entstanden: IONOS startete in Frankfurt mit de; diese Bezeichnung konnte später wegen bestehender Pfade nicht mehr geändert werden.