Die Cloud-Branche verzeichnete im Jahr 2024 einen starken Wachstumsschub. Die weltweiten Gesamtausgaben für Cloud-Dienste stiegen um über 20%, wobei die führenden Cloud-Computing-Anbieter Amazon, Microsoft und Google aus den USA mit 19%, 20% bzw. 35% einen bemerkenswerten Anstieg ihres Cloud-Geschäfts verzeichneten.
Das sind zwar rosige Aussichten, aber nicht alles ist eitel Sonnenschein. Ein Trend namens «Repatriierung» nimmt Fahrt auf: Mit steigenden Kosten, der Komplexität von Cloud-Umgebungen und enttäuschenden Leistungen bei umfangreichen Daten-Workloads konfrontiert, entscheiden sich manche Organisationen dazu, auf eine On-Premises-Infrastruktur zurückzukehren. Berichte über Pannen in der Cloud sowie Strafverfolgungsbehörden, die mit Hintertüren auf Daten zugreifen und die Ende-zu-Ende-Verschlüsselung aushebeln, tun ihr Übriges, um IT-Entscheidungstragende am Nutzen einer Cloud-Migration zweifeln zu lassen.
Damit sind wir bei der entscheidenden Frage angelangt: Wann sollte sich eine Organisation für eine Cloud-Lösung entscheiden oder bei einer On-Premises-Infrastruktur bleiben?
In vielen Situationen bietet die Datenverarbeitung in der Cloud tatsächlich Vorteile. Im Vergleich zu On-Premises-Infrastrukturen passt das Pay-as-you-go-Modell der Cloud besser zur Kostenstruktur vieler dynamischer, wachsender Unternehmen, die vorab nur begrenzte Investitionsmittel, aber dafür Potenzial für niedrigere Betriebskosten haben. Solche Dienste muss man jedoch unter strikter Einhaltung der FinOps-Grundsätze eng steuern, damit Kostenexplosionen ausbleiben (mehr zu den FinOps-Aspekten im Cloud-Betrieb bietet unser Experte Frederic Kottelat hier).
Cloud-Anbieter helfen den Kunden, dies proaktiv mit eingebauten Beobachtungs- und Warnmechanismen sowie mit technischen Massnahmen wie die API-Drosselung zu bewältigen; diese müssen jedoch korrekt konfiguriert sein. Dafür müssen Organisationen ihre Mitarbeitenden entsprechend vorbereiten und schulen: zum einen, damit sie das umfangreiche Angebot an vorgefertigten Tools und Diensten zur vollen Geltung bringen. Zum anderen, damit sie experimentieren und innovativ arbeiten können, ohne dass erhebliche Vorlaufkosten für Hardware, Netzwerk, Rechenzentrum oder Lizenzen anfallen. Aber auch das Upskilling sowie die organisatorischen Veränderungen erfordern eine gezielte Planung und Investition.
Ein weiterer, gerne übersehener Faktor bei der Vorbereitung auf die Cloud ist eine gründliche Schätzung der wiederkehrenden Infrastrukturkosten. Die Cloud-Anbieter stellen spezielle Kalkulatoren für ihre Plattform bereit, aber diese Tools sind mit einer breiten Palette an möglichen Konfigurationen ausgestattet. Um diese Tools effektiv einzusetzen, muss man die genauen Workload-Anforderungen an Service, Speicherung, Sicherheit oder den Netzwerkverkehr kennen. Sonst stimmen die tatsächlichen Kosten nach der Migration höchstwahrscheinlich nicht mit den vorab geschätzten Kosten überein – und sprengen schnell das veranschlagte Budget.
Die Pay-as-you-go-Optionen spielen in dieser Hinsicht eine wichtige ausgleichende Rolle, weil man damit nur für die Ressourcen zahlt, die man tatsächlich verbraucht. Für Prozesse, die zu bestimmten Zeiten Spitzenlasten erreichen oder nur sporadisch einen erhöhten Ressourcenhunger haben, ist dieses Preismodell der beste Weg, um Betriebskosten zu sparen.
Eine weitere Option ist Software as Service (SaaS), womit ein Dienst sich leicht skalieren lässt, wenn Flexibilität und Veränderungen gefragt sind. In diesem Fall erleichtern Cloud-Anbieter auch die Wartung und Upgrades für die Software, was den Arbeitsaufwand und die Kosten für interne technische Ressourcen verringert.
Darüber hinaus gewährleisten umfassende Optionen für die Notfallwiederherstellung, die auf mehreren verfügbaren Rechenzentren in verschiedenen geografischen Regionen basieren, eine hohe Verfügbarkeit und Datenredundanz. Das minimiert den Datenverlust im Falle unvorhergesehener Ereignisse.
Vom Standpunkt der Sicherheit bieten die meisten Cloud-Anbieter solide Rahmenbedingungen, einschliesslich Zugangskontrollen, Verschlüsselungsmechanismen, DDoS-Schutz und Tools, die bei der Compliance helfen. Insbesondere die US-Hyperscaler Microsoft, Amazon und Google bieten Compliance-Portale und Unterstützung für bekannte internationale Standards wie NIST CSF, PCI DSS, GDPR, SOC 2 und die ISO 27k-Familie.
Es ist jedoch wichtig, das Shared-Responsibility-Modell und die Richtlinien zu verstehen, die für die Compliance anzuwenden sind. Während Cloud-Provider spezielle Dienste anbieten, die Transparenz über die Sicherheitslage und die Sicherung der physischen Infrastruktur schaffen, sind die Kunden selbst für die Sicherung ihrer Daten, Arbeitslasten, Zugriffsrichtlinien und Konfigurationen verantwortlich. Dies wird häufig missverstanden und kann zu Sicherheitsvorfällen führen, die z.B. durch fehlkonfigurierte Speicher-Buckets und überprivilegierte Rollen im Identity- und Access-Management (IAM) entstehen.
Cloud-Anbieter haben begonnen, dieses Problem zu lösen, indem sie ihre Dienste standardmässig mit sicheren Konfigurationen bereitstellen. Beispielsweise ist AWS S3 seit 2020 von Haus aus mit privatem Zugriff konfiguriert, und auch Microsoft liefert seit Ende 2023 standardmässig Speicherkonten mit deaktiviertem öffentlichem Zugriff. Dennoch sind die Kunden weiterhin für die korrekte Konfiguration verantwortlich und können die Sicherheitseinstellungen leicht ändern (unser Sicherheitsexperte Salvatore Fagone wirft hier einen tiefergehenden Blick auf das Thema Sicherheit).
Und schliesslich bieten führende Cloud-Provider ein umfangreiches Ökosystem an einsatzbereiten Diensten. Selbst wenn eine benötigte Funktion nicht von einem nativen Dienst abgedeckt wird, sind von Drittanbietern vorgefertigte Integrationen zu externen Diensten verfügbar, wodurch wachsende und innovative Ökosysteme entstehen.
Für Branchen, die mit sensiblen Informationen umgehen, wie Finanzinstitute, Gesundheitsdienstleister, der Verteidigungssektor und Regierungsbehörden, ist dies von strategischer Bedeutung. Selbst das geringste Risiko, dass deren Daten ihren Schutz, ihre Vertraulichkeit und ihre operative Souveränität verlieren, muss ausgeräumt sein. Mit On-Premises-Umgebungen sind sie selbst in der Lage, die strengsten Zugriffskontrollen zu implementieren und Sicherheitsmassnahmen gemäss ihren eigenen organisatorischen Anforderungen zu konzipieren – und sie können sich sicher sein, dass Dritte nicht die Möglichkeit haben, ohne ungeteilte und ausdrückliche Zustimmung auf ihre Daten zuzugreifen oder sie zu verarbeiten.
Rechtliche und regulatorische Gründe untermauern dieses Argument. In Ländern mit modernen Compliance-Anforderungen bietet eine IT-Infrastruktur vor Ort in der Regel die direkteste Möglichkeit, Gesetze zur Datenaufbewahrung und zum Datenschutz zu erfüllen. Vor allem in Regionen wie der Schweiz und der EU beseitigt eine On-Premises-IT-Umgebung die Unklarheiten, die mit dem internationalen Datentransfer und komplizierten Compliance-Anforderungen einhergehen. Bei Cloud-Implementierungen von Einzelanbietern ist das nicht ohne Weiteres möglich.
So müssen beispielsweise kritische militärische IT-Infrastrukturen, in denen Personen, Geräte und Prozesse überprüft werden, in akkreditierten Einrichtungen und in speziellen taktischen Netzen verbleiben, die auch bei einer Zerstörung von allgemeinen Langstreckenfasern weiterhin funktionstüchtig sind. Ein weiteres Beispiel ist das Swiss Interbank Clearing (SIC), das auf einer hochsicheren, dedizierten Infrastruktur laufen muss, während Banking-Apps und SaaS-Lösungen, die mit dem SIC verbunden sind, in Schweizer Regionen in der Cloud gehostet werden dürfen, wenn sie FINMA-konform sind.
Auch Leistung und Zuverlässigkeit sind aufgrund von Latenzzeiten und hohem Durchsatz potenziell triftige Gründe für eine On-Premises-Implementierung. Es gibt einfach einige Arbeitslasten, die eine geringere Latenz (z.B. sofortige Zahlungsabwicklungen) oder garantierte Verfügbarkeit erfordern, ohne auf externe Netzwerkkomponenten angewiesen zu sein. Lösungen für die industrielle Automatisierung wollen eine minimale Latenzzeit; polizeiliche Notfallsysteme und die damit verbundene Datenanalyse verlangen Echtzeitverarbeitung mit garantierter Verfügbarkeit. Für diese Bereiche sind stabile Systeme innerhalb der eigenen Infrastruktur Pflicht.
Wirtschaftliche Gründe sind ebenfalls ein manchmal unterbewertetes Argument in der Diskussion über lokale Infrastrukturen. Obwohl Cloud-Dienste im Allgemeinen Flexibilität und Skalierbarkeit bieten, verursachen sie oft unerwartete Kosten. Dies kann mehrere Ursachen haben: einen variierenden Verbrauch der in den Diensten enthaltenen Ressourcen, die Skalierung des erforderlichen Speicherplatzes für die Dienste oder die anbieterspezifischen Gebührensätze. Umgekehrt kann eine On-Premises-Infrastruktur stabilisierend wirken und die Gesamtbetriebskosten im Laufe der Zeit senken, auch wenn dafür im Vorfeld hohe Investitionen notwendig sind. Insbesondere bei stabilen und hohen Arbeitslasten ist das häufig der Fall.
Schliesslich spielt der Begriff der strategischen Unabhängigkeit eine Rolle. Lokale Infrastrukturen schaffen Unabhängigkeit von den proprietären Technologien, Preismodellen und Roadmaps eines Cloud-Anbieters. Mit einer eigenen On-Premises-Architektur hat man das Design, die Entwicklung und die Weiterentwicklung der Organisation in der eigenen Hand.
Die On-Premises-IT behält also weiterhin ihre Relevanz; für Organisationen, die auf Kontrolle, Compliance, Leistung, Kostenkontrolle und Autonomie setzen, ist sie immer noch eine bewusste und rationale Geschäftsentscheidung.
|
«Technologieentscheidungen sind nicht nur technischer Natur. Es geht um Vertrauen, Kontrolle und die Realitäten des Tagesgeschäfts.» Salvatore Fagone |
|
Wenn man in der Sicherheitsbranche arbeitet, vor allem im IAM, lernt man schnell, dass es kein Patentrezept gibt. Jedes Konzept – Cloud, On-Premises oder eine Mischung der beiden – bringt Kompromisse mit sich. Was auf dem Papier sinnvoll erscheint, sieht oft ganz anders aus, wenn man sich mitten in der Umsetzung befindet.
In Sektoren wie dem Finanzwesen und im öffentlichen Dienst ist es nicht ungewöhnlich, dass Organisationen an On-Premises-Lösungen festhalten. Nicht, weil sie hinterherhinken, sondern weil sie sicher sein müssen, wo ihre Daten gespeichert sind und wer sie einsehen kann. Natürlich gibt es regulatorische Gründe, aber es geht auch um Verantwortlichkeit. Wenn etwas schief geht, wollen diese Organisationen genau sagen können, wo und warum es passiert ist.
Auf der anderen Seite ist in Branchen wie der Logistik oder dem Einzelhandel die Flexibilität der Cloud ein gewichtiger Vorteil. Die Mitarbeitenden sind unterwegs, die Systeme müssen sich schnell skalieren lassen, und Fernzugriff ist ein Muss. Mit der Cloud lässt sich das gut bewerkstelligen – und moderne IDaaS-Plattformen erleichtern zudem die Verwaltung von Benutzenden ohne grossen Infrastrukturaufwand.
Aber sind Cloud-Umgebungen von Natur aus anfälliger als On-Premises-Infrastrukturen?
Es stimmt, dass öffentliche Hyperscaler-Clouds aufgrund des potenziell grossen Datenschatzes mehr Aufmerksamkeit von Angreifern auf sich ziehen. Sie profitieren jedoch auch von weitaus umfangreicheren und professionelleren Sicherheitsmassnahmen als die meisten On-Premises-Umgebungen. Cloud-Anbieter beschäftigen grosse Teams von Sicherheitsfachkräften, betreiben rund um die Uhr Security Operations Centers (SOCs) und nehmen kontinuierlich Patches und Scans nach Schwachstellen vor – oft weit über das hinaus, was einzelne Organisationen zu stemmen fähig sind.
Können sich Hacker innerhalb einer Cloud bewegen, um auf Daten verschiedener Kunden zuzugreifen?
Im Prinzip nein. Cloud-Anbieter sorgen durch Virtualisierung, Netzwerksegmentierung und Schutzmassnahmen auf der Hardwareebene für eine strikte Isolierung der Kundendaten. AWS, Azure und Google Cloud implementieren beispielsweise mehrschichtige Sandboxing- und Zugriffskontrollen, um Querbewegungen zwischen Kunden zu verhindern. Es gibt Grenzfälle – in der Regel verursacht durch Fehlkonfigurationen von Kunden oder seltene Zero-Day-Schwachstellen –, aber erfolgreiche kundenübergreifende Angriffe sind extrem selten.
Gibt es in der Cloud Angriffsvektoren, die sich der Kontrolle des Kunden entziehen?
Ja. Während das Shared-Responsibility-Modell viele Kontrollen (z.B. Identität, Zugriff, Verschlüsselung, Konfiguration) in die Hände der Kunden legt, bleiben die Schutzmassnahmen auf der Infrastrukturebene (Hypervisor, physische Sicherheit, Isolierung auf der Hardwareebene) in der Verantwortung des Anbieters. Dies kann sowohl eine Stärke als auch eine Einschränkung sein: Man verlässt sich auf die Fähigkeiten des Anbieters – aber gibt auch einen Teil der Transparenz auf.
Ist die Aufteilung der Verantwortung ein Vorteil oder eher ein Nachteil?
Dies ist einer der meistdiskutierten Punkte. Das geteilte Modell kann ein grosser Vorteil sein: Man muss keine eigenen Rechenzentren unterhalten oder die Firmware auf der Hardwareebene patchen. Die Kehrseite ist jedoch, dass viele Kunden sich nicht im Klaren darüber sind, wo ihre Verantwortung beginnt und wo sie endet. Fehlkonfigurierte S3-Buckets, überprivilegierte Rollen und fehlende Verschlüsselungseinstellungen gehören zu den häufigsten Ursachen für Sicherheitsvorfälle in der Cloud – das sind keine Fehler der Cloud selbst, sondern in der Art ihrer Nutzung.
Cloud-Anbieter haben darauf reagiert, indem sie Sicherheitsvorgaben erzwingen und Tools für das Sicherheitslagen-Management bereitstellen (z.B. AWS Security Hub, Azure Defender), aber letztendlich bleibt die Verantwortung geteilt – und ist nicht ausgelagert.
Inzwischen haben sich hybride Modelle als die pragmatischste Wahl herausgestellt: Sensible Workloads bleiben vor Ort, während skalierbare und flexible Dienste in die Cloud verlagert werden. Die Herausforderung besteht darin, beide Welten sicher zu integrieren. Das IAM ist dabei von zentraler Bedeutung, da es für konsistente Richtlinien, Transparenz und Zugriffskontrolle in den verschiedenen Umgebungen sorgt.
Das Fazit?
Es gibt keine universell «richtige» Architektur. Die beste Lösung ist diejenige, die den heutigen Anforderungen einer Organisation gerecht wird und sich morgen mit ihr weiterentwickeln kann. Für die meisten bedeutet das ein bisschen von beidem – sowohl Cloud und als auch On-Prem. Und das ist nicht nur eine akzeptable Option – es ist in vielen Fällen der klügste Weg nach vorn.
|
«Control, cost, and clarity – the pillars of secure cloud decisions.» Frederic Kottelat |
|
Die Kosten sind häufig der ausschlaggebende Grund dafür, eine Rückkehr zu On-Premises-Ressourcen in Erwägung zu ziehen. Unsere Consultants beobachten einen Trend: die wachsende Bedeutung von FinOps bei der Verwaltung und Optimierung der Cloud-Kosten. Wie schneiden also Cloud- und On-Premises-Architekturen im Hinblick auf Finanzoperationen ab, insbesondere in einer KI-getriebenen Welt? Schauen wir uns das mal etwas genauer an.
Sind GPU-basierte Cloud-Instanzen eine Herausforderung für FinOps?
Absolut. In der KI-Ära sind GPU-intensive Workloads oft unverzichtbar, insbesondere beim Training grosser Modelle. Doch diese Leistung hat ihren Preis: Eine einzelne GPU-Instanz bei einem Cloud-Anbieter kann mit mehr als 20'000 CHF pro Monat zu Buche schlagen. Wenn Ihre Datenwissenschaftlerinnen und -wissenschaftler diese Ressourcen nur für ein paar Stunden oder Tage im Monat benötigen, ist es ein kostspieliger Fehler, sie ungenutzt zu lassen. Hier kommen FinOps-Verfahren wie die automatisierte Deprovisionierung und nutzungsbasierte Skalierung ins Spiel.
Was treibt neben der Rechenleistung die Cloud-Kosten?
Spezialisierte Tools und architektonische Entscheidungen. Sicherheitsdienste wie Web Application Firewalls, SIEMs und Posture-Management-Tools, aber auch KI/ML-Plattformen und Big-Data-Infrastrukturen wie Data Lakes. Diese Werkzeuge sind leistungsstark – und teuer.
Was sind die Kosten für den Betrieb spezialisierter Tools vor Ort?
Für die Installation, Konfiguration und Wartung von spezialisierten Tools ist hochqualifiziertes Personal vonnöten. In der Cloud geht die Einrichtung schneller, Upgrades erfolgen automatisch, und der Wartungsaufwand ist minimal. Der Nachteil ist jedoch, dass im Gegenzug für die Zeit- und Personalersparnis wahrscheinlich mehr pro Monat bezahlt werden muss.
Wirkt sich die Architektur auf die Cloud-Rechnung aus?
Mehr als den meisten bewusst ist. Gesetzliche Vorschriften und Compliance-Anforderungen sehen eine strikte Trennung der Umgebungen vor. Das kann z.B. bedeuten, dass man separate Kubernetes-Cluster für verschiedene Umgebungen (Dev, UAT, Pre-Prod und Prod) aufsetzen muss. Das ist sicher, aber auch kostspielig. Eine Möglichkeit, dieses Kostenproblem in den Griff zu bekommen, ist die Implementierung von Scale-Down-Strategien für ungenutzte Umgebungen. Compliance muss nicht eine Kostenexplosion bedeuten – sie erfordert lediglich eine durchdachte Gestaltung.
Das Fazit?
Die Cloud bietet Flexibilität, aber ohne FinOps-Disziplin wird diese Flexibilität zu einem finanziellen Risiko. Der beste Ansatz vereint Automatisierung, Architektur und Bewusstsein: Man muss wissen, was man verwendet, warum man es verwendet und wann man es abschalten kann.
Aus der Sicherheitsperspektive ist ein hybrider Ansatz zu empfehlen, der es ermöglicht, sensible Arbeitslasten vor Ort zu belassen und gleichzeitig die Cloud für Skalierbarkeit, Agilität und Innovation einzusetzen. Mit solchen gemischten Umgebungen sind zusätzliche Governance-Frameworks notwendig, z.B. ein Cloud Security Posture Management und eine Zero-Trust-Architektur, um Richtlinien konsistent durchzusetzen und eine effektive Bedrohungsabwehr zu gewährleisten.
Darüber hinaus müssen Organisationen ihre Anwendungen so priorisieren, dass Unterbrechungen minimiert werden. Für Organisationen, die in der «Repatriierung» feststecken, können mangelhafte Planung und eine fehlerhafte Ausführung ein vielversprechendes Element der Innovation in einen teuren Missgriff verwandeln.
Die Repatriierung aus der Cloud sollte nicht als Rückzug von der Modernisierung, sondern als strategische Korrektur verstanden werden. Organisationen mit einem gescheiterten Plan für die Cloud-Migration haben das Ausmass der damit verbundenen Herausforderungen möglicherweise noch nicht ganz erfasst. Oft liegt es daran, dass die Komplexität der Sicherheit unterschätzt wird, die Kosten nicht vorhersehbar sind oder ein Bedarf an massgeschneiderter Kontrolle besteht.
Zu den sicherheitsspezifischen Auslösern für eine Repatriierung gehören:
In den Berichten über Repatriierungen hört man jedoch häufig, dass der Plan für die Cloud-Migration zu voreilig erstellt und auf Systeme angewandt wurde, die nicht für das Cloud Computing geeignet oder bereit sind, weil sie nicht gut genug verstanden wurden. Bevor man also Arbeitslasten, Anwendungen oder Daten in die Cloud migriert, müssen Organisationen ihre Hausaufgaben machen und einige wichtige Fragen beantworten:
Auf diese zentralen Überlegungen folgen dann geschäfts- und anwendungsspezifische Fragen wie:
Eine Cloud-Journey ist ein mehrstufiger Prozess, der eine angemessene Analyse, die Entscheidung über eine vollständige (oder partielle) Cloud-Einführung und die Planung der erforderlichen Schritte umfasst. Es ist also nicht immer eine Abwägung zwischen On-Premises und Cloud – das Ergebnis kann ein hybrider Ansatz sein. Die ideale Verwendung eines solchen hybriden Ansatzes sowie seine Vor- und Nachteile werden wir in nicht allzu ferner Zukunft genauer beleuchten.
[snippet_article_cta id="blog_cloud_vs_on-prem_de"]