← Blog

Cloud-Hosting auswählen: Kriterien und Risiken

Abstrakte Cloud mit Servern als Titelbild für Cloud-Hosting

Beispiel: Ein Cloud-Angebot nennt einen günstigen Monatspreis, aber niemand hat festgelegt, wer nach einer fehlerhaften Datenänderung den Geschäftsablauf wiederherstellt. Wählen Sie Hosting deshalb anhand des Workloads und einer getesteten Zuständigkeitskette: Last, Datenverarbeitung, Verfügbarkeit, Backup, Restore und Betriebskosten gehören in denselben Vergleich. Trennen Sie die Rolle des Infrastruktur-Anbieters von der eines Entwicklungs- oder Betriebspartners, bevor Sie Zusagen bewerten.

Beginnen Sie mit dem Workload

Beschreiben Sie Ihre wichtigsten Nutzerabläufe und den Schaden eines Ausfalls. Für eine interne Testumgebung genügen andere Ziele als für einen Bestellprozess. Legen Sie fest, wie lange ein Dienst ausfallen darf und wie viel Datenverlust tragbar wäre. Daraus folgen Anforderungen an Backup, Replikation, Überwachung und Reaktion.

Strichzeichnung eines Servers als Teil einer Cloud-Infrastruktur

Fragen Sie, wer Patches einspielt, Schlüssel verwaltet, Zugriffe prüft und bei einem Vorfall informiert. Das BSI beschreibt beim Outsourcing, dass die Verantwortung für Informationssicherheit bei der auslagernden Organisation bleibt. Ein Vertrag kann Aufgaben verteilen, aber diese Verantwortung nicht durch einen Werbesatz ersetzen.

Fünf Fragen für den Anbieter-Vergleich

  1. Betrieb: Welche Verfügbarkeit ist vereinbart, wie wird sie gemessen und welche Ausschlüsse gelten?
  2. Wiederherstellung: Wo liegen Backups, wie oft wird ein Restore getestet und welches Ergebnis wurde erreicht?
  3. Daten: In welchen Regionen werden Daten und Protokolle verarbeitet, welche Unterauftragnehmer sind beteiligt und welche Vertragsunterlagen gibt es?
  4. Kosten: Was kosten Rechenleistung, Speicher, Netzwerkverkehr, Support, Tests und ein möglicher Wechsel unter realistischer Last?
  5. Ausstieg: Wie exportieren Sie Daten, Konfiguration und Schlüssel, und wie lange dauert ein Probelauf auf einer anderen Umgebung?

Bewerten Sie jede Antwort mit Beleg und Verantwortlichem. „Skalierbar“ oder „sicher“ ohne definierte Last, Kontrollen und Tests lässt sich nicht vergleichen.

Verantwortung für einen Restore zuweisen

Schreiben Sie für die wichtigste Anwendung einen Ausfallfall auf: Die Datenbank ist erreichbar, aber nach einer fehlerhaften Änderung sind Bestellungen unvollständig. Der Cloud-Anbieter kann einen Snapshot bereitstellen; ob die Anwendung danach konsistente Aufträge zeigt, muss Ihr Team oder ein beauftragter Anwendungspartner prüfen. Fragen Sie im Angebot nach vier getrennten Rollen: Wer erkennt den Fehler? Wer entscheidet über den Wiederherstellungspunkt? Wer führt den Restore aus? Wer nimmt den Geschäftsablauf ab?

Prüfen Sie diese Zuordnung in einer Testumgebung. Halten Sie Zeitpunkt der letzten brauchbaren Daten, Dauer bis zum nutzbaren Dienst, fehlende Konfiguration und Abweichung vom vereinbarten Ziel fest. Ein Backup-Protokoll allein belegt keine Wiederherstellung. Wenn zusätzlich ein externer Partner Fehler in der Anwendung behebt, legen Sie die Übergabe zwischen Anwendungssupport und Betrieb im selben Vorfall fest.

Architektur und Vertrag getrennt prüfen

Eine gut entworfene Anwendung kann bei passendem Betrieb wachsen; ein teurer Anbieter repariert keine ineffizienten Abfragen oder fehlende Fehlerbehandlung. Messen Sie die Engpässe Ihrer Software. Prüfen Sie danach, ob eine gemanagte Datenbank, automatische Skalierung oder eine einfachere Architektur den größten Nutzen bringt.

Wenn Sie einen Entwicklungs- oder DevOps-Partner hinzuziehen, halten Sie fest, welche Cloud-Konten Ihnen gehören, wer Deployments freigibt und wie Wissen übergeben wird. Ein Partner kann den Betrieb unterstützen, sollte aber keine nicht vereinbarte 24/7-Abdeckung oder risikofreie Verfügbarkeit versprechen.

