Multi-Cloud: wann sinnvoll, wann nicht
Worum es geht: Multi-Cloud wird oft als Default-Strategie verkauft. Welche Outcomes sie real liefert, welche Kosten sie verursacht und wann eine bewusste Single-Cloud-Strategie ehrlicher ist.
Im Zentrum: messbare Outcomes und Architekturprinzipien, keine Implementierungsdetails.
Multi-Cloud wird oft als Default-Strategie verkauft. Welche Outcomes sie real liefert, welche Kosten sie verursacht und wann eine bewusste Single-Cloud-Strategie ehrlicher ist.
Dieser Artikel folgt einer einfachen Logik: WHAT statt HOW. Was beobachtbar ist, was sich in der Praxis bewährt hat, welche Prinzipien tragen, ohne vertrauliche Implementierungsdetails, Mandanten-IP oder die proprietären Vorgehensweisen offenzulegen, die in der direkten Zusammenarbeit den Unterschied machen.
Wer sich für die konkrete Umsetzung interessiert, findet am Ende des Artikels einen Hinweis auf das persönliche Gespräch.
Warum Cloud-Kosten eine Architekturfrage sind
Die meisten FinOps-Initiativen beginnen mit der falschen Frage. Sie fragen: "Wo können wir sparen?", und landen bei Reserved Instances, Spot-Pricing und Tagging-Standards.
Die richtige Frage ist: "Welche Architekturentscheidungen erzeugen welche Kostenstrukturen?" Damit verschiebt sich die Diskussion von der Operations- auf die Architektur-Ebene, wo die Hebelwirkung um Grössenordnungen höher ist.
Multi-Cloud wird oft als Default-Strategie verkauft. Welche Outcomes sie real liefert, welche Kosten sie verursacht und wann eine bewusste Single-Cloud-Strategie ehrlicher ist.
Welche Outcomes realistisch sind
In der Praxis lassen sich vier Kategorien von Outcomes beobachten:
- Kostentransparenz. Klare Zuordnung von Cloud-Kosten zu Geschäftsergebnissen, Produkten oder Teams.
- Vermeidung struktureller Kostenfallen. Architekturentscheidungen, die in 12-24 Monaten überproportional teuer werden würden, werden frühzeitig erkannt.
- Optionalität. Die Architektur erlaubt es, Cloud-Anbieter, Pricing-Modelle oder Workloads zu wechseln, ohne kompletten Neubau.
- Kulturwandel. Engineering-Teams treffen Tech-Entscheidungen mit Kostenbewusstsein als integralen Faktor.
Welche dieser Outcomes konkret erreichbar sind und in welcher Grössenordnung, das hängt stark von der Ausgangslage ab und ist Teil der Standortbestimmung im Mandat.
Welche Hebel die grösste Wirkung haben
Aus der Praxis kristallisieren sich vier Hebel mit überproportionaler Wirkung heraus:
- Workload-Architektur. Stateless vs. stateful, Event-driven vs. polling, batch vs. real-time, jede dieser Entscheidungen prägt die Kostenstruktur über Jahre.
- Datenarchitektur. Wo Daten liegen, wie sie repliziert und wie oft sie bewegt werden, ist oft der grösste versteckte Kostentreiber.
- Lifecycle-Management. Was nicht abgeschaltet wird, läuft. Was nicht reklassifiziert wird, liegt in der teuersten Speicherklasse.
- Engineering-Praktiken. Code-Effizienz, Caching-Strategien und Resource-Sharing wirken auf die Kostenbasis stärker als jedes Pricing-Verhandlungsergebnis.
Was nicht funktioniert
Drei Ansätze tauchen in fast jeder gescheiterten FinOps-Initiative auf:
- Sparen am Symptom. Reserved Instances ohne Workload-Stabilität sind Cashflow-Verlagerung, keine Einsparung.
- Tagging als Selbstzweck. Tags ohne organisatorische Konsequenzen erzeugen Reporting, aber keine Verhaltensänderung.
- Zentrale Cost-Police. Wenn ein FinOps-Team allein Entscheidungen trifft, ohne die Engineering-Teams einzubinden, entstehen Workarounds statt Optimierungen.
Was sinnvolle nächste Schritte sind
Vertiefende Perspektiven zu Cloud, FinOps und IT-Architektur finden sich in:
Verwandte Beiträge:
- FinOps, warum Cloud-Kosten eine Architekturfrage und keine Sparmassnahme sind
- Cloud-Architektur, sechs Prinzipien, die langfristig tragen
- Cloud-Governance, was in der Praxis tatsächlich funktioniert
- Konzeptionelle IT-Architektur, warum sie Strategie ist und nicht Technik
- BI-Reifegradmodell, wo die meisten Organisationen wirklich stehen
Für eine konkrete Standortbestimmung: unverbindliches Sparring-Gespräch.
Fragen & Antworten
Worauf zielt dieser Artikel ab?
Auf das WHAT, beobachtbare Outcomes, bewährte Prinzipien, ehrliche Einordnung. Nicht auf das HOW: Implementierungsdetails, Methodik und vertrauliche Mandantenarbeit gehören in den persönlichen Austausch.
Wie lassen sich die genannten Outcomes konkret erzielen?
Die konkrete Umsetzung hängt stark vom organisatorischen Kontext, der Ausgangsarchitektur und den Zielprioritäten ab. Sie ist Gegenstand der Mandatsarbeit und nicht eines öffentlich zugänglichen Beitrags. Eine erste Standortbestimmung ist im Erstgespräch unverbindlich möglich.
Welche Erfahrung steht hinter diesen Aussagen?
Über zwei Jahrzehnte Architektur- und Beratungspraxis in Business Intelligence, Cloud, FinOps und AI, über verschiedene Branchen, Organisationsgrössen und Reifegrade hinweg.
Welche Cloud-Anbieter werden abgedeckt?
Die Architektur-Prinzipien sind anbieterunabhängig. In der Praxis kommen AWS, Azure, GCP sowie Multi-Cloud-Konstellationen vor, die Wahl folgt der Strategie, nicht umgekehrt.
Wenn dieser Beitrag eine eigene Frage in Ihrer Organisation berührt hat, ist das Erstgespräch der nächste sinnvolle Schritt, unverbindlich, kostenlos, mit ehrlicher Einordnung statt Verkaufsdruck.