FinOps – Multi-Cloud-Kosten nachhaltig senken
FinOps verbindet Finance, IT und Business, schafft Cloud-Transparenz und senkt Verschwendung in Multi-Cloud.
Modelle vergleichen, Kosten planen & Sicherheit prüfen. Mit Schritt-für-Schritt-Anleitung.

Wer seine IT-Infrastruktur in die Cloud migrieren möchte, sollte zuerst klären, welche Anwendungen davon profitieren und welche Anforderungen der neue Betrieb erfüllen muss. Entscheidend sind die Abhängigkeiten zwischen Systemen, die benötigte Leistung, Sicherheitsvorgaben und die Gesamtkosten. Daraus entstehen die Zielarchitektur und ein Migrationsplan mit Pilotprojekt, Tests und schrittweiser Umstellung.
Dieser Leitfaden unterstützt IT-Verantwortliche und Geschäftsführungen mittelständischer Unternehmen bei diesen Entscheidungen. Er erklärt die Grundlagen der Cloud-Infrastruktur, vergleicht Betriebsmodelle und zeigt, wie Sie die Migration vorbereiten und den anschließenden Betrieb organisieren.
Eine Cloud-Infrastruktur umfasst die Hardware- und Softwarekomponenten, mit denen Cloud-Dienste bereitgestellt werden. Dazu gehören Server, Datenspeicher, Netzwerke und Virtualisierung. Unternehmen können diese Ressourcen über Verwaltungsportale oder Programmierschnittstellen bereitstellen und an ihren Bedarf anpassen. [1]
Auch die Cloud läuft auf physischer Hardware in Rechenzentren. Der Unterschied liegt vor allem darin, wie Ressourcen genutzt und verwaltet werden: Statt jeden Server einzeln zu beschaffen, beziehen Unternehmen beispielsweise virtuelle Maschinen, Speicher oder verwaltete Dienste. Eine private Cloud kann auch im eigenen Rechenzentrum betrieben werden. [2]
Cloud Computing bezeichnet die Bereitstellung und Nutzung dieser IT-Leistungen. Die Cloud-Infrastruktur bildet dafür die technische Grundlage.
IT-Infrastruktur umfasst mehr als Server. Dazu zählen auch Arbeitsplatzgeräte, Betriebssysteme, Netzwerke und die technischen Grundlagen für Anwendungen wie ERP oder CRM. [3] Bei einer Cloud-Migration müssen deshalb auch die verbleibenden lokalen Komponenten berücksichtigt werden: Endgeräte, WLAN, Internetanschlüsse und gegebenenfalls Produktionssysteme bleiben Teil der gesamten IT-Umgebung.
Die Infrastruktur umfasst die vorhandenen technischen Komponenten. Die IT-Architektur beschreibt, wie diese zusammenwirken und nach welchen Regeln sie aufgebaut werden. Eine Cloud-Architektur legt beispielsweise fest, wie Anwendungen, Daten und Netzwerke verbunden sind. [4]
Für die Migration bedeutet das: Erst definieren Sie den gewünschten Aufbau. Anschließend wählen Sie die passenden Ressourcen und Dienste aus.
Rechenleistung, Speicher und Netzwerke bilden den technischen Kern. Für einen verlässlichen Betrieb kommen Sicherheits- und Verwaltungsfunktionen hinzu.
Rechenressourcen führen Anwendungen aus, beispielsweise auf virtuellen Maschinen oder in Containern.
Blockspeicher dient etwa als Laufwerk für virtuelle Maschinen. Dateispeicher unterstützt gemeinsame Dateiablagen. Objektspeicher eignet sich unter anderem für große Mengen unstrukturierter Daten.
Virtuelle Netzwerke, Routing und Verbindungen zu Standorten ermöglichen die Kommunikation zwischen Anwendungen und Nutzern. [1, 4]
Welche Kombination sinnvoll ist, hängt von den Anwendungen ab. Eine Datenbank hat andere Leistungsanforderungen als ein Dokumentenarchiv. Dimensionieren Sie Ressourcen deshalb anhand gemessener Nutzung und erwarteter Lastspitzen.
Virtualisierung entkoppelt nutzbare Ressourcen von der einzelnen physischen Maschine. So können mehrere virtuelle Systeme dieselbe Hardware nutzen. Automatisierung unterstützt die wiederholbare Bereitstellung und Verwaltung dieser Ressourcen. [5]
In der Praxis lassen sich Netzwerke, Zugriffsregeln und Systeme über dokumentierte Konfigurationen aufbauen. Das erleichtert Änderungen und die Wiederherstellung. Container-Orchestrierung kann für geeignete Anwendungen sinnvoll sein; sie ist keine Voraussetzung für jede Cloud-Migration.
On-Premises bedeutet, dass Systeme in der lokalen Umgebung des Unternehmens betrieben werden. Bei extern bezogenen Cloud-Diensten übernimmt der Anbieter einen Teil der Bereitstellung und des Betriebs. Wie weit diese Entlastung reicht, hängt vom Dienstmodell und vom Vertrag ab.
| Kriterium | On-Premises | Extern bezogene Cloud-Dienste |
|---|---|---|
| Hardware | Unternehmen beschafft oder least sie | Anbieter stellt die zugrunde liegende Hardware bereit |
| Kapazität | Erweiterung innerhalb vorhandener Reserven oder durch Beschaffung | Anpassung innerhalb verfügbarer Dienste, Kontingente und Vertragsgrenzen |
| Kosten | Investitionen plus laufender Betrieb | Nutzungsabhängige oder vereinbarte laufende Entgelte plus eigener Aufwand |
| Administration | Internes Team oder beauftragter Dienstleister | Aufgaben verteilen sich nach Dienstmodell und Vertrag |
| Standortanbindung | Lokales Netz; externe Verbindungen nach Bedarf | Leistungsfähige Verbindung zu den genutzten Cloud-Diensten erforderlich |
| Sicherheit | Unternehmen organisiert Schutzmaßnahmen | Anbieter und Kunde übernehmen unterschiedliche Schutzaufgaben |
Lokale Infrastruktur und Cloud lassen sich kombinieren. Die passende Lösung ergibt sich aus den Anforderungen der einzelnen Anwendungen.
Die Cloud ist besonders dann hilfreich, wenn Ressourcen kurzfristig benötigt werden oder der Bedarf stark schwankt. Sie kann außerdem den Aufwand für den Betrieb physischer Infrastruktur verringern.
Neue Umgebungen können ohne vorherige Hardwarebeschaffung eingerichtet werden.
Kapazitäten lassen sich bei geeigneter Architektur an steigende und sinkende Last anpassen.
Bei externen Diensten übernimmt der Anbieter die physische Infrastruktur.
Unternehmen können etwa verwaltete Datenbanken oder Analyseplattformen nutzen. [1]
Diese Vorteile entstehen nicht automatisch. Eine Anwendung muss zusätzliche Ressourcen auch nutzen können. Und eine einzelne virtuelle Maschine wird durch ihren Standort in der Cloud noch nicht ausfallsicher. Verfügbarkeit, Datensicherung und Wiederherstellung müssen gezielt geplant werden.
Ein guter Anlass ist beispielsweise ein anstehender Hardwarewechsel, Wachstum an mehreren Standorten oder ein hoher Aufwand für Wartung und Bereitstellung. Auch neue Anwendungen können den Ausschlag geben, wenn passende Cloud-Dienste ihre Umsetzung erleichtern.
Formulieren Sie ein messbares Ziel: Soll die Bereitstellung einer Testumgebung schneller werden? Soll die Wiederherstellung nach einem Ausfall verbessert werden? Oder soll das IT-Team weniger Zeit mit Hardwarewartung verbringen? Diese Ziele helfen später bei der Bewertung des Projekts.
Wesentliche Risiken sind unkontrollierte laufende Kosten, Abhängigkeiten von Anbietern, Fehlkonfigurationen und Leistungsprobleme durch ungünstige Netzwerkverbindungen. Ein Anbieterwechsel kann außerdem aufwendig werden, wenn Anwendungen eng an spezielle Dienste gebunden sind.
Prüfen Sie deshalb vor der Migration, welche Fähigkeiten Ihr Team benötigt, wie Störungen bearbeitet werden und wie Daten bei einem späteren Wechsel exportiert werden können.
Public Cloud, Private Cloud und Hybrid Cloud beschreiben unterschiedliche Bereitstellungsmodelle. Multi-Cloud bezeichnet die Nutzung mehrerer Cloud-Anbieter. Die Begriffe sollten bei der Planung getrennt betrachtet werden.
| Modell | Bedeutung | Worauf Sie achten sollten |
|---|---|---|
| Public Cloud | Ein Anbieter stellt Dienste für mehrere Kunden bereit; deren Ressourcen werden voneinander isoliert | Verantwortlichkeiten, Kostensteuerung und benötigte Dienste |
| Private Cloud | Cloud-Umgebung zur ausschließlichen Nutzung durch eine Organisation | Betriebsaufwand, Kapazitätsplanung und Anforderungen an Isolation |
| Hybrid Cloud | Verbundene lokale beziehungsweise private Umgebung und Public Cloud | Schnittstellen, Identitäten und Netzwerkleistung |
| Multi-Cloud | Nutzung von Diensten mehrerer Cloud-Anbieter | Zusätzlicher Aufwand für Betrieb, Sicherheit und Integration |
Die Wahl eines Modells allein garantiert weder Sicherheit noch Datenschutz. Maßgeblich sind die konkrete Umsetzung und die eingesetzten Dienste.
Eine hybride IT-Infrastruktur kann sinnvoll sein, wenn einige Anwendungen eng mit lokalen Systemen verbunden sind und andere von Cloud-Diensten profitieren. Sie erlaubt eine schrittweise Verlagerung statt einer vollständigen Umstellung zu einem einzigen Termin.
Ein mögliches Szenario: Produktionsnahe Systeme bleiben zunächst vor Ort. Eine neue Analyseanwendung verarbeitet ausgewählte Daten in der Cloud. Dafür müssen Datenflüsse, Zugriffsrechte und Netzwerkverbindungen gemeinsam geplant werden.
Mehrere Anbieter können sinnvoll sein, wenn bestimmte Dienste benötigt werden oder bewusst unterschiedliche Plattformen genutzt werden sollen. Die zusätzliche Komplexität muss jedoch zum Nutzen passen. Eine zweite Cloud schafft noch keine Ausfallsicherheit: Dafür braucht es eine getestete Architektur, die den Ausfall tatsächlich abfangen kann.
| Dienstmodell | Bezogene Leistung | Typische Aufgaben des Unternehmens |
|---|---|---|
| IaaS – Infrastructure as a Service | Rechenleistung, Speicher und Netzwerk | Betriebssysteme, Anwendungen, Konfiguration und Zugriffe verwalten |
| PaaS – Platform as a Service | Verwaltete Plattform für Anwendungen | Eigene Anwendung, Daten und freigegebene Einstellungen verwalten |
| SaaS – Software as a Service | Fertige Software als Dienst | Nutzer, Berechtigungen, Daten und Anwendungseinstellungen organisieren |
Die genaue Aufgabenverteilung ist dienstabhängig. Auch bei SaaS bleiben Verantwortung für Daten, Identitäten und die eigenen Einstellungen beim Unternehmen. [6]
Erstellen Sie zuerst eine Bestandsaufnahme. Sie sollte nicht nur Server auflisten, sondern auch die Geschäftsprozesse und technischen Abhängigkeiten erfassen, die daran hängen.
Dokumentieren Sie für jede Anwendung:
Die tolerierbare Ausfallzeit wird häufig als RTO bezeichnet. Das RPO beschreibt, wie viel Datenverlust zeitlich höchstens akzeptabel ist. Beide Werte bestimmen, welche Sicherungs- und Wiederherstellungsverfahren erforderlich sind.
Bewerten Sie jede Anwendung einzeln. Gute Kandidaten können Systeme mit schwankendem Ressourcenbedarf, wenigen lokalen Abhängigkeiten oder einem hohen Modernisierungsbedarf sein. Prüfen Sie dafür auch die Freigaben des Softwareherstellers.
Ein Dateiserver ist nicht automatisch einfach zu migrieren: Berechtigungen, große Dateien und Anwendungen mit direktem Dateizugriff können die Umstellung erschweren. Ebenso kann ein ERP-System cloudfähig sein, wenn Schnittstellen, Lizenzen und Leistung dazu passen. Entscheiden Sie anhand dieser Anforderungen statt allein anhand der Anwendungskategorie.
Für unterschiedliche Anwendungen kommen unterschiedliche Strategien infrage. Das verbreitete Modell der „7 Rs“ hilft, diese Entscheidungen zu ordnen. [7]
| Strategie | Vorgehen |
|---|---|
| Rehost | Anwendung weitgehend unverändert in die Cloud verlagern, auch Lift-and-Shift genannt |
| Replatform | Einzelne technische Komponenten anpassen, ohne die Anwendung grundlegend neu zu entwickeln |
| Refactor | Anwendung für die Zielarchitektur grundlegend überarbeiten |
| Repurchase | Bestehende Software durch eine andere Lösung ersetzen, beispielsweise SaaS |
| Relocate | Bestehende virtualisierte Umgebung auf eine kompatible Zielplattform verschieben |
| Retain | Anwendung vorerst in der bisherigen Umgebung behalten |
| Retire | Nicht mehr benötigte Anwendung stilllegen |
Lift-and-Shift kann den ersten Umzug vereinfachen, übernimmt aber häufig auch bestehende Schwächen. Eine Modernisierung kann später folgen. Legen Sie für jede Anwendung fest, welche Strategie ihren Zweck am besten erfüllt und welcher Aufwand dafür vertretbar ist.
Ein belastbarer Migrationsplan verbindet technische Umsetzung mit fachlicher Abnahme. Die folgenden Schritte bieten dafür einen praktischen Rahmen.
Klären Sie ausdrücklich, wie nach einem fehlgeschlagenen Wechsel weitergearbeitet wird. Dazu gehört der Umgang mit Daten, die während der Umstellung neu entstanden sind. Ein Rückfall darf keine widersprüchlichen Datenstände erzeugen.
Cloud-Sicherheit folgt einer geteilten Verantwortung. Der Anbieter schützt die von ihm betriebenen Ebenen; das Unternehmen sichert die Daten, Identitäten und Komponenten ab, die es selbst kontrolliert. Die Aufteilung verändert sich je nach Dienstmodell. [6]
Planen Sie insbesondere:
Eine synchronisierte Dateiablage kann versehentliche Löschungen oder unerwünschte Änderungen weitergeben. Auch redundante Speicherung schützt nicht automatisch vor jedem Bedienfehler oder Angriff. Legen Sie deshalb fest, welche Daten gesichert werden, wie lange Sicherungen aufbewahrt werden und wer sie wiederherstellen kann.
Wenn ein Cloud-Anbieter personenbezogene Daten in Ihrem Auftrag verarbeitet, benötigen Sie eine Vereinbarung nach Artikel 28 DSGVO. Prüfen Sie unter anderem Weisungsrechte, Unterauftragsverarbeiter, Sicherheitsmaßnahmen und Regelungen zur Datenrückgabe und Löschung.
Ein Rechenzentrum in Deutschland genügt als alleiniger Nachweis nicht. Berücksichtigen Sie auch Backups, Protokolldaten und mögliche Supportzugriffe aus anderen Ländern. Bei Drittlandübermittlungen sind zusätzlich die Voraussetzungen aus Kapitel V DSGVO zu prüfen. [8]
Eine Datenschutz-Folgenabschätzung ist erforderlich, wenn die geplante Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Sensible Daten können dabei ein wichtiger Faktor sein. Die Pflicht ergibt sich jedoch aus der konkreten Verarbeitung und deren Risiken, nicht pauschal aus jeder Cloud-Nutzung. [9]
ISO-27001-Zertifikate und C5-Prüfberichte können die Bewertung unterstützen. Der BSI-Kriterienkatalog C5 beschreibt Anforderungen an die Informationssicherheit von Cloud-Diensten. Die Prüfungsergebnisse dienen als Grundlage für die eigene Risikoanalyse. [10]
Prüfen Sie Geltungsbereich, geprüfte Dienste und Zeitraum der Nachweise. Ein C5-Testat ist keine pauschale Bestätigung der DSGVO-Konformität Ihres Einsatzes.
Die Kosten hängen von Anwendungen, Datenvolumen, Anpassungsbedarf und Betriebsanforderungen ab. Eine belastbare Kalkulation vergleicht die Gesamtkosten, auch Total Cost of Ownership oder TCO genannt, für denselben Zeitraum und ein vergleichbares Leistungsniveau.
Einmalige Kosten entstehen beispielsweise für Analyse, Zielarchitektur, Datenübertragung, Anwendungsanpassungen, Tests und Schulungen. Laufende Kosten umfassen Cloud-Ressourcen, Lizenzen, Netzwerkverbindungen, Datentransfer, Backup, Sicherheit und Administration. Während der Umstellung kommen gegebenenfalls Kosten für den Parallelbetrieb hinzu.
Das lässt sich nur für den konkreten Einsatz beantworten. Bei schwankender Last kann bedarfsgerechte Skalierung wirtschaftlich sein. Bei dauerhaft hoher Auslastung können lokale oder dedizierte Ressourcen günstiger ausfallen. Berücksichtigen Sie auf beiden Seiten auch Personalaufwand, Wartung und Wiederherstellung.
Vermeiden Sie Preisvergleiche, die nur eine virtuelle Maschine einem physischen Server gegenüberstellen. Entscheidend ist, ob beide Varianten dieselben Anforderungen erfüllen.
Ordnen Sie Ressourcen Projekten oder Kostenstellen zu. Richten Sie Budgets und Warnmeldungen ein. Prüfen Sie ungenutzte Systeme und zu große Kapazitäten regelmäßig. Langfristige Preisbindungen sollten Sie erst eingehen, wenn die Grundlast ausreichend bekannt ist.
Budgetwarnungen begrenzen Ausgaben nicht automatisch. Definieren Sie deshalb, wer bei einer Überschreitung reagiert und welche Maßnahmen zulässig sind.
Eine einzelne, gut vorbereitete Anwendung lässt sich wesentlich schneller umstellen als eine gewachsene Umgebung mit vielen Schnittstellen. Eine allgemeingültige Dauer wäre deshalb irreführend.
Planen Sie Analyse, Vertragsprüfung, Vorbereitung, Pilot, Migrationswellen und Stabilisierung getrennt. Datenvolumen, verfügbare Bandbreite, Testaufwand und zulässige Wartungsfenster bestimmen den Zeitbedarf. Der Pilot liefert erste belastbare Erfahrungswerte für die weitere Planung.
Unterscheiden Sie zwischen dem Anbieter der Cloud-Plattform und dem Dienstleister für Migration und Betrieb. Ein Unternehmen kann beide Rollen übernehmen; die Zuständigkeiten müssen trotzdem klar vereinbart werden.
Bewerten Sie die technische Eignung, Erfahrung mit Ihren Anwendungen, Datenschutzunterlagen, Sicherheitsnachweise und Kostenstruktur. Fragen Sie außerdem nach Reaktionszeiten, Wiederherstellung, Betriebsdokumentation und Unterstützung bei einem späteren Anbieterwechsel.
Beschreiben Sie Ihr Cloud-Projekt über IT-Dock. Halten Sie dafür die wichtigsten Anwendungen, Datenmengen, Sicherheitsanforderungen und den gewünschten Zeitrahmen fest. Mit einem klaren Anforderungsprofil können Sie passende Dienstleister gezielt ansprechen und Angebote sinnvoll vergleichen.
Vergleichen Sie den neuen Betrieb mit den anfangs festgelegten Zielen. Prüfen Sie Kosten, Leistung, Störungen und Wiederherstellungsfähigkeit. Passen Sie Kapazitäten an die gemessene Nutzung an und aktualisieren Sie Rechte sowie Dokumentation bei Änderungen.
Regelmäßige Wiederherstellungstests und klare Zuständigkeiten helfen, die Umgebung dauerhaft verlässlich zu betreiben. Bei veränderten Anforderungen können Sie Dienste ergänzen, Anwendungen modernisieren oder einzelne Systeme neu bewerten.
Erfassen Sie Ihre Anwendungen, Verantwortlichen und Schnittstellen. Ergänzen Sie Auslastung, Schutzbedarf und aktuelle Kosten. Diese Bestandsaufnahme zeigt, welche Systeme sich für einen Pilot eignen und welche Anforderungen Ihre künftige Cloud-Infrastruktur erfüllen muss.
Die Kennziffern beziehen sich auf die zugehörigen Abschnitte. Recherche und Überarbeitung: 2. Oktober 2026.
Kommentare (0)
Noch keine Kommentare vorhanden.