Eine kleine Kostenrechnung verhindert falsche Sicherheit

Ein Hosting-Angebot kann bei Grundlast günstig aussehen und bei Lastspitzen, ausgehendem Datenverkehr oder teurem Support anders ausfallen. Rechnen Sie mindestens drei Szenarien: normalen Monat, einen erwarteten Peak und einen Vorfall mit Wiederherstellung. Nehmen Sie internen Betriebsaufwand sowie die Kosten eines möglichen Wechsels auf. Zahlen aus dieser Rechnung sind Planungsannahmen, keine Zusage des Anbieters.

Bitten Sie den Anbieter um eine Beispielrechnung für Ihre Architektur, nicht für einen abstrakten Standardserver. Prüfen Sie, ob der Preis automatische Backups, Testumgebungen, Monitoring und Bereitschaft wirklich einschließt. Wenn eine Leistung nur „optional“ ist, gehört sie in den Vergleich, sobald Ihr Betrieb sie benötigt.

Eine Zusage muss testbar sein

Eine versprochene Verfügbarkeit sagt wenig über die Wiederherstellung eines konkreten Dienstes. Fordern Sie den Ablauf für einen Ausfall Ihrer wichtigsten Datenbank an: Wer erhält einen Alarm, wer entscheidet über den Restore, wie wird die Integrität geprüft und wie erfahren Nutzer vom Ergebnis? Ein Probelauf mit dokumentiertem Resultat ist stärker als ein Logo oder eine allgemeine Sicherheitsbehauptung.

Den Ausstieg einmal durchspielen

Eine Exit-Klausel hilft erst, wenn Sie wissen, was tatsächlich übertragen werden muss. Inventarisieren Sie Daten, Datenbankschema, Konfiguration, Schlüssel, Domains, Zertifikate, Infrastrukturdefinitionen und Betriebswissen. Klären Sie, welche Konten Ihrem Unternehmen gehören und welche Ressourcen nur im Konto des Anbieters existieren. Lassen Sie sich Exportformate und die Unterstützung während eines Wechsels erklären.

Ein kleiner Probelauf kann mit einer Testumgebung beginnen: Exportieren Sie einen Datenausschnitt, stellen Sie ihn in einer anderen Umgebung wieder her und prüfen Sie einen zentralen Nutzerablauf. Protokollieren Sie Zeit, Fehler und fehlende Informationen. Das ist kein Beweis, dass ein vollständiger Wechsel reibungslos wäre, zeigt aber Abhängigkeiten, bevor ein Ausfall oder eine Preiserhöhung den Zeitplan vorgibt.

Häufige Fragen

Brauchen wir für Ausfallsicherheit mehrere Cloud-Anbieter?

Nicht automatisch. Prüfen Sie zuerst, welchen Ausfall Ihre Anwendung verkraften muss und ob ein zweiter Anbieter diesen Fall tatsächlich abdeckt. Mehrere Plattformen erhöhen Aufwand für Datenabgleich, Betrieb, Sicherheit und Tests. Ein sauber getesteter Wiederherstellungsweg bei einem Anbieter kann für manche Anwendungen die bessere erste Investition sein.

Wie erkennen wir, ob Backups im Ernstfall helfen?

Lassen Sie einen Restore mit einer repräsentativen Anwendung und ihren Abhängigkeiten durchführen. Messen Sie Datenstand und Dauer bis zur nutzbaren Funktion. Protokollieren Sie fehlende Schlüssel, Konfiguration oder Rechte. Erst ein solcher Test zeigt, ob die vereinbarten Ziele für Datenverlust und Wiederanlauf erreichbar sind.

Warum reicht der monatliche Serverpreis für den Vergleich nicht?

Zur tatsächlichen Rechnung gehören je nach Architektur auch Speicher, Datenverkehr, Backups, Überwachung, Support und Betriebsarbeit. Legen Sie für alle Angebote dieselben Annahmen zu Last, Wachstum und Verfügbarkeit zugrunde. Lassen Sie einen normalen Monat und einen Last- oder Störfall berechnen, damit unterschiedliche Preisgrenzen sichtbar werden.

Wann Scorpion Power helfen kann

Scorpion Power nennt Cloud- und Systemmodernisierung, DevOps und Softwareentwicklung als Leistungen. Wir können Architektur, Migration oder Automatisierung mit Ihnen prüfen. Ob laufender Hosting-Betrieb Teil eines konkreten Angebots ist, muss ausdrücklich geklärt werden. Senden Sie uns die Anwendung, Ihre Lastannahmen und die offene Betriebsfrage.

Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

3rd Party Cookies

This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.

Keeping this cookie enabled helps us to improve our website.